CUL DISCONNECTED

Begonnen von AndreasS, 17 Juli 2014, 22:48:52

Vorheriges Thema - Nächstes Thema

AndreasS

Hallo Zusammen,
seit gut zwei Monaten schlage ich mich jetzt mit dem Problem rum, dass meine CUL sich regelmäßig von meinem Raspberry pi verabschiedet. Das Problem tritt bevorzugt auf, wenn die CUL etwas senden soll. Bei meiner Fehlersuche bin ich natürlich auch schon über die Hinweise auf die etwas schwache Spannungsversorgung des rpi gestoßen und habe die CUL jetzt über einen USB-Hub mit eigenem Netzteil angeschlossen. Leider hat das das Problem auch nicht gelöst.
Ich bin inzwischen mit meinem Latein am Ende. Und wäre für ein paar gute Ideen dankbar.


In den FHEM-Logs sieht das ganze so aus:
2014.07.17 22:20:18 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2014.07.17 22:20:24 3: CUL0 disconected
2014.07.17 22:20:24 3: Setting CUL_0 baudrate to 9600
2014.07.17 22:20:24 1: /dev/ttyACM0 reappeared (CUL_0)
2014.07.17 22:20:24 4: CUL_send:  CUL_0V
2014.07.17 22:20:24 4: CUL_send:  CUL_0?
2014.07.17 22:20:24 3: CUL_0: Possible commands: BbCFiAZEGMKUYRTVWXefmltux


In 10-15% der Fälle erholt sich das ganze nicht von selbst, d.h. alles ab dem "reappeard" fehlt.

In /var/log/messages findet sich passend dazu die Abmeldung der CUL vom USB
Jul 17 22:20:18 pi kernel: [88946.292200] usb 1-1.3.4: USB disconnect, device number 24
Jul 17 22:20:19 pi kernel: [88946.558521] usb 1-1.3.4: new full-speed USB device number 25 using dwc_otg
Jul 17 22:20:19 pi kernel: [88946.692394] usb 1-1.3.4: New USB device found, idVendor=03eb, idProduct=204b
Jul 17 22:20:19 pi kernel: [88946.692433] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 17 22:20:19 pi kernel: [88946.692449] usb 1-1.3.4: Product: CUL868
Jul 17 22:20:19 pi kernel: [88946.692463] usb 1-1.3.4: Manufacturer: busware.de
Jul 17 22:20:19 pi kernel: [88946.696599] cdc_acm 1-1.3.4:1.0: ttyACM0: USB ACM device


FHEM und CULFW sind aktuell.

rudolfkoenig

Nicht alle USB-HUBs liefern ordentlich Strom, bzw. manche haben andere Probleme. Wenn das CUL auf einem "richtigen" Rechner auch nicht funktioniert, dann wuerde ich es an busware zurueckschicken. Sonst wuerde ich ein "ordentliches" RPi Netzteil besorgen.

Elektrolurch

Hallo,

ich hatte ein ähnliches Problem mit einem CUNO. Den konnte ich zwar nach dem disconnect anpingen, aber mich nicht auf den Port 2311 per telnet connecten.
Da der CUNO in einem Betriebsraum installiert ist, denke ich, dass es bei mir ev. ein thermisches Problem war.

Gruß

Elektrolurch
configDB und Windows befreite Zone!

Arek

#3
Hi,

ich habe genau das gleiche Problem im Cubietruck. Andere USB-Geräte (USB300, HM-USB-CFG, Cardreader) funktionieren, allerdings ist dies das einzige Gerät, das als ttyACM* aufgeführt wird. Anschluss am aktiven Hub brachte keine Besserung.
Ich habe testweise den CUL am RPI angeschlossen und da funktioniert er einwandfrei. Woran kann das liegen???
Hier die Logs:

2014.09.12 04:47:05 4: CUL_Parse: CUL A 0A 47 8002 2640E6 2569A8 0015 -63.5
2014.09.12 04:47:05 5: CUL dispatch A0A4780022640E62569A800::-63.5:CUL
2014.09.12 04:47:05 4: CUL_Parse: CUL A 0C 48 A241 2569A8 180886 0124000A -69
2014.09.12 04:47:05 5: CUL dispatch A0C48A2412569A8180886012400::-69:CUL
2014.09.12 04:47:05 5: CUL sending As0D4880021808862569A80101C800
2014.09.12 04:47:05 5: CUL 2569A8 dly:94ms
2014.09.12 04:47:06 4: CUL_send:  CULAs 0D 48 8002 180886 2569A8 0101C800
2014.09.12 04:47:06 3: data is {"deviceName": "WZ_Fenster","changes":"trigDst_180886:noConfig<|>contact:closed (to CUL)","type":"notify""source":"gcmsend_fhem","vibrate":"false"}
2014.09.12 04:47:06 5: CUL/RAW: /A0C48A2412569A818088601240009

