Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39

[yersinia]

Du kannst tun, was Du nicht lassen kannst. Allerdings brauchst Du mich bei HM-Mischbetrieb gar nicht erst fragen, wenn etwas nicht funktioniert.

Zum Einen wäre der Mischbetrieb im Fehlerfall der erste Analyse- sowie Ansatzpunkt für mich und zum Anderen deute ich deine Antwort als lass es lieber.

Initialisiert wird er sicherlich, aber es behebt wohl nicht Dein "Absturz"-Problem. Ist die ser2net Verbindung nicht stabil? Stromversorgung ausreichend?
uptime am CUL (die interessiert) musst Du manuell auslösen.

Der nanoCUL blinkt dann wild - und ist für FHEM nicht mehr zu erreichen. Das gilt auch für den nanoCUL direkt am RasPi auch wenn es wesentlich seltener auftritt.
Bisher habe ich keine Probleme bei der ser2net Verbindung feststellen können. Wenn der nanoCUL läuft, läuft er zufriedenstellend mit dem ihm zugeordneten Devices. LAN Verbindung ist stabil soweit ich das beurteilen kann (alle anderen Geräte im gleichen Netzwerk laufen stabil), der Router (Archer C7 v5 mit OpenWRT 19.07.7), an dem der nanoCUL am USB Port hängt, läuft auch stabil und der USB-Port liefert seine 500mA.
(Interessanterweise ignoriert die VCCU den nanoCUL Ausfall (der Status ist dann opened), die zugehörigen Devices werden trotzdem nicht auf den in Reichweite befindlichen anderen nanoCUL umgeroutet obwohl ich immer ein preferred IO angegeben habe; ich nutze übrigens auch keine AES Verschlüsselung).
Wenn der nanoCUL sich aufhängt und ich ein get uptime versuche gibt es nur ein no answer. Aber das wird hier langsam OT.
EDIT: im OpenWRT Kernel ringbuffer finde ich folgende Laufzeiten für den nanoCUL: ~210,42 Stunden (~8,7 Tage), ~126,41 Stunden (~5,26 Tage), seit dem läuft dieser unauffällig.

[noansi]

Hallo yersinia,

Der nanoCUL blinkt dann wild - und ist für FHEM nicht mehr zu erreichen.

was passiert denn, wenn Du ein raw B00 an die nanos schickst?

Gruß, Ansgar.

[yersinia]

Was bewirkt ein raw B00? Hab es gefunden. Bisher habe ich immer ein set reopen versucht, was zumindest den Status von initialized auf opened ändert.
Kann ich gerne nachstellen wenn einer nanoCULs wieder hängt - dazu muss ich aber warten. :|

Und ich sehe gerade, dass mich das hier schreiben schon -bezgl Optionen und Information- etwas weitergebracht hat: https://wiki.fhem.de/wiki/CUL#Harter_Lockup_des_CUL

EDIT: falls es mal jemand benötigt - meine nanos habe ich 2017 bestellt, wahrscheinlich laufen die mit dem alten, suboptimalen bootloader wie die meisten clones oder ältere Originale. Auf yt gibt es ein sehr gutes Video wie man den neuen bootloader relativ einfach mit einem weiteren nano und der Arduino IDE draufschreibt: Arduino Bootloader Update or Install - Upgrade a Clone From Old Bootloader to New Optiboot!
Wiring-diagram ist auf arduino.cc gut beschrieben (die Verbindungen sind identisch auch zwischen zwei nanos).

Optiboot unterstützt eine höhere Baudrate (alt: 57600; neu: 115200), um aculfw auf den nano zu flashen muss das entsprechend angepasst werden, zB:

Code: [Auswählen]

avrdude -p atmega328p -c arduino -P [COMPORT] -b 115200 -D -Uflash:w:./nanoCUL868.hex:i
EDIT 2: ich habe jetzt zwei weitere nanos mit der TSnanoCUL.hex geflasht und FHEM entsprechend angepasst und neu gestartet. Ich beobachte, wie es läuft. Als Reserve habe ich die zwei 'alten' nanos mit aculfw und natürlich backup von allem.

