[gelöst] CUL HM kommt aus dem Tritt; Disconnect nach fast jedem Befehl

[kpwg]

Hallo Forum,

nachdem ich mir endlich Homematic "gegönnt" habe, beginnen auch schon die Problemchen, mit denen ich so nicht gerechnet hatte.

Konfiguration: RasPi, FHEM aktuell, culfw 1.58, testweise ausschließlich originaler CUL am RasPi.

Problem: Nachdem ich einen Befehl von der Fernbedienung oder dem Kontaktmodul erhalte, kommt der CUL aus dem Tritt und macht (meist) ein Reconnect. Das Ganze fällt so kaum auf; wenn jedoch mehrere Tasten hintereinander gedrückt werden, geht das schief, da die Zeit des Reconnect zwischen zwei und ziemlich vielen Sekunden liegt.

Auszug Logfile mit verbose 5:

Code Auswählen Erweitern


2014.06.04 20:38:47 5: CUL/RAW: /A0B43A24025470BF1103401390B

2014.06.04 20:38:47 4: CUL_Parse: CUL_HM A 0B 43 A240 25470B F11034 01390B -68.5
2014.06.04 20:38:47 5: CUL_HM dispatch A0B43A24025470BF110340139::-68.5:CUL_HM
2014.06.04 20:38:47 5: CUL_HM sending As0A438002F1103425470B00
2014.06.04 20:38:47 5: CUL 25470B dly:86ms
2014.06.04 20:38:47 4: CUL_send:  CUL_HMAs 0A 43 8002 F11034 25470B 00
2014.06.04 20:38:48 5: CUL/RAW: /A0B44A24025470BF110340139FA

2014.06.04 20:38:48 4: CUL_Parse: CUL_HM A 0B 44 A240 25470B F11034 0139FA -77
2014.06.04 20:38:48 5: CUL_HM dispatch A0B44A24025470BF110340139::-77:CUL_HM
2014.06.04 20:38:48 5: CUL_HM sending As0A448002F1103425470B00
2014.06.04 20:38:48 5: CUL 25470B dly:87ms
2014.06.04 20:38:48 4: CUL_send:  CUL_HMAs 0A 44 8002 F11034 25470B 00
2014.06.04 20:38:50 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_HM)
2014.06.04 20:38:55 3: Setting CUL_HM baudrate to 38400
2014.06.04 20:38:55 1: /dev/ttyACM0 reappeared (CUL_HM)
2014.06.04 20:38:55 4: CUL_send:  CUL_HMV     
2014.06.04 20:38:55 5: CUL/RAW (ReadAnswer): V 1.58 CUL868

2014.06.04 20:38:55 4: CUL_send:  CUL_HM?     
2014.06.04 20:38:55 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.06.04 20:38:55 3: CUL_HM: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.06.04 20:38:55 4: CUL_send:  CUL_HMX2 1     
2014.06.04 20:38:55 4: CUL_send:  CUL_HMAr     
2014.06.04 20:38:55 4: CUL_send:  CUL_HMT0 1     
2014.06.04 20:38:55 5: CUL/RAW (ReadAnswer): 2345

2014.06.04 20:38:55 5: GOT CUL fhtid: 2345
2014.06.04 20:39:30 5: CUL/RAW: /A0B45A24025470BF11034023038

2014.06.04 20:39:30 4: CUL_Parse: CUL_HM A 0B 45 A240 25470B F11034 023038 -46
2014.06.04 20:39:30 5: CUL_HM dispatch A0B45A24025470BF110340230::-46:CUL_HM
2014.06.04 20:39:30 5: CUL_HM sending As0A458002F1103425470B00
2014.06.04 20:39:30 5: CUL 25470B dly:86ms
2014.06.04 20:39:30 4: CUL_send:  CUL_HMAs 0A 45 8002 F11034 25470B 00
2014.06.04 20:39:31 5: CUL/RAW: /A0B46A24025470BF11034023037