2014.09.12 04:47:06 4: CUL_Parse: CUL A 0C 48 A241 2569A8 180886 01240009 -69.5
2014.09.12 04:47:06 5: CUL dispatch A0C48A2412569A8180886012400::-69.5:CUL
2014.09.12 04:47:06 5: CUL sending As0D4880021808862569A80101C800
2014.09.12 04:47:06 5: CUL 2569A8 dly:95ms
2014.09.12 04:47:06 4: CUL_send:  CULAs 0D 48 8002 180886 2569A8 0101C800
2014.09.12 04:47:08 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL)
2014.09.12 04:47:08 3: data is {"deviceName": "CUL","changes":"state:DISCONNECTED","type":"notify""source":"gcmsend_fhem","vibrate":"false"}
2014.09.12 04:47:09 3: Setting CUL baudrate to 38400
2014.09.12 04:47:09 1: /dev/ttyACM0 reappeared (CUL)
2014.09.12 04:47:10 4: CUL_send:  CULV     
2014.09.12 04:47:10 5: CUL/RAW (ReadAnswer): V 1.58 CUL868

2014.09.12 04:47:10 4: CUL_send:  CUL?     
2014.09.12 04:47:10 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C F i A Z E G M K R T V W X e f m l t u x

2014.09.12 04:47:10 3: CUL: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.09.12 04:47:10 4: CUL_send:  CULX2 1     
2014.09.12 04:47:10 4: CUL_send:  CULAr     
2014.09.12 04:47:10 4: CUL_send:  CULT0 1     
2014.09.12 04:47:10 5: CUL/RAW (ReadAnswer): 0000

2014.09.12 04:47:10 5: GOT CUL fhtid: 0000
2014.09.12 04:47:10 3: data is {"deviceName": "CUL","changes":"state:CONNECTED","type":"notify""source":"gcmsend_fhem","vibrate":"false"}
2014.09.12 04:47:13 5: CUL/RAW: /A0ECD84102640E60000000B60EA0C0018

2014.09.12 04:47:13 4: CUL_Parse: CUL A 0E CD 8410 2640E6 000000 0B60EA0C0018 -62
2014.09.12 04:47:13 5: CUL dispatch A0ECD84102640E60000000B60EA0C00::-62:CUL
2014.09.12 04:47:51 5: CUL/RAW: /A0C2E865A2615F5000000A0DF3613

2014.09.12 04:47:51 4: CUL_Parse: CUL A 0C 2E 865A 2615F5 000000 A0DF3613 -64.5
2014.09.12 04:47:51 5: CUL dispatch A0C2E865A2615F5000000A0DF36::-64.5:CUL
2014.09.12 04:48:04 5: CUL/RAW: /A0C5D865A26411A000000A0E93200

2014.09.12 04:48:04 4: CUL_Parse: CUL A 0C 5D 865A 26411A 000000 A0E93200 -74
2014.09.12 04:48:04 5: CUL dispatch A0C5D865A26411A000000A0E932::-74:CUL
2014.09.12 04:48:05 5: CUL/RAW: /A0C6C865A2640E600000060EA3215

2014.09.12 04:48:05 4: CUL_Parse: CUL A 0C 6C 865A 2640E6 000000 60EA3215 -63.5
2014.09.12 04:48:05 5: CUL dispatch A0C6C865A2640E600000060EA32::-63.5:CUL
2014.09.12 04:48:05 3: data is {"deviceName": "WZ_Heizung_Climate","changes":"controlMode2:0","type":"notify""source":"gcmsend_fhem","vibrate":"false"}
2014.09.12 04:48:11 5: CUL/RAW: /A0C2E84702615F500000000DF3612

2014.09.12 04:48:11 4: CUL_Parse: CUL A 0C 2E 8470 2615F5 000000 00DF3612 -65
2014.09.12 04:48:11 5: CUL dispatch A0C2E84702615F500000000DF36::-65:CUL
2014.09.12 04:48:19 5: CUL/RAW: /A0C5D847026411A00000000E932FF

