Vorarbeiten: Update auf MySensors 2.0-API

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

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: Ranseyer am 21 Juli 2018, 18:48:51

Nee RFM96W , also die LoRa 433MHz Stamps von Hope.
NRF* habe ich keine mehr.
Moin, soweit war mir das schon klar ;) .
Aber dirkcx hat - soweit ich das im Kopf habe - nur nRF24 und bisher nur 0 oder 1 als Rückmeldung zu RSSI-Anfragen gehabt. Da ist das hier schon ein Fortschritt (wenn er nicht doch mit RFMx getestet hat).

@dirkcx: Hast du das mit der update-Geschwindigkeit mal getestet? Unter 2.3.0 sollte das auch unter MYSController schlecht laufen, wenn man kein 2.2-GW nimmt...
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

#76
Zitat von: Beta-User am 21 Juli 2018, 18:39:15
Ähm, das ist doch nRF24, oder? Das wäre ja eine angenehme Überraschung :) :) :) !
Klar, das ist nur irgendein Zufallswert  ;) ich hatte aber eine leise Hoffnung ...

Ich hab noch alles auf Version 2.2, FOTA mit MYSController dauerte heute ca 2 Minuten, mit Deinem Modul hat heute kein Update funktioniert, aber ich hab's nur mir smartSleep Node versucht
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

Sidey

Zitat von: Beta-User am 21 Juli 2018, 18:39:15
Danke für die Info, dann baue ich das bei nächster Gelegenheit ein. Schadet in jedem Fall nicht, auch wenn mir völlig unklar ist, wie es dazu kommt, dass dieses Array an der Stelle des Codes nicht exisitiert... Aber vielleicht komme ich ja noch irgendwann dahinter oder jemand erklärt es mir.

Ich habe mir den Code angesehen.

1) Ich blicke leide nicht durch
2) In Zeile 913 steht folgendes:

$hash->{retainedMessages}=scalar(@$messages) if (defined $hash->{retainedMessages});


In Zeile   928 dieses

  $hash->{retainedMessages}=scalar(@$messages);


Ich habe in dem Quellcode nirgends etwas gefunden in dem $hash->{retainedMessages} definiert worden wäre außer in Zeile 928.


3) schaue ich mir $messages an:
Zeile 908

    my $messages = $hash->{retainedMessagesForRadioId}->{messages};


Ich habe die Stelle nicht gefunden in der $hash->{retainedMessagesForRadioId} oder ->{messages} definiert wird.

Wolltest Du hier vielleicht mit $hash->{MessagesForRadioId} arbeiten?

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Beta-User

Zitat von: dirkcx am 21 Juli 2018, 21:34:27
Ich hab noch alles auf Version 2.2, FOTA mit MYSController dauerte heute ca 2 Minuten, mit Deinem Modul hat heute kein Update funktioniert, aber ich hab's nur mir smartSleep Node versucht
Kannst du mal nachsehen, ob das GW die Angabe des OTA-files vergessen hat (dann erscheint bei den sets an der Node auch keine Auswahlliste). Mag nach einer doofen Frage klingen, aber so war das bei mir hier, als ich eben mal mit der Ursachenforschung dazu angefangen habe. Kann aber natürlich auch sein, dass ich das einfach nicht zwischendurch abgespeichert hatte...
Aber da der Code an der Stelle zwischenzeitlich (hoffentlich) nicht geändert wurde, wäre das eine Erklärung; es wäre dann allerdings interessant, wieso es dazu gekommen ist.

Seltsam war auch, dass ich nach der Attributvergabe FHEM neu starten mußte, damit die neue Angabe der OTA-file auch Ergebnisse bei den "sets" der Nodes brachte. Insgesamt fand ich dabei an der Stelle den Ablauf nicht so intuitiv. Vom Gefühl her würde ich dazu tendieren, die "sets" statisch zusammenzubauen, und nicht jedesmal neu die file zu lesen. Allerdings wäre dann die Frage, wie man Änderungen der Liste (betrifft nur die Ziffern) dann in die set-Liste bringt. File überwachen oder manuell anstoßen?
Muß das wohl nochmal in Ruhe durchspielen.

