Vorarbeiten: Update auf MySensors 2.0-API

[dirkcx]

Wenn ich mit den im ersten Post angehängten Dateien in einem Node den fwType setzen will, kommt die Meldung ,,fwType must be numeric"

Die csv Datei sieht so aus

Code Auswählen Erweitern


Type,Name,Version,File,Comments
1,MultiSensor,22,MultiSensor.ino.arduino_standard.hex,Der Standard Sensor
2,simpleHeartbeat,22,simpleHeartbeat.ino.arduino_standard.hex,Test mit Heartbeat
3,MultiSensorBME,22,MultiSensorBME280.ino.arduino_standard.hex,Der Standard Sensor mit BME
...


In der Combobox für fwType werden die Nummern der ersten Spalte der csv Datei richtig angezeigt.

Ich habe dann trotzdem mal ,,set MYSENSOR_5 flash" geklickt und dann kommt das hier:

MYSENSOR_5: Expected bootloader version 3.0 but found

[Beta-User]

Nochmal ein kleiner update zu der device-pm. Hatte die childID für diverse Anfragen noch nicht auf 255 stehen, kann sein, dass das jetzt immer noch nicht vollständig ist.

@dirkcx:
Hast du vorher mal ein get ... version abgesetzt? Es müssen nach meinem Verständnis erst die Infos, die darüber kommen als readings vorhanden sein - wenn schon das nicht klappt, kann es nicht gehen.

@Ranseyer:
Ich habe mal zu dem RSSI-Thema etwas rumgesucht, und bin auf das hier gestoßen: https://forum.mysensors.org/post/56104
Es scheint wenn, dann nur mit dem NEW_DRIVER zu gehen.
Eventuell kannst du mal "sendSignalStrength(const int16_t level, const bool ack = false);" nutzen (core Zeile 185) und dann vorher den level bestimmen; dazu gibt es eine Funktion in der RFM69-Transport.

[dirkcx]

@dirkcx:
Hast du vorher mal ein get ... version abgesetzt? Es müssen nach meinem Verständnis erst die Infos, die darüber kommen als readings vorhanden sein - wenn schon das nicht klappt, kann es nicht gehen.

Ich habe alle "get ..." gemacht und jedes mal danach ein Refresh der Seite, weil nach dem "get" keine sichtbare Reaktion von fhem kam. Der Refresh hat nur den I_DEBUG Wert geändert.

Die "raw-definition" des Nodes zeigt, dass keine neuen Readings dazugekommen sind durch die "get" Abfragen, außer "nowSleeping" und "heartbeat":

Code Auswählen Erweitern


define MYSENSOR_5 MYSENSORS_DEVICE 5
attr MYSENSOR_5 IODev mySensorsGW
attr MYSENSOR_5 alias Test Switch2
attr MYSENSOR_5 mapReading_armed2 2 armed
attr MYSENSOR_5 mapReading_current101 101 current
attr MYSENSOR_5 mapReading_current102 102 current
attr MYSENSOR_5 mapReading_id103 103 id
attr MYSENSOR_5 mapReading_impedance101 101 impedance
attr MYSENSOR_5 mapReading_impedance102 102 impedance
attr MYSENSOR_5 mapReading_temperature103 103 temperature
attr MYSENSOR_5 mapReading_tripped2 2 tripped
attr MYSENSOR_5 mapReading_voltage101 101 voltage
attr MYSENSOR_5 mapReading_voltage102 102 voltage
attr MYSENSOR_5 mode node
attr MYSENSOR_5 requestAck 1
attr MYSENSOR_5 timeoutAlive 10800
attr MYSENSOR_5 version 2.2.0
setstate MYSENSOR_5 2018-06-24 11:28:26 heartbeat last
setstate MYSENSOR_5 2018-06-24 11:28:26 nowSleeping 1
setstate MYSENSOR_5 2018-06-24 11:28:26 state alive
setstate MYSENSOR_5 2018-06-24 11:28:26 temperature103 24.5
setstate MYSENSOR_5 2018-06-24 11:28:26 voltage101 2.72
setstate MYSENSOR_5 2018-06-24 11:28:26 voltage102 2707