2014.09.12 04:48:19 4: CUL_Parse: CUL A 0C 5D 8470 26411A 000000 00E932FF -74.5
2014.09.12 04:48:19 5: CUL dispatch A0C5D847026411A00000000E932::-74.5:CUL
2014.09.12 04:48:25 5: CUL/RAW: /A0C6C84702640E600000000EA3212

2014.09.12 04:48:25 4: CUL_Parse: CUL A 0C 6C 8470 2640E6 000000 00EA3212 -65
2014.09.12 04:48:25 5: CUL dispatch A0C6C84702640E600000000EA32::-65:CUL
2014.09.12 04:48:48 5: CUL/RAW: /A0C95865A2615EB000000A0E8331B

2014.09.12 04:48:48 4: CUL_Parse: CUL A 0C 95 865A 2615EB 000000 A0E8331B -60.5
2014.09.12 04:48:48 5: CUL dispatch A0C95865A2615EB000000A0E833::-60.5:CUL
2014.09.12 04:49:08 5: CUL/RAW: /A0C9584702615EB00000000E8331C

2014.09.12 04:49:08 4: CUL_Parse: CUL A 0C 95 8470 2615EB 000000 00E8331C -60
2014.09.12 04:49:08 5: CUL dispatch A0C9584702615EB00000000E833::-60:CUL
2014.09.12 04:49:20 3: data is {"deviceName": "WZ_Heizung_Thermostat","changes":"state:CMDs_pending","type":"notify""source":"gcmsend_fhem","vibrate":"false"}
2014.09.12 04:49:20 3: CUL_HM set WZ_Heizung_Climate getConfig
2014.09.12 04:49:20 5: CUL sending As0B05B0011808862640E60203
2014.09.12 04:49:20 4: CUL_send:  CULAs 0B 05 B001 180886 2640E6 0203
2014.09.12 04:49:22 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL)
2014.09.12 04:49:23 3: data is {"deviceName": "CUL","changes":"state:DISCONNECTED","type":"notify""source":"gcmsend_fhem","vibrate":"false"}
2014.09.12 04:49:24 3: Setting CUL baudrate to 38400
2014.09.12 04:49:24 1: /dev/ttyACM0 reappeared (CUL)
2014.09.12 04:49:24 4: CUL_send:  CULV     
2014.09.12 04:49:24 5: CUL/RAW (ReadAnswer): V 1.58 CUL868

2014.09.12 04:49:24 4: CUL_send:  CUL?     
2014.09.12 04:49:24 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C F i A Z E G M K R T V W X e f m l t u x

2014.09.12 04:49:24 3: CUL: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.09.12 04:49:24 4: CUL_send:  CULX2 1     
2014.09.12 04:49:24 4: CUL_send:  CULAr     
2014.09.12 04:49:24 4: CUL_send:  CULT0 1     
2014.09.12 04:49:24 5: CUL/RAW (ReadAnswer): 0000

2014.09.12 04:49:24 5: GOT CUL fhtid: 0000
2014.09.12 04:49:24 3: data is {"deviceName": "CUL","changes":"state:CONNECTED","type":"notify""source":"gcmsend_fhem","vibrate":"false"}
2014.09.12 04:49:26 5: CUL sending As0B05B0011808862640E60203
2014.09.12 04:49:26 4: CUL_send:  CULAs 0B 05 B001 180886 2640E6 0203
2014.09.12 04:49:28 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL)
2014.09.12 04:49:28 3: data is {"deviceName": "CUL","changes":"state:DISCONNECTED","type":"notify""source":"gcmsend_fhem","vibrate":"false"}
2014.09.12 04:49:29 3: Setting CUL baudrate to 38400
2014.09.12 04:49:29 1: /dev/ttyACM0 reappeared (CUL)
2014.09.12 04:49:29 4: CUL_send:  CULV     
2014.09.12 04:49:30 5: CUL/RAW (ReadAnswer): V 1.58 CUL868

2014.09.12 04:49:30 4: CUL_send:  CUL?     
2014.09.12 04:49:30 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C F i A Z E G M K R T V W X e f m l t u x

2014.09.12 04:49:30 3: CUL: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.09.12 04:49:30 4: CUL_send:  CULX2 1     
2014.09.12 04:49:30 4: CUL_send:  CULAr     
2014.09.12 04:49:30 4: CUL_send:  CULT0 1     
2014.09.12 04:49:30 5: CUL/RAW (ReadAnswer): 0000

