CUL DISCONNECTED

AndreasS · 17 Juli 2014, 22:48:52

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:

Code Auswählen

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

Code Auswählen

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 · 18 Juli 2014, 08:05:59

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 · 18 Juli 2014, 08:35:36

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

Arek · 12 September 2014, 04:56:21

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:

Code Auswählen

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"}

Code Auswählen

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 · 17 September 2014, 09:47:06

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

dman · 17 September 2014, 13:20:29

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 · 23 September 2014, 22:50:34

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

dman · 24 September 2014, 11:29:28

Du hast schon gelesen, was ich geschrieben habe?

FHEMAN · 08 März 2015, 18:31:55

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:

Code Auswählen

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?

Steffenm · 23 März 2015, 14:56:40

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 · 17 August 2015, 12:37:28

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?

mgernoth · 25 August 2015, 09:39:55

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 · 25 August 2015, 12:40:40

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 · 25 August 2015, 12:52:36

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.

Elektrolurch · 25 August 2015, 14:29:08

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

bgewehr · 27 August 2015, 16:36:43

Zitat von: mgernoth am 25 August 2015, 09:39:55
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.

Kannst Du mir bitte die Download-Prozedur nennen?

Ich erhalte aktuell 1.65, ist das schon die hier erwähnte neue Version?

Commander111 · 03 September 2015, 22:19:30

Hallo,
ich habe sehr aufmerksam die hier veröffentlichten Beiträge gelesen, da ich seit ein paar Wochen disconnected Probleme mit meinem CUL am rPI habe. Mittlerweile habe ich auch alle Lösungsvorschläge ausprobiert. Zuletzt den Austausch der Stromversorgung am rPI.
Gibt es denn jemanden der eine Lösung des Problems gefunden hat und wie sieht diese aus?
Ich weiß mir selber keinen Rat mehr.

skeleton · 04 September 2015, 08:40:38

Hi

ich habe das Problem ebenfalls seit ein paar Tagen....
siehe
http://forum.fhem.de/index.php?action=post;topic=40668.0;last_msg=329087

und warte verzweifelt auf eine Lösung...

cheers
skeleton

mgernoth · 04 September 2015, 12:29:21

Hallo,

Zitat von: bgewehr am 27 August 2015, 16:36:43
Kannst Du mir bitte die Download-Prozedur nennen?

Habe mal eine neue Firmware für CUL und COC angehängt.

Zitat
Ich erhalte aktuell 1.65, ist das schon die hier erwähnte neue Version?

Nein, in der offiziellen 1.65 ist der Fix noch nicht drin. Die hier angehängte meldet sich aber auch als 1.65.

Viele Grüße
Michael

bgewehr · 04 September 2015, 13:04:35

Super, danke!

skeleton · 04 September 2015, 23:02:20

Hi,

eben Compiler, geflasht und das Problem ist immer noch da ....

So langsam macht sich Verzweiflung breit

hat irgendwer andere Ergebnisse erzielt ?

Cheers
skeleton

mgernoth · 05 September 2015, 11:59:31

Hi,

Zitat von: skeleton am 04 September 2015, 23:02:20
eben Compiler, geflasht und das Problem ist immer noch da ....

Immernoch disconnects oder funktioniert HM jetzt einfach nicht? Letzteres würde bedeuten, dass der Fix funktioniert hat (Logge am besten mal die Nachrichten, dann taucht evtl ERR:CCA im Log auf)...
Nachdem das bei Dir nach einem Stromausfall passiert ist: Hast Du Rolladenaktoren? Die werden manchmal bei einem Reboot zum Stoerfunker und niemand anderes kann mehr senden.

Viele Grüße
Michael

skeleton · 05 September 2015, 12:04:20

Hi,

nein das gleich Problem immer noch
2015.09.05 12:01:33 1: /dev/ttyACM0 reappeared (COC)
2015.09.05 12:01:33 3: COC: Possible commands: BbCFiAZEGMKUYRTVWXefmltux

Ich habe keine Rollandeaktoren.
Lediglich Heizkörper Thermostate.
Aussen Thermostate
Youless
und Hutschienen Schalter.

