FHEM Forum

Hallo zusammen,

mit dem morgigen Update wird eine aktualisierte Constants.pm ausgeliefert. Diese dient dazu, einige Neuerungen, die mit der MySensors API 2.0 eingeführt wurden, jetzt auch in FHEM verfügbar zu machen.

In der Umsetzung ist allerdings noch manches offen, es werden Tester benötigt und zu manchem dürft ihr auch vorab eure Meinung äußern, wie es letztendlich umgesetzt werden soll. Da die Koordination dieser Dinge einen gewissen Aufwand erfordert, den Hauswart derzeit aus sehr erfreulichen privaten Gründen nicht leisten kann, haben wir uns auf ein arbeitsteiliges Vorgehen verständigt.

Anbei findet ihr daher eine Testversion der 10_MYSENSORSDEVICE.pm. Diese sollte nach den bisherigen Erfahrungen ohne weiteres und ohne wesentliche Einschränkungen im gewohnten Umfang lauffähig sein, die neuen Funktionen müssen (teilweise) erst noch getestet werden - eine Funktionsgarantie gibt es aber selbstverständlich wie immer nicht.

Was allerdings anders ist, ist die Benennung des battery-Readings. Entsprechend dem Beitrag im Developer-Bereich (https://forum.fhem.de/index.php/topic,87575.0.html (https://forum.fhem.de/index.php/topic,87575.0.html)) ist der Name dieses Readings zukünftig "batteryPercent" - hier ist also "action required", man kann die alte Funktionalität aber übergangsweise bei Bedarf noch recht einfach wieder aktivieren.

Nun zu den eigentlichen Neuerungen:

- heartbeat
Status: getestet und (ausgelöst über die FHEMWEB in der Detailansicht der Nodes) funktional
-- Sendet eine Node ein heartbeat(), wird das alive-Reading aktualisiert. Es wird empfohlen, beim Programmieren der Nodes, die auf "alive" überwacht werden sollen, darauf zu achten, dass diese einen heartbeat (oder smartsleep-Signal) senden (s.u.).
-- Es gibt ein neues "get", mit dem eine Node auch aktiv "angepingt" werden kann - damit kann man also prüfen, ob die Kommunikation von und zu einer Node derzeit steht.
-- Das ist nicht-triggernd realisiert, man muß also den Browser-refresh ausführen, um den aktualisierten Zeitstempel zu sehen. (soll m.E. so bleiben, ggf. kann man das noch über den Aufruf steuern, kommt evtl. noch)
-- Effektiv glaube ich, es wäre besser, das "alive"-Reading zukünftig nur noch bei updates von internen Messages (heartbeat und smartsleep, s.u.) zu aktualisieren. Das mindert die Systemlast bei den übrigen, die die Funktionalität gar nicht nutzen wollen. (Meinungen erbeten!)
EDIT: ist jetzt so umgesetzt, die Zeile ist auskommentiert noch im Code enthalten und kann bei Bedarf wieder manuell aktiviert werden => Ausbau, wenn kein Widerspruch kommt.
-- Macht man das ganze über die Kommandozeile, erscheint ein leeres Dialogfeld - gefällt mir noch nicht...
EDIT: läßt sich bei get nicht verhindern (auch bei anderen neuen get's) => habe ich so belassen, da mir die Logik, dass man sowas aktiv anfordert als "get" besser gefällt :) .

- RSSI
Status: grob getestet (via FHEMWEB-Button), aber mangels eigener RFM-Nodes keine Info, ob in wirklich funktional
-- erfordert aktive Anfrage via neuem "get" oder und entsprechenden Code auf der Node (MY_SIGNAL_REPORT_ENABLED)
-- macht nur bei RFM-Nodes Sinn (soweit bekannt)
-- ebenfalls nichttriggernd - kann bei entsprechendem Wunsch auch anders gemacht werden
-- die Richtung, also die Zuordnung der beiden Readings, die es geben sollte, ist geraten - wer da valide Info hat: her damit.
-- leeres Dialogfeld, wenn über Kommandozeile (das hätte ich noch gerne anders, dazu muss aber noch etwas Arbeit rein... Der Aufruf muß erst an die Node raus und die Rückmeldungen ausgewertet werden; dazu benötige ich aber erst mal welche ;) )
EDIT: Es wird eine Art Schleife aufgerufen, die alle möglichen Werte nacheinander abfragt; gehen zwischenzeitlich Nachrichten verloren, muß das neu angestoßen werden, sonst gibt es ein internal, das anzeigt, auf welcher Stufe der Prozess gerade steht. Ist der länger unverändert, ist die Anforderung im off gelandet...

- smartsleep
Status: fast ungetestet, aber vorhandene ssmartSleep-Nodes scheinen auch keine ernsthafte Gefahr für die Stabilität von FHEM zu sein.Ich hoffe zwar nicht auf echte Schwierigkeiten, aber dennoch bitte vor der Verwendung ein Backup der seitherigen pm bereit halten und ggf. zurückspielen. Der Teil ist auch Perl-mäßig eine echte Herausforderung - wenn also jemand der Perl-Experten da einen kritischen Blick drauf werfen würde, wäre das nett *smile*
-- Status wach/schlafend sollte sichtbar sein (nichttriggernd, kann geändert werden, bei Bedarf über Attribut?)
-- Ziel ist es, auch Sendebefehle an die Node in eine Queue zu schreiben und auszuliefern, sobald die betr. Node aufwacht. Das könnte miot etwas Glück sogar schon funktionieren - Testergebnisse wären nett, ich mach bei Gelegenheit auch mal den einen oder anderen Test...
EDIT: Das funktioniert soweit, allerdings ist bei Nicht-ACK-Nachrichten nicht auszuschließen, dass Messages verloren gehen, gerade bei solchen Nodes, die über einen Repeater angesprochen werden. Hängt von den konkreten Umständen ab. Ggf. hilft es bei Problemen, die Zeit bis zum Einschlafen der Nodes zu verlängern (MY_SMART_SLEEP_WAIT_DURATION_MS).
ToDo: Gelegentich wird bei gleichzeitigem zeitverzögertem Senden der asleep/awake-Status nicht sauber aktualisiert.

Was die Namen der diversen Readings angeht, können die ggf. auch noch angepaßt werden.

Eure Rückmeldungen (und ggf. Mitarbeit!) sind also willkommen, bei neuen Erkenntnissen werde ich den Post bzw. Anhang dann aktualisieren. Sobald das insgesamt oder in wesentlichen Teilen ausgetestet ist, erfolgt dann der Rollout, ggf. auch in Etappen.
Wer mag, kann sich die Constants.pm natürlich auch direkt schon aus dem SVN holen ;) .
Grüße,

Beta-User

EDIT: Neue Versionen angehängt, Details sind dem Thread zu entnehmen bzw. werden nachgereicht
Sonstige Neuerungen, soweit bisher nicht im obigen Text erwähnt:- OTA-Funktionalität eingebaut (Danke an Wallmeier!) - kann sehr langsam sein für nRF-Nodes@2.3.0, dann bitte das GW und evtl. Repeater-Nodes auf 2.20 downgraden, siehe hier (https://forum.mysensors.org/post/91688).
- MY_SPECIAL_DEBUG kann genutzt werden (Abfrageschleife wie RSSI, s.o.)
- Kommentare bei der Presentation können in die Reading-Namen eingebaut werden, das ganze wird durch ein "get" angestoßen, wie hier beschrieben:

Zitatdass standardmäßig das bisherige Naming stattfindet und ein weiteres "get" einzubauen. Stößt man das an, soll geprüft werden, ob die aktuelle Namensgebung mit der sich aus Kommentaren ergebenden zusammenpaßt und ggf. dann das Naming angepaßt werden. Das hat den weiteren Vorteil, dass man auch Abweichungen ins Log schreiben und damit - zumindest nach einer weiteren Prüfung - auch Inkonsistenzen wie die in #42 aufdecken bzw. korrigieren kann.

Hier funktioniert das Löschen der bisherigen Reading-Namen noch nicht...

EDIT2: per svn verfügbare Dateien aus dem Thread gelöscht

Ich bin dabei (wie besprochen) zu testen.
(Und habe hiermit auch diesen Faden abonniert)

Ich teste auch gerne mit. Ist geplant irgendwann eine OTA Funktion über fhem einzubauen?

Dann willkommen an Bord!

Sofern ihr bereits gestern die Dateien eingespielt habt: Bitte darauf achten, dass ihr nach einem (ersten) Update vermutlich wieder die "alte" 10_MYSENSORS_DEVICE.pm erhaltet. Diese muß dann wieder durch die aus dem ersten Post ersetzt werden.

Was OTA angeht: "geplant" würde ich nicht behaupten wollen. Ist im Moment oberhalb meiner Fähigkeiten, aber wenn's jemand beisteuert, kommt das gerne rein! Noch gerner, wenn jemand einen OTA-Bootloader für HardwareSerial und ATMega328 (und ATMega32U4) bauen würde ;) ... Dann könnte ich auch meine RS485-Nodes bequem updaten, dann wäre das "veraltete" "alpha" schneller weg.

@Ranseyer:
Ich vermute ein Kommunikationsproblem auf der Funkstrecke. Die grundsätzliche Funktionalität des "get ... heartbeat" kannst du auch mit anderen GW/Nodes-Kombinationen testen, und ein nichtssagender RSSI-Wert von -256 kam bei mir, solange die Abfrage auf ne "-256" noch nicht drin war. Zum Testen kann man also ggf. die Abfrage aus den Zeilen 676 und 682 (" if ($msg->{payload} ne "-256" )")  löschen, dann sollte jede ansprechbare Node irgendwas zurückmelden (aber nur einen Wert).

Verwendest du den neuen oder alten Driver? Versuch's ggf. mal mit dem anderen (muß aber auf GW und Node)!

Ich verwende immer diese Konfig beim RFM69:

Zitat#define MY_RADIO_RFM69
#define MY_IS_RFM69HW // Lokale Vorschriften beachten !
#define MY_RFM69_FREQUENCY RFM69_868MHZ
#define MY_RFM69_NEW_DRIVER

Neu: alles auf die Testumgebung umgezogen, und deinen Dev-Stand (4 Files) aufgespielt und Owner gesetzt.
=> Alles wie auf dem Produktivsystem: Der Motionsensor conected sich und liefert fleissigst Daten.



Nun GW (und Node!) mit Debug und nicht mit neuem Treiber kompiliert:
0;255;3;0;9;0 MCO:BGN:INIT GW,CP=RRNGA---,VER=2.3.0
0;255;3;0;9;12 TSM:INIT
0;255;3;0;9;20 TSF:WUR:MS=0
0;255;3;0;9;28 TSM:INIT:TSP OK
0;255;3;0;9;36 TSM:INIT:GW MODE
0;255;3;0;9;45 TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;57 MCO:REG:NOT NEEDED
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.3.0
0;255;3;0;9;69 MCO:BGN:STP
0;255;3;0;9;90 MCO:BGN:INIT OK,TSP=1


Komisch ist dass nun gar keine Kommunikation mehr funktioniert (Die Node):

__  __       ____
|  \/  |_   _/ ___|  ___ _ __  ___  ___  _ __ ___
| |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
| |  | | |_| |___| |  __/ | | \__ \  _  | |  \__ \
|_|  |_|\__, |____/ \___|_| |_|___/\___/|_|  |___/
        |___/                      2.3.0

51 MCO:BGN:INIT NODE,CP=RRNNA---,VER=2.3.0
79 TSM:INIT
83 TSF:WUR:MS=0
88 TSM:INIT:TSP OK
94 TSF:SID:OK,ID=111
100 TSM:FPAR
1320 TSF:MSG:SEND,111-111-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
3340 !TSM:FPAR:NO REPLY
3346 TSM:FPAR
4567 TSF:MSG:SEND,111-111-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6586 !TSM:FPAR:NO REPLY
6592 TSM:FPAR
7813 TSF:MSG:SEND,111-111-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
9832 !TSM:FPAR:NO REPLY
9838 TSM:FPAR
11059 TSF:MSG:SEND,111-111-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
13078 !TSM:FPAR:FAIL
13082 TSM:FAIL:CNT=1
13088 TSM:FAIL:DIS
13094 TSF:TDI:TSL


Wahrscheinlich hat das keinen Zusammenhang mit deinen Änderungen und meine Tests bisher wären wertlos.
Das könnte doch ein HW Problem sein welches ich genauer ansehen muss. Aber leider muss ich nun erst mal weg.

Ahh, Lustig:
-Nur beim Node die RFM69HW Option weggenommen und die kommunizieren wieder !
-Wenn ich das auch beim GW wegnehme ändert sich nix.

=> Sensor liefert fleissig Daten , aber es kommen keine "Kommandos" auf der Debug-Konsole des Nodes an.
Was ich nicht verstehe: Die Kommunikation muss doch bereits beidseitig funktionieren oder hab ich nen Denkfehler ?

Zitat von: dirkcx am 23 Juni 2018, 08:17:28
Ich teste auch gerne mit. Ist geplant irgendwann eine OTA Funktion über fhem einzubauen?

Hatte ich vor längerer Zeit mal als Patch zur Verfügung gestellt - wurde aber nie übernommen...

Zu finden unter https://forum.fhem.de/index.php/topic,81917.msg744431.html#msg744431 ...

... ich klinke mich dann auch mal ein, das mit dem OTA würde mich auch brennend interessieren. Aber m.Wn. ist der Quellcode des Bootloaders noch nicht öffentlich.

Gruß PeMue

Zitat von: PeMue am 23 Juni 2018, 13:02:41
... ich klinke mich dann auch mal ein, das mit dem OTA würde mich auch brennend interessieren. Aber m.Wn. ist der Quellcode des Bootloaders noch nicht öffentlich.

Gruß PeMue

Ich verwende den Bootloader hier und habe damit keine Probleme.
https://github.com/mysensors/MySensorsBootloaderRF24 (https://github.com/mysensors/MySensorsBootloaderRF24)
Upload erfolgt über https://www.mysensors.org/controller/myscontroller (https://www.mysensors.org/controller/myscontroller), bin aber Mac/Linux User, daher ist diese Windows-Anwendung für mich nur suboptimal.

Zitat von: Wallmeier am 23 Juni 2018, 11:25:17
Hatte ich vor längerer Zeit mal als Patch zur Verfügung gestellt - wurde aber nie übernommen...

Zu finden unter https://forum.fhem.de/index.php/topic,81917.msg744431.html#msg744431 ...

Ich weiß nicht, wie ich den Patch mit dem Code zusammenführen muss und per Hand scheint mir das sehr aufwändig. Und ich habe keine Ahnung von Perl :-(
Ich würde aber gerne beim Test unterstützen, wenn ich die Originaldatei bekommen würde ;-)

Yup, OTA-code ist public...

Wäre also für jemanden mit guten C/C++-Kenntissen sicher keine große Übung, den für RS485@Serial umzubauen ;) .