2014.09.12 04:49:30 5: GOT CUL fhtid: 0000
2014.09.12 04:49:30 3: data is {"deviceName": "CUL","changes":"state:CONNECTED","type":"notify""source":"gcmsend_fhem","vibrate":"false"}
2014.09.12 04:49:30 3: data is {"deviceName": "WZ_Heizung_Thermostat","changes":"state:ResndFail","type":"notify""source":"gcmsend_fhem","vibrate":"false"}
2014.09.12 04:49:30 3: data is {"deviceName": "WZ_Heizung_Thermostat","changes":"RESPONSE TIMEOUT:eerList","type":"notify""source":"gcmsend_fhem","vibrate":"false"}


Sep 11 12:58:05 Home kernel: [212278.137054] usb 5-1: USB disconnect, device number 32
Sep 11 12:58:05 Home kernel: [212278.210576] ehci_irq: port change detect
Sep 11 12:58:05 Home kernel: [212278.546425] ehci_irq: port change detect
Sep 11 12:58:05 Home kernel: [212278.616469] The port change to OHCI now!
Sep 11 12:58:06 Home kernel: [212278.929334] usb 5-1: new full-speed USB device number 33 using sw-ohci
Sep 11 12:58:08 Home kernel: [212281.011007] ehci_irq: port change detect
Sep 11 12:58:08 Home kernel: [212281.358751] usb 5-1: device not accepting address 33, error -62
Sep 11 12:58:08 Home kernel: [212281.448922] hub 5-0:1.0: unable to enumerate USB device on port 1
Sep 11 12:58:09 Home kernel: [212281.836427] ehci_irq: port change detect
Sep 11 12:58:09 Home kernel: [212281.896489] The port change to OHCI now!
Sep 11 12:58:09 Home kernel: [212282.209301] usb 5-1: new full-speed USB device number 35 using sw-ohci
Sep 11 12:58:09 Home kernel: [212282.403354] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
Sep 11 12:58:15 Home kernel: [212288.017785] usb 5-1: USB disconnect, device number 35
Sep 11 12:58:15 Home kernel: [212288.091247] ehci_irq: port change detect
Sep 11 12:58:15 Home kernel: [212288.426404] ehci_irq: port change detect
Sep 11 12:58:15 Home kernel: [212288.486423] The port change to OHCI now!
Sep 11 12:58:16 Home kernel: [212288.799239] usb 5-1: new full-speed USB device number 36 using sw-ohci
Sep 11 12:58:16 Home kernel: [212288.990388] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
Sep 11 12:58:18 Home kernel: [212291.514140] usb 5-1: USB disconnect, device number 36
Sep 11 12:58:18 Home kernel: [212291.587654] ehci_irq: port change detect
Sep 11 12:58:19 Home kernel: [212291.926364] ehci_irq: port change detect
Sep 11 12:58:19 Home kernel: [212291.996388] The port change to OHCI now!
Sep 11 12:58:19 Home kernel: [212292.309346] usb 5-1: new full-speed USB device number 37 using sw-ohci
Sep 11 12:58:19 Home kernel: [212292.500650] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
Sep 11 12:59:38 Home kernel: [212371.272051] usb 5-1: USB disconnect, device number 37
Sep 11 12:59:38 Home kernel: [212371.345572] ehci_irq: port change detect
Sep 11 12:59:38 Home kernel: [212371.685860] ehci_irq: port change detect
Sep 11 12:59:38 Home kernel: [212371.745917] The port change to OHCI now!
Sep 11 12:59:39 Home kernel: [212372.058721] usb 5-1: new full-speed USB device number 38 using sw-ohci
Sep 11 12:59:39 Home kernel: [212372.250329] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
Sep 11 12:59:45 Home kernel: [212378.321729] usb 5-1: USB disconnect, device number 38
Sep 11 12:59:45 Home kernel: [212378.395215] ehci_irq: port change detect
Sep 11 12:59:45 Home kernel: [212378.725818] ehci_irq: port change detect
Sep 11 12:59:45 Home kernel: [212378.785867] The port change to OHCI now!
Sep 11 12:59:46 Home kernel: [212379.098674] usb 5-1: new full-speed USB device number 39 using sw-ohci
Sep 11 12:59:46 Home kernel: [212379.298709] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
Sep 11 12:59:49 Home kernel: [212381.898400] usb 5-1: USB disconnect, device number 39
Sep 11 12:59:49 Home kernel: [212381.971885] ehci_irq: port change detect
Sep 11 12:59:49 Home kernel: [212382.305789] ehci_irq: port change detect
Sep 11 12:59:49 Home kernel: [212382.375835] The port change to OHCI now!
Sep 11 12:59:49 Home kernel: [212382.688679] usb 5-1: new full-speed USB device number 40 using sw-ohci
Sep 11 12:59:50 Home kernel: [212382.890656] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
Sep 11 12:59:56 Home kernel: [212389.450942] usb 5-1: USB disconnect, device number 40
Sep 11 12:59:56 Home kernel: [212389.524448] ehci_irq: port change detect
Sep 11 12:59:57 Home kernel: [212389.855740] ehci_irq: port change detect
Sep 11 12:59:57 Home kernel: [212389.925835] The port change to OHCI now!
Sep 11 12:59:57 Home kernel: [212390.238651] usb 5-1: new full-speed USB device number 41 using sw-ohci
Sep 11 12:59:57 Home kernel: [212390.430680] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
Sep 11 13:00:00 Home kernel: [212393.172829] usb 5-1: USB disconnect, device number 41