Alles Homatic nix spezielles

Auf der Telnet console ist auch nix ( für mich) zu sehen
em> get COC ccconf
COC ccconf => freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB

fhem> get COC raw T02
COC raw => No answer

Cheers und danke

skeleton · 05 September 2015, 12:12:17

Hier mal das Verhalten mit Loglevel 5

Code Auswählen


2015-09-05_12:10:14 COC Initialized
2015.09.05 12:10:14 5: Triggering COC (1 changes)
2015.09.05 12:10:14 5: Notify loop for COC CONNECTED
==> COC-2015.log <==
2015-09-05_12:10:14 COC CONNECTED
2015.09.05 12:10:15 4: CUL_Parse: COC A 0F 0E 8610 293B1B 000000 0A98BE0D2D1811 -65.5
2015.09.05 12:10:15 5: COC dispatch A0F0E8610293B1B0000000A98BE0D2D18::-65.5:COC
2015.09.05 12:10:23 4: CUL_Parse: COC A 0C 4A 8670 2F211A 000000 00C64703 -72.5
2015.09.05 12:10:23 5: COC dispatch A0C4A86702F211A00000000C647::-72.5:COC
2015.09.05 12:10:23 5: COC sending As094AA112F147112F211A
2015.09.05 12:10:23 4: CUL_send:  COCAs 09 4A A112 F14711 2F211A 
2015.09.05 12:10:25 1: /dev/ttyACM0 disconnected, waiting to reappear (COC)
2015.09.05 12:10:25 5: Triggering COC (1 changes)
2015.09.05 12:10:25 5: Notify loop for COC DISCONNECTED
==> COC-2015.log <==
2015-09-05_12:10:25 COC DISCONNECTED
2015.09.05 12:10:27 3: Setting COC serial parameters to 38400,8,N,1
2015.09.05 12:10:27 1: /dev/ttyACM0 reappeared (COC)
2015.09.05 12:10:27 4: CUL_send:  COCV      
2015.09.05 12:10:27 4: CUL_send:  COC?      
2015.09.05 12:10:27 3: COC: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2015.09.05 12:10:27 4: CUL_send:  COCX2 1     
2015.09.05 12:10:27 4: CUL_send:  COCAr      
2015.09.05 12:10:27 4: CUL_send:  COCT0 1     
2015.09.05 12:10:27 5: Triggering COC (1 changes)
2015.09.05 12:10:27 5: Notify loop for COC Initialized
==> COC-2015.log <==
2015-09-05_12:10:27 COC Initialized
2015.09.05 12:10:27 5: Triggering COC (1 changes)
2015.09.05 12:10:27 5: Notify loop for COC CONNECTED
==> COC-2015.log <==
2015-09-05_12:10:27 COC CONNECTED
2015.09.05 12:10:41 4: CUL_Parse: COC A 0F 05 8610 2B3A88 000000 0AA0BA0C6400FB -76.5
2015.09.05 12:10:41 5: COC dispatch A0F0586102B3A880000000AA0BA0C6400::-76.5:COC
2015.09.05 12:10:43 4: CUL_Parse: COC A 0F B0 8610 2E7056 000000 0A90D10D004005 -71.5
2015.09.05 12:10:43 5: COC dispatch A0FB086102E70560000000A90D10D0040::-71.5:COC
2015.09.05 12:11:00 4: CUL_Parse: COC A 0F EA 8610 2B39C2 000000 0AB0CE0C640004 -72
2015.09.05 12:11:00 5: COC dispatch A0FEA86102B39C20000000AB0CE0C6400::-72:COC

Kann ich sonst noch was liefern an Informationen das Helfen würde ?

mgernoth · 05 September 2015, 12:25:20

Hi,

Zitat von: skeleton am 05 September 2015, 12:12:17
Hier mal das Verhalten mit Loglevel 5

Code Auswählen Erweitern
2015.09.05 12:10:23 4: CUL_send: COCAs 09 4A A112 F14711 2F211A 2015.09.05 12:10:25 1: /dev/ttyACM0 disconnected, waiting to reappear (COC)

Hmm, das ist eigentlich genau die Stelle, die gefixed sein sollte...