[noansi]

Hallo yersinia,

ok, meine Vermutung zur Bootloader Loop nach Watchdog Reset hat wohl gepasst. 
Schön, dass Du den Optiboot Hinweis schon gefunden hast.

Der Watchdog kann bei jeder Firmware Variante zuschlagen, wenn gleich ich versucht habe, dies für den Normalbetrieb nach Möglichkeit in der tsculfw zu vermeiden. Sprich Warten mit Timeout, statt warten, bis der Watchdog zuschlägt.

Dann gibt es auch noch die Möglichkeit des Pufferüberlaufs bei der seriellen Übertragung auf CUL Seite. Und da ASKSIN immer mit HEX Daten als Befehl versorgt wird, kann das prinzipiell im ungünstigen Fall zu Datensalat führen bei dem auch ein B00 statt des gewünschten Befehls ausgeführt wird -> auch ein Watchdog Reset. Gilt auch für jede Firmware Variante. Allerdings müssen dazu mehrere Befehle hintereinander ohne Pause an den seriell angebunden CUL gesendet werden.
In TSCUL gibt es aber Bremsmechanismen, so dass der Zustand nicht eintreten sollte.
Xon/Xoff für die serielle Übertragung war noch nie in einer der Firmware Varianten implementiert, so weit ich das gesehen habe (und möchte ich wegen SlowRf auch nicht in die tsculfw einbauen).

In beiden Fällen muss der CUL also diese Watchdog Reset "überleben", was bei einem problematischen Bootloader beim nano offenbar schief geht.

Gruß, Ansgar.

[yersinia]

Danke für die Details.

Gibt es eine Möglichkeit die tsculfw CULs zu überwachen?
Mit aculfw kann ich das Reading state via ReadingsAge überwachen, wenn der nanoCUL hängt, dann aktualisiert das Reading sich nicht.
Bei den tsculfw nanoCULs sehe ich nur das Reading scF welches regelmässig aktualisiert wird. Ich würde gern mitbekommen, wenn der nanoCUL hängt oder (im Falle von ser2net) nicht erreichbar ist - würde auch das VCCU-Handling vereinfachen. (bezgl. der VCCU hat das bei mir eigentlich nie funktioniert, dass auf ein anderes IODev umgeschwenkt wird wenn das eine ausfällt; möglicherweise weil die VCCU das gar nicht mitbekommen hat - das war aber auch mit dem alten nano Bootloader)

Btw, der HMclassic Betrieb hat jetzt eine Nacht (Rolläden runter und wieder rauf) überlebt, ich denke, bisher läuft es ganz gut.

[noansi]

Hallo yersinia,

das scF wird zwar aktualisiert, löst aber kein Event aus. Es ist nur ein Reading, weil es so einen FHEM restart überlebt, somit dann wieder genutzt werden kann.

Das Reading 'cond' kannst Du überwachen (erzeugt events). Wenn 900s lang nichts empfangen wird, dann wird ein C99 an den CUL gesendet, womit alle cc1101 Register zurückgeliefert werden. Wenn diese Antwort nicht kommt, dann geht der CUL auf 'cond' disconnected mit event.
Dann siehst Du ggf. auch 'Warning-HighLoad' oder 'ERROR-Overload'.

Für CULs, die via Netzwerk angebunden werden, also mit IP:Port definiert werden (außer localhost) wird alle knapp 60s ein ping an den CUL gesendet (wenn nicht gerade ohnehin Kommunikation im Gange ist). Bleibt die ping Antwort (nach Timeout) aus, wird der CUL ebenfalls auf 'cond' disconnected gesetzt.
In der nächsten Modulversion werde ich diesen Mechanismus auch noch mit einem 'forceAlivePing' Attribut für alle CULs erzwingbar machen. Dann könnte man so einen Bootloop nano auch etwas früher erkennen (aber auch nicht beheben, geht nur mit Bootloader Update).