Gruß Arek

Arek

Kann mir niemand helfen? Gibt es vielleicht verschiedene Treiber(versionen)? Kann man andere Treiber installieren oder die Treiber neuinstallieren?

dman

Ich habe ähnliche Symptome. Ich habe zwei CUL über HUB an einem Raspberry PI. Betroffen ist immer nur ein bestimmter CUL, der im homematic-mode betrieben wird. Offenbar immer nach einem Sendevorgang ist er dann irgendwann "disconnected". Manchmal hilft Ein-/Ausstecken, manchmal muss der RasPi komplett stromlos gemacht werden, um wieder zu connecten.

Ich hatte das vor einigen Wochen schon mal und vor ein paar Tagen wieder. Ich habe keine systematische Fehlersuche betrieben, sondern zunächst nur verschiedene Dinge probiert, was sich denn geändert haben könnte (schließlich lief das System vorher monatelang ohne Probleme). Wie auch immer, scheint das Problem mit einer neuen CUL.pm-Version zusammen zu hängen. Beides mal habe ich dann wieder die ältere Version eingespielt und dann lief es wieder. Vor ein paar Monaten, meine ich, wurde nach eine CUL.pm-Änderung relativ bald nochmal was geändert. Mit der dann neuen Version ging es dann auch wieder.

Da ich leider nicht sehr systematisch vorgegangen bin und der CUL auch wieder lief, habe ich mich im Forum noch nicht geäußert. Ich kann auch nicht die Hand ins Feuer legen, ob das obige tatsächlich ursächlich ist (etwas komisch finde ich das schon:). Vielleicht probierst Du das einfach auch mal, wenn nicht schon geschehen.

Arek

Hat denn niemand eine Idee? Kann man die Treiber irgendwie neuinstallieren? Gibt es verschiedene Versionen?

dman

Du hast schon gelesen, was ich geschrieben habe?

FHEMAN

#8
Ich habe seit etwa 2 Wochen das gleiche Problem!
Ich betreibe einen Cubie mit Igor Image, damit der Poweroff Button funktioniert noch acpi installiert. Sonst alles Standard.
Zeitlich kurz davor hatte ich mit einem Akku als Notstromversorung rumgespielt (d.h. nur angeschlossen) und temporär auch mal den USB Port der beiden angeschlossenen CUL und HMLAND getauscht.
@Arek: hast Du eine Lösung gefunden?
@d-man: Wie kann man eine ältere CUL.pm einspielen?

Folgende Infos zeigt mir die Konsole:
(http://i.imgur.com/ARtw9PR.jpg)
Folgende Meldungen erscheinen im Log:
2015.03.08 17:57:10 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL0)
2015.03.08 17:57:11 3: Setting CUL0 baudrate to 9600
2015.03.08 17:57:11 1: /dev/ttyACM0 reappeared (CUL0)
2015.03.08 17:57:11 3: CUL0: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.03.08 18:01:13 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL0)
2015.03.08 18:01:14 3: CUL_HM set Display.01 statusRequest
2015.03.08 18:01:14 3: Setting CUL0 baudrate to 9600
2015.03.08 18:01:14 1: /dev/ttyACM0 reappeared (CUL0)
2015.03.08 18:01:14 3: CUL0: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.03.08 18:04:54 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL0)
2015.03.08 18:04:55 3: CUL_HM set Rauchmelder.Flur statusRequest
2015.03.08 18:04:55 3: Setting CUL0 baudrate to 9600
2015.03.08 18:04:55 1: /dev/ttyACM0 reappeared (CUL0)
2015.03.08 18:04:55 3: CUL0: Possible commands: BbCFiAZEGMKUYRTVWXefmltux