Internals:

Code Auswählen Erweitern


Internals
CFGFN ./conf/fhem_mysensors.cfg
DEF 5
IODev mySensorsGW
I_DEBUG F
NAME MYSENSOR_5
NR 673
TYPE MYSENSORS_DEVICE
ack 1
nexttry -1
outstandingAck 0
protocol 2.2.0
radioId 5
repeater 0
timeoutAck 0
timeoutAlive 10800


Update: zwischenzeitlich kamen doch noch ein paar Readings dazu, die Fehlermeldungen bleiben die Gleichen:

Code Auswählen Erweitern


setstate MYSENSOR_5 2018-06-24 12:09:19 BL_VERSION 1.3
setstate MYSENSOR_5 2018-06-24 12:09:19 FW_BLOCKS 624
setstate MYSENSOR_5 2018-06-24 12:09:19 FW_CRC 41187
setstate MYSENSOR_5 2018-06-24 12:09:19 FW_TYPE 80
setstate MYSENSOR_5 2018-06-24 12:09:19 FW_VERSION 20
setstate MYSENSOR_5 2018-06-24 12:09:26 SKETCH_NAME Door Window Switch (I2C)
setstate MYSENSOR_5 2018-06-24 12:09:26 SKETCH_VERSION 2.2.0


noch ein Update: im fhem.log kommt noch folgende Fehlermeldung:

Code Auswählen Erweitern

Can't use an undefined value as an ARRAY reference at ./FHEM/10_MYSENSORS_DEVICE.pm line 401.

Update 3:

Code Auswählen Erweitern

PERL WARNING: Use of uninitialized value in string ne at ./FHEM/00_MYSENSORS.pm line 421.
nach einem externen FOTA stürzt nun fhem komplett ab (reproduziert)

Code Auswählen Erweitern

PERL WARNING: "my" variable $name masks earlier declaration in same scope at ./FHEM/00_MYSENSORS.pm line 460, <$fh> line 5.

[Beta-User]

So ganz steige ich bei dem OTA-Ablauf noch nicht durch, vielleicht kann da @Wallmeier noch etwas Aufklärung beisteuern.

Nach meinem Verständnis ist es erforderlich, die Firmware-CSV auch beim entsprechenden Gateway als Attribut zu hinterlegen. Da fileread verwendet wird: Wenn du confiDB nutzt, muß die firmware m.E. auch in die Datenbank importiert werden.

Für den Fall, dass das insgesamt schon funktionieren sollte: Kann jemand ein paar Stichworte zum Ablauf für den Starter-Guide zusammenstellen? Die wechselseitigen Abhängigkeiten und erforderlichen Vorarbeiten lasse sich m.E. nur sehr bedingt aus der aktuellen commandref ablesen (und gehören im Detail da auch nicht rein).

Was ich bisher verstanden habe:

- Bootloader: entweder optiboot von MySensors + SPI-Memory oder nRF24 mit 1.3-beta-Tekka-Bootloader + Kanal 76 am GW
- GW: CSV als Attribut
- Node: get version (?)

Und dann update-Aufruf mit

[Beta-User]

Ergänzend noch die Info, dass in der letzten Version das mit dem smartSleep  angetestet ist und erweitert. Nunmehr wird auch "state" mit "sleeping" bzw. "awoken" gefüllt, wenn sich die Node entsprechend meldet. Soweit funktioniert das also.

Beides ist triggernd ausgeführt, Ausnahme ist, wenn die Node auf NACK steht.

Ob auch verzögernd was gesendet werden kann, ist noch ungetestet...

[dirkcx]

Mein Setup bislang mit Nutzung von MYSController.