Ein disconnected triggert auch ein 'DISCONNECTED' event für den CUL.

Mit folgenden reconnect Versuchen werden sie dann ggf. wieder auf 'ok' gesetzt, wenn dies erfolgreich ist.

wenn der nanoCUL hängt oder (im Falle von ser2net) nicht erreichbar ist - würde auch das VCCU-Handling vereinfachen

Sollte "out of the box" funktionieren, weil ich das condition Handling in TSCUL compatibel zu HMLAN gemacht habe (ohne Anspruch auf vollständige Fehlerfreiheit  ).

Gruß, Ansgar.

[yersinia]

Hallo noansi,

Danke, das hilft. Bisher brauch(t)e ich kein event, da ich periodisch (1x pro Stunde) ua die nanoCULs abfrage. Bei aculfw genügt es, state mit ReadingsAge zu prüfen - ich löse ein reopen aus wenn das Reading das letzte mal vor >900s aktualisiert worden ist. Wenn das dreimal fehlschlägt gibt das script auf. Es forciert aber den aculfw-nanoCUL-state auf opened zu zwingen.

Der VCCU geb' ich auch (erstmal) keine Schuld, da selbst FHEM nicht mitbekommen hat, dass die nanoCULs mit dem alten Bootloader nicht mehr reagieren - wie soll die VCCU das dann mitbekommen?
Ich beobachte mal wie gut der neue Optiboot Bootloader jetzt auch mit der tsculfw läuft. Hoffentlich schwenkt die VCCU um wenn ein nanoCUL ausfällt.

Aber, bisher, läuft die tsculfw echt unaufällig, so soll es ja auch sein.

[noansi]

Hallo yersinia,

Hoffentlich schwenkt die VCCU um wenn ein nanoCUL ausfällt.

Reconnect, sofern möglich, soll "out of the box" funktionieren. Ansonsten soll es bei disconnected bleiben und die VCCU den noch lebenden nutzen, sofern IOList und IOgrp richtig konfiguriert sind.

Sende ein raw B00 (erzwingt einen Watchdog Reset) an die CULs und schau, was passiert (macht nur Sinn, wenn der Optiboot geflashed wurde. Wäre sonst nur duch USB Portreset zu retten, aber das macht TSCUL nicht).
Zieh die CULs ab und steck sie wieder an und schau was passiert.
Zieh das Netzwerkkabel am ser2net ab und wieder an und schau, was passiert.
Lass jeweils einen abgezogen und schau was passiert.
Jeweils mit Geduld.
Testen ist da besser als Beten.

Gruß, Ansgar.

[noansi]

Hallo Testwillige,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 aktualisiert.

Das Attribut 'forceAlivePing' ist damit für TSCUL drin.

Gruß, Ansgar.

[yersinia]

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 aktualisiert.

Das Attribut 'forceAlivePing' ist damit für TSCUL drin.

Danke.
Gibt es eine Übersicht, welche Dateien unter FHEM/ geändert worden sind? Dann kann ich mir sparen, alle Dateien zu sichern bzw. ersetzen. Nach dem Änderungsdatum vermute ich (im Vergleich zur 65):
00_TSCUL.pm
16_TSCUL_RFR.pm
DevIoTS.pm
Bezgl. Firmware scheint es keine Änderungen zu geben.

Ich sehe auch gerade, dass die angepasste 10_CUL_HM.pm auf dem Modustand der Revision 23856 basiert, also aktueller als 09/2020 ist. (Übrigens auch für HMConfig.pm (23857), 98_HMinfo.pm (23776) und 98_HMtemplate.pm (19079))  Danke dafür!

[noansi]

Hallo yersinia,

Bezgl. Firmware scheint es keine Änderungen zu geben.

Modulstand ... geändert

Gibt es eine Übersicht, welche Dateien unter FHEM/ geändert worden sind?