2014.06.04 20:39:31 4: CUL_Parse: CUL_HM A 0B 46 A240 25470B F11034 023037 -46.5
2014.06.04 20:39:31 5: CUL_HM dispatch A0B46A24025470BF110340230::-46.5:CUL_HM
2014.06.04 20:39:31 5: CUL_HM sending As0A468002F1103425470B00
2014.06.04 20:39:31 5: CUL 25470B dly:86ms
2014.06.04 20:39:31 4: CUL_send:  CUL_HMAs 0A 46 8002 F11034 25470B 00
2014.06.04 20:39:56 5: CUL/RAW: /A0B47A24025470BF11034023115

2014.06.04 20:39:56 4: CUL_Parse: CUL_HM A 0B 47 A240 25470B F11034 023115 -63.5
2014.06.04 20:39:56 5: CUL_HM dispatch A0B47A24025470BF110340231::-63.5:CUL_HM
2014.06.04 20:39:56 5: CUL_HM sending As0A478002F1103425470B00
2014.06.04 20:39:56 5: CUL 25470B dly:86ms
2014.06.04 20:39:56 4: CUL_send:  CUL_HMAs 0A 47 8002 F11034 25470B 00
2014.06.04 20:39:57 5: CUL/RAW: /A0B48A24025470BF11034023113

2014.06.04 20:39:57 4: CUL_Parse: CUL_HM A 0B 48 A240 25470B F11034 023113 -64.5
2014.06.04 20:39:57 5: CUL_HM dispatch A0B48A24025470BF110340231::-64.5:CUL_HM
2014.06.04 20:39:57 5: CUL_HM sending As0A488002F1103425470B00
2014.06.04 20:39:57 5: CUL 25470B dly:86ms
2014.06.04 20:39:57 4: CUL_send:  CUL_HMAs 0A 48 8002 F11034 25470B 00
2014.06.04 20:39:59 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_HM)
2014.06.04 20:40:00 3: Setting CUL_HM baudrate to 38400
2014.06.04 20:40:00 1: /dev/ttyACM0 reappeared (CUL_HM)
2014.06.04 20:40:00 4: CUL_send:  CUL_HMV     
2014.06.04 20:40:00 5: CUL/RAW (ReadAnswer): V 1.58 CUL868

2014.06.04 20:40:00 4: CUL_send:  CUL_HM?     
2014.06.04 20:40:00 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.06.04 20:40:00 3: CUL_HM: Possible commands: BCFiAZEGMKRTVWXefmltux
2014.06.04 20:40:00 4: CUL_send:  CUL_HMX2 1     
2014.06.04 20:40:00 4: CUL_send:  CUL_HMAr     
2014.06.04 20:40:00 4: CUL_send:  CUL_HMT0 1     
2014.06.04 20:40:00 5: CUL/RAW (ReadAnswer): 2345

2014.06.04 20:40:00 5: GOT CUL fhtid: 2345

Wie gesagt, ein Befehl klappt immer. Mehrere gelegentlich, meist jedoch nicht. Mir fiel das erst so richtig auf, als ich den CUL-Reconnects mir bekannten Zeiten zuordnen konnte.

Edit 5.6.14: das Update brachte keine wirkliche Verbesserung. ein paar Tastendrücke bzw. Auslösungen funktionierne oft, dann "stirbt" aber die Verbindung zum CUL.

Hat wer eine Idee, wie ich dem Problem auf die Schliche komme?

Viele Grüße, Ricardo

[kpwg]

Nachtrag: Auch mit einem anderen CUL funktioniert es nicht besser, beide CUL sind jedoch mit FS20 fehlerfrei. 

[martinp876]

Der Fehler scheint in der CUL zu liegen, wenn man mehrere messages sendet - oder parallel gesendet und empfangen werden muss. Ich habe das noch nicht beobachtet und auch nicht davon gehört. Ob es etwas mit der USB schnittstelle zu tun hat kann ich nicht ausschliessen.
sorry - wenig hilfe

[topfi]

Ich nutze den CUL zwar nicht für Homematic, habe aber mit der CUL-FW 1.58 nur Ärger gehabt: Disconnects, schlechtere Feldstärke und und nicht geschaltete Dosen.  Ich habe es zweimal mit der 1.58 probiert und immer wieder auf 1.55 zurückgeflasht. Damit läuft alles stabil.