Zitat von: dirkcx am 21 Juli 2018, 21:34:27
Klar, das ist nur irgendein Zufallswert  ;) ich hatte aber eine leise Hoffnung ...
An Zufälle mag ich nicht so recht glauben. Es wird nur was angezeigt, wenn die Node auf die entsprechenden Anfragen was liefert, und dass die irgendwas erfindet oder völlig zufällig liefert, mag ich nicht glauben. Könnte aber sein, dass das Bilden eines Werts eine gewisse Anzahl Messages voraussetzt. Müßte man im Code der MySensors-lib mal nachforschen.
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

ZitatKannst du mal nachsehen, ob das GW die Angabe des OTA-files vergessen hat (dann erscheint bei den sets an der Node auch keine Auswahlliste).
Ich fürchte, dass Du an dieser Stelle meine nicht vorhandenen Perl Kenntnisse überschätzt. Die Combobox in der UI hat eine Liste aller Firmwares, wenn Du das wissen willst. Ich versuche gerade weitere FOTAs. Die sieht man auch im log, aber meine Interpretation ist, dass der Node das nicht annimmt.
Es geht hier konkret um Firmware "40" im Node "MYSENSOR_105".


2018.07.22 09:09:46 4: MYSENSORS Read: Rx: fr=105 ci=255 c=004(C_STREAM      ) st=000(ST_FIRMWARE_CONFIG_REQUEST) ack=0 '280014005003775B0103'

2018.07.22 09:09:46 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:46 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:46 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:46 4: MYSENSOR_105: received ST_FIRMWARE_CONFIG_REQUEST
2018.07.22 09:09:46 4: MYSENSOR_105: MYSBootloader asking for firmware update, calling firmware update procedure
2018.07.22 09:09:46 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:46 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:46 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:46 4: MYSENSOR_105: Flashing './FHEM/firmware/MotionMultiSensorV2.ino.arduino_standard.hex'
2018.07.22 09:09:46 5: MYSENSOR_105 is sleeping, enqueueing message!
2018.07.22 09:09:46 5: Send firmware info to MYSENSOR_105.
2018.07.22 09:09:46 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:51 4: MYSENSORS/RAW: /105;255;4;0;0;280014005003775B0103

2018.07.22 09:09:51 4: MYSENSORS Read: Rx: fr=105 ci=255 c=004(C_STREAM      ) st=000(ST_FIRMWARE_CONFIG_REQUEST) ack=0 '280014005003775B0103'

2018.07.22 09:09:51 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:51 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:51 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:51 4: MYSENSOR_105: received ST_FIRMWARE_CONFIG_REQUEST
2018.07.22 09:09:51 4: MYSENSOR_105: MYSBootloader asking for firmware update, calling firmware update procedure
2018.07.22 09:09:51 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:51 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:51 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:51 4: MYSENSOR_105: Flashing './FHEM/firmware/MotionMultiSensorV2.ino.arduino_standard.hex'
2018.07.22 09:09:51 5: MYSENSOR_105 is sleeping, enqueueing message!
2018.07.22 09:09:51 5: Send firmware info to MYSENSOR_105.

und 5 Sekunden später wird C_PRESENTATION abgefragt. Das interpretiere ich als "ignorieren" des Befehls.

2018.07.22 09:09:56 4: MYSENSORS/RAW: /105;255;0;0;17;2.2.0

2018.07.22 09:09:56 4: MYSENSORS Read: Rx: fr=105 ci=255 c=000(C_PRESENTATION) st=017(S_ARDUINO_NODE  ) ack=0 '2.2.0'

2018.07.22 09:09:56 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:56 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:56 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:56 4: MYSENSORS/RAW: /105;255;3;0;6;99

2018.07.22 09:09:56 4: MYSENSORS Read: Rx: fr=105 ci=255 c=003(C_INTERNAL    ) st=006(I_CONFIG        ) ack=0 '99'

2018.07.22 09:09:56 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:56 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:56 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:56 5: MYSENSOR_105 is sleeping, enqueueing message!
2018.07.22 09:09:56 4: MYSENSORS_DEVICE MYSENSOR_105: respond to config-request, node parentId = 99
2018.07.22 09:09:58 4: MYSENSORS/RAW: /105;255;3;0;11;Motion Multi Sensor (I2C)