Macht es Sinn, andere, die von einem älteren Stand updaten, mit der von Dir gewünschten Information zu verwirren, mit dem Erfolg, Fehlfunktionen aus Mischzusammenstellungen entwirren zu müssen?

Aber Du hast ja schon den Informationsgehalt des Dateisystems und Revisionsnummern entdeckt und für Dich nutzbar gemacht. 

Gruß, Ansgar.

[yersinia]

Hallo noansi,

Modulstand ... geändert

pfff, als wenn ich das so genau lese (head->table). Ja, Leseverständnis ist manchmal etwas nicht vorhanden.

Macht es Sinn, andere, die von einem älteren Stand updaten, mit der von Dir gewünschten Information zu verwirren, mit dem Erfolg, Fehlfunktionen aus Mischzusammenstellungen entwirren zu müssen?

Aber Du hast ja schon den Informationsgehalt des Dateisystems und Revisionsnummern entdeckt und für Dich nutzbar gemacht. 

Jup, damit ist es für mich in Ordnung.

Übrigens, der Modulstand 66 läuft bisher unauffällig (gut). Bedankt.

[noansi]

Hallo Testwillige,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 aktualisiert.

Pairing ist verbessert.

Gruß, Ansgar.

[noansi]

Hallo Testwillige,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 aktualisiert.

Pflege Aktualisierungen CUL_HM und Co.

Gruß, Ansgar.

[pte]

Hallo Ansgar,

ich habe im Log gelegentlich nachfolgende Einträge:

Code: [Auswählen]