Aber wie gesagt: kein Homematic-Mode. Du kannst ja mal testweise die alte FW probieren.

Ansonsten der übliche Verdächtige: Stromversorgung. Spendiere doch dem CUL mal einen eigenen Hub mit Stromversorgung.

[kpwg]

sorry - wenig hilfe

Egal, Martin. Ich merke, das ich vielleicht noch genauer den Fehler lokalisieren und darstellen müsste, um Hilfreicheres zu abzuliefern. Manchmal weiß man einfach nicht, wie das Problem für die Wissenden verständlich darstellbar sein könnte 

Topfi, das werde ich testen. Habe ja auch noch mein Testsystem hier, wo ich das- ohne WAF-Einbußen- durchspielen kann. Noch macht hier HM nur die Klingelsignalerkennung und eine kleine Wohnzimmerfernbedienung.

Viele Grüße und Vielen Dank schon mal, Ricardo

ps: habe vorab ein wenig den USB Treiber des RasPi in Verdacht.

[kpwg]

Bin ein wenig weiter: Der selbe CUL, selbe Config, selbes gepairtes Gerät funktioniert am Testsystem einwandfrei und auch mit Stress (wildes Tastendrücken auf der Fernbedienung, das dem Eventmonitor ganz komisch wird  ) )gab es nicht einen Aussetzer. CUL zurück gesteckt, einmal (!) die Fernbedienung betätigt, DISCONNECT, sofortiger RECONNECT. Habe mal zwangsweise im RasPi auf USB1.1 gestellt, was aber auch nichts verbesserte.

Ich kann somit vorerst den CUL und seine 1.58er Software ausschließen. Neuer Ansatz: USB-Hub mit externer Stromversorgung. Vielleicht ist da ein Problem im RasPi? Welchen Strom nimmt ein CUL im Sendefall auf? Doch keine -zig Milliampere!

dmesg sagt auch nicht viel:

Code Auswählen Erweitern

[   28.607268] Adding 102396k swap on /var/swap.  Priority:-1 extents:2 across:507900k SS
[   67.463877] usb 1-1.3: USB disconnect, device number 5
[   67.785854] usb 1-1.3: new full-speed USB device number 8 using dwc_otg
[   67.891182] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=204b
[   67.891211] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   67.891227] usb 1-1.3: Product: CUL868
[   67.891240] usb 1-1.3: Manufacturer: busware.de
[   67.897469] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
root@raspi-fhem:~#

[Mr. P]

Hej Ricardo,

soweit ich weiß, ist der Raspberry recht heikel bei Stromschwankungen. Ein gutes Netzteil ist daher recht wichtig.
Hab an meinem Raspberry einen COC drauf gesteckt und einen CUL am laufen, beides ohne Probleme. Dem Raspberry hab ich allerdings ein 2A-Netzteil spendiert, das auch mit kurzfristigen Spitzen gut klar kommt.

Versuch doch einmal, die Spannung am Raspberry zu messen. Zuerst im Idle, dann unter Last.
Der RPi hat zwei Meßpunkte. TP1 und TP2. Am ersten liegen die 5V, am TP2 ist GND. Während der Tests sollte die Spannung nie unter 4,7V sinken, da er ab dem Zeitpunkt anfängt, unzuverlässig zu arbeiten.
Wenn du den Raspberry übertaktet hast, kannst du auch hier versuchen, diese einmal wieder zu deaktivieren, um sie als Fehlerquelle auszuschließen.

[kpwg]

Mr. P, das war die richtige Spur! Habe nochmals vor der anstehenden Messung den USB-Standfuß gegen ein anderes Modell getauscht und es funktioniert. Wer denkt denn an sowas...  Zu erkennen ist an dem Fuß nix, jedoch scheint die Buchse nicht ganz maßhaltig zu sein.

Jedenfalls funktioniert es nun einwandfrei und ließ sich trotz aller Mühen nicht mehr aus dem Tritt bringen. Habe auch den Eindruck, das die HM-Pakete nun im Event-Monitor viel zeitnaher kommen. Aber das kann auch Einbildung sein- HM ist ja sowieso sehr flott unterwegs 

Vielen Dank und Viele Grüße, Ricardo