2018.07.22 09:09:58 4: MYSENSORS Read: Rx: fr=105 ci=255 c=003(C_INTERNAL    ) st=011(I_SKETCH_NAME   ) ack=0 'Motion Multi Sensor (I2C)'

2018.07.22 09:09:58 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:58 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:58 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:59 4: MYSENSORS/RAW: /105;255;3;0;12;2.0
105;0;0;0;17;Motion Multi Sensor (I2C)
105;101;0;0;30;Battery
105;4;0;0;7;HTU21D humidity I2C

2018.07.22 09:09:59 4: MYSENSORS Read: Rx: fr=105 ci=255 c=003(C_INTERNAL    ) st=012(I_SKETCH_VERSION) ack=0 '2.0'

2018.07.22 09:09:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 09:09:59 4: MYSENSORS Read: Rx: fr=105 ci=000 c=000(C_PRESENTATION) st=017(S_ARDUINO_NODE  ) ack=0 'Motion Multi Sensor (I2C)'

2018.07.22 09:09:59 4: MYSENSORS Read: Rx: fr=105 ci=101 c=000(C_PRESENTATION) st=030(S_MULTIMETER    ) ack=0 'Battery'

2018.07.22 09:09:59 4: MYSENSORS Read: Rx: fr=105 ci=004 c=000(C_PRESENTATION) st=007(S_HUM           ) ack=0 'HTU21D humidity I2C'




PS: ich muss meine Aktivitäten hier nun für eine Weile ruhen lassen ;)
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, das war genau, was ich an Infos brauchte ;) , vertiefte Perl-Kenntnisse sind nicht erforderlich. Vermutlich hatte ich wirklich die Angabe des OTA-files nicht in der cfg gespeichert...

Es war noch ein Denkfehler drin: FHEM dachte, die Node schläft noch, als der firmware-Request kam. Dabei gehe ich davon aus, dass kein spezielles  OTA-IODev angegeben war. Daher wurde die Antwortmessage erst mal zwischengespeichert, die Node hat dann den Bootvorgang fortgesetzt, weil die Antwort nicht rechtzeitig kam; später ging die Antwort dann zwar an die Node, die konnte damit aber nichts mehr anfangen...

Ist in der neuen Version im ersten Post geändert, jetzt sollte es auch durchlaufen, wenn kein OTA-GW angegeben ist - diese Message wird jetzt auch direkt versendet, wenn die Node vermeintlich schläft.

Jetzt wird es echt Zeit, dass ich mal ein paar eigene nRF-OTA-Testnodes fertigmache ;) .

Zitat von: dirkcx am 22 Juli 2018, 09:16:22
PS: ich muss meine Aktivitäten hier nun für eine Weile ruhen lassen ;)
Danke für die Geduld bis dahin, das war sehr hilf- und lehrreich!
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

Zitat von: Sidey am 22 Juli 2018, 01:11:23
Ich habe mir den Code angesehen.
1) Ich blicke leider nicht durch
Danke, ich hatte ja auch in meinem allerersten Threadbeitrag gleich darauf hingewiesen, dass diese Art des Codings eigentlich über meinem Niveau ist; offen gesagt bin ich recht froh und ziemlich überrascht, dass das bis hierher halbwegs unfallfrei gediehen ist...

Hilfe ist daher sehr willkommen :) !

An sich habe ich an der Stelle "nur" versucht, das nachzuvollziehen, was in der bisherigen Ack-Logik drin war (in 00_MYSENSORS.pm) und auf die Zwecke hier umzumodeln.

Zitat von: Sidey am 22 Juli 2018, 01:11:23
2) In Zeile 913 steht folgendes:

$hash->{retainedMessages}=scalar(@$messages) if (defined $hash->{retainedMessages});


In Zeile   928 dieses

  $hash->{retainedMessages}=scalar(@$messages);


Ich habe in dem Quellcode nirgends etwas gefunden in dem $hash->{retainedMessages} definiert worden wäre außer in Zeile 928.


3) schaue ich mir $messages an:
Zeile 908

    my $messages = $hash->{retainedMessagesForRadioId}->{messages};