Was den OTA-Patch angeht (habs nur kurz überflogen):
-- Die Constants.pm dürfte jetzt bereits den Stand haben
-- Die Änderung in der "Device" ist ja überraschend minimalistisch, ich bau's demnächst ein.

Dann kommt vermutlich wegen des Dialogfeld-Themas der heartbeat-Request in die sets statt der gets rein, dann ggf. gleich mit der Option, das wahlweise mit und ohne Response-Event "zu befehlen". Hat sonst jemand die heartbeat-Probleme wie Ranseyer?

Zur Erläuterung: Bei meinen Vorversuchen hatte ich auch die anderen beiden Dateien (+die 00_MYSENSORS.pm und die Message.pm) mal abgeändert, war aber der Überzeugung, das aber dann wieder ausgebaut zu haben.

Interessieren würde mich im Moment noch: Kennt jemand eine Möglichkeit, den "Transportweg" abzufragen? Das RSSI-Thema macht nur bei RFM Sinn, OTA im Moment nur bei nRF24 => beim Rest gleich ignorieren wäre das Ziel (solange keiner einen Bootloader für RS485 baut ::) ). Zu nRF24-OTA noch: Da der Kanal 76 da zwingend ist, aber nicht jeder diesen nutzt (ich z.B. nicht), müßte man eigentlich mit/nach dem Request an die Node für eine gewisse Zeit den Kanal umschalten. Kennt einer einen Weg dafür (flashen war nicht gemeint, Perl... 8) )?

OTA macht auch beim RFM69 Sinn - nur damit habe ich es getestet...

OK, Danke für die Info - interessant wäre es trotzdem, wie man es einsetzt ist ja was anderes ;) .
Im ersten Post sind jetzt die OTA-Dinge eingearbeitet, ich hoffe, ohne größere Kollateralschäden. Aber Vorsicht: das war doch eine größere Aktion als auf dem ersten Blick gedacht, die Strukturen sind teilweise etwas auseinander gedriftet gewesen, so dass ich einiges leicht ummodeln mußte.
Im Moment kann ich nur behaupten, dass mein FHEM mit diesen Dateien startet, die Sensoren Werte liefern und ich testweise auch Nodes einen heartbeat abverlangen kann.
Vielleicht kann jemand den OTA-Teil Testen, der passende Nodes hat, ich müßte erst noch eine Node vorbereiten? Die Änderungen in der Constants.pm sind recht gering, ebenso in der 00_MYSENSORS, sollte also auch mit der bisherigen Device-pm zusammenarbeiten. Wenn keine größeren Probleme gemeldet werden, würde ich Hauswart bitten, diese beiden zeitnah wieder in das SVN einzuchecken?
Und @Wallmeier: Da du funktionierende RFM-Nodes hast, würde mich schon interessieren, ob RSSI-Werte kommen und ob die Richtung korrekt geraten wurde...
Und ein riesiges Dankeschön für den Patch! Super Arbeit!

ZitatUnd @Wallmeier: Da du funktionierende RFM-Nodes hast, würde mich schon interessieren, ob RSSI-Werte kommen und ob die Richtung korrekt geraten wurde...

Das würde mich auch spannend interessieren, ansonsten muss ich Ende nächster Woche mal in Richtung der HW forschen. (Hab ich Stamps gekauf mit falscher Aufschrift: "HW", oder fehlt bei der Node die IRQ Leitung, usw.)

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

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

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.

Zitat von: Beta-User am 24 Juni 2018, 10:19:52
@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":

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:

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:

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:
Can't use an undefined value as an ARRAY reference at ./FHEM/10_MYSENSORS_DEVICE.pm line 401.

Update 3:
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)
PERL WARNING: "my" variable $name masks earlier declaration in same scope at ./FHEM/00_MYSENSORS.pm line 460, <$fh> line 5.

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

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

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 (https://github.com/theolind/pymysensors)

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

@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 ;D .
Damit sind dann demnächst alle 8 USB-Ports an dem T5740 belegt  ;D 8) ::) - es liegt noch ein umzuflashender CC2531 (?) für zigbee rum (vermutlich die MQTT-Variante).

@dirkcx

Zitat von: Wallmeier am 16 Januar 2018, 20:18:59Unterstü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).

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

@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 (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:

[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 (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:

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

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

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

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

Zitat von: Beta-User am 26 Juni 2018, 07:28:08
@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...

Zitat von: Beta-User am 26 Juni 2018, 07:28:08
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.

Zitat von: Beta-User am 26 Juni 2018, 07:28:08
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).

So, im ersten Post wieder ein update, vorrangig wegen der OTA-update-Themen.

Es gibt jetzt ein neues Attribut "BL_Type", mit dem die Art des update-Mechanismus augewählt werden kann. Das muss für den MYSBootloader und andere Optiboot-Varianten wie V3.0 gesetzt werden. Dann gibt es state updates, die ggf. auch laufende updates anzeigen sollten bzw. den Abschluß nach dem Reboot der Node (durch eine Presentation).

Ansonsten kann ich im Moment nicht viel mehr sagen wie: Modul lädt, Readings kommen, hier klappt es, presentations etc. anzufordern - scheint also jedenfalls in dem Bereich keine Verschlechterung zu bringen. Allerdings ist die Stream-Message-Logik auf einen handler umgebastelt und es sind zum Updateverlauf einige Verbose-4-Meldungen eingebaut.
Von daher wäre es nett, wenn @Wallmeier rückmelden könnte, ob der Optiboot-Update weiterhin klappt und @dirkcx einen erneuten Versuch mit MYSBootloader wagen würde und die entspr. Logfile-Auszüge bereitstellen... Wäre zwar verwunderlich, wenn das jetzt bereits direkt klappt, aber man kann nie wissen ::) .

@Wallmeier: Beim Überarbeiten ist mir nicht so ganz klar geworden, ob die Abfragen, ob der Bootloader der richtige ist an allen Stellen wirklich erforderlich sind, v.a. in der onStreamMessage(). An sich könnte man ja argumentieren, dass eine Node, die sowas anfragt auch "weiß", was sie damit tun will.

Dann bin ich latent noch am überlegen, ob es sinnvoll wäre, ggf. während des update-Prozesses das GW bei Bedarf umschalten zu können (ich nutze wie gesagt einen anderen Kanal wie 76, könnte aber natürlich ein "76-er update-GW" bei Bedarf anklemmen). Das wäre ggf. nach einem Timeout oder bei Eintrudeln der Presentation-Message (die kommt auch, wenn dann wieder das "falsche" GW genutzt wird). Dazu wäre aber noch zu klären, wann ggf. der richtige Zeitpunkt dafür ist..

Das Update klappt einwandfrei mit der neuen Version - sowohl ohn gesetztes Attribut BL_Type als auch mit (mit dem Wert OptiBoot).

Danke für die Rückmeldung!

Jetzt sollte es kein so großes Problem mehr sein, das auch für MYSBootloader vollends hinzubekommen. Werde - voraussichtlich aber erst am WE - dann gelegentlich mal nRF24-Test-HW aufbauen. Für die optionale Verwendung eines anderen GW's zum update habe ich auch schon eine Idee :) , das sollte eigentlich ohne Umschalten alleine aufgrund des Typs der zu versendenden Messages klappen 8) . Damit wäre es dann recht einfach, bei Bedarf einfach per Attribut das "OTA_Chan76_IODev" festzulegen

Vermutlich wäre es clever, beim nächsten update dann alle Attribute usw., die mit OTA zu tun haben, mit einem entsprechenden Prefix zu versehen? Wäre dann für Neueinsteiger ggf. übersichtlicher.

Die Update-Files müssen - so wie es jetzt programmiert ist - übrigens auch bei ConfigDB im Filesystem zu finden sein.

Wenn das dann mit beiden BL-Varianten klappt, geht es wieder mit den Dingen weiter, um die es ursprünglich hier mal ging :) . Hat da jemand zwischenzeitlich irgendwelche Rückmeldungen zu?

Und: Da sich bisher niemand gewehrt hat, ist der "alive"-Mechanismus auf heartbeat&Co reduziert. Die betreffenden Zeilen sind zwar im Moment nur auskommentiert, aber bei fehlender anderweitiger Rückmeldung fliegen die dann demnächst ganz raus ::) .

neuer Versuch mit MYSBootloader und den neuesten Modulen ("RequestAck" =0 und =1 getestet sowohl am GW als auch am Node):

"BL_Type" eingestellt auf "MYSBootloader" - funktioniert:
2018.06.29 08:39:39 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200


fwType eingestellt auf "81" in der Combobox - Fehler:
fwType must be numeric

set MYSENSOR_5 reboot  - funktioniert
2018.06.29 08:42:41 5: MYSENSORS send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=0 ''
2018.06.29 08:42:41 5: SW: 353b3235353b333b303b31333b0a


get MYSENSOR_5 presentation  - keine Reaktion in der UI
2018.06.29 08:43:11 5: MYSENSORS send: Rx: fr=005 ci=-01 c=003(C_INTERNAL    ) st=019(I_PRESENTATION  ) ack=0 ''
2018.06.29 08:43:11 5: SW: 353b2d313b333b303b31393b0a

get MYSENSOR_5 version  - keine Reaktion in der UI
2018.06.29 08:44:21 5: MYSENSORS send: Rx: fr=005 ci=-01 c=003(C_INTERNAL    ) st=002(I_VERSION       ) ack=0 ''
2018.06.29 08:44:21 5: SW: 353b2d313b333b303b323b0a
2018.06.29 08:44:24 4: MYSENSORS/RAW: /0;255;3;0;5;0


set MYSENSOR_5 fwType 81 über die UI mit Auswahl in der Combobox - Fehler:
MYSENSOR_5: Firmware type not defined (FW_TYPE)

2018.06.29 08:46:54 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.29 08:46:54 3: Firmware type not defined (FW_TYPE) for MYSENSOR_5, update not started


Frage: kann ich den FW_TYPE manuell setzen ohne die Combobox?
Mit set MYSENSOR_5 fwType 81 in der Kommandozeile kommt der selbe Fehler
fwType must be numeric

Das muss ich mir mal im Detail ansehen.

Eine Sache habe ich gefunden, die zu @Wallmeiers patch geändert war und vermutlich die Ursache für das "must be numeric", entsprechend angepaßte Versionen anbei. Allerdings sind da schon einige weitere Änderungen drin (Anpassung der OTA-Readingnamen, 2. Update-GW und so) und auf Lauffähigkeit getestet war nur der Stand von gestern abend (ohne die genannte eine Sache). Daher benötigt man auch beide Module.

Was die anderen Dinge angeht: die internen Abfragen (presentation und version) gehen jedenfalls im Moment direkt und ohne warten auf das Aufwachen raus; das scheint auch zu funktionieren, wenn ich die Logs richtig deute. Wenn da die Node allerdings schläft, bekommt sie das nicht mit... Ggf. kannst du den entsprechenden Aufruf in ein notify auf "awake" packen, dann sollte das klappen und auch die entsprechenden Readings aktualisiert werden (den Aufruf selber sieht man an der Oberfläche nie, nur das Ergebnis/die Rückmeldung.
EDIT: rausgenommen, da war noch ein Fehler drin, der bereits behoben, aber nicht eingecheckt war.

So, anbei mal wieder neue Versionen. Da sich die Readings-Namen teilweise geändert haben, erst mal noch kein update im ersten Post. Das Problem, dass sich die fwType nicht hat setzen lassen, scheint in der Perl-Version vergraben gewesen zu sein.

Jedenfalls dieser Teil klappt jetzt bei mir, OTA-Hardware habe ich noch keine, und im Moment glaube ich auch nicht daran, dass das dieses WE bei mir noch reicht, mal schauen.

Wenn wir grade bei wünsch dir was sind: Was ich gerne noch einbauen würde, wäre die Option, den Reading-Namen durch die Angabe eines Kommentars bei der Presentation (im Sketch) vorzugeben (z.B. die ID eines DS18B20). Gibt es Meinungen dazu?

EDIT: Anhänge gelöscht

So, durch die Änderungen der Readingsnamen musste ich erstmal ein wenig in den Code gucken ;-) Änderungen sind nun nachvollzogen, die Einstellungen sind geändert. Ich nehme an, OTA_Chan76_IODev entspricht dem IODev, d.h. dem Namen des Gateways?

Firmware-Config wird dann auch wieder korrekt gelesen. Einstellen des OTA_BL_Type auch, also klasse! Vielen Dank!
Autoupdate habe ich erstmal aus (=0) gelassen.

Wenn ich nun "set MYSENSORS_5 flash" setze, wird ein Reboot ausgelöst, siehe log, aber ein FOTA wird nicht gestartet. Der Node hat ein smartSleep von 60 Sekunden.

Kann man das Gateway-Modul so ändern, dass "getFirmwareTypes" nur durch bspw. "set <<GW>> reloadFirmwareList" neu einliest? Das log erweckt den Eindruck, dass das ständig passiert.

Kein Unterschied, ob mit oder ohne RequestAck.


2018.06.30 07:47:29 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:30 5: MYSENSORS outstanding ack, re-send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''

2018.06.30 07:47:30 5: SW: 353b3235353b333b313b31333b0a
2018.06.30 07:47:34 5: MYSENSORS outstanding ack, re-send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''

2018.06.30 07:47:34 5: SW: 353b3235353b333b313b31333b0a
2018.06.30 07:47:41 5: MYSENSORS outstanding ack, re-send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''

2018.06.30 07:47:41 5: SW: 353b3235353b333b313b31333b0a
2018.06.30 07:47:47 5: MYSENSORS outstanding ack, re-send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''

2018.06.30 07:47:47 5: SW: 353b3235353b333b313b31333b0a
2018.06.30 07:47:55 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:55 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:55 5: MYSENSORS outstanding ack, re-send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''

2018.06.30 07:47:55 5: SW: 353b3235353b333b313b31333b0a
2018.06.30 07:47:58 4: MYSENSORS/RAW: /5;255;3;0;33;60000

2018.06.30 07:47:58 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=033(I_POST_SLEEP_NOTIFICATION) ack=0 '60000'

2018.06.30 07:47:58 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:58 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:58 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:58 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:58 4: MYSENSORS/RAW: /5;255;3;0;22;5107088
5;101;1;0;38;2.69
5;103;1;0;0;25.0
5;102;1;0;38;2681
5;255;3;0;32;500

2018.06.30 07:47:58 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=022(I_HEARTBEAT_RESPONSE) ack=0 '5107088'

2018.06.30 07:47:58 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:58 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:58 4: MYSENSORS Read: Rx: fr=005 ci=101 c=001(C_SET         ) st=038(V_VOLTAGE       ) ack=0 '2.69'

2018.06.30 07:47:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:59 4: MYSENSORS Read: Rx: fr=005 ci=103 c=001(C_SET         ) st=000(V_TEMP          ) ack=0 '25.0'

2018.06.30 07:47:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:59 4: MYSENSORS Read: Rx: fr=005 ci=102 c=001(C_SET         ) st=038(V_VOLTAGE       ) ack=0 '2681'