Du hast selbstkompiliert und bist auf Revision 523?

Du könntest versuchen, den Timeout in clib/rf_asksin.h -> ASKSIN_WAIT_TICKS_CCA weiter zu reduzieren. 125 ist 1s.

Die einzig andere Stelle im TX-Pfad die sich verklemmen könnte ist, wenn der CC1101 nie aufhört zu senden. Das ist aber laut Datenblatt eigentlich nicht möglich...

Viele Grüße
Michael

skeleton · 05 September 2015, 12:41:24

Ja habe selber kompiliert und zwar die Version die hier im Threat hängt...

kann ich mal versuchen wird aber heute Abend werden....

skeleton · 05 September 2015, 13:16:22

Hi,

bist du sicher das dein Pfad korrekt ist ?

schauh mal

Code Auswählen


root@bananapi:/opt/SETUP-FHEM# grep -r ASKSIN culfw-1.*
culfw-1.55/docs/commandref.html:    <li> ASKSIN (aka BidCos(R))
culfw-1.55/Devices/CUL/CUL.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CUL/CUL.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CUL/CUL.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CUL/board.h:#  define HAS_ASKSIN
culfw-1.55/Devices/CUL/board.h:#  define HAS_ASKSIN
culfw-1.55/Devices/CUNO/CUNO.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CUNO/CUNO.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CUNO/CUNO.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CUNO/board.h:#define HAS_ASKSIN
culfw-1.55/Devices/COC/board.h:#define HAS_ASKSIN
culfw-1.55/Devices/COC/COC.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/COC/COC.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/COC/COC.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CUN/CUN.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CUN/CUN.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CUN/CUN.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CUN/board.h:#define HAS_ASKSIN
culfw-1.55/Devices/CUNO2/board.h:#define HAS_ASKSIN
culfw-1.55/Devices/CUNO2/CUNO2.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CUNO2/CUNO2.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CUNO2/CUNO2.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/AirLinked/board.h.RWE_PSS:#define HAS_ASKSIN
culfw-1.55/Devices/AirLinked/board.h.CSM:#define HAS_ASKSIN
culfw-1.55/Devices/AirLinked/board.h.zCSM:#define HAS_ASKSIN
culfw-1.55/Devices/AirLinked/board.h.HM-LC-Sw1-PI:#define HAS_ASKSIN
culfw-1.55/Devices/CUR/board.h:#define HAS_ASKSIN
culfw-1.55/Devices/zCSM/CSM.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/zCSM/CSM.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/zCSM/CSM.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/zCSM/board.h:#define HAS_ASKSIN
culfw-1.55/Devices/TuxRadio/CSM.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/TuxRadio/CSM.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/TuxRadio/CSM.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/TuxRadio/board.h://#define HAS_ASKSIN
culfw-1.55/Devices/TuxRadio2/CSM.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/TuxRadio2/CSM.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/TuxRadio2/CSM.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/TuxRadio2/board.h:#define HAS_ASKSIN
culfw-1.55/Devices/CSM/CSM.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CSM/CSM.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CSM/CSM.c:#ifdef HAS_ASKSIN
culfw-1.55/Devices/CSM/board.h:#define HAS_ASKSIN
culfw-1.55/clib/intertechno.c:#ifdef HAS_ASKSIN
culfw-1.55/clib/intertechno.c:	#ifdef HAS_ASKSIN
culfw-1.55/clib/intertechno.c:  	#ifdef HAS_ASKSIN
culfw-1.55/clib/intertechno.c:		#ifdef HAS_ASKSIN
culfw-1.55/clib/intertechno.c:		#ifdef HAS_ASKSIN
culfw-1.55/clib/rf_asksin.c:#ifdef HAS_ASKSIN
culfw-1.55/clib/rf_asksin.c:const uint8_t PROGMEM ASKSIN_CFG[50] = {
culfw-1.55/clib/rf_asksin.c:    if (pgm_read_byte( &ASKSIN_CFG[i] )>0x40)
culfw-1.55/clib/rf_asksin.c:    cc1100_writeReg( pgm_read_byte(&ASKSIN_CFG[i]),
culfw-1.55/clib/rf_asksin.c:                     pgm_read_byte(&ASKSIN_CFG[i+1]) );
culfw-1.55/clib/rf_asksin.c:  uint8_t enc[MAX_ASKSIN_MSG];
culfw-1.55/clib/rf_asksin.c:  uint8_t dec[MAX_ASKSIN_MSG];
culfw-1.55/clib/rf_asksin.c:    if (enc[0]>=MAX_ASKSIN_MSG)
culfw-1.55/clib/rf_asksin.c:         enc[0] = MAX_ASKSIN_MSG-1;
culfw-1.55/clib/rf_asksin.c:  uint8_t enc[MAX_ASKSIN_MSG];
culfw-1.55/clib/rf_asksin.c:  uint8_t dec[MAX_ASKSIN_MSG];
culfw-1.55/clib/rf_asksin.c:  uint8_t hblen = fromhex(in+1, dec, MAX_ASKSIN_MSG-1);
culfw-1.55/clib/rf_receive.c:#ifdef HAS_ASKSIN
culfw-1.55/clib/rf_asksin.h:#ifndef _RF_ASKSIN_H
culfw-1.55/clib/rf_asksin.h:#define _RF_ASKSIN_H
culfw-1.55/clib/rf_asksin.h:#define MAX_ASKSIN_MSG 30
Binary file culfw-1.61.tar matches
root@bananapi:/opt/SETUP-FHEM# grep -r ASKSIN_WAIT culfw-1.*
root@bananapi:/opt/SETUP-FHEM#

skeleton · 05 September 2015, 13:28:50

Hi,

sorry verges meinen letzten Post ich hab Mist gebaut vergangene Nacht und das falsche HEX File geflasht ...nun geht es ....

Super und danke für die Geduldige Hilfe....aber nach einer 60 Stunden Woche und einer späten Landung in Koeln sollte man nicht mehr mit der HW spielen....also sorry ...

skeleton · 05 September 2015, 13:32:59

aber dafür nun das

2015.09.05 13:31:15 2: COC: unknown message ERR:CCA
2015.09.05 13:31:31 2: COC: unknown message ERR:CCA
2015.09.05 13:31:33 2: COC: unknown message ERR:CCA
2015.09.05 13:31:39 2: COC: unknown message ERR:CCA

mgernoth · 05 September 2015, 14:08:54

Hi,

Zitat von: skeleton am 05 September 2015, 13:32:59
2015.09.05 13:31:15 2: COC: unknown message ERR:CCA

Ja, das war zu erwarten
Du hast einen Störsender, der ständig auf der Frequenz funkt, weswegen der CUL selbst nicht senden kann. Das führt jetzt zu dieser Meldung, davor zum Absturz. Nicht alle HM-Komponenten machen CCA, weswegen Du noch manche Meldungen von diesen Komponenten empfängst.

Also mal alle HM-Komponenten nacheinander deaktivieren und schauen, wer schuld ist (oder mit einem billigen rtlsdr direkt nach der Störquelle suchen).

Viele Grüße
Michael

bgewehr · 07 Oktober 2015, 16:36:00

Ich habe vor einiger Zeit das Update gemacht und seitdem keinen Disconnect mehr erlebt. Vielen Dank also für die gute Lösung!

SVLoneStar · 28 Oktober 2015, 22:16:19

Hallo - ich habe seit einigen Tagen auch das Problem, daß sich meine nanoCULs (nicht aber mein Busware CUL...?) mehrmals täglich disconnecten.
Wird die Änderung, die in den oben angefügten '1.65+' culfw-Firmwares enthalten ist, den Weg in die nächste Release der culfw auch für nanoCULs finden?

sasquuatch · 01 März 2016, 10:36:41

Zitat von: skeleton am 05 September 2015, 13:32:59
2015.09.05 13:31:39 2: COC: unknown message ERR:CCA

Zitat von: mgernoth am 05 September 2015, 14:08:54
Du hast einen Störsender, der ständig auf der Frequenz funkt, weswegen der CUL selbst nicht senden kann. Das führt jetzt zu dieser Meldung, davor zum Absturz. Nicht alle HM-Komponenten machen CCA, weswegen Du noch manche Meldungen von diesen Komponenten empfängst.

Also mal alle HM-Komponenten nacheinander deaktivieren und schauen, wer schuld ist (oder mit einem billigen rtlsdr direkt nach der Störquelle suchen).

mal eine frage, ich habe die selbe fehlermeldung und weiß ziemlich genau welcher HM (rollladen)aktor das ist. der hat mir schon zu schaffen gemacht auf meinem alten raspi mit COC. da hatte ich dann an fast allen aktoren missing ack stehen, da war das netzteil zu schwach. jetzt habe ich meine micro sd-karte in einem raspi 2 mit USB-CUL stecken und finde auf einmal neue fehlermeldungen, eben diese obige und so ziemlich jedes mal wenn ich den rollladen betätige, erhalte ich diese meldung. was kann ich da machen?
so langsam ist es anstrengend von einer Baustelle in die nächste zu rutschen

Code Auswählen

2016.03.01 10:10:58.687 3: CUL_HM set Dachfenster_Rollladen_Kueche 86
2016.03.01 10:12:25.548 3: CUL_HM set Dachfenster_Rollladen_Kueche 100
2016.03.01 10:12:28.833 2: CUL: unknown message ERR:CCA
2016.03.01 10:12:53.856 3: CUL_HM set Dachfenster_Rollladen_Kueche 64
2016.03.01 10:12:58.578 2: CUL: unknown message ERR:CCA
2016.03.01 10:17:48.451 3: CUL_HM set Dachfenster_Rollladen_Kueche 100
2016.03.01 10:17:52.963 2: CUL: unknown message ERR:CCA
2016.03.01 10:23:18.947 3: CUL_HM set Rollladen_links 83
2016.03.01 10:23:20.876 3: CUL_HM set Rollladen_rechts 83
2016.03.01 10:23:44.119 3: CUL_HM set Rollladen_links 100
2016.03.01 10:23:45.375 3: CUL_HM set Rollladen_rechts 100
2016.03.01 10:24:08.310 3: CUL_HM set Kaffeemaschine on

vielleicht hat der Rollladenaktor auch mit dem folgenden Fehler zu tun

Code Auswählen

2016.03.01 03:26:08.945 2: CUL: unknown message PLL0
und wenn ich den ERR:CCA abstellen kann, ist vielleicht auch der PLL0 fehler weg :s

martin5233 · 16 März 2016, 20:51:26

Hallo,

auch ich gehöre zu denjenigen, die von diesem Problem mit den Disconnects betroffen sind. Bei mir geht leider seit ca. 2 Monaten gar nichts mehr, vorher lief meine FHEM-Installation über ca. 2 Jahre recht problemlos. Ich setze einen Cubietruck mit FHEM 5.7 ein.
Um dem Problem auf die Spur zu kommen, habe ich diverse Dinge ausprobiert, die mich zu der Vermutung bringen, dass das Ganze etwas mit der USB-Kommunikation zu tun hat.
Ich habe den CUL bei mir an vier verschiedene Rechner angeschlossen, alle mit der identischen Linux-Kernel-Version 3.16, die derzeit in einem Debian-Stable verwendet wird.
Am Cubietruck und an einem Notebook mit Intel-Prozessor tritt das bekannte Problem auf, dass beim Senden von Kommandos sich der CUL abmeldet und anschließend wieder anmeldet. Auf zwei Desktop-Rechnern (einmal mit identischer Software-Konfiguration) tritt das Problem jedoch nicht auf. Änderungen der Linux-Kernel-Version bewirken nichts, d.h. weder mit älteren noch neueren Versionen ändert sich das beschriebene Verhalten auf allen getesteten Rechnern.
Ich habe auch die Spannungsversorgung an drei der vier Rechner nachgemessen, beim Cubietruck war die Spannung sogar am höchsten von allen dreien, daran kann es wohl also auch nicht liegen.

Meine Vermutung geht jetzt in die Richtung, dass hier irgendetwas bei der USB-Kommunikation schiefgeht, evtl. gibt es einen Timing-Zusammenhang. Ansonsten kann ich mir nicht erklären, warum das früher auf dem Cubietruck ging und heute nicht mehr. Ich habe mir mal das in der CUL-Firmware verwendete LUFA angeschaut, das für die USB-Kommunikation eingesetzt wird. In der aktuellen CUL-FW ist ein LUFA-Stand von 2009 drin, innerhalb des LUFA-Projektes sind zwischenzeitlich diverse Fehlerkorrekturen eingebaut worden. Leider sind die Änderungen im LUFA-Projekt so umfangreich, dass sich diese vermutlich nicht ohne Weiteres in die CUL-FW integrieren lassen.

Bringen all diese Beobachtungen einen von euch auf irgendwelche Ideen?

Martin

rudolfkoenig · 16 März 2016, 21:15:23

ZitatBringen all diese Beobachtungen einen von euch auf irgendwelche Ideen?

Durch welche Aenderung wurde das Problem ausgeloest?
Hilft ein culfw factory reset (e)?
Hast du die Moeglichkeit, ein weiteres CUL zu probieren?
Man koennte auch USB-debugging (usbmon/etc) porbieren, ich habe damit aber keine Erfahrung.

martin5233 · 20 März 2016, 12:10:00

Hallo Rudolph,

wodurch die Änderung ausgelöst wurde, weiß ich leider nicht. Ich hatte erst ein Linux-Kernel-Update im Verdacht, aber ich habe bereits diverse ältere Kernel installiert und auch einen aktuelleren, aber ohne Erfolg. In den Log-Files habe ich auch früher schon Meldungen bzgl. "Disconnects" gefunden, aber da hat es dann trotzdem beim zweiten oder dritten Anlauf funktioniert, sodass das nicht weiter auffiel. Das ist auch der Grund, warum ich Timing-Probleme vermute, die evtl. durch Alterungseffekte ausgelöst werden können.
Einen Factory-Reset habe ich bereits ausprobiert, einen anderen CUL habe ich leider nicht zur Verfügung. Was mich so irritiert, ist die Tatsache, dass das Problem an zwei Rechnern auftritt und an zwei anderen nicht.
usbmon habe ich ebenfalls ausprobiert: Ich habe dabei die Logs von einem funktionierendem System mit dem vom nicht funktionierendem Notebook verglichen. In der Phase des Ansteckens und Initialisierens sieht beides sehr ähnlich aus, aber wenn der CUL dann etwas senden soll, kommt via USB dann erst einmal keine Antwort zurück, erst nach ca. 2 Sekunden kommt dann ein neues Connect. Ich kann Dir gerne die Logs zukommen lassen, wenn Du damit etwas anfangen kannst.
Ich werde noch versuchen, die bisherige Erklärung auszuschließen, dass dort irgendwer den Funkkanal blockiert. Ich habe mir dazu einen USB-Stick für RTL-SDR besorgt, aber das noch nicht getestet. Ich halte das aber für extrem unwahrscheinlich, weil es ja auf einem unmittelbar neben den beiden anderen Rechnern stehenden Rechner problemlos funktioniert. Wenn eine Funkstörung vorläge, müsste die ja alle gleichmäßig betreffen.

Martin

martin5233 · 23 März 2016, 20:14:21

Hallo zusammen,

ich habe eben testweise mal einen USB-Hub (ohne eigene Stromversorgung) zwischen den CUL und den jeweiligen Rechner gehängt und siehe da: Jetzt funktioniert alles wie gewohnt. Mein Verdacht, dass das Problem mit den Disconnects an der USB-Verbindung liegt, scheint sich damit zu bestätigen. Das Ganze funktioniert sowohl an meinem Notebook, mit dem es vorher nicht klappte, als auch am Cubietruck. Jetzt lassen sich wieder sämtliche Geräte ohne irgendwelche Fehlermeldungen steuern.

Martin

bgewehr · 12 April 2016, 16:44:59

Ich hatte immer schon einen Hub dazwischen und habe trotzdem disconnects!

martin5233 · 13 April 2016, 18:54:14

Ich vermute mal, dass Hub nicht unbedingt gleich Hub ist. Wenn es stimmt, das die Timings vom CUL nicht ganz sauber sind, kann es ja durchaus sein, dass manche Hubs hier pingeliger als andere sind. Vielleicht kannst Du den Hub versuchsweise mal durch ein anderes Fabrikat ersetzen und gucken, ob sich etwas ändert.

Martin

bgewehr · 24 April 2016, 14:16:09

Gibt der CUL eigentlich ein event "CUL868:disconnected" raus, wenn er "stirbt"? Ich kann in meinen Logs keins finden, obwohl er regelmäßig auf disconnected springt.

rudolfkoenig · 24 April 2016, 18:31:44

Das kann man doch leicht testen: Event Monitor aufrufen, CUL abstecken bzw. wieder einstecken.
Es sei denn, mit "stirbt" meint man was anderes.

bgewehr · 24 April 2016, 20:20:30

Gut.

Ich erhalte

Code Auswählen


2016.04.24 19:08:24 1 : /dev/CUL868 disconnected, waiting to reappear (CUL868)
2016-04-24 19:08:24 CUL CUL868 DISCONNECTED

Dann CUL wieder angesteckt. Immer noch disconnected.

Was ich machen möchte, ist ein watchdog, der bei disconnect ein set CUL reopen absetzt, das klappt nämlich meistens.

Mein jetziger Watchdog ist ein

Code Auswählen


define CUL_watchdog watchdog CUL868:DISCONNECTED.* 00:00:10 CUL868:initialized set CUL868 reopen

Habt Ihr noch eine bessere Idee?
Das hat noch nicht wirklich etwas verhindert...

Elektrisch werde ich mal den HUB auswechseln, vielleicht hilft das. Allerdings habe ich den schon immer und es gab auch schon lange stabile Phasen.

rudolfkoenig · 24 April 2016, 20:28:20

ZitatDann CUL wieder angesteckt. Immer noch disconnected.

Ist unueblich, im Normalfall wird es nach spaetestens 5 Sekunden erkannt, und eingebunden, und ein watchdog ist eher stoerend.
Ich habe in ca 8 Jahren (mit "richtigen" CULs) solche Probleme nicht gehabt.

Elektrolurch · 28 April 2016, 12:20:24

Zitat:
« Antwort #42 am: 24 April 2016, 20:28:20 »
Zitat
Dann CUL wieder angesteckt. Immer noch disconnected.

Leider kann ich von einem ähnlichen Effekt berichten:
Wenn ich fhem auf einem Cubie neu starte (nur fhem) dann kann es so mit ca. 30 % iger Wahrscheinlichkeit passieren, dass die CULs, die über USB angeschlossen sind, von vorne herein "disconnected" sind und auch über einen "set CUL_0 reopen" Befehl nicht mehr ins Leben gerufen werden können. Dann kann ich nur noch den Cubie koplett neu starten.
Für mich schaut das so aus, als wäre der USB-Treiber von fehm nach dem Neustart von fhem immer noch aktiv und würde so einen reconnect gelegentlich verhindern.
Macht ja von der Prozeßlogik keinen Sinn, aber eine andere Erklärung fällt mir nicht ein. Zumal die Sache nur gelegentlich auftritt und nicht eindeutig reproduzierbar ist.

Elektrolurch

rudolfkoenig · 28 April 2016, 17:35:39

In so einem Fall muss aber im Log was stehen. Kannst du bitte pruefen, was?

det. · 28 April 2016, 19:26:52

Bei mir war dieser Fehler auf dem neu aufgesetztem NUC nach define CUL_0 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@960 xxxx weg.

Chriddy · 28 März 2018, 20:52:42

Super!
Wochenlang hatte ich das selbe Problem.
Alle vorhergehenden Lösungsvorschläge schlugen fehl.
Mit dieser Einstellung funktioniert es wie durch Zauberhand.
In einem anderen Beitrag habe ich jedoch gelesen, dass die Änderung der Baudrate keinen Einfluß hat, da es sich nicht um eine reelle serielle Schnittstelle handelt.

CUL DISCONNECTED

AndreasS

dman

dman

Steffenm

martin5233

martin5233

martin5233

martin5233