Ich habe die Stelle nicht gefunden in der $hash->{retainedMessagesForRadioId} oder ->{messages} definiert wird.

Wolltest Du hier vielleicht mit $hash->{MessagesForRadioId} arbeiten?

Grüße Sidey
$hash->{retainedMessagesForRadioId} oder ->{messages} sollte nach meinem Verständnis in Zeilen 913 ("my $messages = $hash->{retainedMessagesForRadioId}->{messages};") iVm. Zeile 918 ("$messages = {messages => [%msg]};") initialisiert werden; der Unterschied zu der Vorlage aus dem Ack-Code besteht nur darin, dass bei der Initialisierung gleich die Nachricht reingeschrieben wird und nicht nur der Datenbereich definiert; in Zeile 918 kommt der Ablauf ja auch nur, wenn der Hash noch nicht definiert ist, sonst wird der Zweig darunter mit dem push genutzt (und das Array vorher auf Infos an denselben Endpunkt durchsucht, die dann nicht in das neue Array gehen).

Komisch ist nur, dass - egal ob über Variante 1 oder 2 - das Array eigentlich vorhanden sein müßte, wenn man zu Zeile 928 kommt; hier könnte eventuell  ein Zusammenhang mit dem "unkorrekten" Zustand (nur scheinbar asleep)  bestehen.

Jedenfalls muß es ein anderer Hash als $hash->{MessagesForRadioId} sein, denn dort steht drin, was bereits gesendet wurde, für das aber noch kein Ack erhalten wurde.

An sich scheint das alles auch soweit zu funktionieren, wenn man an eine schlafende Node z.B. einen Request für extended_DEBUG und RSSI sendet, wird das internal sauber auf 2 hochgezählt und wird dann auch wieder 0, wenn alles durch ist und (hoffentlich) die Werte zurückgemeldet wurden. Man muß nur einen refresh des Browsers durchführen, dann sieht man jeweils die Änderungen.

Aber wie gesagt, ich bin kein geübter Perl-Programmierer und das kann alles auch ganz anders sein...

Und wenn du Tips hast, wie wir die verbliebenen Punkte vollends gelöst bekommen, wäre das super:
Zitat von: Beta-User am 20 Juli 2018, 07:44:24
- das Löschen der "normalen"/alten Readings klappt noch nicht innerhalb der get-Funktion (bzw. Presentation-Auswertung);
- manchmal wird eine smartSleep-Node nicht als schlafend vermerkt, wenn parallel eine der "Stapelverarbeitungsfunktionen" (RSSI oder extendedDebug) ausgeführt wird.
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

So, mit der neuesten Version funktioniert es scheinbar gleich beim ersten Versuch.
Ich vermute aber, dass irgendwo noch eine Schleife falsch läuft, weil ich das log so verstehe, dass mehrfach der gleiche Block
Firmware block request 1089 (type 40, version 25) verschickt wird. Warum auch immer.

Anbei mal ein Auszug

2018.07.22 11:46:03 5: MYSENSOR_105: Firmware block request 1089 (type 40, version 25)
2018.07.22 11:46:03 5: MYSENSORS send: Rx: fr=105 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=1 '2800190041044095309521953F4F4F4F5F4F08959095'

2018.07.22 11:46:03 5: SW: 3130353b3235353b343b313b333b32383030313930303431303434303935333039353231393533463446344634463546344630383935393039350a
2018.07.22 11:46:03 5: MYSENSOR_105: refreshInternalMySTimer called (Ack)
2018.07.22 11:46:03 4: MYSENSOR_105: Ack timeout timer set at 1532253063.46479
2018.07.22 11:46:03 5: MYSENSOR_105 is not sleeping, sending message!
2018.07.22 11:46:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 11:46:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 11:46:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 11:46:03 4: MYSENSORS Read: Rx: fr=105 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '280019004104'

2018.07.22 11:46:03 5: MYSENSOR_105: Firmware block request 1089 (type 40, version 25)
2018.07.22 11:46:03 5: MYSENSORS send: Rx: fr=105 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=1 '2800190041044095309521953F4F4F4F5F4F08959095'