2018.06.30 07:47:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:59 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=032(I_PRE_SLEEP_NOTIFICATION) ack=0 '500'

2018.06.30 07:47:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:47:59 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 07:48:03 5: MYSENSORS outstanding ack, re-send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''

2018.06.30 07:48:03 5: SW: 353b3235353b333b313b31333b0a
2018.06.30 07:48:12 5: MYSENSORS outstanding ack, re-send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''

2018.06.30 07:48:12 5: SW: 353b3235353b333b313b31333b0a
2018.06.30 07:48:24 5: MYSENSORS outstanding ack, re-send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''

2018.06.30 07:48:24 5: SW: 353b3235353b333b313b31333b0a
2018.06.30 07:48:27 4: MYSENSORS/RAW: /0;255;3;0;5;0

2018.06.30 07:48:27 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=005(I_INCLUSION_MODE) ack=0 '0'

2018.06.30 07:48:27 5: MYSENSORS send: Rx: fr=000 ci=255 c=-01(''            ) st=005(''              ) ack=0 '1'

2018.06.30 07:48:27 5: SW: 303b3235353b2d313b303b353b310a
2018.06.30 07:48:27 4: MYSENSORS/RAW: /0;255;3;0;5;1

2018.06.30 07:48:27 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=005(I_INCLUSION_MODE) ack=0 '1'

2018.06.30 07:48:38 5: MYSENSORS outstanding ack, re-send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''


Die Idee den ReadingNamen vorzugeben finde ich super. Ich nehme dazu im Sketch derzeit folgenden Code, der aber in FHEM nichts nutzt.

Update, hatte mit müden Augen den falschen Codeteil kopiert ;-)

#ifdef SEND_ID
for (int i=0; i<numSensors && i<MAX_ATTACHED_DS18B20; i++) {
if (dallas.getAddress(tempDeviceAddress, i)) {
charAddr = addrToChar(tempDeviceAddress);
present(CHILD_ID_TEMP+i, S_TEMP, charAddr);
}
}
#endif


Zitat von: Beta-User am 30 Juni 2018, 06:40:45
Wenn wir grade bei wünsch dir was sind: Was ich gerne noch einbauen würde, wäre die Option, den Reading-Namen durch die Angabe eines Kommentars bei der Presentation (im Sketch) vorzugeben (z.B. die ID eines DS18B20). Gibt es Meinungen dazu?

Finde ich sehr gut - dafür gibt es ja auch bei der Presentation den zweiten Parameter...
present(1, S_MULTIMETER, "5V - Ch1");

Der Dallas-Code mit der ID als Kommentar kommt mir bekannt vor 8) , schön, dass euch die Idee gefällt.

Zu dem gelogge der Set-Geschichte: das ist verbose 5, und ob man den Aufruf woanders hinschieben könnte, kann ich nicht sagen. So häufig kommt das vermutlich deshalb, weil du vermutlich versuchst, den Reboot bei smartsleep-nodes mit Ack aufzurufen, was genau die noch komplett ungenutzten Teile des Ursprungscodes nutzt. Bedeutet wohl: funktioniert im wesentlichen noch nicht. Dass das ständig kommt, dürfte auf die allg. Ack-Routine zurüchzuführen sein. Für die im Moment relevanten Ausgaben habe ich auch verbose 4 genutzt, der sollte also reichen.

Interimsweise bitte für smartsleep-Nodes vorerst generell KEIN Ack nutzen (ggf. outstanding messages durch FHEM-Neustart löschen) und
- entweder erst das flashen mit einer nicht-Smartsleep-node testen (das wäre mir am liebsten, dann funktioniert der code nämlich prinzipiell, wenn das so klappt), oder
- ein notify auf "awake" setzen und damit den flash-Befehl absetzen (hatte ich oben schon mal erwähnt). Wenn die Node nicht blitzschnell wegdämmert, sollte das reichen, ist aber eben eine mögliche Fehlerquelle.

Vorschlag zur Vorgehensweise:
- erst machen wir die flash-Routine ohne smartsleep auch für den MYSBootloader klar
- dann smartsleep (incl. OTA)
- zuletzt Wünsche wie das mit "Comment to readingname"

Das mit dem 2. GW ist übrigens NUR für Exoten wie mich gedacht, die das normale nRF24-Netzwerk mit einem anderen Channel als 76 betreiben (oder die Base-ID geändert haben). Wer die defaults genutzt hat, muß da gar nichts machen (und sollte es auch nicht, ist nur eine potentielle weitere Fehlerquelle ;) ).

So, das FOTA Update funktioniert "unattended" auch mit MYSBootloader. Ich war definitiv nicht zuhause, als das Update lief:

Aber, das Update sieht im kompletten log seltsam aus, ich versuche noch herauszufindenfinden, was da genau passiert ist, aber mein erster Eindruck war, dass das Update mehrfach gestartet oder durchgeführt wurde, vielleicht nur teilweise. Es ist aber definitiv eine neue Version auf dem Node.


2018.06.30 17:01:51 5: SW: 353b3235353b333b313b31333b0a
2018.06.30 17:01:51 4: MYSENSORS/RAW: /5;255;3;0;33;60000
5;255;3;0;22;333798
5;101;1;0;38;2.69
5;103;1;0;0;25.4
5;102;1;0;38;2681
5;255;3;0;32;500

2018.06.30 17:01:51 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=033(I_POST_SLEEP_NOTIFICATION) ack=0 '60000'

2018.06.30 17:01:51 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:01:51 5: MYSENSOR_5: refreshInternalMySTimer called (Alive)
2018.06.30 17:01:51 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:01:51 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=022(I_HEARTBEAT_RESPONSE) ack=0 '333798'

2018.06.30 17:01:51 5: MYSENSOR_5: refreshInternalMySTimer called (Alive)
2018.06.30 17:01:51 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:01:51 4: MYSENSORS Read: Rx: fr=005 ci=101 c=001(C_SET         ) st=038(V_VOLTAGE       ) ack=0 '2.69'

2018.06.30 17:01:51 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:01:51 4: MYSENSORS Read: Rx: fr=005 ci=103 c=001(C_SET         ) st=000(V_TEMP          ) ack=0 '25.4'

2018.06.30 17:01:51 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:01:51 4: MYSENSORS Read: Rx: fr=005 ci=102 c=001(C_SET         ) st=038(V_VOLTAGE       ) ack=0 '2681'

2018.06.30 17:01:51 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:01:51 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=032(I_PRE_SLEEP_NOTIFICATION) ack=0 '500'

2018.06.30 17:01:51 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:01:51 5: MYSENSOR_5: refreshInternalMySTimer called (Alive)
2018.06.30 17:01:51 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:01:51 4: MYSENSORS/RAW: /5;255;3;1;13;

2018.06.30 17:01:51 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=013(I_REBOOT        ) ack=1 ''

2018.06.30 17:01:51 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/00_MYSENSORS.pm line 421.
2018.06.30 17:02:01 4: MYSENSORS/RAW: /5;255;4;0;0;510016003804617C0103

2018.06.30 17:02:01 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=000(ST_FIRMWARE_CONFIG_REQUEST) ack=0 '510016003804617C0103'

2018.06.30 17:02:01 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:01 4: MYSENSOR_5: received ST_FIRMWARE_CONFIG_REQUEST
2018.06.30 17:02:01 4: MYSENSOR_5: MYSBootloader asking for firmware update, calling firmware update procedure
2018.06.30 17:02:01 1: PERL WARNING: Argument "Type" isn't numeric in numeric eq (==) at ./FHEM/00_MYSENSORS.pm line 472.
2018.06.30 17:02:01 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:01 4: MYSENSOR_5: Flashing './FHEM/firmware/DoorWindowSwitchV2_debug.ino.arduino_standard.hex'
2018.06.30 17:02:01 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=001(ST_FIRMWARE_CONFIG_RESPONSE) ack=0 '5100170038043085'

2018.06.30 17:02:01 5: SW: 353b3235353b343b303b313b353130303137303033383034333038350a
2018.06.30 17:02:01 4: MYSENSORS/RAW: /5;255;4;0;2;510017003704

2018.06.30 17:02:01 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017003704'

2018.06.30 17:02:01 1: PERL WARNING: substr outside of string at ./FHEM/10_MYSENSORS_DEVICE.pm line 381.
2018.06.30 17:02:01 1: PERL WARNING: Use of uninitialized value in hex at ./FHEM/10_MYSENSORS_DEVICE.pm line 381.
2018.06.30 17:02:01 5: MYSENSOR_5: Firmware block request 1079 (type 81, version 23)
2018.06.30 17:02:01 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017003704FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF'

2018.06.30 17:02:01 5: SW: 353b3235353b343b303b333b35313030313730303337303446464646464646464646464646464646464646464646464646464646464646460a
2018.06.30 17:02:01 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:01 4: MYSENSORS/RAW: /5;255;4;0;2;510017003604

2018.06.30 17:02:01 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017003604'

2018.06.30 17:02:01 5: MYSENSOR_5: Firmware block request 1078 (type 81, version 23)
2018.06.30 17:02:01 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017003604FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF'

2018.06.30 17:02:01 5: SW: 353b3235353b343b303b333b35313030313730303336303446464646464646464646464646464646464646464646464646464646464646460a
2018.06.30 17:02:01 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:01 4: MYSENSORS/RAW: /5;255;4;0;2;510017003504

2018.06.30 17:02:01 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017003504'

2018.06.30 17:02:01 5: MYSENSOR_5: Firmware block request 1077 (type 81, version 23)
2018.06.30 17:02:01 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017003504FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF'

2018.06.30 17:02:01 5: SW: 353b3235353b343b303b333b35313030313730303335303446464646464646464646464646464646464646464646464646464646464646460a
2018.06.30 17:02:02 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:02 4: MYSENSORS/RAW: /5;255;4;0;2;510017003404

2018.06.30 17:02:02 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017003404'

2018.06.30 17:02:02 5: MYSENSOR_5: Firmware block request 1076 (type 81, version 23)
2018.06.30 17:02:02 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017003404FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF'

2018.06.30 17:02:02 5: SW: 353b3235353b343b303b333b35313030313730303334303446464646464646464646464646464646464646464646464646464646464646460a
2018.06.30 17:02:02 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:02 4: MYSENSORS/RAW: /5;255;4;0;2;510017003304

2018.06.30 17:02:02 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017003304'

2018.06.30 17:02:02 5: MYSENSOR_5: Firmware block request 1075 (type 81, version 23)
2018.06.30 17:02:02 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017003304FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF'

2018.06.30 17:02:02 5: SW: 353b3235353b343b303b333b35313030313730303333303446464646464646464646464646464646464646464646464646464646464646460a
2018.06.30 17:02:02 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:02 4: MYSENSORS/RAW: /5;255;4;0;2;510017003204

2018.06.30 17:02:02 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017003204'

2018.06.30 17:02:02 5: MYSENSOR_5: Firmware block request 1074 (type 81, version 23)
2018.06.30 17:02:02 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017003204FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF'

2018.06.30 17:02:02 5: SW: 353b3235353b343b303b333b35313030313730303332303446464646464646464646464646464646464646464646464646464646464646460a
2018.06.30 17:02:02 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:02 4: MYSENSORS/RAW: /5;255;4;0;2;510017003104

2018.06.30 17:02:02 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017003104'

2018.06.30 17:02:02 5: MYSENSOR_5: Firmware block request 1073 (type 81, version 23)
2018.06.30 17:02:02 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170031048F16A8169A16EB16FFFFFFFFFFFFFFFF'

2018.06.30 17:02:02 5: SW: 353b3235353b343b303b333b35313030313730303331303438463136413831363941313645423136464646464646464646464646464646460a
2018.06.30 17:02:02 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:02 4: MYSENSORS/RAW: /5;255;4;0;2;510017003004

2018.06.30 17:02:02 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017003004'

2018.06.30 17:02:02 5: MYSENSOR_5: Firmware block request 1072 (type 81, version 23)
2018.06.30 17:02:02 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170030042074656D70003100000000000D177318'

2018.06.30 17:02:02 5: SW: 353b3235353b343b303b333b35313030313730303330303432303734363536443730303033313030303030303030303030443137373331380a
2018.06.30 17:02:02 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:02 4: MYSENSORS/RAW: /5;255;4;0;2;510017002F04

2018.06.30 17:02:02 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002F04'

2018.06.30 17:02:02 5: MYSENSOR_5: Firmware block request 1071 (type 81, version 23)
2018.06.30 17:02:02 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017002F04790041444320706F7765720043686970'

2018.06.30 17:02:02 5: SW: 353b3235353b343b303b333b35313030313730303246303437393030343134343433323037303646373736353732303034333638363937300a
2018.06.30 17:02:02 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:02 4: MYSENSORS/RAW: /5;255;4;0;2;510017002E04

2018.06.30 17:02:02 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002E04'

2018.06.30 17:02:02 5: MYSENSOR_5: Firmware block request 1070 (type 81, version 23)
2018.06.30 17:02:02 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017002E046F772073656E736F7200426174746572'

2018.06.30 17:02:02 5: SW: 353b3235353b343b303b333b35313030313730303245303436463737323037333635364537333646373230303432363137343734363537320a
2018.06.30 17:02:02 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:02 4: MYSENSORS/RAW: /5;255;4;0;2;510017002D04

2018.06.30 17:02:02 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002D04'

2018.06.30 17:02:02 5: MYSENSOR_5: Firmware block request 1069 (type 81, version 23)
2018.06.30 17:02:02 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017002D0420284932432900646F6F722F77696E64'

2018.06.30 17:02:02 5: SW: 353b3235353b343b303b333b35313030313730303244303432303238343933323433323930303634364636463732324637373639364536340a
2018.06.30 17:02:02 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:03 4: MYSENSORS/RAW: /5;255;4;0;2;510017002C04

2018.06.30 17:02:03 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002C04'

2018.06.30 17:02:03 5: MYSENSOR_5: Firmware block request 1068 (type 81, version 23)
2018.06.30 17:02:03 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017002C046F722057696E646F7720537769746368'

2018.06.30 17:02:03 5: SW: 353b3235353b343b303b333b35313030313730303243303436463732323035373639364536343646373732303533373736393734363336380a
2018.06.30 17:02:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:03 4: MYSENSORS/RAW: /5;255;4;0;2;510017002B04

2018.06.30 17:02:03 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002B04'

2018.06.30 17:02:03 5: MYSENSOR_5: Firmware block request 1067 (type 81, version 23)
2018.06.30 17:02:03 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017002B0432392E362E202864656275672900446F'

2018.06.30 17:02:03 5: SW: 353b3235353b343b303b333b35313030313730303242303433323339324533363245323032383634363536323735363732393030343436460a
2018.06.30 17:02:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:03 4: MYSENSORS/RAW: /5;255;4;0;2;510017002A04

2018.06.30 17:02:03 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002A04'

