Vorarbeiten: Update auf MySensors 2.0-API

Begonnen von Beta-User, 22 Juni 2018, 20:28:35

Vorheriges Thema - Nächstes Thema

Beta-User

@dirkcx:Du meinst die gestern 16:52 Uhr veröffentlichte Version, oder?

Kannst du bitte nachsehen, was im log steht und kurz schildern, wie dein Umfeld aussieht? (insbesondere sowas: wieviele Nodes mit dem MYSBootloader, was für ein GW, welcher Kanal, und vor allem: was genau hast du gemacht, bevor FHEM hängen geblieben ist).
Meine Vermutung wäre, dass es daran lag, dass du eine Node neu gestartet hast, für die keine firmware in der csv festgelegt war?

Das müßte mit der beigefügten Version behoben sein.

Allgemein scheinen mir noch ein paar Nacharbeiten sinnvoll: z.B. könnte man m.E. davon ausgehen, dass es sich um dem MYSBootloader handelt, wenn die OTA-typischen Readings vorhanden sind (z.B. FW_BLOCKS). Dann würde es reichen, den "anderen" OTA-Mechanismus in Optiboot als Attribut zu hinterlegen und ansonsten davon auszugehen, dass es sich um dem MYSBootloader handelt.

Aber an sich ist es auch nicht dramatisch, wenn man "zu viele" Attribute setzen muß.

Meinungen dazu?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

So, vorhin habe ich noch getestet, ob das mit dem 2. GW klappt, wenn man nodes hat mit einem anderen Kanal. Ergebnis ist erst mal negativ, weil die Anfrage nach der firmware über das "falsche" GW rein kommt (wird auf Kanal76 empfangen).
Dort ist die Node aber natürlich nicht als Client hinterlegt, was dazu führt, dass die Anfrage verworfen wird.
Wer also eine schnelle Idee hat, wie onStreamMessage() in 00_MYSENSORS.pm sinnvollerweise zu erweitern wäre (um Zeile 430 herum): Her damit...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dirkcx

Hallo @Beta-User,

ich habe die neue Version eingespielt und es läuft erstmal gut.
Ich fürchte, dass ich das Attribut OTA_firmwareConfig nicht gesetzt hatte und dass ggf daher der Absturz kam. Das habe ich aber geändert. Vielleicht kannst Du da noch einen "Exception Handler" (wenn es das in Perl gibt) einbauen.

Es kann aber auch sein, dass der Absturz eine Folge eines Reboots war für einen Node, dessen Firmware in FHEM einen anderen Wert (80) hatte als in der csv-Daten (84), aber da ich kein OTA gemacht habe, sollte doch egal sein, welcher FW_TYPE eingetragen ist.

Ich habe aber einen anderen Node, der relativ "neu" ist und hier steht der FW_TYPE auf 65535:

setstate MYSENSOR_102 2018-10-01 22:42:15 BL_VERSION 1.3
setstate MYSENSOR_102 2018-10-01 22:42:15 FW_BLOCKS 65535
setstate MYSENSOR_102 2018-10-01 22:42:15 FW_CRC 16657
setstate MYSENSOR_102 2018-10-01 22:42:15 FW_TYPE 65535
setstate MYSENSOR_102 2018-10-01 22:42:15 FW_VERSION 65535
setstate MYSENSOR_102 2018-12-18 03:31:21 SKETCH_NAME Multi Sensor BME280GYRO
setstate MYSENSOR_102 2018-12-18 03:31:21 SKETCH_VERSION 2.2.1 03.11.2018


Mein Setup:
Raspberry mit FHEM, das Gateway ist ein ESP8266 über IP, Port 5003 an FHEM, dann habe ich 12 Sensor Nodes und einen Repeater. (Fast) alles hat den MYSBootloader und alles mit MySensors v2.2 kompiliert.

Ich hatte eine PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/10_MYSENSORS_DEVICE.pm line 940. auf Verbose level 5

Ein OTA Update habe ich aber noch nicht gemacht. Ich beobachte weiter...
Server: Gigabyte GB-BACE3160 | Ubuntu 20.04 LTS Server | aktuelles FHEM | CULUSB (busware) FS20/FHT/... | MySensors: seriell / esp8266 | ZigBee (Zigbee CC2531 / zigbee2mqtt) | homebridge / homebridge-config-ui