2021.03.22 06:24:23.767 3: CUL_HM set EGHauslicht getConfig noArg
2021.03.22 06:24:28.921 3: LogHist KGHZCUNO:  06568799 A F101 08717108 00 16 0E A010 4AB43F F11234 038200003264009E00FF813363 -65dB
2021.03.22 06:24:28.921 3: LogHist KGHZCUNO:  06568920 A F103 08717204 01 0A 0E 8002 F11234 4AB43F 00 _CCAdly:4 _dhmSt:96
2021.03.22 06:24:28.921 3: LogHist KGHZCUNO:  06569048 A F101 08717352 00 0C 0F A010 4AB43F F11234 030000 -65dB
2021.03.22 06:24:28.922 3: LogHist KGHZCUNO:  06569166 A F103 08717448 01 0A 0F 8002 F11234 4AB43F 00 _CCAdly:4 _dhmSt:96
2021.03.22 06:24:28.922 3: LogHist KGHZCUNO:  06569275 A F103 08717552 01 10 10 A001 F11234 4AB43F 01044E61C60303 _CCAdly:4 _dhmSt:200
2021.03.22 06:24:28.923 3: LogHist KGHZCUNO:  06569438 A F101 08717712 00 16 10 A010 4AB43F F11234 030222300069005900FF813333 -65.5dB
2021.03.22 06:24:28.923 3: LogHist KGHZCUNO:  06569527 A F103 08717808 01 0A 10 8002 F11234 4AB43F 00 _CCAdly:4 _dhmSt:96
2021.03.22 06:24:28.923 3: LogHist KGHZCUNO:  06569662 A F101 08717964 00 16 11 A010 4AB43F F11234 03820000326400FF00FF201463 -65dB
2021.03.22 06:24:28.924 3: LogHist KGHZCUNO:  06569780 A F103 08718060 01 0A 11 8002 F11234 4AB43F 00 _CCAdly:4 _dhmSt:96
2021.03.22 06:24:28.924 3: LogHist KGHZCUNO:  06569826 A F101 08718128 00 0D 18 A410 54A14A F11234 06040000 -78.5dB
2021.03.22 06:24:28.924 3: LogHist KGHZCUNO:  06569907 A F101 08718212 00 0C 12 A010 4AB43F F11234 030000 -65dB
2021.03.22 06:24:28.924 3: LogHist KGHZCUNO:  06570083 A F101 08718252 00 0A 18 8002 F11234 54A14A 00 -86.5dB
2021.03.22 06:24:28.925 3: LogHist KGHZCUNO:  06570198 A F101 08718500 00 0C 12 A010 4AB43F F11234 030000 -65.5dB
2021.03.22 06:24:28.925 3: LogHist KGHZCUNO:  06570599 A F101 08718900 00 0C 12 A010 4AB43F F11234 030000 -66dB
2021.03.22 06:24:28.925 3: TSCUL_ParseTsHM: KGHZCUNO HM send message cleared while waiting for CCA to 4AB43F/EGHauslicht:  06570615 A F104 08718884 00 00 12 8002 F11234 4AB43F 00
:
:
2021.03.22 09:04:59.090 3: CUL_HM set Regensensor_Heating off noArg
2021.03.22 09:04:59.249 3: LogHist GASCCUL:  16157192 A F001 10365180 00 0F 63 8610 43F4DD 000000 0A28B10B0000 -78dB
2021.03.22 09:04:59.249 3: LogHist GASCCUL:  16158722 A F001 10366716 00 0C 15 8470 694D67 000000 00B428 -92dB
2021.03.22 09:04:59.250 3: LogHist GASCCUL:  16164154 A F001 10372136 00 0D C5 A610 4E6A52 F11234 06036600 -83dB
2021.03.22 09:04:59.250 3: LogHist GASCCUL:  16164968 A F001 10372948 00 0F 12 8610 6AD422 000000 0A88B40A0000 -83.5dB
2021.03.22 09:04:59.250 3: LogHist GASCCUL:  16174472 A F001 10382456 00 0C AE 865A 695053 000000 88AE29 -91dB
2021.03.22 09:04:59.251 3: LogHist GASCCUL:  16176032 A F001 10384016 00 0F 1C 8610 28B3C9 000000 0A5068090000 -95dB
2021.03.22 09:04:59.251 3: LogHist GASCCUL:  16180927 A F001 10388940 00 16 8B 8653 403AFA 000000 0041002142001B43000644FFFA -78.5dB
2021.03.22 09:04:59.251 3: LogHist GASCCUL:  16194472 A F001 10402456 00 0C AE 8470 695053 000000 00AE29 -91.5dB
2021.03.22 09:04:59.252 3: LogHist GASCCUL:  16200755 A F001 10408028 00 0D 11 A610 24582D F11234 06010000 -44dB
2021.03.22 09:04:59.252 3: LogHist GASCCUL:  16200756 A F103 10408124 01 0A 11 8002 F11234 24582D 00 _CCAdly:4 _dhmSt:96
2021.03.22 09:04:59.252 3: LogHist GASCCUL:  16200755 A F103 10408228 01 0E 12 A011 F11234 24582D 0202000000 _CCAdly:4 _dhmSt:200
2021.03.22 09:04:59.253 3: LogHist GASCCUL:  16200755 A F101 10408380 00 0E 12 8002 24582D F11234 0102000025 -43.5dB
2021.03.22 09:04:59.253 3: LogHist GASCCUL:  16200755 A F103 10408656 01 0E 12 A011 F11234 24582D 0202000000 _CCAdly:4 _dhmSt:276
2021.03.22 09:04:59.253 3: LogHist GASCCUL:  16200941 A F101 10408812 00 0E 12 8002 24582D F11234 0102000025 -44dB
2021.03.22 09:04:59.254 3: TSCUL_ParseTsHM: GASCCUL HM send message cleared while waiting for CCA to 24582D/Regensensor:  16200941 A F104 10408808 00 00 12 A011 F11234 24582D 0202000000

Firmwarestand für TSCUL ist 0.38, Modulstand ist 68.

Grundsätzliches Fehlverhalten der Geräte kann ich erst einmal nicht feststellen.
Ich betreibe 2 HMLAN, 1 CUNO V2 sowie einen CUL V3 über ser2net. Angebunden sind etwa 90 Homematic-Komponenten.

Was verbirgt sich dahinter und an welcher Ecke müsste ich anfangen zu suchen?

Gruß Peter