2018.06.30 17:02:03 5: MYSENSOR_5: Firmware block request 1066 (type 81, version 23)
2018.06.30 17:02:03 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017002A04003F00322E322E3000322E322E302E20'

2018.06.30 17:02:03 5: SW: 353b3235353b343b303b333b35313030313730303241303430303346303033323245333232453330303033323245333232453330324532300a
2018.06.30 17:02:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:03 4: MYSENSORS/RAW: /5;255;4;0;2;510017002904

2018.06.30 17:02:03 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002904'

2018.06.30 17:02:03 5: MYSENSOR_5: Firmware block request 1065 (type 81, version 23)
2018.06.30 17:02:03 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170029044E4F4E43453E004F4B004E41434B0021'

2018.06.30 17:02:03 5: SW: 353b3235353b343b303b333b35313030313730303239303434453446344534333435334530303446344230303445343134333442303032310a
2018.06.30 17:02:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:03 4: MYSENSORS/RAW: /5;255;4;0;2;510017002804

2018.06.30 17:02:03 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002804'

2018.06.30 17:02:03 5: MYSENSOR_5: Firmware block request 1064 (type 81, version 23)
2018.06.30 17:02:03 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170028040BFF00FCE1A8A8FFFFFF52145214013C'

2018.06.30 17:02:03 5: SW: 353b3235353b343b303b333b35313030313730303238303430424646303046434531413841384646464646463532313435323134303133430a
2018.06.30 17:02:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:03 4: MYSENSORS/RAW: /5;255;4;0;2;510017002704

2018.06.30 17:02:03 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002704'

2018.06.30 17:02:03 5: MYSENSOR_5: Firmware block request 1063 (type 81, version 23)
2018.06.30 17:02:03 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170027040A960C030A550CD9092F0C9F09810938'

2018.06.30 17:02:03 5: SW: 353b3235353b343b303b333b35313030313730303237303430413936304330333041353530434439303932463043394630393831303933380a
2018.06.30 17:02:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:03 4: MYSENSORS/RAW: /5;255;4;0;2;510017002604

2018.06.30 17:02:03 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002604'

2018.06.30 17:02:03 5: MYSENSOR_5: Firmware block request 1062 (type 81, version 23)
2018.06.30 17:02:03 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170026049D038000FFFFFFFFFFCD0A940A560A82'

2018.06.30 17:02:03 5: SW: 353b3235353b343b303b333b35313030313730303236303439443033383030304646464646464646464643443041393430413536304138320a
2018.06.30 17:02:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:03 4: MYSENSORS/RAW: /5;255;4;0;2;510017002504

2018.06.30 17:02:03 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002504'

2018.06.30 17:02:03 5: MYSENSOR_5: Firmware block request 1061 (type 81, version 23)
2018.06.30 17:02:03 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017002504DEBF0FBECDBFED010895F894FFCF0000'

2018.06.30 17:02:03 5: SW: 353b3235353b343b303b333b35313030313730303235303444454246304642454344424645443031303839354638393446464346303030300a
2018.06.30 17:02:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:03 4: MYSENSORS/RAW: /5;255;4;0;2;510017002404

2018.06.30 17:02:03 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002404'

2018.06.30 17:02:03 5: MYSENSOR_5: Firmware block request 1060 (type 81, version 23)
2018.06.30 17:02:03 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170024040C811B81AA81B981CE0FD11D0FB6F894'

2018.06.30 17:02:03 5: SW: 353b3235353b343b303b333b35313030313730303234303430433831314238314141383142393831434530464431314430464236463839340a
2018.06.30 17:02:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:03 4: MYSENSORS/RAW: /5;255;4;0;2;510017002304

2018.06.30 17:02:03 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002304'

2018.06.30 17:02:03 5: MYSENSOR_5: Firmware block request 1059 (type 81, version 23)
2018.06.30 17:02:03 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170023048C849B84AA84B984C884DF80EE80FD80'

2018.06.30 17:02:03 5: SW: 353b3235353b343b303b333b35313030313730303233303438433834394238344141383442393834433838344446383045453830464438300a
2018.06.30 17:02:03 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:03 4: MYSENSORS/RAW: /5;255;4;0;2;510017002204

2018.06.30 17:02:03 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002204'

2018.06.30 17:02:03 5: MYSENSOR_5: Firmware block request 1058 (type 81, version 23)
2018.06.30 17:02:03 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017002204CDBF09942A88398848885F846E847D84'

2018.06.30 17:02:03 5: SW: 353b3235353b343b303b333b35313030313730303232303443444246303939343241383833393838343838383546383436453834374438340a
2018.06.30 17:02:04 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:04 4: MYSENSORS/RAW: /5;255;4;0;2;510017002104

2018.06.30 17:02:04 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002104'

2018.06.30 17:02:04 5: MYSENSOR_5: Firmware block request 1057 (type 81, version 23)
2018.06.30 17:02:04 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017002104CDB7DEB7CA1BDB0B0FB6F894DEBF0FBE'

2018.06.30 17:02:04 5: SW: 353b3235353b343b303b333b35313030313730303231303443444237444542374341314244423042304642364638393444454246304642450a
2018.06.30 17:02:04 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 17:02:04 4: MYSENSORS/RAW: /5;255;4;0;2;510017002004

2018.06.30 17:02:04 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017002004'

2018.06.30 17:02:04 5: MYSENSOR_5: Firmware block request 1056 (type 81, version 23)
2018.06.30 17:02:04 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '510017002004CF92DF92EF92FF920F931F93CF93DF93'


Immer wieder sind solche langen Zeilen (5;255;4;0;2;510017000000) im log, hier im Beispiel ist das Binary definitiv durch "510017000000", sieht man an den letzten 4 Nullen.
Es scheint, als ob das Update ganz oft die gleiche Nachricht schickt. Verbindungsprobleme habe ich definitiv nicht. Mit MYSController läuft so ein Update in < 1 Minute.

2018.06.30 18:26:12 5: SW: 353b3235353b343b303b333b35313030313730303031303030433934333130333043393433313033304339343837303330433934333130330a
2018.06.30 18:26:12 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000100'

2018.06.30 18:26:12 5: MYSENSOR_5: Firmware block request 1 (type 81, version 23)
2018.06.30 18:26:12 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170001000C9431030C9431030C9487030C943103'

2018.06.30 18:26:12 5: SW: 353b3235353b343b303b333b35313030313730303031303030433934333130333043393433313033304339343837303330433934333130330a
2018.06.30 18:26:12 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000100'

2018.06.30 18:26:12 5: MYSENSOR_5: Firmware block request 1 (type 81, version 23)
2018.06.30 18:26:13 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170001000C9431030C9431030C9487030C943103'

2018.06.30 18:26:13 5: SW: 353b3235353b343b303b333b35313030313730303031303030433934333130333043393433313033304339343837303330433934333130330a
2018.06.30 18:26:13 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000100'

2018.06.30 18:26:13 5: MYSENSOR_5: Firmware block request 1 (type 81, version 23)
2018.06.30 18:26:13 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170001000C9431030C9431030C9487030C943103'

2018.06.30 18:26:13 5: SW: 353b3235353b343b303b333b35313030313730303031303030433934333130333043393433313033304339343837303330433934333130330a
2018.06.30 18:26:13 1: Timeout for PRESENCE_DoLocalFunctionScan reached, terminated process 3523
2018.06.30 18:26:17 1: Timeout for LGTV_WebOS_PresenceRun reached, terminated process 3551
2018.06.30 18:26:17 4: MYSENSORS/RAW: /5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000
5;255;4;0;2;510017000000

2018.06.30 18:26:17 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:17 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:17 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:17 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:17 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:17 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:17 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:17 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:17 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:17 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:17 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:17 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:17 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:17 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:17 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:17 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:17 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:17 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:17 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:17 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:17 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:17 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:17 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:17 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:17 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:17 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:17 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:17 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:17 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:18 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:18 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:18 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:18 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:18 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:18 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:18 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:18 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:18 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:18 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:18 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:18 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:18 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:18 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:18 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:18 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:18 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:18 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:18 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:18 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:18 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:18 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:18 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:18 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:18 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:18 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:18 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:18 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:18 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:18 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:18 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:18 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:18 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:18 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:18 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:18 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:18 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:18 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:18 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:18 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:18 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:18 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:18 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:18 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:18 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:19 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:19 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:19 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:19 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:19 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:19 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:19 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:19 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:19 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:19 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:19 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:19 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:19 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:19 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:19 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:19 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:19 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:19 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:19 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:19 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:19 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:19 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:19 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:19 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:19 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:19 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:19 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:19 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:19 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:19 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:19 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:19 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:19 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:19 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:19 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:19 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:19 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:19 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:19 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:19 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:19 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:19 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:19 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:19 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:19 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:19 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:20 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:20 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:20 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:20 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:20 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:20 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:20 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:20 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:20 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:20 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:20 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:20 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:20 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:20 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:20 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:20 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:20 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:20 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:20 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:20 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:20 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:20 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:20 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:20 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:20 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:20 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:20 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:20 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:20 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:20 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:20 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:20 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:20 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:20 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:20 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:20 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:20 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:20 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:20 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:20 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:20 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:20 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:20 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:20 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:20 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:21 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:21 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:21 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:21 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:21 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:21 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:21 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:21 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:21 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:21 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'

2018.06.30 18:26:21 5: SW: 353b3235353b343b303b333b35313030313730303030303030433934303930333043393438353134304339344143313430433934333130330a
2018.06.30 18:26:21 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=002(ST_FIRMWARE_REQUEST) ack=0 '510017000000'

2018.06.30 18:26:21 5: MYSENSOR_5: Firmware block request 0 (type 81, version 23)
2018.06.30 18:26:21 5: MYSENSORS send: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=003(ST_FIRMWARE_RESPONSE) ack=0 '5100170000000C9409030C9485140C94AC140C943103'



Nach knapp 80 Minuten war dann das Ganze vorbei, erfolgreich!

2018.06.30 18:26:31 4: MYSENSORS/RAW: /5;255;4;0;0;51001700380430850103
0;255;3;0;5;0
0;255;3;0;5;1
5;255;4;0;0;51001700380430850103

2018.06.30 18:26:31 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=000(ST_FIRMWARE_CONFIG_REQUEST) ack=0 '51001700380430850103'

2018.06.30 18:26:31 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:31 4: MYSENSOR_5: received ST_FIRMWARE_CONFIG_REQUEST
2018.06.30 18:26:31 4: MYSENSOR_5: MYSBootloader asking for firmware update, calling firmware update procedure
2018.06.30 18:26:31 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:31 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=005(I_INCLUSION_MODE) ack=0 '0'

2018.06.30 18:26:31 5: MYSENSORS send: Rx: fr=000 ci=255 c=-01(''            ) st=005(''              ) ack=0 '1'

2018.06.30 18:26:31 5: SW: 303b3235353b2d313b303b353b310a
2018.06.30 18:26:31 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=005(I_INCLUSION_MODE) ack=0 '1'

2018.06.30 18:26:31 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=000(ST_FIRMWARE_CONFIG_REQUEST) ack=0 '51001700380430850103'

2018.06.30 18:26:31 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:31 4: MYSENSOR_5: received ST_FIRMWARE_CONFIG_REQUEST
2018.06.30 18:26:31 4: MYSENSOR_5: MYSBootloader asking for firmware update, calling firmware update procedure
2018.06.30 18:26:31 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:33 4: MYSENSORS/RAW: /5;255;4;0;0;51001700380430850103

2018.06.30 18:26:33 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=000(ST_FIRMWARE_CONFIG_REQUEST) ack=0 '51001700380430850103'

2018.06.30 18:26:33 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:33 4: MYSENSOR_5: received ST_FIRMWARE_CONFIG_REQUEST
2018.06.30 18:26:33 4: MYSENSOR_5: MYSBootloader asking for firmware update, calling firmware update procedure
2018.06.30 18:26:33 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:36 4: MYSENSORS/RAW: /5;255;4;0;0;51001700380430850103

2018.06.30 18:26:36 4: MYSENSORS Read: Rx: fr=005 ci=255 c=004(C_STREAM      ) st=000(ST_FIRMWARE_CONFIG_REQUEST) ack=0 '51001700380430850103'

2018.06.30 18:26:36 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:36 4: MYSENSOR_5: received ST_FIRMWARE_CONFIG_REQUEST
2018.06.30 18:26:36 4: MYSENSOR_5: MYSBootloader asking for firmware update, calling firmware update procedure
2018.06.30 18:26:36 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:45 4: MYSENSORS/RAW: /5;255;0;0;17;2.2.0
5;255;3;0;6;0

2018.06.30 18:26:45 4: MYSENSORS Read: Rx: fr=005 ci=255 c=000(C_PRESENTATION) st=017(S_ARDUINO_NODE  ) ack=0 '2.2.0'

2018.06.30 18:26:45 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:45 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:45 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=006(I_CONFIG        ) ack=0 '0'

2018.06.30 18:26:45 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:45 5: MYSENSORS send: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=006(I_CONFIG        ) ack=0 'M'

2018.06.30 18:26:45 5: SW: 353b3235353b333b303b363b4d0a
2018.06.30 18:26:45 4: MYSENSORS_DEVICE MYSENSOR_5: respond to config-request, node parentId = 0
2018.06.30 18:26:45 4: MYSENSORS/RAW: /5;255;3;0;11;Door Window Switch (I2C)

2018.06.30 18:26:45 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=011(I_SKETCH_NAME   ) ack=0 'Door Window Switch (I2C)'

2018.06.30 18:26:45 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:45 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:45 4: MYSENSORS/RAW: /5;255;3;0;12;2.2.0. 29.6. (debug)
5;0;0;0;17;Door Window Switch (I2C)
5;2;0;0;0;door/window sensor
5;101;0;0;30;Battery
5;102;0;0;30;ADC power
5;103;0;0;6;Chip temp

2018.06.30 18:26:45 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=012(I_SKETCH_VERSION) ack=0 '2.2.0. 29.6. (debug)'

2018.06.30 18:26:45 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:45 4: MYSENSORS Read: Rx: fr=005 ci=000 c=000(C_PRESENTATION) st=017(S_ARDUINO_NODE  ) ack=0 'Door Window Switch (I2C)'

2018.06.30 18:26:45 4: MYSENSORS Read: Rx: fr=005 ci=002 c=000(C_PRESENTATION) st=000(S_DOOR          ) ack=0 'door/window sensor'

2018.06.30 18:26:45 4: MYSENSORS Read: Rx: fr=005 ci=101 c=000(C_PRESENTATION) st=030(S_MULTIMETER    ) ack=0 'Battery'

2018.06.30 18:26:45 4: MYSENSORS Read: Rx: fr=005 ci=102 c=000(C_PRESENTATION) st=030(S_MULTIMETER    ) ack=0 'ADC power'

2018.06.30 18:26:45 4: MYSENSORS Read: Rx: fr=005 ci=103 c=000(C_PRESENTATION) st=006(S_TEMP          ) ack=0 'Chip temp'