2018.07.22 11:46:03 5: SW: 3130353b3235353b343b313b333b32383030313930303431303434303935333039353231393533463446344634463546344630383935393039350a
2018.07.22 11:46:03 5: MYSENSOR_105: refreshInternalMySTimer called (Ack)
2018.07.22 11:46:03 4: MYSENSOR_105: Ack timeout timer set at 1532253063.62172
2018.07.22 11:46:03 5: MYSENSOR_105 is not sleeping, sending message!
2018.07.22 11:46:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 11:46:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 11:46:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 11:46:03 4: MYSENSORS Read: Rx: fr=105 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '280019004104'

2018.07.22 11:46:03 5: MYSENSOR_105: Firmware block request 1089 (type 40, version 25)
2018.07.22 11:46:03 5: MYSENSORS send: Rx: fr=105 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=1 '2800190041044095309521953F4F4F4F5F4F08959095'

2018.07.22 11:46:03 5: SW: 3130353b3235353b343b313b333b32383030313930303431303434303935333039353231393533463446344634463546344630383935393039350a
2018.07.22 11:46:03 5: MYSENSOR_105: refreshInternalMySTimer called (Ack)
2018.07.22 11:46:03 4: MYSENSOR_105: Ack timeout timer set at 1532253063.77708
2018.07.22 11:46:03 5: MYSENSOR_105 is not sleeping, sending message!
2018.07.22 11:46:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 11:46:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 11:46:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 11:46:03 4: MYSENSORS Read: Rx: fr=105 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '280019004104'

2018.07.22 11:46:03 5: MYSENSOR_105: Firmware block request 1089 (type 40, version 25)
2018.07.22 11:46:03 5: MYSENSORS send: Rx: fr=105 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=1 '2800190041044095309521953F4F4F4F5F4F08959095'

2018.07.22 11:46:03 5: SW: 3130353b3235353b343b313b333b32383030313930303431303434303935333039353231393533463446344634463546344630383935393039350a
2018.07.22 11:46:03 5: MYSENSOR_105: refreshInternalMySTimer called (Ack)
2018.07.22 11:46:03 4: MYSENSOR_105: Ack timeout timer set at 1532253063.96112
2018.07.22 11:46:03 5: MYSENSOR_105 is not sleeping, sending message!
2018.07.22 11:46:04 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 11:46:04 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 11:46:04 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 30 40 50 60 70 75 80 90 100 111 112 120 130 150 200
2018.07.22 11:46:08 4: MYSENSORS/RAW: /105;255;4;0;2;280019004104


Nach ca. 10 Minuten Updateprozess bin ich nun bei Firmware block request 914 (type 40, version 25) und ich habe den Eindruck, dass die Anzahl der Wiederholungen je Paket bei jedem neuen Paket mehr werden.

@Beta-User: Wenn Du mir eine PN mit Deiner Adresse schickst, schicke ich Dir per Post gerne eine unbestückte Platine (https://www.openhardware.io/view/28/Very-narrow-and-minimal-switch-node) und einen passenden SMD NRF24L01+ sozusagen als kleines Danke für Deinen Aufwand hier ... dann kannst Du selber besser debuggen ;)
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

Zitat von: dirkcx am 22 Juli 2018, 11:55:34
Ich vermute aber, dass irgendwo noch eine Schleife falsch läuft, weil ich das log so verstehe, dass mehrfach der gleiche Block
Firmware block request 1089 (type 40, version 25) verschickt wird. Warum auch immer.
Der Hinweis war m.E. zielführend: das Problem dürfte  das Ack sein ::) ; habe den Anhang zu Post 1 nochmal geändert, jetzt gehen diese update-Messages erst mal alle zwangsweise ohne Ack raus. Wenn ich dann endlich soweit bin, dass ich mit eigener HW teste wird dann ausgefiltert werden, ob es ein Ack war oder ein "echter Request" (es sei denn, die Node fragt aktiv nach, wenn was verloren gegangen sein sollte).

Aber jetzt mach' ich auch erst mal wieder was anderes, crashes scheint es ja derzeit keine mehr zu geben...

