CUNO im CUL mode - lethargisches Antwortverhalten führt zu MISSING_ACKs

[rene]

Hallo,

von Zeit zu Zeit (zwischen 2 und 14 Tagen) fängt FHEM an, konstant MISSING_ACKs zu produzieren. Ich hab das Verhalten mittlerweile bis auf die Connection zum CUNO (im CUL mode) eingegrenzt. Zum einen führt ein anschließender FHEM Neustart zu einem kompletten Konnektiviätsverlust mit dem CUNO/CUL, zum anderen kann man dann das lethargische Verhalten auch in einer screen Session selbst nachvollziehen. In dem Moment scheint es dann so, als ob die Antwort vom CUNO nicht direkt auf das ENTER folgt, sondern erst auf einen nachfolgenden Tastendruck.

Beispiel:

Code Auswählen Erweitern


V Enter
(keine Reaktion)
V (ohne Enter)
Antwort: V 1.57 CUNO868

1 Enter
(keine Reaktion)
2 (ohne Enter)
Antwort: ? (1 is unknown) Use one of m B C F Z i A I G M R T V W X O e f l t u H x E c q
3 Enter
4 (ohne Enter)
Antwort ? (23 is unknown) Use one of m B C F Z i A I G M R T V W X O e f l t u H x E c q


Das ist auch der Grund, warum FHEM den CUNO / CUL nicht initialisiert beim nächsten Start. Siehe Logauszug:

Code Auswählen Erweitern


2014.03.25 20:13:06.744 3: Opening CUNO device /dev/ttyUSB0
2014.03.25 20:13:06.840 3: Setting CUNO baudrate to 38400
2014.03.25 20:13:06.843 3: CUNO device opened
2014.03.25 20:13:06.943 5: SW: V
2014.03.25 20:13:09.957 5: SW: V
2014.03.25 20:13:09.968 5: CUL/RAW (ReadAnswer): V 1.57 CUNO868^M

2014.03.25 20:13:09.969 5: SW: ?
2014.03.25 20:13:09.980 5: CUL/RAW (ReadAnswer): V 1.57 CUNO868^M

2014.03.25 20:13:09.980 4: CUL_Parse: CUNO V 1.57 CUNO868^M

2014.03.25 20:13:09.981 5: Triggering CUNO (1 changes)
2014.03.25 20:13:09.982 5: Notify loop for CUNO UNKNOWNCODE V 1.57 CUNO868^M

2014.03.25 20:13:09.983 4: eventTypes: CUL CUNO UNKNOWNCODE V 1.57 CUNO868^M
-> UNKNOWNCODE V .* CUNO868^M

2014.03.25 20:13:09.984 2: CUNO: unknown message V 1.57 CUNO868^M

2014.03.25 20:13:12.988 1: /dev/ttyUSB0 disconnected, waiting to reappear
2014.03.25 20:13:12.990 5: Triggering CUNO (1 changes)
2014.03.25 20:13:12.990 5: Notify loop for CUNO DISCONNECTED
2014.03.25 20:13:12.992 4: eventTypes: CUL CUNO DISCONNECTED -> DISCONNECTED
2014.03.25 20:13:12.993 3: CUNO: Possible commands: Noanswer
2014.03.25 20:13:12.993 5: SW: X21
2014.03.25 20:13:13.004 5: SW: T01
2014.03.25 20:13:13.014 1: Cannot init /dev/ttyUSB0, ignoring it


Bisher musste es dann immer ein Neustart des CUNO richten. Heute bei der Analyse mit screen ist nach einem Screen terminate und anschließender neuer screen Session plötzlich wieder normales Verhalten in der Session aufgetreten und auch der FHEM Neustart lief ohne Beanstandung genau wie nach einen CUNO Neustart wieder durch.

Code Auswählen Erweitern


2014.03.25 20:18:30.411 3: Opening CUNO device /dev/ttyUSB0
2014.03.25 20:18:30.462 3: Setting CUNO baudrate to 38400
2014.03.25 20:18:30.465 3: CUNO device opened
2014.03.25 20:18:30.566 5: SW: V
2014.03.25 20:18:30.577 5: CUL/RAW (ReadAnswer): V 1.57 CUNO868^M

2014.03.25 20:18:30.577 5: SW: ?
2014.03.25 20:18:30.602 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of m B C F Z i A I G M R T V W X O e f l t u H x E c q^M

2014.03.25 20:18:30.603 3: CUNO: Possible commands: mBCFZiAIGMRTVWXOefltuHxEcq
2014.03.25 20:18:30.603 5: SW: X21
2014.03.25 20:18:30.613 5: SW: T01