Hat jemand eine Idee? Was heißt sw-ohci? Hat es was mit Stromsparfunktionen zu tun?
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

Steffenm

Hallo,

ich habe schon gedacht ich bin bescheuert. Habe auch das Problem mit dem nanoCUL. Hab auch schon neue Firmware geflasht aber immer noch die selben Probleme, mit dem Disconnect.
Fhem ist auch auf dem neusten Stand.

@d-man
Kann man deine alte CUL.pm mal bekommen um es zu testen. Oder wie komme ich an die alten Versionen.
Ab wann hat sich der Fehler denn eingeschlichen? ich habe mir erst vor ca. 3 Wochen einen nanoCul gebaut, sodass ich keine vergleich zu vorher habe.

Gruß
Steffen

bgewehr

Ich habe leider auch immer wieder sporadische disconnects am CUL868 im Homematic Mode am aktiven Hub am BananaPI. Wie kann ich bei der Fehlersuche helfen?
FritzBox 7590, Synology DS216+II mit Docker
Docker: FHEM mit hmlan, Homebridge, node-red, mosquitto, ems-collector für Buderus EMS mit AVR Net-IO
Gartenwasser über MQTT auf R/Pi A+
Volkszaehler.org auf R/Pi 2B mit Pi_Erweiterung
Raspberrymatic auf R/Pi 4B mit RPI-RF-MOD u. CUL868

mgernoth

Hallo,

das aktuelle culfw-Release stuerzt leider ab, wenn der Kanal im Homematic-Modus nicht innerhalb von 2s freigegeben wird, waehrend versucht wird zu senden. Dies fuehrt dann zu Disconnects.
Die Ursache ist meist ein durchdrehender Dauersender in der Umgebung (Rolladenaktoren scheinen besonders haeufig betroffen).

Die aktuelle culfw im SVN bricht den Versuch nach 1,5s ab und gibt eine Fehlermeldung (ERR:CCA -> Clear Channel Assessment) zurueck. Fhem wiederholt dann den Versuch noch 2 mal automatisch.

Gruss
  Michael

BlackStone

ist das evtl, ein Selbstbau CUL mit Arduino Nano v3 ?

denn die Arduino nano v3 Clone haben oft einen fiesen kleinen Bug, der mich auch schon gut nerven gekostet hat, denn der ftdi Chip, bzw. der Testpin vom selbigen muss auf Masse gezogen werden.
sonst steigt der Chip immer wieder aus, wenn auch unregelmäßig und scheinbar ohne Grund.

dazu einfach PIN 25 und 26 Brücken. http://www.opentilt.org/fixduino-800px.jpg

bei mir waren die Probleme damit weg.

Hollo

Zitat von: Elektrolurch am 18 Juli 2014, 08:35:36
...ich hatte ein ähnliches Problem mit einem CUNO. Den konnte ich zwar nach dem disconnect anpingen, aber mich nicht auf den Port 2311 per telnet connecten.
Da der CUNO in einem Betriebsraum installiert ist, denke ich, dass es bei mir ev. ein thermisches Problem war...

Habe seit einigen Wochen(?) ähnliche Probleme mit meinem HMLAN.
Lief quasi monatelang problemlos und verabschiedet sich nun in unregelmäßigen Abständen komplett.
Ich meine nicht sporadische disconnects wg. dem 30Sekunden-Ping; das ist was anderes.
Ist dann dauerhaft disconnected, läßt sich IMMER anpingen und per Software ansprechen, connected aber von selbst nicht wieder.
Manchmal hilft ein Restart, meist muss ich das Ding mehrfach für x Minuten stromlos machen.
Hab mir mittlerweile schon eine Funksteckdose dazwischen gehängt, und zudätzlich einen HM-CFG-USB als Fallback.
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

Elektrolurch

Hallo,

ich habe das Problem mit dem CUNO gefunden. Die Fritzbox war schuld. Sie hat eine Route zu einem vermeintlichen CUNO eingetragen (CUNO connected via 192.168.1.58), das war aber mein Internetradio. Daher konnte ich zwar pingen, aber der Port 2323 existierte natürlich nicht an der Squeezebox.
Tipp: Mal auf der FB nachsehen, wie der CUNO dort angeschlossen ist. Bei mir war das die Ursache für die sporadischen Totalausfälle. Wartet man lange genug, dann ist die Route auch auf der FB vergessen.

Elektrolurch
configDB und Windows befreite Zone!