Danke auch für das Angebot mit der HW; ich habe eigentlich alles da liegen, um eine MYSBootloader-Node zusammenzubasteln (bzw. die liegt hier schon rum und muß nur den richtigen BL bekommen) und auch ein 2. Kanal76-GW, gleiches gilt für eine RFM69-Node mit BualOptiboot und mach' das dann auch irgendwann. Allerdings wäre ich alleine nicht so ohne weiteres auf das eine oder andere gekommen, jeder erledigt die Dinge halt doch auf seine Weise ;) . Mittelfristig wird dann bei mir neben RS485 eher RFM69 (und RFM95) zum Einsatz kommen.
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

Nun hatte ich wieder einen fhem Absturz mit der allerneuesten Version, bitte wieder die Version vor heute Mittag zurücklegen, ich habe kein Backup.

fhem hat immer wieder versucht, die neue Firmware-Version zu updaten, kam aber nicht weiter als bis zum ersten Block. Daher habe ich fhem neu gestartet, weil ich dachte, das Modul hängt in einer Schleife... ich habe das mit OTA_autoupdate 1 und 0 sowie mit und ohne RequestAck versucht.

Nach dem Neustart von fhem habe ich ich bei einem smartSleep() Node "get Version" abgeschickt und dann kam der Absturz. Letzter Eintrag im Log:

2018.07.22 13:44:25 5: MYSENSOR_108 is sleeping, enqueueing message!
2018.07.22 13:44:25 4: MYSENSOR_108: No array yet for enqueued message, building it!
Not an ARRAY reference at ./FHEM/10_MYSENSORS_DEVICE.pm line 928.


Das mit dem "zwangsweise ohne Ack" war vermutlich keine gute Idee ;)

Jetzt habe ich den "Restprozess" von fhem per "sudo kill -9 <pid>" abgeschossen und nun kann ich den fhem-service nicht mehr per "sudo systemctl start fhemserver"
starten. Neustart des RPi notwendig  :'(
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

Ups, das war nicht beabsichtigt.

Die Version von heute vormittag ist als "requested" im ersten Post, allerdings bin ich ziemlich sicher, dass das nicht die Absturzursache war, sondern weiterhin der nicht initialisierte Hash. Deswegen eine weitere Fassung der "Device" auch im Ausgangspost, die das Problem auch für alle anderen abfangen sollte - es wird der Hash im ersten Durchlauf mit "1" belegt und das eval() nur noch durchgeführt, wenn das Array erweitert wird.

Die Ack-Sache habe ich auch dahingehend geändert, dass die Ack-Rückmeldungen (hoffentlich) an der richtigen Stelle verworfen werden. (Info an dirkcx: vorher war es so gewesen, dass man am Device oder GW zu requestAck einstellen konnte, was man wollte, es war immer wirkungslos...).
Allerdings kann ich nicht sagen, ob damit jetzt noch ein update funktioniert.

Jetzt mach ich mich mal kurz ans Testen (Laden geht, es kommen auch Werte rein, aber viel mehr habe ich im Moment noch nicht getestet, muß erst mal die Antenne wieder an meine RFM-Node löten...)

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

Zitat von: Beta-User am 22 Juli 2018, 16:34:44Jetzt mach ich mich mal kurz ans Testen
Zwischenstand dazu: Testnode gelöscht und dann wieder neu angelegt. Kein Absturz, RSSI-Werte lassen sich abfragen, scheint also jedenfalls nicht schlechter zu sein als vorher...
Nodes für update-Tests kann ich nicht vor Mittwoch bauen (aber auch da wird es eher nicht reichen).
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

Sidey

#87
Zitat von: Beta-User am 22 Juli 2018, 11:29:52
$hash->{retainedMessagesForRadioId} oder ->{messages} sollte nach meinem Verständnis in Zeilen 913 ("my $messages = $hash->{retainedMessagesForRadioId}->{messages};") iVm. Zeile 918 ("$messages = {messages => [%msg]};") initialisiert werden; der Unterschied zu der Vorlage aus dem Ack-Code besteht nur darin, dass bei der Initialisierung gleich die Nachricht reingeschrieben wird und nicht nur der Datenbereich definiert; in Zeile 918 kommt der Ablauf ja auch nur, wenn der Hash noch nicht definiert ist, sonst wird der Zweig darunter mit dem push genutzt (und das Array vorher auf Infos an denselben Endpunkt durchsucht, die dann nicht in das neue Array gehen).