Da ich nun schon unglücklich mit dem CUNO bin, weil ich ihn wegen Timingproblemen im CUL mode fahren muss, stört es mich nun umsomehr, dass dieses Verhalten zu häufig zu manuellen Neustarts und damit hoher Maintenance führt. Ich würde also gern wenigsten den CUL mode stabil zum Laufen bekommen wollen, wenn es schon im Netzwerkmode gar nicht geht.

Jemand eine Idee, woher das kommen mag?

Vielen Dank schonmal.
René

[rudolfkoenig]

Hilft eine reboot der CUNO per Kommando (B00) ? Wenn ja, dann koenntest du das per at als workaround einmal taeglich durchfuehren.

Sonst koennte man durch weglassen unbenoetigter Features in Firmware das Problem lokalisieren. Dazu kann man in culfw/Devices/CUNO[2]/board.h sowas wie HAS_ETHERNET, HAS_ONEWIRE, etc auskommentieren.

[rene]

Hi Rudi,

wie immer der Hilfsbereite hier. Dank dir dafür.

Also B00 im screen reagiert überhaupt nicht. Allerdings tut es das auch nach einem Hardware Restart nicht. Auch "set CUNO raw B00" scheint offenbar gar nichts zu tun.

Letzte Nacht hat sich FHEM und der CUNO2 zu meinem Leidweisen gleich komplett in die Untätigkeit abgemeldet. STATE vom _Clima Channel blieb in "set ..." hängen, das Thermostat auf "CMDs pending" die Heizkörperthermostate hatten auch nicht geacked und FHEM hat das noch nichtmal mit MISSING_ACKS irgendwann quittiert, woraufhin das Monitoring folglich nicht anspring und der Raum nun knapp 24h fröhlich für die Katz geheizt wurde.

Sukzessive Features abschalten zieh ich mal in Betracht. Ich muss aber gestehen, dass ich für das Gratis FHEM zwar sehr gern Beta Tester spiele und dafür auch Zeit investiere, für den verhältnismäßig teuren CUNO2 bei der Unterstützungsmotivationslage von tostmann (siehe Ethernet Timing Problem) gerade etwas zögere. Andererseits wäre das nun wieder nicht fair denen gegenüber, die hier aktiv helfen, also werde ich wohl etwas Zeit investieren.

Ich fang dann erstmal mit Version 1.58 an, schalte dann ETHERNET ab (und lege 50% des Gerätewertes einfach lahm ), IRTX brauch ich auch nicht, ebenso wie ONE_WIRE. Ich werde den Stand und die Resultate dann hier dokumentieren.

VG
René

[rene]

So, CUNO2 auf V 1.58 upgegraded:

Nach Anstöpseln im FHEM Log

Code Auswählen Erweitern


2014.04.05 22:12:06.572 3: Setting CUNO baudrate to 38400
2014.04.05 22:12:06.576 1: /dev/ttyUSB0 reappeared (CUNO)
2014.04.05 22:12:06.677 4: CUL_send:  CUNOV
2014.04.05 22:12:06.688 5: CUL/RAW (ReadAnswer): V 1.58 CUNO868^M

2014.04.05 22:12:06.688 4: CUL_send:  CUNO?
2014.04.05 22:12:06.713 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of m B C F Z i A I G M R T V W X O e f l t u H x E c q^M

2014.04.05 22:12:06.714 3: CUNO: Possible commands: mBCFZiAIGMRTVWXOefltuHxEcq
2014.04.05 22:12:06.714 4: CUL_send:  CUNOX2 1 Ar
2014.04.05 22:12:06.725 4: CUL_send:  CUNOT0 1


Zur Sicherheit und der Vollständigkeit halber, nach FHEM Neustart:

Code Auswählen Erweitern


2014.04.05 22:16:56.161 3: Opening CUNO device /dev/ttyUSB0
2014.04.05 22:16:56.215 3: Setting CUNO baudrate to 38400
2014.04.05 22:16:56.218 3: CUNO device opened
2014.04.05 22:16:56.318 5: SW: V
2014.04.05 22:16:56.329 5: CUL/RAW (ReadAnswer): V 1.58 CUNO868

2014.04.05 22:16:56.330 5: SW: ?
2014.04.05 22:16:56.354 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of m B C F Z i A I G M R T V W X O e f l t u H x E c q

2014.04.05 22:16:56.355 3: CUNO: Possible commands: mBCFZiAIGMRTVWXOefltuHxEcq
2014.04.05 22:16:56.356 5: SW: X21
2014.04.05 22:16:56.367 5: SW: T01


Dann schauen wir mal wie lang es dauert, bis der nächste Aussetzer kommt. B00 reagiert nach wie vor nicht. Vielleicht tut er, aber man merkt es nicht?

[rudolfkoenig]

B00 reagiert nach wie vor nicht. Vielleicht tut er, aber man merkt es nicht?