2018.06.30 18:26:46 4: MYSENSORS/RAW: /5;255;3;0;22;7

2018.06.30 18:26:46 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=022(I_HEARTBEAT_RESPONSE) ack=0 '7'

2018.06.30 18:26:46 5: MYSENSOR_5: refreshInternalMySTimer called (Alive)
2018.06.30 18:26:46 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:46 4: MYSENSORS/RAW: /5;101;1;0;38;2.66
5;103;1;0;0;25.5
5;102;1;0;38;2656
5;255;3;0;32;500

2018.06.30 18:26:46 4: MYSENSORS Read: Rx: fr=005 ci=101 c=001(C_SET         ) st=038(V_VOLTAGE       ) ack=0 '2.66'

2018.06.30 18:26:46 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:46 4: MYSENSORS Read: Rx: fr=005 ci=103 c=001(C_SET         ) st=000(V_TEMP          ) ack=0 '25.5'

2018.06.30 18:26:46 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:46 4: MYSENSORS Read: Rx: fr=005 ci=102 c=001(C_SET         ) st=038(V_VOLTAGE       ) ack=0 '2656'

2018.06.30 18:26:46 5: mySensorsGW: getFirmwareTypes - list contains: Type 1 2 3 10 20 40 50 60 70 75 80 81 90 100 111 112 120 130 150 200
2018.06.30 18:26:46 4: MYSENSORS Read: Rx: fr=005 ci=255 c=003(C_INTERNAL    ) st=032(I_PRE_SLEEP_NOTIFICATION) ack=0 '500'


PS: nach dem Update waren die neuen Readings gelöscht, z.B. OTA_BL_Type

 :)

Danke für die Rückmeldung! Trotz aller Nebenwirkungen ist das super, dass das Update durchgelaufen ist! Das bedeutet, dass jedenfalls irgendeine Message (mit oder ohne Ack) verzögert gesendet wurde, die smartsleep-Dinge demnach grundsätzlich auch so in der Richtung gehen sollten.

Warum das so lange gedauert hat, kann ich nicht vollständig nachvollziehen, vermute aber, dass das mit dem Versuch zu tun hat, jeweils den aktuellen (Zwischen-) Stand des Updates auch in FHEM nachvollziehen zu können. Das dürfte aber eigentlich überflüssig sein - wenn man unterstellt, dass eine Node, die wissen will, was die aktuelle Firmware ist auch "weiß, was sie tut". Von daher neige ich im Moment dazu, bei MYSBootloader-Nodes den "Auto-Update-Modus" als gegeben zu unterstellen, also die firmware immer auszuliefern wenn die Node das will (was ggf. auch bei einem Reboot durch Tastendruck der Fall sein könnte, sofern überhaupt eine neuere firmware hinterlegt ist).

Kurz hatte ich den Versuch unternommen, die Firmware-TYPE als Attribut statt als "set" zu definieren, aber vermutlich hätte das zu dauernden roten Fragezeichen geführt, und das fand ich dann noch unschöner als die verbose-5-Meldung.

Anbei daher erst mal eine für den MYSBootloader-Update aufgeräumte Fassung, wieder nur "im Prinzip lauffähig" und nicht OTA-mäßig getestet, die Hoffnung wäre, dass das damit genauso zackig durchläuft wie mit dem MYSController; für heute mach' ich jetzt erst mal Feierabend 8) .

EDIT: Anhang gelöscht

Ein Update funktioniert auch mit der neuen Version bei einem Repeater-Node (ohne sleep), dauert leider weiterhin lange (läuft derzeit noch...)
Mit einem Node mit smartSleep() konnte ich den Updateprozess leider bislang nicht mehr reproduzieren.

Danke für die erneute Rückmeldung, interessant wäre jetzt noch die Dauer des updates bei einer OptiBoot-nRF-Node. Entweder ist der RFM so viel schneller (@Wallmeier sprach von mehreren Minuten, nicht von mehr als einer Stunde), oder an der Implementierung gibt es Raum für Optimierungen. (Nutzt ihr beide Raspis?)

Wird jetzt vermutlich eine ganze Zeit dauern, bis ich mich da insgesamt nochmal durchgedacht und -getestet habe.
@dirkcx: Der Effekt, dass hinterher die OTA-Readings alle gelöscht waren ist jetzt aber nicht mehr aufgetreten, oder?

Zitat von: Beta-User am 02 Juli 2018, 21:39:49
@dirkcx: Der Effekt, dass hinterher die OTA-Readings alle gelöscht waren ist jetzt aber nicht mehr aufgetreten, oder?

Nein, war ein Fehler meinerseits, config-Datei war einem falschem user zugeordnet (chown), das habe ich aber erst festgestellt, als ich "save" per Kommandozeile eingegeben  habe. Der "Save Config" Befehl in der WebUI von FHEM zeigt keinen Fehler an.

FHEM läuft auf einem Raspi 2 Model B.

fhem läuft bei mir auf einem Raspi 3B und das Update dauert ca. 3-5 Minuten...

So,

anbei die aktualisierten Fassungen - aufgrund der Abweichungen zum Standard und einiger offener Fragen auch erst mal nur hier und nicht im ersten Post.

Was ist neu: Aus einem Kommentar wird (teilweise) ein Readingname. Der Haken an der Sache: Will man das upgedated haben, muß man erst das alte Attribut löschen :( . Hat man z.B. einen DS18B20 und überträgt die ID als Kommentar, wird das sauber angelegt und auch die Temp auf den Sensor unter temperature aktualisiert. Soweit also so gut. Allerdings: wenn man dann einen anderen anschließt, passiert folgendes: Da das mapping durch ist, wird der Name nicht aktualisiert. Die temp wird unter derselben ChildID gesendet. Daher kommt dann die Temp dieses Sensors auch unter der "falschen" ID an. Dass es nicht der ursprüngliche Sensor ist, erkennt man ggf. nur daran, dass das ID-Reading und der ID_Reading-Name nicht zusammenpassen (wenn man auch die ID unter ID sendet)... Ob das ein Fortschritt ist? Dürft ihr euch zu äußern :-\ .

Sieht dann so aus:

Zitatid_28FF943E36160495     28FFD6EC801402D8      2018-07-08 13:17:45

Ansonsten habe ich mir den update-Code nochmal angesehen, und fand kein Optimierungspotential (außer dass der Funktionsname flashFirmware() jedenfalls für MYSBootloader-Nodes irreführend ist). Keine Ahnung also, warum das so lange dauert.

Was nach wie vor nicht funktioniert, ist das Queuen von Nachrichten, wenn die Node bekanntermaßen schläft (der Status- und Reading-update funktioniert, es liegt also ziemlich sicher an den Funktionen zur Array-Bildung bzw. dem Senden der einzelnen Zeilen aus dem Array). Hilfe von Leuten, die wirklich Perl können, ist herzlich willkommen, dann wären wir nämlich ziemlich fertig ;) .

Denn die anderen Dinge funktionieren "an sich", allerdings kommt bei meinen RFM69-Testnodes mit NEW-Driver kein vernünftiger Wert zurück. Das ist m.E. aber auf den Code auf der Node zurückzuführen und nichts, was am Modul geändert werden könnte. Übrigens scheinen nRF-Nodes ab 2.2 auch einen "Pseudo"-RSSI-Wert zurückzuliefern, kann sein, dass man dazu aber ein Flag setzen muß (#define MY_SIGNAL_REPORT_ENABLED). Muß mal bei Gelegenheit ein Node dafür neu flashen (meine verbliebenen nRFs sind "älter").
Vielleicht kann jemand Rückmeldung geben, der den OLD-Driver im Einsatz hat - da sollte das ootb funktionieren (nach dem, was ich dazu bisher gefunden habe).

Die "neue" MYSENSORS.pm bringt nichts wirklich neues, außer, dass die Fehlermeldung wegen eines angeblich fehlerhaften Vergleichs in L472 weg sein sollte. M.E. könnte man diese Version einchecken, ohne dass es zu Problemen für die führt, die die "offizielle" MYSENSORS_DEVICE nutzen.

Viel Spaß erst mal damit und: Rückmeldungen (und Hilfen zu dem Array-Thema) sind willkommen!

Schönen Sonntag noch,

Beta-User

Neues zum Thema RSSI:

Man muß - ähnlich wie bei den DEBUG-Anfragen - als Payload mit angeben, was man genau wissen möchte ;) .Der Code ist daher jetzt bei beidem (auch DEBUG) so umgebaut, dass nacheinander automatisch alle in Frage kommenden Werte abgefragt werden. Kommt was sinnvolles zurück (bei RSSI-Anfragen also nicht "-256"), wird das entsprechende Reading gefüllt. Vorschläge zur Namensgebung sind willkommen.
Ich hoffe, der Automatismus kommt nicht nur mir entgegen, ich fand es jedenfalls recht umständlich, die einzelnen Get-Elemente manuell auszuwählen.

Außerdem ist die Version anbei so gestrickt, dass bei der Info einer smartSleep-Node "Ich gehe jetzt dann schlafen" das Sendefenster noch kurz (den Defaultwert von 500ms) offen gehalten wird, bevor "Asleep" gesetzt wird.

Bleibt das Thema mit der Queue...

Gruß, Beta-User

Die neue Version liefert jetzt bei mir plausible RSSI-Werte...

Danke!

Bei mir läuft die Version mit MYSBootloader auch, wenngleich nur bei 2 von 4 Nodes der Update geklappt hat. RSSI kann der nRF24L01+ leider nicht.

Danke für die Rückmeldungen.

Was RSSI angeht: @Wallmeier: Mußtest du da was speziell einschalten im Code für die Node oder ging das so? Ich hatte erst gedacht, es ginge ohne und habe dann  nach dem ersten Mißerfolg den Code auf das #define MY_SIGNAL_REPORT_ENABLED umgestellt. Würde mich interessieren, ob das nötig ist - ich denke eigentlich nämlich nicht.

@dirkcx: Für nRF24 sollte auch ein Pseudo-Wert verfügbar sein, aber jedenfalls dafür braucht man im Code den obigen Flag. Kannst ja mal Testen. (Es wird irgend was aus den verlorenen Messages kalkuliert). Was die updates angeht, ist das echt irritierend, dass das mit dem anderen Controller so viel besser durchlaufen soll. Aber wie gesagt, ich habe keine Idee, an was es hängen könnte (unterstellt, die Positionierung des GW ist identisch) :( .

Meinungen zu den Reading-Namen aus dem Kommentar? Bekannte Nebenwirkungen? Sollte man das per Attribut zuschaltbar machen?

Danke jedenfalls für's Testen!

Ich habe in meinem Sketch auf dem Node auch das define MY_SIGNAL_REPORT_ENABLED drin...

Auch die Reading-Namen aus den Kommentar funktioniert wunderbar - das möchte ich nicht mehr missen :)

Bei meinem Node wird folgendes angezeigt (nRF24l01+) mit
#define MY_SIGNAL_REPORT_ENABLED

rssi_at_IODev = 0

Reading-Namen aus den Kommentaren finde ich auch gut.

Wenn jetzt das FOTA auch mit Node mit smartSleep() immer nach dem Aufwecken funktionieren würde, wäre erstmal alles da, was ich bräuchte. Vielen Dank erstmal, @Beta-User

...mal schauen, wann ich dieses für mich dicke Perl-Brett mit dem Queuen der Messages vollend hinbekomme, heute morgen bin ich zwar einigen Problemen auf die Schliche gekommen, habe mir dabei allerdings ein paar mal FHEM abgeschossen, also solltet ihr erst mal noch etwas Geduld aufbringen ::) .

Einwände, wenn die Debug und RSSI-Werte je ein Präfix bekommen? R_... für RSSI und XDBG_...

Was die "0" bei rRF angeht: kannst du mal mit der Node wohin gehen, wo nicht mehr alles durchkommt (ggf. am Seriellen Monitor der IDE oä mal sehen, dass Wiederholungen erforderlich werden)? Wäre interessant, ob auch dann noch die "0" kommt. Könnte nämlich sein, dass "0" schlicht heißt: alle Pakete sind ohne Wiederholung angekommen - das wäre doch auch ne Aussage, oder?

Zum Testen für das zeitversetzte Senden erste funktionierende Fassung anbei 8) :) ;D 8) .

Muß wohl noch etwas aufräumen. Damit bekomme ich pro Durchgang eine Message durch . bei einer RFM69-Node mit eher schlechten RSSI-Werten, die sofort wieder schlafen geht.

Viel Spaß beim Testen und schönes WE!

Gruß, Beta-User

Den Präfix für RSSi usw finde ich gut. RSSI zeigt bei mir eine 1 bei einem entfernten Node, der über einen anderen Node als Repeater versorgt wird. Sonst 0.

Bei den Reading-Namen aus den Kommentaren fände ich besser wenn das per Konfig ein/aus geschaltet werden könnte. Macht doch nicht bei allem bei mir Sinn.

Hmm, dann scheint das Thema RSSI bei nRF-Nodes eher wenig Sinn zu machen, schade eigentlich.

Was die Reading-Namen angeht: Das Problem dabei ist, dass man eigentlich die Wahl bereits getroffen haben sollte, bevor die Node sich das erste Mal meldet. Das ginge zwar ggf. durch ein Attribut am GW, wäre dann aber wieder für alle Nodes an diesem GW gültig. An sich könnte man auch sagen: wer das haben will, baut Kommentare in den Code der Nodes, wer nicht, soll es eben lassen (so in die Richtung ging meine Denke, als ich das reingebaut habe).

Meine Tendenz geht zwischenzeitlich aber dahin, das so umzubauen, dass standardmäßig das bisherige Naming stattfindet und ein weiteres "get" einzubauen. Stößt man das an, soll geprüft werden, ob die aktuelle Namensgebung mit der sich aus Kommentaren ergebenden zusammenpaßt und ggf. dann das Naming angepaßt werden. Das hat den weiteren Vorteil, dass man auch Abweichungen ins Log schreiben und damit - zumindest nach einer weiteren Prüfung - auch Inkonsistenzen wie die in #42 aufecken bzw. korrigieren kann. Ist aber was, wo ich erst wieder etwas Zeit finden muß...

Bei Gelegenheit würde ich dann aber den ersten Beitrag mal anpassen und die aktuellen Versionen (ggf. vorerst ganz ohne Kommentar-basierte Readingbenennung) dort posten. Ernsthafte Probleme scheint ja bisher keiner der (wenigen) Tester der aktellen Versionen gehabt zu haben.

So,

im ersten Post des Threads finden sich jetzt nochmal aktuelle Versionen.

00_MYSENSORS.pm habe ich nur aus einem der letzten Posts nach dort verschoben, ist nur wg. L472 geändert, wer also noch eine "alte" nutzt: kein wirkliches Problem.
10_MYSENSORS_DEVICE.pm ist so umgebaut, wie im letzten Post angedacht, man muß also das comment-basierte Bennenen der Readings aktiv mit einem get anstoßen.
Allerdings funktionieren zwei Dinge noch nicht perfekt, aber da ich im Moment auch nicht so recht dazu komme, erst mal diese Zwischenversion - vielleicht kann ja jemand unterstützen:
- 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.

