Vorarbeiten: Update auf MySensors 2.0-API

Beta-User · 21 Juli 2018, 19:53:30

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

dirkcx · 21 Juli 2018, 21:34:27

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

Sidey · 22 Juli 2018, 01:11:23

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:

Code Auswählen


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

In Zeile 928 dieses

Code Auswählen

 
  $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

Code Auswählen


    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

Beta-User · 22 Juli 2018, 06:41:41

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.

dirkcx · 22 Juli 2018, 09:16:22

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".

Code Auswählen


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.

Code Auswählen


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

Beta-User · 22 Juli 2018, 10:26:51

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!

Beta-User · 22 Juli 2018, 11:29:52

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:
Code Auswählen Erweitern
$hash->{retainedMessages}=scalar(@$messages) if (defined $hash->{retainedMessages});

In Zeile 928 dieses
Code Auswählen Erweitern
$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
Code Auswählen Erweitern
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.

dirkcx · 22 Juli 2018, 11:55:34

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

Code Auswählen

Firmware block request 1089 (type 40, version 25) verschickt wird. Warum auch immer.

Anbei mal ein Auszug

Code Auswählen


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

Code Auswählen

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

Beta-User · 22 Juli 2018, 12:50:00

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
Code Auswählen Erweitern
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.

dirkcx · 22 Juli 2018, 13:56:01

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:

Code Auswählen


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

Beta-User · 22 Juli 2018, 16:34:44

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...)

Beta-User · 22 Juli 2018, 16:48:00

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).

Sidey · 22 Juli 2018, 23:22:10

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

Code Auswählen

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

Beta-User · 26 Juli 2018, 12:15:26

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

Beta-User · 29 Juli 2018, 08:30:40

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