Gateway: ESP8266 mit NRF24L01 PA LNA
+ 1 Repeater mit NRF24L01 PA LNA
ca. 12 Nodes mit NRF24L01+, meist Sensoren, teilw. mit Relays, die batteriebetriebenen laufen alle mit smartSleep() und wachen i.d.R. alle 10 Minuten kurz auf
MySensors Version: 2.2.0
Default Kanal: 76

Bootloader: https://github.com/mysensors/MySensorsBootloaderRF24 in Version 1.3 (Standard, aber selber compiliert)

Updateprozess mit MYSController:

Die *.hex Datei wird in der *.csv Datei nach o.g. Muster eingetragen, wobei die Zahlen meines Wissens nach keine Relevanz haben.
In MYSController wird der Node ausgewählt und per Kontextmenü (Screenshot im Anhang) stelle ich den Node als MYSBootloder Node ein.
Dann wähle ich im Kontextmenü "AssignFW" und wähle eine Firmware aus, die aus der csv-Datei kommt.
Wenn der Node dann beim nächsten Intervall aufwacht, startet das Update...

Es gibt noch einen Versuch für FOTA mittels Python, funktionierte aber leider bei mir nur einmal bislang und ich kann das leider nicht rekonstruieren.
https://github.com/theolind/pymysensors

[Ranseyer]

@Betauser:
...falls du als kleines Dankeschön für deinen Einsatz je einen Node+GW für RFM69 und zweiten LoRa haben möchtest für Testzwecke wäre das kein Problem...

[Beta-User]