Alles keine essentiellen Dinge, ansonsten scheint der Code keine ernsthaften Probleme zu machen.

Wegen der Dauer des updates bei nRF: Versucht das mal mit einem GW und Repeatern mit Softwarestand 2.2.0 - es gab da bei MySensors.org einen Hinweis, dass die Probleme durch irgendwas im Framework bedingt sein könnten :( . Dann kann ich über dem Perl-code lange brüten...

Viel Spaß erst mal damit, freue mich über euer Feedback. Wenn die beiden Dinge vollends ausgemerzt sind, könnte das m.E. dann nach einem gewissen Testbetrieb (und nach sauberer Formatierung usw.) ins svn.

Gruß, Beta-User

Hinweise im ersten Post sind angepaßt/erweitert.

Sorry für die evtl. dumme Frage: Ich habe ein funktionierendes RFM69 Pärchen aufgebaut und mit "New-Driver" laufen. Sollte da RSSI sinnvoll angezeigt werden ?

Internals:
   DEF        111
   IODev      mySensGwRFM69
   I_DEBUG    1
   I_RSSI     1
   NAME       MYSENSOR_111
   NR         36
   STATE      ???
   TYPE       MYSENSORS_DEVICE
   ack        0
   getCommentReadings 1
   protocol   2.3.0
   radioId    111
   repeater   0
   READINGS:
     2018-07-20 16:07:21   SKETCH_NAME     Motion Sensor
     2018-07-20 16:07:21   SKETCH_VERSION  1.0
     2018-07-20 16:07:20   parentId        0
     2018-07-20 16:15:37   tripped1        off
   gets:
   readingMappings:
     1:
       15:
         name       armed1
       16:
         name       tripped1
   retainedMessagesForRadioId:
   sensorMappings:
     0:
       receives:
       sends:
         16
         15
     1:
       receives:
       sends:
         16
         15
     10:
       receives:
       sends:
         6
         7
     11:
       receives:
       sends:
         11
     12:
       receives:
       sends:
         12
         14
     13:
       receives:
         24
       sends:
         17
         18
         54
         55
         56
         24
     14:
       receives:
       sends:
         45
         21
         0
         2
     15:
       receives:
       sends:
         13
         43
     16:
       receives:
       sends:
         23
         37
     17:
       receives:
       sends:
     18:
       receives:
       sends:
     19:
       receives:
         36
       sends:
         36
     2:
       receives:
       sends:
         16
         15
     20:
       receives:
         32
       sends:
         33
         50
         32
     21:
       receives:
         24
       sends:
         34
         35
         24
     22:
       receives:
       sends:
         37
         43
     23:
       receives:
         24
         25
         26
         27
         28
       sends:
         24
         25
         26
         27
         28
     24:
       receives:
       sends:
         37
         43
     25:
       receives:
       sends:
         19
         20
     26:
       receives:
         40
         17
         3
       sends:
         40
         17
         3
     27:
       receives:
         41
         17
         3
       sends:
         41
         17
         3
     28:
       receives:
         40
       sends:
         40
     29:
       receives:
       sends:
         2
         0
         45
         44
         21
         46
         22
     3:
       receives:
         2
         17
       sends:
         2
         17
     30:
       receives:
       sends:
         38
         39
         14
     31:
       receives:
       sends:
         2
         16
     32:
       receives:
       sends:
         16
         15
     33:
       receives:
       sends:
         37
         16
         15
     34:
       receives:
       sends:
         37
         16
         15
     35:
       receives:
       sends:
         37
         16
         15
     36:
       receives:
         47
       sends:
         47
     37:
       receives:
       sends:
         34
         35
     38:
       receives:
       sends:
         49
     39:
       receives:
       sends:
         0
         51
         52
         53
         2
     4:
       receives:
         2
         3
         17
       sends:
         2
         3
         17
     5:
       receives:
         29
         30
         31
         3
       sends:
         29
         30
         31
         3
     6:
       receives:
       sends:
         0
         42
     7:
       receives:
       sends:
         1
     8:
       receives:
       sends:
         4
         5
     9:
       receives:
       sends:
         8
         9
         10
   sets:
     clear      noArg
     flash      noArg
     fwType     
     reboot     noArg
     time       noArg
   typeMappings:
     0:
       type       temperature
     1:
       type       humidity
     10:
       type       direction
     11:
       type       uv
     12:
       type       weight
     13:
       type       distance
     14:
       type       impedance
     15:
       type       armed
       val:
         0          off
         1          on
     16:
       type       tripped
       val:
         0          off
         1          on
     17:
       type       power
     18:
       type       energy
     19:
       type       button_on
     2:
       type       status
       val:
         0          off
         1          on
     20:
       type       button_off
     21:
       type       hvacflowstate
     22:
       type       hvacspeed
     23:
       type       brightness
       range:
         max        100
         min        0
         step       1
     24:
       type       value1
     25:
       type       value2
     26:
       type       value3
     27:
       type       value4
     28:
       type       value5
     29:
       type       up
     3:
       type       percentage
       range:
         max        100
         min        0
         step       1
     30:
       type       down
     31:
       type       stop
     32:
       type       ir_send
     33:
       type       ir_receive
     34:
       type       flow
     35:
       type       volume
     36:
       type       lockstatus
       val:
         0          off
         1          on
     37:
       type       level
     38:
       type       voltage
     39:
       type       current
     4:
       type       pressure
     40:
       type       rgb
     41:
       type       rgbw
     42:
       type       id
     43:
       type       unitprefix
     44:
       type       hvacsetpointcool
     45:
       type       hvacsetpointheat
     46:
       type       hvacflowmode
     47:
       type       text
     48:
       type       custom
     49:
       type       position
     5:
       type       forecast
       val:
         0          stable
         1          sunny
         2          cloudy
         3          unstable
         4          thunderstorm
         5          unknown
     50:
       type       ir_record
     51:
       type       ph
     52:
       type       orp
     53:
       type       ec
     54:
       type       value
     55:
       type       va
     56:
       type       power_factor
     6:
       type       rain
     7:
       type       rainrate
     8:
       type       wind
     9:
       type       gust
Attributes:
   IODev      mySensGwRFM69
   mapReading_armed1 1 armed
   mapReading_tripped1 1 tripped
   mode       node
   version    2.3.0

Flag im sketch muss gesetzt sein an der Node. Dann get ausführen.

Danke. Das hatte ich übersehen: #define MY_SIGNAL_REPORT_ENABLED

Dann per Webfrontend "get xy RSSI" und mal aktualisieren: Ändert nichts. RSSI=1

Also habe ich auch das Gateway neu geflasht mit "#define MY_SIGNAL_REPORT_ENABLED". Keine Änderung.

Am Gateway sehe ich beim "get xy RSSI" entsprechende Aktivitäten. Am Sensor-Node wird dazu nichts auf der Debug-Konsole ausgegeben.

Denke ich muss erst mal in die Sonne raus ... 8) (Wenn das laufen würde könnte ich mal die 433MHzr LoRa Nodes testen die auf dem Tisch liegen)

Moin,

eine "Kleinigkeit" scheine ich nicht klar genug zum Ausdruck gebracht zu haben: FHEM muss wissen, wann die Node erreichbar ist. Schläft die Node überwiegend, kommt die Info von smartSleep statt sleep, dann bleibt der Transceiver vor dem Einschlafen erst noch kurz wach (default: 500ul => sinnvollerweise erhöhen für nicht 1MHz-Arduinos).

Mein Testcode, ergänzt um MY_SMART_SLEEP_WAIT_DURATION_MS:

// Enable debug prints to serial monitor
#define MY_DEBUG
#define MY_NODE_ID 20

// Enable and select radio type attached
//#define MY_RADIO_NRF24
//#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM95

//Special Options for testing new FHEM module
#define MY_SPECIAL_DEBUG
//#define
#define MY_SIGNAL_REPORT_ENABLED //most likely only needed for nRF-Type nodes to get a pseudo-value - https://forum.mysensors.org/topic/9073/new-2-2-0-signal-report-function
#define MY_SMART_SLEEP_WAIT_DURATION_MS 500

#define MY_RADIO_RFM69
#define MY_IS_RFM69HW // Lokale Vorschriften beachten !
#define MY_RFM69_FREQUENCY RFM69_868MHZ
#define MY_RFM69_NEW_DRIVER


// Define a lower baud rate for Arduino's running on 8 MHz (Arduino Pro Mini 3.3V & SenseBender)
#if F_CPU == 8000000L
#define MY_BAUD_RATE 38400
#endif



#include <MySensors.h>

uint32_t SLEEP_TIME = 30000; // Sleep time between reports (in milliseconds)
#define DIGITAL_INPUT_SENSOR 3   // The digital input you attached your motion sensor.  (Only 2 and 3 generates interrupt!)
#define CHILD_ID 1   // Id of the sensor child

// Initialize motion message
MyMessage msg(CHILD_ID, V_TRIPPED);

void setup()
{
  pinMode(DIGITAL_INPUT_SENSOR, INPUT);      // sets the motion sensor digital pin as input
}

void presentation()
{
  // Send the sketch version information to the gateway and Controller
  sendSketchInfo("Motion Sensor", "1.0");

  // Register all sensors to gw (they will be created as child devices)
  present(CHILD_ID, S_MOTION,"Test 0.1 ä");
}

void loop()
{
  // Read digital motion value
  bool tripped = digitalRead(DIGITAL_INPUT_SENSOR) == HIGH;

//  Serial.println(tripped);
//  send(msg.set(tripped?"1":"0"));  // Send tripped value to gw
  //wait(1000);
  // Sleep until interrupt comes in on motion sensor. Send update every two minute.
  smartSleep(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), CHANGE, SLEEP_TIME);
}


Hoffe, das ist jetzt klarer. Man kannt den Verlauf/Status prüfen (und die Anzahl der zurückgehaltenen Messages usw.), indem man den Browser refresht, diese internen Vorgänge sind nicht-triggernd.

Gruß, Beta-User

Danke, damit konnte ich das Problem "lösen". (Aktuell mit RFM69)

Ursache waren zwei Probleme. Ich denke es geht nur mit smartSleep. Das kommt zwar im Text vor, aber mir war nicht klar dass das sein muss.
Und dann klappt es bei mir trotzdem nur "gelegentlich". Bei MotionSensor muss ich den Finger auf der Sensor-Pin legen um das nötige Chaos herzustellen damit der Sensor quasi andauern funkt.

Denke das kennst Du selber schon.

Im Sketch steht bei mir gerade:

Zitatpresent(CHILD_ID, S_MOTION,"Test 0.1 ä");

Daraus wird dann in den Readings:

Zitattripped_Test_0.1_

Das nächste wäre LoRa 433 gewesen, aber FHEM ist abgeschmiert.

Das ist mit dieser kleinen Testinstanz vorher noch nie passiert. Das ist das Ende vom Logfile:
2018.07.21 09:14:08 4: MYSENSORS/RAW: /0;
2018.07.21 09:14:08 4: MYSENSORS/RAW: 0;/255;3;0;9;3600003 TSM:READY:NWD REQ
0;255;3
2018.07.21 09:14:08 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '3600003 TSM:READY:NWD REQ'

2018.07.21 09:14:08 5: MYSENSORS gateway mySensGwRFM69: 3600003 TSM:READY:NWD REQ
2018.07.21 09:14:08 4: MYSENSORS/RAW: 0;255;3/;0;9;3600017 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,
2018.07.21 09:14:08 4: MYSENSORS/RAW: 0;255;3;0;9;3600017 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,/l=0,sg=0,ft=0,st=OK:
0;255;3;0;9;3600039 TSF:SAN:OK

2018.07.21 09:14:08 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '3600017 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=O
K:'

2018.07.21 09:14:08 5: MYSENSORS gateway mySensGwRFM69: 3600017 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK:
2018.07.21 09:14:08 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '3600039 TSF:SAN:OK'

2018.07.21 09:14:08 5: MYSENSORS gateway mySensGwRFM69: 3600039 TSF:SAN:OK
2018.07.21 09:14:36 5: MYSENSORS outstanding ack, re-send: Rx: fr=111 ci=255 c=003(C_INTERNAL    ) st=006(I_CONFIG        ) ack=1 'M'

2018.07.21 09:14:36 5: SW: 3131313b3235353b333b313b363b4d0a
2018.07.21 09:14:37 4: MYSENSORS/RAW: /0;255;3;0;9;3629017 !TSF
2018.07.21 09:14:37 4: MYSENSORS/RAW: 0;255;3;0;9;3629017 !TSF/:MSG:SEND,0-0-111-111,s=255,c=3,t=6,pt=0,l=1,sg=0,ft=0,st=NACK:M

2018.07.21 09:14:37 4: MYSENSORS Read: Rx: fr=000 ci=255 c=003(C_INTERNAL    ) st=009(I_LOG_MESSAGE   ) ack=0 '3629017 !TSF:MSG:SEND,0-0-111-111,s=255,c=3,t=6,pt=0,l=1,sg=0,ft=0,st=N
ACK:M'

2018.07.21 09:14:37 5: MYSENSORS gateway mySensGwRFM69: 3629017 !TSF:MSG:SEND,0-0-111-111,s=255,c=3,t=6,pt=0,l=1,sg=0,ft=0,st=NACK:M
Not an ARRAY reference at ./FHEM/10_MYSENSORS_DEVICE.pm line 928.


LoRa 433 lauft auch und gibt  auf die kurze Entfernung ein RSSI von -9 und nach zwei Wänden von -43
=>plausibel !

Was ich immer noch nicht so recht verstanden habe: Wenn ich keinen Zugriff auf den Node habe muss ich mich also vor FHEM setzen und warten bis der Node "awake" ist, und dann get RSSI absetzen.
Bei einem Default von 500ms ist das doch kaum machbar. Oder ? (Ich musste da mal z.B. 10000 eintragen um auch zuverlässig Erfolg zu haben...)

ich habe noch zwei "Probleme" entdeckt:

a) ist der FW_TYPE einmal gesetzt, kann man den Node nicht mit einem anderen Sketch mit anderem FW_TYPE flashen. Ich hatte einen Node auf FW_TYPE 81 für Testzwecke und die 81 dann wieder entfernt aus der config-Datei. Dann wollte ich den Node auf einen Sketch vom Typ 80 flashen, aber fhem hat das Reading immer wieder auf 81 zurück gesetzt und der alte Sketch blieb.

b) wenn ich einen Node mittels eines anderen Tools (z.B. MYSController) per FOTA flashe, dann stürzt fhem immer ab. Der Node war in fhem angemeldet.
Kommt selten vor, aber manchmal muss ich halt noch ohne fhem arbeiten, wenn FOTA per fhem nicht klappt  ;)