Kleines Zitat aus der Perldoc:

Use of defined on aggregates (hashes and arrays) is no longer supported. It used to report whether memory for that aggregate had ever been allocated. You should instead use a simple test for size:

Kommt vermutlich darauf an, welche Perlversion man verwendet. So wie ich das einschätze ist $messages genau so ein Datentyp und die Zeile
unless (defined $messages) {

sagt nur aus, dass für $messages speicher belegt wird.

Mal generell um das ganze überschaubarer zu machen. Ich würde beim define des Gerätes alle hashes und Arrays anlegen die gebraucht werden.
Wenn dann ein Wert aufgenommen werden soll mittels push etwas reinlegen und mittels pop oder shift entfernen.


Das würde ich einfach mal generell für alles so machen. Dann wiesst Du sicher, dass ein Datenbereich initialisiert ist und bist nicht davon Abhängig, ob irgendeine Prüfung korrekt interpretiert wurde.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Beta-User

Hallo zusammen,

nachdem ich gestern noch etwas an dem Perldoc-Thema rumgekaut habe, hat es leider wieder nicht gereicht, auch HW für die OTA-Sachen aufzubauen.

Kleiner Zwischenstatus: die im ersten Post am So. angehängte Version 10_MYSENORS_DEVICE.pm sollte keine _zusätzlichen_ Probleme (mehr) verursachen.  Allerdings wird das abgekündigte "defined" vermutlich irgendwann an noch mehr Stellen des gesamten (auch älteren) Codes zu Problemen führen. Danke an Sidey für den Hinweis! Das sollte man also auch an allen relevanten Stellen grundsätzlich anders lösen. Soweit ich das überblicke, betrifft es die Ack-Teile (vorrangig die Array-Verwaltung in 00_MYSENSORS.pm, zum Rest s.u.) und eben die hier diskutierte retainedMessages-Logik. Um das zu fixen, kann man hier "if (ref $messages eq 'ARRAY') ..." verwenden, an anderen Stellen muß ggf. nach 'HASH' geprüft werden. Sowas scheint jedenfalls auch bei undefinierten Elementen nicht zum Abschmieren von FHEM zu führen.

Zum weiteren Hinweis von Sidey zur Gliederung des Codes: Testweise war das auch mal so angepaßt, das im Define-Teil ein leeres Array bereitgestellt wurde. Das hat aber den Nachteil, dass da erst mal ein (leeres) Element vorhanden ist, was erst mal - im ersten Sleep-Zyklus - zu der (falschen) Angabe geführt hat, dass eine smartSleep-Node noch eine Nachricht zu erhalten hätte. Hmm... Hab's daher erst mal so gelassen, wie es bisher war.

Bei meinen gestrigen Aktivitäten war allerdings festzustellen, dass es irgend ein Problem mit Messages zu geben scheint, die gleich beim Aufruf von sendClientMessage() ein "ack => 1" (oder 0) mitbekommen. Diese Messages gehen scheinbar durch den ganzen flow, werden aber _alle_ so behandelt, als wäre ack auf 0 gesetzt (und gingen in meinen Tests dann teilweise verloren). Wenn da jemand eine Idee hat: her damit. Meine eigene: da ist wieder das "defined" drin, allerdings auf einen HASH. Werde daher erst mal die diesbezüglichen Teile auf obige Abfragevariante umstellen.

M.E. hat das Vorrang vor der OTA-Test-Hardware; da ich am So. noch das Verwerfen von Ack-Rückmeldungen in den OTA-Teil reingebaut hatte, wäre ich für eine Rückmeldung dankbar, ob das das "Aufschaukeln" der Message-Anzahl verhindert ;) .

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

Beta-User

#89
Anbei die aktualisierten Fassungen der 00_MYSENSORS.pm und 10_MYSENSORS_DEVICE.pm.

EDIT: Anhänge gelöscht

Da das Ack-Handling etwas umgestellt wurde und jetzt alle internen Messages zwangsweise ohne Ack rausgehen, kann es sein, dass das so nicht in jedem Punkt so funktioniert wie bisher oder von euch erwartet. Deswegen bleiben die alten Fassungen auch erst mal im ersten Post, dazu gab es ja bislang jedenfalls keine allzu kritischen Rückmeldungen.