Sehr merkwuerdig, das sollte ein reboot ausloesen per aktivierten Watchdog und eine Endlosschleife, und das sollte zu einem USB-Abbruch fuehren, das habe ich mit einem CUL hunderte Male getestet. Da TCP/IP nicht eplicit heruntergefahren wird, sollten Netzwerkverbindungen einfrieren oder abbrechen, hier bin ich aber nicht ganz sicher.

[rene]

Naja, ich würde nicht ausschließen, dass ich es einfach falsch mache, oder der CUNO es vielleicht gar nicht unterstützt.

Hier mal ein Log vom Aufruf. Hätte ein Reset stattgefunden, würde hier wohl auch wie im vorigen Post ein "reappeared" auftauchen müssen, schätze ich mal.

Code Auswählen Erweitern


2014.04.06 22:28:51.889 5: Cmd: >set CUNO raw B00<
2014.04.06 22:28:51.890 3: set CUNO raw B00
2014.04.06 22:28:51.890 4: CUL_send:  CUNOB0 0     
2014.04.06 22:28:51.901 5: Triggering CUNO (1 changes)
2014.04.06 22:28:51.902 5: Notify loop for CUNO raw B00
2014.04.06 22:28:51.905 4: eventTypes: CUL CUNO raw B00 -> raw B00
2014.04.06 22:28:51.999 5: Cmd: >{ReadingsVal("CUNO","bWidth","")}<
2014.04.06 22:28:52.009 5: Cmd: >{AttrVal("CUNO","room","")}<


Im Übrigen korrigiere ich mich. Irgendwas tut er, denn anschließend an diese Befehl kommen keine Statusmeldungen der Thermostate mehr rein, wie ich gerade feststelle. Was du mit "aktivierten Watchdog und Endlosschleife" genau meinst, erschließt sich mir nicht. Vermutlich liegt da mein wichtigster Fehler im Moment.

Jedenfalls braucht es anschließend ein "shutdown restart", um alles ins Lot zubringen. Also vermute ich mal, dass du einen Automatismus meinst, der die beiden Schritte (automatisch) kombiniert.

Wenn der CUNO das nächste mal aussteigt, dann versuche ich es mal mit den beiden Schritten, falls du mich bis dahin nicht erleuchtet hast.

VG
René

[rudolfkoenig]

B00 scheint zu funktionieren, da es danach nichts mehr empfangen wird.
Ein CUL reagiert darauf mit Unterbrechung der USB Funktionalitaet, woraufhin das Betriebsystem das Verschwinden des Geraetes meldet, und FHEM das Geraet wieder oeffnet und initialisiert(!).
Bei Dir scheint das Geraet nicht zu verschwinden (verstehe ich nicht), deswegen wird sie von FHEM auch nicht neu initialisiert, und deswegen ist der Empfang ausgeschaltet.

Um auch den Empfang zu aktivieren, wuerde ich folgendes absetzen

Code Auswählen Erweitern

set CUNO raw B00; sleep 1; set CUNO raw X21

wobei X21 SlowRF (FS20/FHT/etc) aktiviert.

[dougie]

...bin mir nicht sicher, ob ein "sleep 1" zum Booten eines CUNO reicht... meiner braucht da etwas länger (ist mein Gefühl...)

[PeMue]

Sonst koennte man durch weglassen unbenoetigter Features in Firmware das Problem lokalisieren. Dazu kann man in culfw/Devices/CUNO[2]/board.h sowas wie HAS_ETHERNET, HAS_ONEWIRE, etc auskommentieren.

Hallo Rudolf,

ich denke, HAS_ETHERNET sollte man drinlassen, da der CUNO nur über Netzwerk angesprochen wird, oder? Der Rest (IR, Intertechno, Max, etc.) kann ggf. zum Testen weggelassen werden ...

Gruß PeMue

[rudolfkoenig]

Ein CUNO/CUNO2 habe ich nie gesehen, aber das CUN hatte auch noch USB.
Oder man testet es direkt ueber USB, ohne etwas zu kompilieren.

[Puschel74]

Hallo,

...bin mir nicht sicher, ob ein "sleep 1" zum Booten eines CUNO reicht... meiner braucht da etwas länger (ist mein Gefühl...)

Der CUNO wird per LAN angebunden und hat somit eine eigene Energieversorgung aka Steckernetzteil.
Die Bootzeit des CUNO sollte eigentlich nur relevant sein bei einem Stromausfall der das gesamte Haus betrifft.

Und selbst nachdem ich bei mir an einem "Versuchs"-CUNO
a) den LAN-Stecker gezogen und wieder angesteckt habe und
b) das Steckernetzteil abgesteckt und wieder angesteckt habe
wurde der CUNO immer wieder als initialized angezeigt - und hat auch wieder einwandfrei funktioniert.

my2cents

Grüße

P.S.: Ich hab 4 CUNO im Einsatz und keinerlei Probleme