Autor Thema: CUNO im CUL mode - lethargisches Antwortverhalten führt zu MISSING_ACKs  (Gelesen 3737 mal)

rene

  • Gast
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:
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:

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.

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é

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21939
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

  • Gast
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

  • Gast
So, CUNO2 auf V 1.58 upgegraded:

Nach Anstöpseln im FHEM Log
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:
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?

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21939
Zitat
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

  • Gast
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.

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é

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21939
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
set CUNO raw B00; sleep 1; set CUNO raw X21
wobei X21 SlowRF (FS20/FHT/etc) aktiviert.

Offline dougie

  • Sr. Member
  • ****
  • Beiträge: 605
    • dougie's tools

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

Offline PeMue

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5158
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
1x FB7170 (29.04.88) 5.7 1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F)
1x RPi BV2LCDCSM 1.63 5.7 2xMAX HKT, 1xMAX RT, V200KW1
1xFB 7490 (113.06.05) 5.7 1xCUL V3 1.63 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 1xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU 1xRFXtrx 90 1xWT440H 1xCM160 3xTFA30.3150 5xFA21

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21939
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.

Offline Puschel74

  • Hero Member
  • *****
  • Beiträge: 9838
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
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

 

decade-submarginal