Danke für die Rückmeldungen, das klingt ja erst mal nach Arbeit :( .

Ohne das im Detail auf die Schnelle analysieren zu können:

- Das mit FW_TYPE muß ich mir ansehen. Wenn ich das richtig verstanden habe, wird zwar das set ausgeführt, aber dann trotzdem immer die erste gemachte Vorgabe abgearbeitet. Richtig?

- Was den Absturz bei Verwendung eines weiteren Controllers angeht: Steht dazu was im Log? (ich hoffe mal, dass es auch Zeile 928 ist...) Sonst evtl. mal bitte Stacktrace einschalten und den Absturz provozieren.

- Man muß mit irgendwelchen Befehlen nicht warten, bis die Node auf "awake" geht. Die Message wird in ein Array geschrieben und dann wieder daraus gelesen, sobald die Node ein "ich bin jetzt wach" sendet (genau wie alle Ack-Messages nochmal gesendet werden, die nicht zugestellt worden sind). Die Abfrage der Größe des Arrays steht in Zeile 928, die für den Absturz bei Ranseyer verantwortlich war. Allerdings ist mir nicht recht klar, wie das zustande kommt, weil FHEM sich für das Array nur dann interessiert, wenn die Node schläft und versucht wird, was zu senden. Die einzige Ausnahme von diesem Prinzip sind update-bezogene messages für nRF-Nodes - die gehen direkt an das IO (Chanel76, wenn vorhanden, sonst das normale).

=>Könnt ihr die Zeile mal in "eval ($hash->{retainedMessages}=scalar(@$messages));" ändern, dann sollte sich FHEM wenigstens nicht mehr weghängen?
- Die Umwandlung der Sonderzeichen bei den Kommentaren ist Absicht - was du da gefunden hast, war ein nicht beseitigter Testcode, ob das funktioniert ;) . Feststellung: Scheinbar klappt das nicht nur bei mir, wenigstens was 8) ...

@Beta-User
R_RSSI_from_Parent zeigt nun übrigens -37 an, ich bringe den Node mal in ein anderes Zimmer...

ZitatWenn ich das richtig verstanden habe, wird zwar das set ausgeführt, aber dann trotzdem immer die erste gemachte Vorgabe abgearbeitet. Richtig?

korrekt

ZitatSteht dazu was im Log?

nein, mein Loglevel ist "1", sorry. Der Hänger war zwischen 11:14 und 11:35 Uhr, dazwischen ist nichts im log. Ich werde das mal reproduzieren, aber vermutlich heute nicht mehr - Pool ruft  ;)

2018.07.21 11:14:23 5: MYSENSOR_5: timeoutMySTimer called (timeoutAwake)
2018.07.21 11:35:57 5: MYSENSOR_5: refreshInternalMySTimer called (Alive)


Zeile 928 ist bei mir eine Leerzeile, ich hab wohl nicht die aktuellste Version der 10_MYSENSORS_DEVICE.pm. Ich bringe mein System auf den aktuellen Stand.

Update: habe die Zeile 928 nun angepasst.

Reicht eigentlich ein reload 10_MYSENSORS_DEVICE.pm um Änderungen wirksam zu machen oder muss ich fhem neu starten?

@Beta-User

woher ziehst Du die Werte für
XDBG_CPU_FREQUENCY  80
XDBG_CPU_VOLTAGE    2344
XDBG_FREE_MEMORY    1280


Könnte man da auch die CPU Temperatur auslesen als XDBG_CPU_TEMPERATURE?

ZitatMan muß mit irgendwelchen Befehlen nicht warten, bis die Node auf "awake" geht. Die Message wird in ein Array geschrieben und dann wieder daraus gelesen,

Wow, das ist cool und hätte ich nicht erwartet. Wenn ich also 10* "get RSSI" absetze dann macht er das also wohl brav der Reihe nach.
Ich hab da schon ordentlich Befehle abgesetzt weil es ein ungutes Gefühl ist, wenn die TX/RX LEDs nicht blinken wenn man das Zeug über ein FTDI Modul speist...
Da wäre ggf. besser mit nem SDR oder so mitzuhören statt auf die LEDs zu schauen...  :'(

Danke nochmals für den Einsatz!

Hinter den DEBUG-Werten steckt https://www.mysensors.org/apidocs-beta/group__SerialDebugGrpPub.html#ga261ca40adab009c13aaf354c9064d958 (https://www.mysensors.org/apidocs-beta/group__SerialDebugGrpPub.html#ga261ca40adab009c13aaf354c9064d958) - ganz am Ende. Temperatur geht daher also nicht. Dürfte bei den Arduinos auch kein größeres Thema sein, da wird ja immer dasselbe gemacht.

Das mit der FW_TYPE wird vermutlich etwas dauern.

Den Verbose-Level hast du ja schon hochgedreht, wenn ich das richtig interpretiere. Dann hilft wohl nur ein stacktrace (wenn es das mit Zeile 928 nicht war).

Ein Reload sollte in der Regel reichen.
Nein, wenn du 10* get RSSI eingibst, wird nur 1* am Ende tatsächlich gesendet; der Code sollte so intelligent sein, dass neue Anweisungen an dasselbe Child die alten überschreiben (wenn du also ein "aus" für ein Licht im der Queue hast, dann "ein" sendest, bleibt am Ende nur das "ein" im Array ;) ). Geklaut von der Ack-Logik ::) .

Ob gesendet wurde, sieht man an der Größe des Arrays (=> Zeile 928...), die im Internal "retainedMessages" steht ;) .

Mit der Codeänderung stürzt fhem nicht mehr ab, wenn ein Node extern per FOTA eine neue Software bekommt.

Zitat von: dirkcx am 21 Juli 2018, 14:11:47
R_RSSI_from_Parent zeigt nun übrigens -37 an, ich bringe den Node mal in ein anderes Zimmer...

Ähm, das ist doch nRF24, oder? Das wäre ja eine angenehme Überraschung :) :) :) !

Zitat von: dirkcx am 21 Juli 2018, 17:37:13
Mit der Codeänderung stürzt fhem nicht mehr ab, wenn ein Node extern per FOTA eine neue Software bekommt.

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.

Zitat von: Beta-User am 21 Juli 2018, 18:39:15
Ähm, das ist doch nRF24

Nee RFM96W , also die LoRa 433MHz Stamps von Hope.
NRF* habe ich keine mehr.

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

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

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

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.

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

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!

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.

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

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.

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  :'(

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

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

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

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

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

Hi,

mein mysensors Gateway verliert leider ab und an mal die Netzwerk Verbindung.
Da im mysensors Modul kein Reconnect eingebaut war, habe ich das mal mittels Timer nachgerüstet.

Den Patch anbei.

PS: Habe das Modul nun seit 2 Wochen mit dem Patch laufen und konnte nichts negatives feststellen.

In dem Patch sind jetzt halt aber auch die anderen Änderungen mit enthalten die nicht von mir stammen.

Hi Sidey,

Danke für den Patch, war einige Zeit weg, deswegen die späte Rückmeldung.

Ich hatte es mir gestern kurz angesehen und Hauswart auch empfohlen, das (zusammen mit der constants.pm aus dem ersten Beitrag dieses Threads) einzuchecken.

Gestern bin ich dann aber noch über diese Sache hier gestolpert: https://forum.fhem.de/index.php/topic,90682.msg831620.html#msg831620

Da du zwei Timer nutzt: Ich bin mir nicht so ganz sicher, ob sich die beide nicht irgendwie ins Gehege kommen (also der eine den anderen überschreibt).
Sollte man die beiden nicht so wie im Beispiel von Rudi aufgeführt umschreiben? (Dasselbe würde ich dann im -DEVICE auch machen, aber die werden bereits getrennt benamst).

Und: müßte man den Timer nicht beim Löschen eines GW ebenfalls ausdrücklich löschen, oder erfolgt das automatisch, weil mit dem Geräte-Hash verknüpft (bei meinem muß das ausdrücklich gemacht werden, die haben keinen Bezug zum Gerätehash)?

Sorry für die evtl. doofen Fragen, ich bin nach wie vor eigentlich kein Programmierer ::) .

Gruß, Beta-User

Beim undef hast Du recht. Da müsste noch ein removeinternaltimer rein.

Ob sich die Timer ins Gehege kommen, weiss ich aktuell nicht.
Da muss ich noch drüber nachdenken.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Moin,

beim undef war/ist alles ok, da ist schon immer ein removeinternalTimer($hash) drin, das löscht alle zugehörigen timer.

Was die Struktur angeht,  noch ein paar Anmerkungen bzw. Fragen (ist eher Kosmetik):
Eigentlich ist der Funktionsname "GetConnectStatus" m.E. irreführend, es müßte eigentlich eher "DoReconnect" heißen, weil nach Ablauf dieses Timers ja effektiv "Start" aufgerufen wird (der 5-Sek.-Timer wird ja nie abgebrochen, oder?), was seinerseits "Init" ruft.

Wie wäre es,  den Heartbeat-Request und den ersten Aufruf des 5-Minuten-Timers nach "Init" zu verschieben? Das ergäbe dann m.E. eine (langsame) Dauer-Loop von "Start" und "Init", bis der angefragte Heartbeat kommt (btw. m.E. unabhängig davon, ob der Heartbeat vom GW oder eine Node dahinter kommt; das macht aber nichts, Hauptsache, die Verbindung ist (noch) da).

Btw.: Paßt der Loglevel 4 in"GetConnetStatus/DoReconnect" auf Verbindungsabbrüche?

Oder habe ich das ganze falsch interpretiert?
EDIT: Ja, falsch, es gibt den Abbruch, daher stimmt auch der Funktionsname ??? ...
Frage: Sollte man den Timer-Ablauf bei Verbindungsabbruch nicht loggen? Dann wäre im 5-Sek.-Timer nicht "Start" aufzurufen, sondern eine Zwischenfunktion, die loggt und dann "Start" aufruft. (Wieder nur Kosmetik).

Grüße, Beta-User

Die Änderungen sind ab morgen via SVN verfügbar. Danke @Sidey und @Beta-User


@Sidey die Reconnect Probleme hatte ich vor Monaten auch mal (Workaround war at der alle 5 Minunten den Reconnect durchgeführt hatte) aber seit ein paar Monaten habe ich auch ohne at keine Probleme mehr.


Gruss

Hallo zusammen,
vorab mal Danke an HAuswart und Sidey für die zwischenzeitlichen Ergänzungen.

Was 10...DEVICE angeht, muß ich zugeben, dass ich etwas den Faden verloren hatte, nachdem die OTA-Sache mit dem MyS-Bootloader wohl nicht so wollte und dann noch eine Unterbrechung wg. Urlaubs dazukam.

Heute habe ich dann mal endlich angefangen, wieder mal "echte" Hardware in die Hand zu nehmen. Hat jedenfalls bis zu dem Punkt funktioniert, dass ich einige kaputte Arduinos aussortiert habe und jetzt weiß, dass ich den Lötkolben auspacken muß bzw. das das einfachste sein wird :( .

Wenn das mit dem OTA-Thema noch länger dauern sollte, weil wieder was nicht klappt, würde ich vorschlagen, ggf. erst mal den Rest weiter zu machen und dann die OTA-Sache nochmal gesondert anzugehen.

Da es ja einige wenige gibt, die den Stand von Ende Juli (29.) runtergeladen haben (läuft auch bei mir derzeit so noch):
- Irgendwelche bekannten Probleme damit?
- OTA versucht?

Das einzige, was mir an Problemen bekannt ist: die Set-Namen müßte man in der "use-Comments"-Option ebenfalls noch automatisiert ändern (wie die Reading-Namen). Die OTA-Sache war jetzt ohne ACKs und könnte daher ggf. auch bereits jetzt schneller sein.

Oder sollte das eurer Meingung nach ggf. halt "unfertig" an den Start gehen (gefällt mir nicht so)?

Gruß, Beta-User

Hi,

ich habe mich in OTA Update erst mal wieder einarbeiten müssen.
Hatte das bei einem Sensor vor über einem Jahr gemacht, aber seitdem der stabil läuft, gab es keinen Anlass etwas zu verändern :)

Jetzt habe ich zwei neue Sensoren, die den mysensorsbootloader haben. Hat ein bisschen gedauert, bis ich das hinbekommen hatte.
Ich könnte die Thematik also durchaus mal ausprobieren.

Zum Thema Heartbeat zum mysensos gateway - das scheint das reading "heartbeat" nicht zu aktualisieren, so wie es aktuell in der normalen svn Version implementiert ist.


Grüße Sidey

Hallo Sidey,
wäre klasse, wenn du das machen könntest, ich muß eigens für OTA Hardware aufbauen und ein Gefühl dafür entwickeln.

Dann würde ich mich im Gegenzug endlich mal dran machen, den set_-Teil noch umzuarbeiten.

Was man evtl. noch machen könnte, wäre die Timer in DEVICE mit dem hash zu verknüpfen, wie das allg. üblich ist. (@all: Mithilfe ist gerne gesehen!)

---

Was den heartbeat am GW angeht:
Hast du mehrere GW's? Ich hatte eben die Daten bei mir mal geprüft. Da hatte das erste ein Reading "last" mit einem ziemlich aktuellen Zeitstempel, das scheint also aktualisiert zu werden, allerdings (wenn es so gemacht ist wie an den DEVICE-Devices) nichttriggernd. Man muß also den Browser-refresh ausführen, damit man Änderungen sieht.
ABER: das 2. GW, das ich mir angesehen hatte, hatte gar kein solches Reading.

Muß ich mir mal ansehen :( . (Bei der Gelegenheit: Braucht man die Angabe überhaupt noch? Ich hatte das bei meinen ersten Gehversuchen reingebaut, quasi als händische Kontrollmöglichkeit. Jetzt ist es evtl. unnötig und verwirrt ggf. mehr als es hilft.)

Gruß, Beta-User

Hi Leute,

vielen Dank erst mal für die Arbeit am MySensors Modul! Mein DIY Netzwerk wächst stetig.

Allerdings stürzt seit dem Update leider FHEM ab wenn ich einzelne bereits angelernte Nodes neu starte (z.B. Stecker raus und wieder rein). Im Log findet sich anschließend folgende Fehlermeldung:

Undefined subroutine &MYSENSORS::DEVICE::onStreamMessage called at ./FHEM/00_MYSENSORS.pm line 428.

Meine Nodes laufen alle auf dem MYSbootlader und ich als Laie könnte mir vorstellen, dass es damit zusammenhängt. Während des Bootens schickt der Bootloader nämlich irgendwelche "Firmware Check" Messages. Vielleicht kann das FHEM Modul nicht richtig mit diesen umgehen.

Sobald man neue Nodes einschaltet, dessen Node-ID in fhem noch nicht definiert sind, stürzt aber komischerweise nichts ab und das Gerät wird ordnungsgemäß per autocreate hinzugefügt.

Gibt es eine Möglichkeit, dieses Problem zu beheben?

Viele Grüße,
Mathea

Kannst du die Message vom Node aufzeichnen, wenn es neu startet?

Zitat von: Mathea am 19 September 2018, 22:00:38

Code Auswählen Erweitern

Undefined subroutine &MYSENSORS::DEVICE::onStreamMessage called at ./FHEM/00_MYSENSORS.pm line 428.

Ich unterstelle mal, dass du nicht eine der aktualisierten 10_MYSENSORS_DEVICE.pm-Fassungen aus dem Thread hier verwendest, sondern die über das reguläre update verteilten?

Wenn dem so ist, füge bitte in deine -DEVICE.pm (z.B. vor der sub attr) folgendes ein:
sub onStreamMessage($$) {
    my ($hash, $msg) = @_;
}
Versuch's dann nochmal. Wenn das dann den Fehler behebt, bitte um Info.
@Hauswart: Wenn das das Problem behebt: kannst du das dann in die 10....pm einpflegen und ins svn geben?

Danke für die Fehlermeldung. Danach darfst du natürlich gerne auch die Version hier aus dem Thread austesten (am besten die von Ende Juli). Damit könnte auch OTA funktionieren...

Gruß, Beta-User

@Mathea kannst du diese Datei bitte kurz testen?

Zitat von: Hauswart am 20 September 2018, 07:35:26
@Mathea kannst du diese Datei bitte kurz testen?

@Hauswart, vielen Dank für den schnellen Patch und die Hilfe! Das hat das Problem behoben :) Habe drei verschiedene Nodes neu gestartet und bei keinem ist FHEM ausgefallen. Es findet sich auch keine Fehlermeldung mehr im Log.