Beta-User

Moin @dirkcx,
Danke für die Rückmeldung, das sieht mir danach aus, als wäre der "Exception Handler" aus dem letzten Post wirksam :) ; es brauchte eigentlich nur einen "case handler" für den Fall, dass keine sinnvolle firmware-Angabe da war...

Was das FW_TYPE + FW_VERSION angeht, wird das mit den bisherigen Versionen angelegt (die Readings stammen von Oktober, seitdem scheint die Node gelaufen zu sein ;) ), wenn man Kanal 76 nutzt. Das sendet nämlich der MYSBootloader, wobei die 65535 sowas wie ein Standard zu sein scheint (und daher mit der aktuellen Version auch nicht mehr aktualisiert wird, wenn der MYSBootloader die sendet).
Der allg. Ablauf ist wie folgt: Node (BL) sendet die eigenen Infos und fragt die Eckdaten zur aktuellen firmware ab. Gibt's was anderes, wird das der Node mitgeteilt und der BL fragt dann rückwärts die Blöcke nacheinander ab. Ist die "0" erreicht, wird die FW_VERSION mit der Angabe aus dem firmware-config-file geschrieben, FW_TYPE wird gar nicht angefaßt (wohlgemerkt, beim MYSBootloader; für den Optiboot sollte alles gleich geblieben sein).

Was jetzt noch fehlt, ist der richtige Umgang mit Nodes, die im Normalbetrieb einen anderen Kanal verwenden: die MYSBootloader-Anfrage kommt immer über Kanal 76, man bekommt die also empfangen, wenn man ein anderes GW hat, das diesen Kanal nutzt. Was aber (noch) nicht geht, ist die Zuordnung der  message zur "richtigen" Node, weil die nicht als Client bei diesem GW eingetragen ist.

Mal schauen, ob ich das noch gelöst bekomme, kann eigentlich auch kein Hexenwerk sein :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

dirkcx

Hallo @Beta-User,
so jetzt ist FHEM seit ca. 1 Stunde nicht mehr erreichbar, 1 CPU bei 105% (RasPi mit 4 Kernen), schreibt seid dem nichts mehr ins log (MySensors Gateway ist auf verbose 5) und auch per Telnet (inform timer) nichts. Allerdings bekomme ich im Browser auch kein Timeout, d.h. irgendwas hält ihn am "Leben" aber der Browser zeigt eine leere Seite, nur die erste Zeile ist da.   

Ich könnte jetzt den fhem Prozess killen, aber dann kann ich nichts mehr über den Grund herausfinden. Wg. im Fhem-Log steht nichts. Im syslog auch nicht.
Wo kann ich noch nach Gründen für das "Hängen" vom FHEM suchen?
Server: Gigabyte GB-BACE3160 | Ubuntu 20.04 LTS Server | aktuelles FHEM | CULUSB (busware) FS20/FHT/... | MySensors: seriell / esp8266 | ZigBee (Zigbee CC2531 / zigbee2mqtt) | homebridge / homebridge-config-ui

Beta-User