Die 00_MYSENSORS.pm ist eigentlich nur im Hinblick auf zukünftige Perl-Versionen bezgl. des "define"-Themas angepaßt. Zur besseren Orientierung habe ich mal angefangen, zusaätzlich ein paar Kommentare einzufügen, hoffe, das hilft etwas. Der Code ist insgesamt etwas unübersichtlich, weil man an der einen Stelle was auslöst, aber an einer ganz anderen Stelle die Reaktion darauf findet (besonders undurchsichtig bei der Comment->Reading-Sache, dass das indirekt über den I-SKETCH_NAME läuft).

In 10_MYSENSORS_DEVICE.pm ist neben der oben erwähnten Vermeidung von Acks für interne Messages neu, dass jetzt auch das Löschen der alten "mapReading_"-Attribute klappt. Der Teil fehlt für setReading allerdings noch. Da gibt es ebenfalls einen Merker für den Stand des Prozesses: Gestartet ist der Prozess mit getCommentReadings = 1, erfolgreich durchgelaufen mit getCommentReadings = 2. Das Internal verschwindet allerdings erst wieder, wenn eine erneute Presentation erfolgt - leider kann man nicht so einfach feststellen, wenn alle Children präsentiert sind. Es ginge evtl., an den ersten Sensorwert anzuknüpfen, aber dann müßte man das jedes Mal machen, wenn irgendwas aktualisiert wird, was ein ziemlich unnötiger Overhead wäre. Bei Gelegenheit kommt das (und auch die anderen beiden Durchlauf-Merker) in den Hintergrund, so dass man es nur noch in einem list sieht.

Bekanntes Problem: Man muß die erste Anfrage an eine schlafende Node doppelt machen, da stimmt vermutlich etwas mit der Initialisierung des Arrays nicht.

Zu dem Ack-Thema  noch ein paar Bemerkungen:
- Eigentlich sollte es so sein, dass man die Anzahl der noch nicht zugestellten Messages mit Ack-Request an der jeweiligen Node und am GW (dort als Gesamtzahl für alle zugehörigen Nodes) sieht. Worüber ich neulich gestolpert bin ist der Umstand, dass das an der Node vermutlich noch nie funktioniert hat - da steht immer eine "0".
- Am GW sieht man dann den tatsächlichen Stand, allerdings ist der bestehende Code nicht für Acks auf interne Messages gemacht (jedenfalls, was RFM-Nodes angeht; mind. die erzeugen die Acks in Software) - ich gehe mal davon aus, dass sich der MySensors-Node-Code darauf beschränkt, mind. auf bestimmte Anforderungen schlicht die Antwort zurückzusenden, statt den Erhalt der Frage zu bestätigen. Das macht es nicht so einfach, das Sende-Array zu durchsuchen, ob die Antwort zur Frage paßt... Damit hat man bei internen Messages das Problem, dass der Zähler am GW dann auf einem zu hohen Wert stehen bleibt, also auf ein Problem hindeutet, das gar nicht (mehr) existiert.

Das ist der Grund, warum die Acks ausgeschaltet sind; sonst scheint es zu einer Art Schleife zu kommen. Die vermeintlich nicht zugestellten Nachrichten werden sonst wieder und wieder gesendet. Der Nachteil ist der, dass jetzt Nachrichten verloren gehen können, und damit z.B. die Abfrageschleifen für RSSI und extendedDebug nicht komplett durchlaufen. Die muß man dann halt nochmal anstoßen.

Wer dazu eine Idee hat: her damit.

Ich werde vermutlich die nächste Zeit nicht dazu kommen, da viel dran weiterzumachen, daher eben mal wieder nur ein Zwischenstand.

Gruß, Beta-User

EDIT: mit der beigefügten Version der 10_... bleiben manuelle mapReading-Vorgaben erhalten, wenn die Node bei der Presentation eines Childs keinen Kommentar sendet.
Weiter werden jetzt zurückgehaltene Messages erst nach der PRESLEEP-Notification versendet. Das scheint besser zu sein, weil es dann weniger Kollissionen mit Sendungen gibt, die die Node erst mal loswerden will...
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