@Beta-User: Vorher hatte ich tatsächlich das File aus dem regulären Update drin und mich noch nicht an die Versionen hier aus dem Thread getraut.

Bezüglich OTA:
Ich kenne das Unterfangen via der Windows MYScontroller-Software aus dem MySensors Forum. Ist meine Annahme korrekt, dass ich für eine Nutzung der FHEM-internen OTA Funktionalität das dort genutzte firmware-config.csv file mitsamt firmware .hex files in einen Ordner auf meinen fhem Server kopieren kann? Muss dieser Ordner an einem bestimmten Platz liegen und einen bestimmten Namen haben?
Außerdem: Wie wird das FOTA Update von batteriebetriebenen Nodes gehandhabt, die SmartSleep nutzen? Im MYScontroller hat man die Möglichkeit, ein Device als "batteriebetrieben" zu kennzeichnen. In dem Moment wartet MYScontroller mit dem Senden der Reboot Message bis eine SmartSleep Nachricht des Nodes empfangen wurde. Kann das das FHEM Modul auch?

Gruß,
Mathea

Zitat von: Mathea am 20 September 2018, 15:06:02
@Hauswart, vielen Dank für den schnellen Patch und die Hilfe! Das hat das Problem behoben :) Habe drei verschiedene Nodes neu gestartet und bei keinem ist FHEM ausgefallen. Es findet sich auch keine Fehlermeldung mehr im Log.

@Beta-User: Vorher hatte ich tatsächlich das File aus dem regulären Update drin und mich noch nicht an die Versionen hier aus dem Thread getraut.

Bezüglich OTA:
Ich kenne das Unterfangen via der Windows MYScontroller-Software aus dem MySensors Forum. Ist meine Annahme korrekt, dass ich für eine Nutzung der FHEM-internen OTA Funktionalität das dort genutzte firmware-config.csv file mitsamt firmware .hex files in einen Ordner auf meinen fhem Server kopieren kann? Muss dieser Ordner an einem bestimmten Platz liegen und einen bestimmten Namen haben?
Außerdem: Wie wird das FOTA Update von batteriebetriebenen Nodes gehandhabt, die SmartSleep nutzen? Im MYScontroller hat man die Möglichkeit, ein Device als "batteriebetrieben" zu kennzeichnen. In dem Moment wartet MYScontroller mit dem Senden der Reboot Message bis eine SmartSleep Nachricht des Nodes empfangen wurde. Kann das das FHEM Modul auch?

Gruß,
Mathea

Danke für die Blumen, aber @Beta-User hat die Arbeit geleistet. Ich habe es nur schnell zusammengeschustert. Werde es erst morgen hochladen können somit ab Samstag für alle.

Zitat von: Hauswart am 20 September 2018, 15:16:49
Danke für die Blumen, aber @Beta-User hat die Arbeit geleistet. Ich habe es nur schnell zusammengeschustert. Werde es erst morgen hochladen können somit ab Samstag für alle.

Danke für die schnelle Reaktion deinerseits, die Reparatur an sich war Ehrensache, ich hab's schließlich auch verbockt ;) !

@Mathea:
Danke für die schnelle Rückmeldung.

Das mit dem OTA funktioniert (hoffentlich) ziemlich genau so wie von dir beschrieben, das csv ist dasselbe, die passenden Dateiorte auf dem FHEM-Rechner stehen nach meiner Erinnerung in der Commandref.

FHEM erkennt übrigens automatisch, dass es sich um smartsleep-Nodes handelt und startet das update dann erst in einer "Wachphase". Man muß halt zuerst warten, bis die Node erstmalig eine Meldung abgesetzt hat, dass sie jetzt "smart" schlafen geht (sieht man ggf. erst nach einem Browser-refresh).

Man kann jetzt übrigens auch jede andere Art von Info (nicht nur OTA) an smartsleep-Nodes senden (davon gehe ich zumindest nach meinen bisherigen Tests aus).

Es gab bei den OTA-updates allerdings noch ein Problem: es hat sehr lange gedauert, bis das durchgelaufen ist. Ob das jetzt beseitigt ist, wissen wir noch nicht. Ich habe da "auf Verdacht" was geändert, bin aber selbst noch nicht zum Testen gekommen (ich nutze eigentlich nur noch RS485-Nodes mit Hardwareserial, da geht das eh' nicht bzw. nur mit DualOptiboot).

Wenn du also testen magst: Gerne :) .

Solange du "nur die bisherige" Funktionalität nutzt, sollte das ungefährlich sein.

So, jetzt hatte ich mal Muße, eine meiner Schalt-Nodes auch mal mit "sprechenden" Namen für diverse Schaltausgänge zu versehen.
An sich war ich da schon Ende Juli recht weit gewesen, das funktioniert soweit, allerdings ist es bei den "set"-Befehlen leider nicht so, dass die überflüssigen auch wieder aus der set-Liste entfernt werden. Vielleicht hat da einer der Perl-Experten eine Idee?

Ist aber m.E. auch nicht sooo dramatisch; Meinungen dazu?

Ansonsten anbei ein Bildchen, wie das dann aussieht und der leicht aktualisierte Code mit dem Hinweis, wo's noch fehlt...

Irgendjemand schon mit Rückmeldung, ob das mit dem Update auf MyS-BL jetzt schneller durchläuft und auf dem Dual-Optiboot noch? (Habe grad wirklich keine große Lust auf Steckbrett und Lötkolben ::) )

Schönes WE allseits,

Beta-User

EDIT: pm im Anhang in den ersten Threadbeitrag verschoben.

@Sidey:
Hast du noch was rausgefunden wegen der heartbeat-Geschichte am GW? Ich habe eben mal eine readingsgroup gebastelt, um da einen Überblick über den aktuellen Stand zu haben. Da sah fast alles ok aus:

4 von den 5 derzeit laufenden GW's haben ein ziemlich aktuelles heartbeat-Reading, das 5. nicht. Sind alles serielle GW's, die 4 mit "heartbeat"-Reading sind Nanos (3xFTDI, 1 CHG340), die stehen auf "startup complete", das 5. ist ein ProMicro, der steht auf "opened" (und funktioniert tadellos, das ist mein RS485-GW mit HW-serial; da könnte es sein, dass der den heartbeat dann auf die andere serielle Schnittstelle legt, was zwar hier den Zweck nicht erfüllt, aber eigentlich logisch ist...).
RG (nicht schön, aber  erfüllt ihren Zweck):
defmod rg_MySensors_GWs readingsGroup <Gerät>,<Status>,<Heartbeat> TYPE=MYSENSORS state,heartbeat
Gruß, Beta-User

kurze Anmerkung noch:
in der 00_MYSENSORS.pm wird folgende Fehlermeldung geworfen:

Undefined subroutine &MYSENSORS::DEVICE::onStreamMessage called at ./FHEM/00_MYSENSORS.pm line 428.

weil in der (aus svn per Update gezogenen) 10_MYSENSORS_DEVICE.pm die Methode onStreamMessage nicht existiert.

Das führt leider bei mir regelmäßig zu Abstürzen, daher habe ich die Zeile 428 auskommentiert.

Hmmm,
eigentlich sollte das mit dem update schon vor einiger Zeit behoben sein, siehe dazu die letzten posts hier.
Bist du sicher, dass du die letzte "Device".pm erhalten hast?

Ansonsten bitte übergangsweise die pm aus dem ersten Post verwenden.

Hallo Zusammen,
hatte den Fix nie ins SVN commitet. Ist ab morgen via Update vorhanden.

Gruss

Zitat von: Beta-User am 18 September 2018, 08:59:27
wäre klasse, wenn du das machen könntest, ich muß eigens für OTA Hardware aufbauen und ein Gefühl dafür entwickeln.

Dann würde ich mich im Gegenzug endlich mal dran machen, den set_-Teil noch umzuarbeiten.

Was man evtl. noch machen könnte, wäre die Timer in DEVICE mit dem hash zu verknüpfen, wie das allg. üblich ist. (@all: Mithilfe ist gerne gesehen!)

Ich hab mir das mit dem FOTA vorbereitet.
Das attribut "OTA_firmwareConfig" habe ich im MYSENSORS Gerät gesetzt.
Allerdings finde ich nirgendwo eine Option das Update zu starten...

Was muss ich denn hier machen um das mal zu testen?

Grüße Sidey

Soweit ich das im Kopf habe:
set <device> fwType (passend zur Node; die Infos kommen aus der Config-file, die am GW als attr. hinterlegt ist)Dann set <device> flash
Das sollte es eigentlich schon gewesen sein (es gibt dazu auch schon eine rudimentäre commandref.)

Hallo,

Leider habe ich kein

set <device> fwType
Und auch kein flash Befehl.

In der Commandref stehen die Befehle leider auch nicht. Das wundert mich ja so.

Grüße Sidey


Gesendet von meinem Moto Z (2) mit Tapatalk

Hallo @Sidey, kann es sein, dass Du die Version aus dem svn installiert hast und nicht die, die hier im ersten Post angehängt ist?

Das ist richtig.
Die ist ja von Ende Oktober aus dem SVN.

Die Oktober-svn-Version ist "nur" eine leicht modifizierte "alte", enthält aber nix zum Thema OTA (außer, dass eine leere Funktion eingebaut ist, um firmware-requests nicht gleich mit einem Absturz zu quittieren).

Die "September"-Version ist also die eigentlich aktuellste.

Was mir insgesamt noch nicht so ganz gefällt: Scheinbar wird bei jedem set-Befehl (also auch, wenn man nur einen switch auf off schaltet) die firmware-config gelesen. Finde ich nicht sooo toll, weiß aber auch nicht, ob das wirklich stört oder irgendwie anders besser gelöst werden könnte. Hatte kurz die Überlegung, das in ein get umzuwandeln.

Gibt's da Meinungen zu?

@Sidey:
Hast du jetzt die September-Version mal OTA-mäßig getestet und für gut (oder schlecht) befunden?

Bin leider schon wieder verhindert... habe es aber noch vor.

So, jetzt habe ich den Tag über erfolgreich mit diverser Hardware rumgekämpft 8) .

Ergebnis anbei, damit läuft ein kleinerer Sketch in ca. einer Minute durch, bis er wieder vollends online ist - gute Funkbedingungen vorausgesetzt. Allerdings ist die interne Logik bei den MYSBootloader-Dingern etwas anders als bei DualOptiboot, so dass theoretisch da was kaputt gegangen sein könnte (ich denke aber nicht).

Wäre daher nett, wenn jemand diesen Teil nochmal verifizieren könnte, ansonsten würde ich das dann irgendwann über Weihnachten vollends einchecken.

Soweit erkennbar, wäre das einzige, dass durch den veränderten heartbeat-Mechanismus "ältere" alive-Überwachungen nicht mehr so ohne weiteres laufen. Da wäre dann eine Zeile wieder zu aktivieren, sonst sehe ich eigentlich keine größeren Schwierigkeiten, oder übersehe ich grade was?

Gruß und viel Spaß damit,

Beta-User

 :( leider bleibt mein fhem mit der Version 10_MYSENSORS_DEVICE.pm mit MYSBootloader nach kurzem Test komplett hängen.
Ich teste in den nächsten Tagen weiter, aber wirklich "debuggen" kann ich das mangels Perl Kenntnissen und Tools leider nicht.
Tipps dazu nehme ich aber gerne an ;-)
schöne Feiertage ...

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

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

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

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

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

Meinungen dazu?

So, vorhin habe ich noch getestet, ob das mit dem 2. GW klappt, wenn man nodes hat mit einem anderen Kanal. Ergebnis ist erst mal negativ, weil die Anfrage nach der firmware über das "falsche" GW rein kommt (wird auf Kanal76 empfangen).
Dort ist die Node aber natürlich nicht als Client hinterlegt, was dazu führt, dass die Anfrage verworfen wird.
Wer also eine schnelle Idee hat, wie onStreamMessage() in 00_MYSENSORS.pm sinnvollerweise zu erweitern wäre (um Zeile 430 herum): Her damit...

Hallo @Beta-User,

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

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

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

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


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

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

Ein OTA Update habe ich aber noch nicht gemacht. Ich beobachte weiter...

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

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

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

Mal schauen, ob ich das noch gelöst bekomme, kann eigentlich auch kein Hexenwerk sein :) .

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

Ich könnte jetzt den fhem Prozess killen, aber dann kann ich nichts mehr über den Grund herausfinden. Wg. im Fhem-Log steht nichts. Im syslog auch nicht.
Wo kann ich noch nach Gründen für das "Hängen" vom FHEM suchen?

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

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

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

Ansonsten muß ich mir den Code insgesamt nochmal durchsehen, aber wie gesagt: eine richtige Idee habe ich im Moment nicht...

Also,

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

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

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

Meinungen dazu?

Gruß,

Beta-User

Hallo Jörg,

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

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

Meinungen dazu?

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

Gruß Peter

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

Übrigens läuft fhem mit Deiner neuesten Datei schon seit Stunden sauber, alles mit verbose 5. Ich habe zwischendurch mal ein Reboot auf einem krischen Node gemacht, auch ok. Noch kein "flash". Ich beobachte weiter ...

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

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

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

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

Dann werde ich das mal am WE soweit fertig machen, wenn sich keiner mehr wehrt :) .

So,
jetzt wird es also wahr...

Ich habe das update vorhin noch mit ein paar kleineren Änderungen ins svn gepackt, Rückmeldung im Problemfall dann bitte hier (https://forum.fhem.de/index.php/topic,95298.0.html).

Gruß und viel Spaß damit,
Beta-User