Hmm, so richtig die durchschlagende Idee habe ich im Moment auch nicht, bei mir läuft FHEM (allerdings mit einer etwas abgeänderten MYSENSORS.pm) ohne Hänger (die besagten Änderungen in MYSENSORS sind auch nicht ursächlich für's Weiterlaufen, das betrifft die Rückwärtssuche für das 2. IO...).

Die Log-Ausgaben, die das GW erzeugt, sind ziemlich sicher auch nicht so aufschlußreich wie das, was sich an der jeweiligen Node abspielt, aber auch da ist es eigentlich so, dass entweder was zugeordnet werden kann (dann wird ein Reading aktualisiert), oder eben nicht. (oder es wird ein Update veranlaßt; das sähe man dann am Log der Node bei verbose 4/5).

Das einzige, was ich mir im Moment denken kann, wäre ein deutlich erhöhter Speicherverbrauch, wenn mehrere Nodes firmware-Abfragen tätigen. Aber sowas kommt wenn dann erst dann, wenn die Nodes einen Reboot durchführen. Hast du in die Richtung was veranlaßt?

Ansonsten muß ich mir den Code insgesamt nochmal durchsehen, aber wie gesagt: eine richtige Idee habe ich im Moment nicht...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Also,

nachdem ich jetzt nochmal eine Nacht drüber geschlafen habe, will ich mal folgendes zur Diskussion stellen:

-Vorläufigen Ausbau der OTA-Optionen, Veröffentlichung der übrigen Änderungen (smartSleep, RSSI-etc. Abfragen, heartbeat-Alive usw.).

- Umbau der OTA-Funktion hin zu einem "set <device> flash" unter Verwendung einer konkreten Pfadangabe zum jeweiligen OTA-file, kein auto-Update aus der Liste mehr (ähnlich wie Signalduino). Dann ließe es sich m.E.  leichter verhindern, dass größere Datenmengen im Hintergrund automatisch geladen werden, wenn Nodes neu starten.

Meinungen dazu?

Gruß,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

PeMue

Hallo Jörg,

Zitat von: Beta-User am 27 Dezember 2018, 07:52:03
-Vorläufigen Ausbau der OTA-Optionen, Veröffentlichung der übrigen Änderungen (smartSleep, RSSI-etc. Abfragen, heartbeat-Alive usw.).

- Umbau der OTA-Funktion hin zu einem "set <device> flash" unter Verwendung einer konkreten Pfadangabe zum jeweiligen OTA-file, kein auto-Update aus der Liste mehr (ähnlich wie Signalduino). Dann ließe es sich m.E.  leichter verhindern, dass größere Datenmengen im Hintergrund automatisch geladen werden, wenn Nodes neu starten.

Meinungen dazu?
ich habe es nicht getestet, finde aber Deinen Ansatz gut. Das ist dann auch kompatibel z.B. zum LaCrosse Gateway.

Gruß Peter
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

dirkcx

@Beta-User: ja, finde ich auch alles ok. OTA nur manuell fände ich sogar besser als die automatische Funktion. Und ich fände es auch gut, wenn die Readings wahlweise (durch set) auf Basis der Comments erstellt würden. Manchmal brauche ich die normalen Readings.

Übrigens läuft fhem mit Deiner neuesten Datei schon seit Stunden sauber, alles mit verbose 5. Ich habe zwischendurch mal ein Reboot auf einem krischen Node gemacht, auch ok. Noch kein "flash". Ich beobachte weiter ...
Server: Gigabyte GB-BACE3160 | Ubuntu 20.04 LTS Server | aktuelles FHEM | CULUSB (busware) FS20/FHT/... | MySensors: seriell / esp8266 | ZigBee (Zigbee CC2531 / zigbee2mqtt) | homebridge / homebridge-config-ui

Beta-User

Danke für die Rückmeldungen und die Entwarnung.

Da es nun doch keine größeren Probleme mit der neueren Version und MYSBootloader-Nodes zu geben scheint (?), werde ich das vermutlich im Wesentlichen so lassen, wie es ist, denn für die OptiBoot-Fraktion war es ja schon länger ok - zumindest gab es keine negativen Rückmeldungen.

Was ich ändern werde: die MYSBootloader-Nodes bekommen einen internen Merker, ob sie beim nächsten booten (ggf.) ein update erhalten sollen oder nicht. Damit dürften eventuelle Probleme, die durch die Anfragen @boottime kommen auf die Fälle beschränkt bleiben, die vom user veranlaßt waren. Das feature bekommt einen "experimental"-flag, dann sollten die, die es nutzen, erkennen können, dass eventuell nicht alles bis ins Letzte getestet ist...

Fehlt dann noch die Rückwärtssuche für das 2.GW, aber das kann auch erst mal so bleiben mit einem Vermerk in der commandref, dass es noch nicht fertig ist. Die hierfür erforderlichen Änderungen betreffen m.E. nur die 00_MYSENSORS.pm.

Dann werde ich das mal am WE soweit fertig machen, wenn sich keiner mehr wehrt :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

So,
jetzt wird es also wahr...

Ich habe das update vorhin noch mit ein paar kleineren Änderungen ins svn gepackt, Rückmeldung im Problemfall dann bitte hier.

Gruß und viel Spaß damit,
Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files