@dirkcx:
Es war eher der Ablauf innerhalb FHEM gemeint, also was man wie einstellen muß. Bist du da weiter gekommen? Bzw. kann jemand "wissendes" weiterhelfen und ggf. verifizieren, dass ich keinen Bug reingebaut hab' beim zusammenklauben der Code-Versionen...
Ansonsten würde mich interessieren, ob die smartSleep-Geschichten bei dir zielsetzungsgemäß schon funktionieren (ich habe nur kurz eine RS485-smartSleep-Node zusammengeschustert und mit "get heartbeat" getestet - das hat prompt nicht funktioniert . War aber eigentlich auch nicht realistischerweise zu erwarten.

@Ranseyer:
Sehr nettes Angebot . Nehme ich gerne an, du darfst mir auch gerne sagen, was du haben wolltest für das LoRa-Päarchen - ich habe evtl. nämlich seit ein paar Tagen eine praktische Anwendung dafür, sofern ca. 5km Luftlinie mit näherungsweise Sichtverbindung realisierbar wären .
Damit sind dann demnächst alle 8 USB-Ports an dem T5740 belegt  - es liegt noch ein umzuflashender CC2531 (?) für zigbee rum (vermutlich die MQTT-Variante).

[Beta-User]

@dirkcx

Unterstützt wird aktuell die Variante DualOptiBoot mit externem Flash-Speicher - dabei wird das neue Hex-File vom laufenden Sketch auf dem Node empfangen und im externen Flash abgelegt. Sobald das Hex-File komplett empfangen wurde, wird über den Bootloader das eigentliche Flashen des AtMegas durchgeführt.

Du nutzt doch den anderen Bootloader, oder? Sieht so aus, als wäre das firmware-upload-Kommando nicht der richtige Initiierungsweg.

Kannst du mal versuchen, ob der upload loslegt, wenn du einen Reboot von FHEM aus initiierst? Dann müßte die Node eine entsprechende Anfrage an FHEM senden, und wenn wir großes Glück haben, geht es dann direkt los. Ansonsten bitte mal ein verbose 5 auf die Node legen und dann nochmal versuchen. Vielleicht finden wir raus, auf was wir hören müssen, um dann den firmware-Sendeprozess zu starten. Danach gerne Verbose wieder zurück auf 3. Vor dem 2. Versuch muß die Node natürlich erst wieder in den normalen Betriebsmodus zurückgefunden haben (macht sie glaube ich nach einem timeout von 30 Sek. oder so).

[Wallmeier]

Bzgl. FOTA habe ich nur Erfahrung mit dem DualOptiBoot. Dabei ist das Vorgehen wie folgt:

• Im Firmware-Verzeichnis braucht es eine Datei csv-Datei, die definiert, welche Firmwares es für MySensors gibt. Das Format habe ich 1:1 vom MYSController übernommen, wie es auch unter https://www.mysensors.org/about/fota beschrieben ist
• Die Firmware-Dateien (*.hex) müssen auch ins firmware-Verzeichnis gelegt werden
• Jedem Node kann man einen Firmware-Typ mittels der Setter-Funktion fwType zuweisen
• Mit der Funktion flash kann man dann den Node flashen
• Zusätzlich habe ich in dem ursprünglichen Patch das Attribute autoUpdate eingeführt, dass dazu dient, dass, wenn der Node gebootet hat, nachsieht, ob es eine neuere Firmware gibt und diese automatisch an den Node schickt

Da ich selber keine ConfigDB nutze, kann ich nicht sagen, was sich durch den Einsatz von ConfigDB an dem Vorgehen ändert...

Zur Zeit betreibe ich den Node nur in einem Testaufbau (und somit nicht produktiv) und bin noch bei MySensors 2.2.0 hängen geblieben. Ich werde die Tage mal auf 2.3.0 updaten und dann auch die neue fhem Implementierung aus dem ersten Post testen...

[dirkcx]

@Beta-User

Nach meinem Verständnis läuft der OTA Prozess im Bootloader wie folgt ab, siehe auch Details unter https://github.com/mysensors/MySensorsBootloaderRF24:

Nach dem Reboot sendet der Bootloader einen ConfigRequest an das Gateway und fragt Infos zur Firmware ab.
Darauf antwortet das Gateway mit Infos zur Firmware (type, version, blocks, crc).
Bekommt er die nicht, startet das normale Sketch, ansonsten schickt das Gateway sukzessive Datenpakete an den Bootloader als normale Message, wobei der Nachrichteninhalt die binär-codierte Firmware zeilenweise enthält.

Das sieht im log des MYSController dann so aus:

Code Auswählen Erweitern


[2018-05-06 20:00:54.804 Info] RX 5;255;4;0;0;FFFFFFFFFFFFFE400103
[2018-05-06 20:00:54.805 Info] DEBUG Undefined firmware/type for node=5
[2018-05-06 20:00:54.805 Info] INFO BL version=259
[2018-05-06 20:00:54.806 Info] INFO No FW assigned
[2018-05-06 20:00:57.895 Info] RX 5;255;4;0;0;FFFFFFFFFFFFFE400103
[2018-05-06 20:00:57.896 Info] DEBUG Undefined firmware/type for node=5
[2018-05-06 20:00:57.896 Info] INFO BL version=259
[2018-05-06 20:00:57.896 Info] INFO No FW assigned
[2018-05-06 20:01:00.277 Info] TX 5;0;3;0;13;0
[2018-05-06 20:01:00.279 Info] INFO FW "DoorWindowSwitchV20" assigned to node 5
[2018-05-06 20:01:00.991 Info] RX 5;255;4;0;0;FFFFFFFFFFFFFE400103
[2018-05-06 20:01:00.992 Info] CHILD New child discovered, node id=5, child id=internal
[2018-05-06 20:01:00.993 Info] DEBUG Undefined firmware/type for node=5
[2018-05-06 20:01:00.993 Info] INFO BL version=259
[2018-05-06 20:01:00.994 Info] INFO Send FW info to node 5: type=50, version=14, blocks=0x0270, CRC=0xA0E3
[2018-05-06 20:01:00.995 Info] TX 5;0;4;0;1;500014007002E3A0
[2018-05-06 20:01:01.029 Info] RX 5;255;4;0;2;500014006F02
[2018-05-06 20:01:01.030 Info] DEBUG FW update started, node id = 5
[2018-05-06 20:01:01.031 Info] TX 5;255;4;0;3;500014006F020E3C0F00FFFFFFFFFFFFFFFFFFFFFFFF
[2018-05-06 20:01:01.048 Info] RX 5;255;4;0;2;500014006E02
[2018-05-06 20:01:01.050 Info] TX 5;255;4;0;3;500014006E02003100000000005E0FC410E00EF90EEB
[2018-05-06 20:01:01.064 Info] RX 5;255;4;0;2;500014006D02
[2018-05-06 20:01:01.066 Info] TX 5;255;4;0;3;500014006D0220706F77657200436869702074656D70
[2018-05-06 20:01:01.085 Info] RX 5;255;4;0;2;500014006C02
[2018-05-06 20:01:01.087 Info] TX 5;255;4;0;3;500014006C026E736F72004261747465727900414443
[2018-05-06 20:01:01.105 Info] RX 5;255;4;0;2;500014006B02
[2018-05-06 20:01:01.107 Info] TX 5;255;4;0;3;500014006B022900646F6F722F77696E646F77207365
[2018-05-06 20:01:01.129 Info] RX 5;255;4;0;2;500014006A02
[2018-05-06 20:01:01.130 Info] TX 5;255;4;0;3;500014006A026E646F77205377697463682028493243
[2018-05-06 20:01:04.286 Info] RX 5;255;4;0;2;500014006902
[2018-05-06 20:01:04.287 Info] TX 5;255;4;0;3;500014006902A30C01322E322E3000446F6F72205769
[2018-05-06 20:01:04.302 Info] RX 5;255;4;0;2;500014006802
[2018-05-06 20:01:04.303 Info] TX 5;255;4;0;3;50001400680203D900E703FF00FCE1A8A8FFFFFFA30C
[2018-05-06 20:01:04.323 Info] RX 5;255;4;0;2;500014006702
[2018-05-06 20:01:04.325 Info] TX 5;255;4;0;3;50001400670203A700FA021F055303EF043903D10417
[2018-05-06 20:01:04.338 Info] RX 5;255;4;0;2;500014006602
[2018-05-06 20:01:04.340 Info] TX 5;255;4;0;3;500014006602FFCF00003E038000FFFFFFFFFFA30194
[2018-05-06 20:01:04.356 Info] RX 5;255;4;0;2;500014006502
[2018-05-06 20:01:04.357 Info] TX 5;255;4;0;3;50001400650220BD0FB6F894FA9AF99A0FBE0895F894
[2018-05-06 20:01:04.374 Info] RX 5;255;4;0;2;500014006402
[2018-05-06 20:01:04.376 Info] TX 5;255;4;0;3;50001400640292BD81BDF89A019700B4021639F01FBA
[2018-05-06 20:01:04.390 Info] RX 5;255;4;0;2;500014006302
...
...


Dazu sind Commands vom Typ "Stream" notwendig, siehe https://www.mysensors.org/download/serial_api_20, mit den Subtypen

• ST_FIRMWARE_CONFIG_REQUEST
• ST_FIRMWARE_CONFIG_RESPONSE
• ST_FIRMWARE_REQUEST
• ST_FIRMWARE_RESPONSE

Ich hoffe, das hilft weiter.

Ich kann die fwType nicht zuordnen, daher funktioniert das auch nach Reboot nicht. Die Readings
BL_VERSION 1.3
FW_BLOCKS 624
FW_CRC 41187
FW_TYPE 80
FW_VERSION 20
bekomme ich derzeit auch nicht mehr angezeigt.

Leider sehe ich keine Reaktion auf ein Reboot unter fhem. Hier das log, allerdings sind da auch zwischendurch Nachrichten eines anderen Nodes enthalten:

Code Auswählen Erweitern


2018.06.25 21:08:14 5: MYSENSOR_5: timeoutMySTimer called (timeoutAck)
2018.06.25 21:08:14 4: MYSENSOR_5: timeoutMySTimer called (timeoutAck), outstanding: ARRAY(0x3e80040)
2018.06.25 21:08:28 5: MYSENSORS outstanding ack, re-send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''

2018.06.25 21:08:28 5: SW: 353b3235353b333b313b31333b0a
2018.06.25 21:08:30 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:30 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:30 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:30 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:30 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:30 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:31 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:31 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:31 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:31 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:31 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:31 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:32 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:32 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:42 5: MYSENSORS send: Rx: fr=005 ci=-01 c=003(C_INTERNAL    ) st=019(I_PRESENTATION  ) ack=0 ''

2018.06.25 21:08:42 5: SW: 353b2d313b333b303b31393b0a
2018.06.25 21:08:42 5: MYSENSORS outstanding ack, re-send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''

2018.06.25 21:08:42 5: SW: 353b3235353b333b313b31333b0a
2018.06.25 21:08:42 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:42 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:45 5: MYSENSORS send: Rx: fr=005 ci=-01 c=003(C_INTERNAL    ) st=002(I_VERSION       ) ack=0 ''

2018.06.25 21:08:45 5: SW: 353b2d313b333b303b323b0a
2018.06.25 21:08:47 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:47 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:48 4: MYSENSORS/RAW: /5;255;3;0;33;60000

2018.06.25 21:08:48 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=033(I_POST_SLEEP_NOTIFICATION) ack=0 '60000'

2018.06.25 21:08:48 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:48 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:48 5: MYSENSOR_5: refreshInternalMySTimer called (Alive)
2018.06.25 21:08:48 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:48 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:48 4: MYSENSORS/RAW: /5;255;3;0;22;1159289
5;101;1;0;38;2.71
5;103;1;0;0;24.7
5;102;1;0;38;2694
5;255;3;0;32;500

2018.06.25 21:08:48 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=022(I_HEARTBEAT_RESPONSE) ack=0 '1159289'

2018.06.25 21:08:48 5: MYSENSOR_5: refreshInternalMySTimer called (Alive)
2018.06.25 21:08:48 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:48 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:48 4: MYSENSORS Read: Rx: fr=005 ci=101 c=001(C_SET         ) st=038(V_VOLTAGE       ) ack=0 '2.71'

2018.06.25 21:08:48 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:48 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:48 5: MYSENSOR_5: refreshInternalMySTimer called (Alive)
2018.06.25 21:08:49 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:49 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:49 4: MYSENSORS Read: Rx: fr=005 ci=103 c=001(C_SET         ) st=000(V_TEMP          ) ack=0 '24.7'

2018.06.25 21:08:49 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:49 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:49 5: MYSENSOR_5: refreshInternalMySTimer called (Alive)
2018.06.25 21:08:49 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:49 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:49 4: MYSENSORS Read: Rx: fr=005 ci=102 c=001(C_SET         ) st=038(V_VOLTAGE       ) ack=0 '2694'

2018.06.25 21:08:49 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:49 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:49 5: MYSENSOR_5: refreshInternalMySTimer called (Alive)
2018.06.25 21:08:49 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:49 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:49 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=032(I_PRE_SLEEP_NOTIFICATION) ack=0 '500'

2018.06.25 21:08:49 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:49 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:49 5: MYSENSOR_5: refreshInternalMySTimer called (Alive)
2018.06.25 21:08:49 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:49 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:51 5: MYSENSORS send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''

2018.06.25 21:08:51 5: SW: 353b3235353b333b313b31333b0a
2018.06.25 21:08:51 5: MYSENSOR_5: refreshInternalMySTimer called (Ack)
2018.06.25 21:08:51 4: MYSENSOR_5: Ack timeout timer set at 1529953761.72393
2018.06.25 21:08:51 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:51 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:51 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:51 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:08:52 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:05 5: MYSENSORS outstanding ack, re-send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''

2018.06.25 21:09:05 5: SW: 353b3235353b333b313b31333b0a
2018.06.25 21:09:11 4: MYSENSORS/RAW: /0;255;3;0;5;0

2018.06.25 21:09:11 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=005(I_INCLUSION_MODE) ack=0 '0'

2018.06.25 21:09:11 5: MYSENSORS send: Rx: fr=000 ci=255 c=-01(''            ) st=005(''              ) ack=0 '1'

2018.06.25 21:09:11 5: SW: 303b3235353b2d313b303b353b310a
2018.06.25 21:09:11 4: MYSENSORS/RAW: /0;255;3;0;5;1

2018.06.25 21:09:11 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=005(I_INCLUSION_MODE) ack=0 '1'

2018.06.25 21:09:17 4: MYSENSORS/RAW: /108;255;3;0;33;600000

2018.06.25 21:09:17 4: MYSENSORS Read: Rx: fr=108 ci=255 c=003(C_INTERNAL    ) st=033(I_POST_SLEEP_NOTIFICATION) ack=0 '600000'

2018.06.25 21:09:17 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:17 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:17 4: MYSENSORS/RAW: /108;255;3;0;22;4853547
108;101;1;0;38;2.48
108;103;1;0;0;24.4
108;102;1;0;38;2464
108;255;3;0;32;500

2018.06.25 21:09:17 4: MYSENSORS Read: Rx: fr=108 ci=255 c=003(C_INTERNAL    ) st=022(I_HEARTBEAT_RESPONSE) ack=0 '4853547'

2018.06.25 21:09:17 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:17 4: MYSENSORS Read: Rx: fr=108 ci=101 c=001(C_SET         ) st=038(V_VOLTAGE       ) ack=0 '2.48'

2018.06.25 21:09:17 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:17 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:17 4: MYSENSORS Read: Rx: fr=108 ci=103 c=001(C_SET         ) st=000(V_TEMP          ) ack=0 '24.4'

2018.06.25 21:09:17 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:18 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:18 4: MYSENSORS Read: Rx: fr=108 ci=102 c=001(C_SET         ) st=038(V_VOLTAGE       ) ack=0 '2464'

2018.06.25 21:09:18 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:18 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:18 4: MYSENSORS Read: Rx: fr=108 ci=255 c=003(C_INTERNAL    ) st=032(I_PRE_SLEEP_NOTIFICATION) ack=0 '500'

2018.06.25 21:09:18 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:18 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:20 5: MYSENSORS outstanding ack, re-send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''

2018.06.25 21:09:20 5: SW: 353b3235353b333b313b31333b0a
2018.06.25 21:09:24 5: MYSENSOR_5: timeoutMySTimer called (timeoutAck)
2018.06.25 21:09:24 4: MYSENSOR_5: timeoutMySTimer called (timeoutAck), outstanding: ARRAY(0x3e80040)
2018.06.25 21:09:24 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:24 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:38 4: MYSENSORS/RAW: /1;255;3;0;33;600000
1;3;1;0;0;23.8
1;4;1;0;1;57.3
1;101;1;0;38;2.65
1;103;1;0;0;23.4
1;102;1;0;38;2656
1;255;3;0;22;10291181
1;255;3;0;32;500
107;255;3;0;33;600000
107;255;3;0;22;2162320
107;101;1;0;38;2.53
107;103;1;0;0;23.6
107;102;1;0;38;2514

2018.06.25 21:09:38 4: MYSENSORS Read: Rx: fr=001 ci=255 c=003(C_INTERNAL    ) st=033(I_POST_SLEEP_NOTIFICATION) ack=0 '600000'

2018.06.25 21:09:38 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:38 5: mySensorsGW: getFirmwareTypes - list contains:
2018.06.25 21:09:38 4: MYSENSORS Read: Rx: fr=001 ci=003 c=001(C_SET         ) st=000(V_TEMP          ) ack=0 '23.8'




Und außerdem stürzt fhem immer wieder ab mit dem neuen Module von Dir, vermutlich immer, wenn ich einen Reboot des Nodes einleite.

Viele Grüße
Dirk

[Beta-User]

Hmm, scheint eine ziemliche Aufgabe zu sein mit der OTA-Geschichte. Danke jedenfalls für die Infos bis dahin, sieht so aus, als sollte ich auch mal einen Testaufbau mit MySBootloader machen (heute morgen habe ich auch SPI-Flash bestellt, aber das wird dauern).

Vom Vorgehen her würde ich folgendes vorschlagen: Wir komplettieren erst den Dual-Optiboot-Weg. Nach meinem Eindruck könnte es sein, dass manche "last;" noch im code fehlen, die kann ich evtl. bis Do oder so nachliefern. Vermutlich brauchen wir eine Möglichkeit, die zulässigen Bootloader durch den Nutzer festlegen zu lassen und uU. darüber auch den Update-Pfad pro Node zu bestimmen (könnte als Attribut(e) am GW funktionieren). 

An sich sollte der Funk-Prozess ansonsten gleich sein, nur dass Optiboot die Daten erst mal in externes EEPROM schreibt und dann beim Starten erst flasht (wenn eine neue firmware erkannt wird) und MySBootloader direkt das EEPROM schreibt. Die Initialisierung muß halt klappen.

Was das Reboot-Problem angeht, bin ich für Lösungsvorschläge dankbar. Im Moment würde ich darauf tippen, dass wir eine "Abfrage ins Leere" haben und leere Daten oder so verschickt werden sollen. Nach dem softwaremäßig angestoßenen Reboot (der Bootloader scheint unterscheiden zu können, ob er stromlos war oder nicht (=Reset-Knopf oder abstöpseln)) will er Daten in einem bestimmten Format zurück haben, die im Moment nicht geliefert werden - eventuell, weil im Moment die firmware nicht ausgeliefert wird, wenn der Bootloader nicht V3.0 ist (=Optiboot). Der MySBootloader ist aber V1.3...

Kannst du am Log was erkennen, wenn FHEM anhält (letzte Einträge)?

@Wallmeier: Ich denke, die OTA-Geschichte sollte sich auch mit V2.2-Nodes testen lassen - andererseits: dazu ist es da, kannst ja bei der Gelegenheit die V2.3.0 verteilen...
Generell noch eine Frage: die states würde ich noch nach asleep und awake umbenamsen. Gehe davon aus, dass keine Einwände bestehen...

[Wallmeier]

@Beta-User: Das OTA-Update des Nodes auf 2.3.0 mit Deinen Dateien aus dem ersten Post hat einwandfrei funktioniert - das Gateway steht noch auf 2.2.0-rc2...

[Beta-User]

@Wallmeier
Danke für die Rückmeldung, darauf sollte man aufbauen können. Ergänzend wäre noch interessant, ob auch die "alte" Version aus deinem Post mit einem MySBootloader FHEM abschießt. Und: Wie lange dauert es denn etwa, bis eine mittlere Firmware (50-60% Speicherbelegung) übertragen ist? Reagiert FHEM so lange?

@dirkcx
Es sollten vermutlich erst noch ein paar Debug-Ausgaben für "deinen" Pfad in den Code, bitte daher um etwas Geduld . Aber das kann ich wenigstens auch mit vorhandener HW selbst testen, wenn ich mal etwas Zeit habe.

[Wallmeier]

@Wallmeier
Danke für die Rückmeldung, darauf sollte man aufbauen können. Ergänzend wäre noch interessant, ob auch die "alte" Version aus deinem Post mit einem MySBootloader FHEM abschießt.

Da ich keinen Node mit einem MySBootloader habe, kann ich das leider nicht testen...

Und: Wie lange dauert es denn etwa, bis eine mittlere Firmware (50-60% Speicherbelegung) übertragen ist?

Bei meinem Node, der den Speicher fast voll ausgereizt hat, dauert die Übertragung mehrere Minuten.

Reagiert FHEM so lange?

Ja - da der Node die Blöcke einzeln anfordert und es somit nicht eine einzige durchgehende Aktion ist (sondern viele kurze).