Probleme mit OTA via mysbootloader und FHEM

Begonnen von uwetaz, 08 Mai 2021, 21:55:48

Vorheriges Thema - Nächstes Thema

uwetaz

Hallo,

ich habe OTA mit MYSController und einem GW mit Node jeweils mit NRF24 zum Laufen gebracht und wollte jetzt OTA mal über FHEM probieren. So richtig bekomme ich das aber nicht hin. Ich versuche mal zu beschreiben was nicht klappt (eigentlich kommt nur eine Fehlermeldung im log-File).

Ich habe das GW zusätzlich zu meinem schon vorhandenen RFM69HW GW zum Spielen eingebunden.

Vorab zwei Fragen:
1) Ist es richtig dass das csv File firmware_config.csv heißen muss und die erste Spalte Type eine Art ID der FW ist? Zumindest habe ich es so verstanden, da ich in FHEM ja keinen hex-Filenamen vorgeben kann. FW_TYPE vom Node habe ich jedenfalls auf genau diese Zahl aus dem csv gesetzt (hier 20). Das File sieht so aus
Type,Name,Version,File,Comments
10,Blink,1,Blink.ino.hex,blinking example
20,uwe,1,2021_04_25_mysensors_nrf_temperature.ino.hex,kommentar

2) Liest FHEM sowohl das csv-File als auch das hex-File im Moment des updates oder gibt es sowas ähnliches mit in MYSController mit "Reload Repo"?

Ich habe einen einfachen Sketch mit einer blinkenden LED (via millis Funktion, da kein delay funktioniert) und habe jeweils ein hex-File mit schnellem und eines mit langsamen Blinken. FHEM scheint den node nach set flash auch noch rebooten zu können (LED hört auf zu blinken) aber dann passiert nichts.
Im logfile steht das hier (die zweite Zeile kommt dann aller 2-3s):
2021.05.08 21:08:16 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/00_MYSENSORS.pm line 460.
2021.05.08 21:08:23 3: No firmware defined for type 20 - not flashing!

Nach einem Reboot und nochmaligem Versuch steht zusätzlich zu den obigen Zeilen noch diese Zeile
2021.05.08 21:25:18 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/10_MYSENSORS_DEVICE.pm line 406.


Was mache ich falsch?
Vielen Dank für einen Hinweis
Grüße
Uwe

Beta-User

Vorab: Ich habe auch schon ewig nichts mehr bzgl. update gemacht, und wie es mit MYSController funktioniert, kann ich nicht sagen, das hatte ich nie im Einsatz...

#460 kann ich nicht zuordnen, in der aktuellen Version sollte es eine andere Zeilennummer sein (falls das uninitialized nicht sogar schon gefixt ist) => FHEM-update durchführen.

Grundsätzlich müsste ein update mit genau derselben File gehen wie mit MYSController, und die Vorgabe betrifft lt. commandref zu MYSENSORS eigentlich eher das Verzeichnis und weniger den Dateinamen. Ggf. zeigst du mal ein list vom GW, ich vermute, an der Stelle paßt was nicht zusammen, die Config-file kann nicht gelesen werden und daher passiert auch nichts. Hast du denn die Nummern in einem Drop-Down in FHEMWEB (zumindest, soweit ich mich entsinne, müßten die zur Auswahl stehen, wenn die File gelesen werden kann).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

uwetaz

Danke für Deine Antwort!

Das FHEM Update habe ich gemacht. Die Fehlermeldung bleibt. Es git nur noch eine Warnung. Die Zeilennummer ist wie erwartet anders.
Versionen vorher
00_MYSENSORS.pm Rev 20188
10_MYSENSORS_DEVICE.pm Rev 20506
nacher
Rev 24385 für beide Files

2021.05.09 19:58:16 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/00_MYSENSORS.pm line 784.
2021.05.09 19:58:23 3: No firmware defined for type 20 - not flashing!

Beim Rumprobieren bin ich eher zufällig über die Ursache gestolpert. Danach ging es: Im GW gibt es ein Attribut dem der Name der csv-Datei übergeben werden muss. Das ist aber standardmäßig erst nach dem Setzen sichtbar.

Da ich vor dem hier beschriebenem Problem über weitere Kleinigkeiten beim Thema OTA gestolpert bin, hätte ich mögliche Ergänzungen für
https://wiki.fhem.de/wiki/MySensors_Starter_Guide#OTA
;siehe Anhang (einmal jpg wo die Änderungen markiert sind und einmal als txt zum Kopieren). Vielleicht hilft das ja jemandem die zwei Abende zu sparen die ich investieren musste.

Ferner ist mir eine Kleinigkeit beim Web-IF in diesem Zusammenhang aufgefallen:
Nach set fw type schließt sich im Web IF das Fenster vom node und es steht nur noch FW_TYP: xxx da. Könnte man das nicht weglassen? Der FW_TYP ist ja in der Node-Maske sichtbar.

Beta-User

Danke erst mal für die konstruktive Rückmeldung.

Den Text im Wiki habe ich - etwas modifiziert - ergänzt.

Es wäre klasse, wenn du mal checken könntest, ob die angehängten Modulversionen das eine oder andere Problemchen beseitigen.
Da ist v.a. umgestellt, dass die OTA-file nicht mehr jedes Mal geladen wird, wenn man die Detailseite einer Node (neu) aufruft. Hat zwar den "Nachteil", dass man das Einlesen der file ggf. forcieren muss (via "set <IO> connect"), aber dafür gibt es jetzt einen eindeutigen Hinweis, dass die File ggf. nicht (richtig) gesetzt ist.
Weiter war da etwas "C-style-loop"-Coding drin, das ich bei der Gelegenheit dann auch durch die Perl-Variante ersetzten würde, wenn es jemand erfolgreich getestet hat ::) .

Generell weiß ich immer noch nicht, ob die Parallelisierung zu MYSController eine gute Idee war, oder ob man das nicht dorch irgendwann auf den "üblichen FHEM-Standard" ändern sollte, dass man halt eine fw-file angibt....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

uwetaz

#4
Ich habe die Module mal hergenommen und probiert.

Muss ich eigentlich immer FHEM neu starten nach dem Kopieren der Files? Ich hab es jedenfalls gemacht.

Ergebnis
Ein Problem scheint weg zu sein. Von dem hatte ich noch nicht geschrieben weil ich mir es noch anschauen wollte: Der aktualisierte Node lief nicht mehr richtig an weil FHEM im kurz nach dem Anmelden des Nodes mit der Sketch Version immer gleich wieder einen Reset verpasst zu haben scheint. Der Sketch ist drin und läuft auch an wenn ich den GW einfach abschalte. So richtig verstanden habe ich es nicht. Allerdings müssten wir erst mal mit der neuen Version soweit kommen dass ich ein update einspielen kann.
Denn:
Im Node Device geht set Device fwType nicht mehr. Es ist zwar ein Drop down da aber es steht nur ein fester Eintrag, nämlich eine 5, drin. Die gibt es in meinem csv-File nicht.
Das File sieht aktuell so aus
Type,Name,Version,File,Comments
10,Blink,1,Blink.ino.hex,blinking example
20,uwe,1,2021_04_25_mysensors_nrf_temperature.ino.hex,kommentar
100,uwe,1,2021_04_25_mysensors_nrf_temperature.ino_100ms.hex,kommentar
1000,uwe,1,2021_04_25_mysensors_nrf_temperature.ino_1000ms.hex,kommentar

Wenn ich den Button set trotzdem drücke kommt:
fwType must be numeric, but got >5<.
Eine 5 ist doch numerisch...

Das hat auch das "set MySensorsGw03 connect" nicht behoben.

Ich probier gern noch was aus. Ich werde auch noch mit dualoptiboot was machen da ich auch RFM69HW im Einsatz habe.

Also ich persönlich fände die Angabe eines fw-files etwas intuitiver. Ich sehe in der csv-Datei nicht wirklich einen Vorteil außer dass man sie 1:1 nehmen kann wenn man OTA mal via MYSCONTROLLER am Laufen hatte. Es sei denn in dem drop down wäre zumindest noch das eigentliche File was angezogen wird sichtbar. In MYSCONTROLLER ist in dem Menü wo ich die FW zuweise wenigstens neben der fwType der Kommentar der entsprechenden Zeile sichtbar. Aber ohne Kenntnis was in dem csv-File steht eine Nummer einstellen erscheint mir noch nicht als optimale Lösung.

Beta-User

#5
Zitat von: uwetaz am 11 Mai 2021, 20:38:57
Ich habe die Module mal hergenommen und probiert.

Muss ich eigentlich immer FHEM neu starten nach dem Kopieren der Files? Ich hab es jedenfalls gemacht.
Danke für die Rückmeldung. Neu starten ist in dem Fall sicherer, weil im Geräte-Hash vom Gateway was angelegt wird, und wenn da was schef geht, schmiert FHEM schlimmstenfalls ab.

Zitat
Ergebnis
Ein Problem scheint weg zu sein. Von dem hatte ich noch nicht geschrieben [...]
Das Problem ist vermutlich noch nicht weg, weil schlicht der update-Prozess gar nicht angelaufen ist: Die "5" war die Zahl der Elemente in einem Array, zurügegeben werden sollte aber dessen Inhalt, und diesen Zustand konnte man auch mit set connect nicht beheben.
Das macht hoffentlich die angehängte Version besser - allerdings wird dann die Node wieder in den Reboot-loop gehen (es sei denn, du schaltest erst mal das "autoupdate" aus (das ist doch aktiviert, oder?)).

Zitat
Ich probier gern noch was aus. Ich werde auch noch mit dualoptiboot was machen da ich auch RFM69HW im Einsatz habe.
Dann bitte nochmal mit den angehängten Versionen.

Zitat
Also ich persönlich fände die Angabe eines fw-files etwas intuitiver. Ich sehe in der csv-Datei nicht wirklich einen Vorteil außer dass man sie 1:1 nehmen kann wenn man OTA mal via MYSCONTROLLER am Laufen hatte. Es sei denn in dem drop down wäre zumindest noch das eigentliche File was angezogen wird sichtbar. In MYSCONTROLLER ist in dem Menü wo ich die FW zuweise wenigstens neben der fwType der Kommentar der entsprechenden Zeile sichtbar. Aber ohne Kenntnis was in dem csv-File steht eine Nummer einstellen erscheint mir noch nicht als optimale Lösung.
Na ja, ich habe den Code damals schlicht aus einem patch übernommen und war erst mal froh, das OTA-feature überhaupt anbieten zu können. Das jetzt so umzubauen, dass man (auch) direkt eine .hex angeben könnte, ist vermutlich nicht schwierig, aber etwas Aufwand, und jemand müßte es testen...

Wenn es gewünscht ist, schaue ich mir das auch noch an, aber erst sollte der bisherige Weg wieder fehlerfrei funktionieren.
[EDIT]
Also: um den Update-Prozess zu steuern, muss man der Node wohl erst mitteilen, welche FW-Version das ist und wie der CRC dazu aussieht. Mind. die FW-Version steht aber nicht direkt in der .hex => vermutlich wäre also das "drumrum" zu aufwändig bzw. für die User auch nicht so einfach zu durchschauen, als dass sich der ganze Aufwand lohnt...
[/EDIT]

Zur Sicherheit auch nochmal die DEVICE, am Code ist aber eigentlich nur in der MYSENSORS was geändert. (Bitte mit Neustart, s.o.).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

uwetaz

Hallo Beta-User,

das Drop Down funktioniert wieder wie vorher. Ich kann den flash-Vorgang wieder anstoßen. Ich sehe im Event Monitor "update done", aber das Anlaufproblem ist noch da. Und nein "autoupdate" ist deaktiv (OTA_autoUpdate = 0).

Wie können wir das weiter einkreisen? Gibt es Möglichkeiten auf einer Konsole Debuginfos auszugeben?

PS1: Dass bei den Drop Downs jetzt Hilfen angezeigt werden ist prima. Verwirrend ist nur dass erst was erscheint wenn man auf einen anderen Wert stellt. Ich kann aber damit leben.
PS2: Ja das mit dem FW-File war ja nur so ein Gedanke. Wir sollten den Aufwand im Rahmen lassen. Im Anhang habe ich mal skizziert was ich mit "nur" Anzeige der anderen Felder meine. Ist das vielleicht einfacher zu realisieren? Das kämme ja quasi dann der Auswahl eines hex-Files gleich. Testen könnte ich.

Beta-User

Zitat von: uwetaz am 12 Mai 2021, 20:08:27
Hallo Beta-User,

das Drop Down funktioniert wieder wie vorher. Ich kann den flash-Vorgang wieder anstoßen. Ich sehe im Event Monitor "update done", aber das Anlaufproblem ist noch da. Und nein "autoupdate" ist deaktiv (OTA_autoUpdate = 0).
Ganz wie vorher sollte es nicht sein, weil die "Kopfzeile" aus der csv nicht mehr angezeigt wird ;) .

Die Reboot-Schleife könnte auch aus DEVICE/Zeile 325 kommen, wenn das ACK verloren geht. Ändere das mal auf Senden ohne ACK:
  ack => 0,


Aber bevor wir da allgemein was drehen: Wie sind denn allg. die Ack-Einstellungen am GW und der Node? Und meldet das GW ausstehende ACK's, oder ist der Counter zurück auf "0"?

Zitat
Wie können wir das weiter einkreisen? Gibt es Möglichkeiten auf einer Konsole Debuginfos auszugeben?
Wenn es nicht die Acks sind: Konsole nicht wirklich, je nachdem könnte man höchstens den MySensors-Funkverkehr mit einem Repeater mithören und darüber an USB ausgeben lassen.
Der "normale Weg" in FHEM wäre, verbose an der Node und/oder dem GW hochzudrehen, ich kann aber nicht sagen, ob darüber dann wirklich was rauszubekommen wäre.

Zitat
PS1: Dass bei den Drop Downs jetzt Hilfen angezeigt werden ist prima. Verwirrend ist nur dass erst was erscheint wenn man auf einen anderen Wert stellt. Ich kann aber damit leben.
Ob, kann man als Modulautor einstellen, freut mich, dass du diese Änderung gut findest. Das Verhalten an sich (erst nach Auswahl sichtbar) kommt aber aus dem framework => da kann ich (afaik) nichts machen.

Zitat
PS2: Ja das mit dem FW-File war ja nur so ein Gedanke. Wir sollten den Aufwand im Rahmen lassen. Im Anhang habe ich mal skizziert was ich mit "nur" Anzeige der anderen Felder meine. Ist das vielleicht einfacher zu realisieren? Das kämme ja quasi dann der Auswahl eines hex-Files gleich. Testen könnte ich.
Hmm, mehrstufige Auswahlen sind in FHEM nicht möglich. Was ginge, wäre Inhalte aus der csv zu einem einzigen Text zusammenzukleben (ungültige Zeichen müßten ersetzt werden...) und hinterher wieder die "Startzahl" rauszuextrahieren. Ist aber aufwändig, und - ganz ehrlich - wer sich mit OTA befasst, sollte den Schluss von Nummer auf File auch ohne diesbezügliche Anzeige hinbekommen, andernfalls ist das Risiko zu groß, dass da auch an anderen Stellen was schiefgeht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

uwetaz

#8
Ich bleib mal bei der Reboot-Schleife:
Es scheint wirklich was mit ACK zu tun zu haben. Ich habe daran weder am Node noch am GW nach dem Anlegen etwas geändert. Es sind die Standardeinstellungen.
Was habe ich gemacht?
Das GW habe ich über die Kommandozeile im Web IF mit "define Name MYSENSORS port@Baudrate" angelegt.
Manuell habe ich über Menüs im Web IF umgestellt:
- GW: autocreate auf 1
- Node: OTA_BL_Type auf MYSBootloader
- Node: fwType und dann flash

Den Fehler bekommt man weder mit Ziehen Stecken vom GW noch mit Neustart von FHEM weg.
Er geht nur weg wenn ich
1) eine neue Modulversion von Dir eingespielt habe oder
2) das GW auf disconnect und dann wieder auf connect setze

Wie bin ich drauf gekommen?
Nach dem Tip von Dir wegen ACK weg habe mal hinsichtlich der ACK-Einstellungen geschaut.
GW:
Internal "ack" steht auf 0. Beim Attribut requestAck könnte man im Dropdown "nur" 1 auswählen (siehe Anhang). Ob das dem Internal ack entspricht weiß ich nicht. Ich finde es generell irgendwie verwirrend, dass
a) mal in den Auswahlen Werte nicht dabei sind weil sie gerade aktiv sind. Das ist nämlich irgendwie nicht durchgängig. Bei set disconnect und connect ist das z.B. nicht so.
b) Die Namen nicht konsistent sind.
c) scheinbar bei Attributen die einen default-Wert haben dieser in den Auswahlmöglichkeiten nicht enthalten ist wenn ich das richtig verstanden habe.
Ich bin da vielleicht etwas empfindlich und nach zwei solchen Kleinigkeiten meist komplett durcheinander :)

outstandingAck steht nach einem flash des nodes im GW auf 1, erhöht sich aber nicht auf 2 wenn ich nochmal flashe. Nach dem disconnect und connect des GW steht outstandingAck dann auf 0. Flashe ich wieder, geht es wieder auf 1 und die Reboot-Schleife kommt wieder.

Beta-User

Dann ist jedenfalls mal klar, dass die Ack-Anforderung die Schleife verursacht. Die Frage ist nur, warum die Node den Erhalt nicht "ordnungsgemäß" quittiert. Ist die Node irgendwo weit weg und srommäßig gut versorgt? Welche Version vom MySensors-Framework ist das (vielleicht hat sich da was geändert, Ack heißt jetzt ja irgendwie anders)?

Ich meine, das mit Ack (also mit der "1", wie es jetzt im Code steht) getestet zu haben, das Ausschalten hat ggf. Nebenwirkungen, von daher würde ich diesen allgemeinen Weg nur gehen wollen (oder auf Auslesen des Attributs umstellen), wenn es nachhaltige Probleme verursacht.

Wie ich das so schreibe: Möglicherweise paßt der "message ist angekommen"-Match jetzt nicht mehr wegen der Anpassung betr. diese "uninitialized"-Geschichte. Kannst du parseMsg (ca. Zeilen 951ff) wieder auf den Ursprungszustand zurückdrehen bzw. Teile auskommentieren:

    #my $payload = $+{payload} // q{};

    return {
        radioId => $+{nodeid}, # docs speak of "nodeId"
        childId => $+{childid},
        cmd     => $+{command},
        ack     => $+{ack},
        subType => $+{type},
        payload => $+{payload}
        #payload => $payload


Ein paar allg. Anmerkungen noch:
- Attribute, die man entweder setzt oder eben nicht (=> löscht, wenn nicht mehr erwünscht), sind in FHEM häufig ähnlich "seltsam" gestrickt, indem man eben nur einen Wert auswählen kann.
- Messages, die denselben "Endpunkt" haben, werden so verwaltet, dass immer die letzte wirksam ist. Daher ist "1" outstanding logisch, wenn es um die erneute Reboot-Anforderung geht.
- startet man das GW neu, wird dieses Array neu initialisiert (=>0).

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

uwetaz

#10
Wer muss denn im Node das ACK quittieren? Der Bootloader oder der Sketch?

Zu Deinen Fragen/Kommentaren
1) Node Entfernung und Stromversorgung
Der Node ist 2m entfernt und hängt an 2 AA-Zellen. Das funktioniert in MYSController eigentlich. Ich hatte anfänglich Probleme mit dem GW. Da ist ein Fake FT232 auf dem Arduino Nano. Dessen 3,3V Ausgang scheint relativ schlecht zu sein. Denn OTA über MYSController hatte immer wieder OTA Übertragungen wiederholen müssen weil der Node es angefragt hatte so dass sich das update dann auf 5min hingezogen hatte. Das habe ich aber mit zusätzlichen 4,7uF zu den eh schon agelöteten 1uF in 0805 an den 3,3V des NRF komplett wegbekommen und die updates von meinen 6,5kB FW waren in <60s drauf. So lang dauert das update bei FHEM ja nun auch.
Dass es ein Fake FT232 ist, hatte ich dann rausgefunden da sich die Seriennummer mit FTprog nicht ändern ließ und alle chinesischen Nanos die ich hier habe die gleiche Seriennummer hatten. Dazu gibts auch Infos im Netz (http://www.starlino.com/ftdi-chip-real-of-fake-how-to-spot-a-fake-rt232r-rt232rl-and-others.html).

2) MySensors-Framework
Ich verwende das aktuelle MySensors-Framework 2.3.2. Mein Sketch ist im Anhang.
MY_TRANSPORT_WAIT_READY_MS hatte ich drin, damit der Node auch ohne GW in den Sketch läuft (ich wollte einfache Arduino Basteleien bauen die einfach eine neue FW bekommen können ohne alles auseinanderbauen zu müssen; bei ESP32 auch eine feine Sache). Damit ich sicher bin dass es nicht daran liegt habe ich das jetzt rausgenommen. Das Verhalten ist aber gleich geblieben.

Auf dem GW verwende ich das unveränderte Beispiel des serial GW aus der Lib.

3) vorgeschlagene Änderung in FHEM
Wenn ich die beiden Zeilen mit "payload" wie unten vorgeschlagen in  00_MYSENSORS.pm auskommentiere, meldet sich der Node gar nicht mehr bzw. nur noch mit einer Meldung im Event monitor:
Global global ATTR MYSENSOR_20 mode node
Mehr kommt dann nicht. Die Infos die der Bootloader überträgt (CRC usw.), Sketchinfos und die festen Istwerte meines Sketches kommen dann nicht mehr.

4) ferner zu den allg. Anmerkungen von Dir:
So richtig verstanden habe ich es nicht. Ich habe mal nur zum Spaß/Verständnis requestAck im GW auf 1 gesetzt. Dann geht ack in den Internals auch auf 1 (siehe Anhang). Ok das hab ich erwartet. Das Feld bei Internals heißt halt anders aber es scheint das Gleiche zu sein. Aber ich kann das Attribut nicht wieder auf 0 setzen. Ich hab halt nicht gespeichert und einfach FHEM nochmal gestartet. Sorry, das kapier ich echt nicht, ist aber erst mal nicht so wichtig hätte ich gesagt.
Ist halt generell schade dass so gefühlt komische Bedienphilosophien hinter FHEM stecken. Das scheut sicher andere Leute ab es einzusetzen. Leute wie Du machen sich in ihrer Freizeit damit so viel Arbeit, FHEM ist so vielseitig und dann sind es nur "Kleinigkeiten" die einen DAU wie mich zum Stolpern bringen. Bitte nicht falsch verstehen, ich bin trotzdem sehr dankbar dass es FHEM gibt und Du im konkreten Fall hier immer wieder antwortest!

Aber lass uns auf das update konzentrieren. Mir würde der workaround mit dem GW disconnect und connect für meinen NRF24 Anwendungsfall erst mal reichen, aber ich glaube wir sollten das aufräumen, oder? Und meinen Testaufbau mit Dualoptiboot und RF69HW habe ich auch fast fertig. Dann ist das ein Aufwasch mit der Testerei für die neue Version...

Wie geht das verbose an der Node und/oder dem GW hochzudrehen?

Beta-User

Das Ack erfolgt normalerweise automatisch, bei den nRF24 kann es sogar sein, dass das der Chipset selbst macht.

Wenn es sonst keine Übertragungsprobleme gibt, ist das mit der Spannungsversorgung wohl auch nicht das Problem.

Bzgl. der Änderungen in MYSENORS:
a) Du hattest gesehen, dass da neben den Kommentaren auch noch eine weitere Zeile geändert war (die mit payload =>)?
b) hattest du das mit ack => "0" auch gemacht (oder alternativ mal die Zeile auskommentiert)?

Wir sollten das mit nRF/MyS-BL sauber bekommen, der Mechanismus bei Optiboot ist anders, da wird die Reboot-Aufforderung nicht gesendet, so dass da das loop-Problem nicht (oder anders) besteht.

Zu dem Attribut: man kann (ganz allgemein: solche "Flag-") Attribute auch einfach löschen, wenn sie nicht gesetzt sein sollen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

uwetaz

#12
a) nein, habe ich übersehen, sorry
b) dass ich hier was machen sollte, hab ich überhaupt nicht gecheckt.

Ich habe daher nochmal mit den Änderungen probiert:
Ich habe jetzt erst a) probiert und dann b) zusätzlich. Nach den Änderungen immer FHEM neu gestartet. Das Verhalten mit der Reboot-Schleife ist leider immer noch das Gleiche.

Zur Sicherheit ein Screenshot wie der Code nach a) und b) aussieht.

Wenn ich noch was probieren/ändern soll wäre vielleicht ein git diff zu der letzten geschickten Version sicherer dass ich verstehe was ich machen soll.

Ich frage mich welches Telegramm vom Controller soll der Node denn quittieren? Ist es das Telegramm dass der Node neu booten soll? Er quittiert es einfach nicht und bekommt es daher immer wieder geschickt sobald er "online" ist? Ich sehe im Event monitor immer die 4 Übertragungen vom Bootloader, die Meldung vom Sketch und evtl. noch einen Istwert. Die LED die via Sketch angesteuert wird blinkt auch kurz und dann geht das von vorn los.
Ich hab davon auch mal ein Screenshot angehangen.

Soll ich mal die Infos aufzeichnen die MYSController bei einem udate des nodes ausspukt? Vielleicht wird ja generell das reboot Protokoll nicht quittiert weil der reboot sofort im Node umgesetzt wird?

Beta-User

#13
Da hast du die falsche Stelle erwischt mit dem ack => '0', sorry.

Die "0" gehört zum Versenden der Reboot-Anweisung, nicht zur Auswertung der erhaltenen Nachrichten.

Ich denke, ich schubse am besten mal eine Version ins svn, die die bisherigen findings konsolidiert, und dann sehen wir weiter?
(EDIT: ist im svn, kommt ab morgen früh per update)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

uwetaz

#14
Ok.
Soll ich dann nochmal mit der Version nach dem update probieren und mich dann melden oder schreibst Du mir was ich genau machen soll?
Dann würde ich nämlich ggf. update, ändern und probieren in einem Aufwasch machen.

Beta-User

Es sollte reichen, das update zu machen, damit die reboot-Schleife weg ist.

Evtl. kommt dann die "uninitialized"-Meldung wieder, was aber nicht sooo tragisch ist, weil das scheinbar nur passiert, wenn die Payload "nichts" ist, was nur bei den update-Anfragen der Fall zu sein scheint. Ggf. können wir uns dafür noch was überlegen, aber erst, wenn der Rest soweit paßt.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

uwetaz

#16
Die Reboot-Schleife ist weg.

zum Drop Down Menü
1) Nachdem ich das update gemacht hatte und ich die csv-Datei noch nicht in dem firmware-Verzeichnis hatte sah es so aus wie im Anhang. Das bekam ich weg indem ich das GW disconnected/connected habe.

2) Das Drop Down im Node wird nach Änderungen an der csv erst aktualisiert wenn ich das GW disconnecte/connecte. Das passt noch nicht mit dem Satz in der Doku zusammen:
ZitatAktualisierungen der Datei werden erst sichtbar, wenn im Web-IF die Detailansicht der node neu geladen wird.

ferner eine Kleinigkeit (falls die noch weg soll, mich störts nicht):
3) Ich hab mal probiert in der csv-Datei eine zu der Sketch-Version konsistente Nummer im Feld Version (z.B. 1.1) anzugeben. Das geht nicht. Er übernimmt nur "1". Liegt wahrscheinlich am Zahlenformat.

Beta-User

ad 1: Das ist Absicht.
Findest du den ausdrücklichen Hinweis, was zu tun ist (statt einem leeren Eingabefeld) nicht gut?

ad 2: Hab im Wiki einen kurzen Satz ergänzt. Prio lag wie immer auf cref.

ad 3: Die Version wird in hex umgewandelt, und auch in der "Muster"-csv (bei MySensors) sind nur Ganzzahlen enthalten. Kann man vermutlich nicht konsistent hinbiegen, und für Doku dazu fehlt mir grade eine Idee (oder ein Vorschlag ;) )...

Hast du noch/wieder "uninitialized"-warnings? Die würde ich gerne noch beseitigen, falls du noch Lust hast für weitere Tests...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

uwetaz

zu 1)
Doch finde ich besser als leer. Aber ich war trotzdem irritiert. Das Attribut war nämlich bei mir im GW nicht leer bzw. es war gesetzt. Ich hatte die Datei nur noch nicht wieder in den Ordner reingeschoben. Sie war also nicht da.
Wie wäre es mit "problem_with_atrr_OTA_firmwareConfig_in_GW"? Ist nur 5 Zeichen länger und erschlägt den Fall Datei nicht da und den Fall Attribut nicht definiert bzw. gesetzt.

zu 2)
prima

zu 3)
Vorschlag zur Doku
Unter dem ersten Punkt (ferner ist in der ersten Zeile ein "Datei" zuviel) am Ende in dieser Art:
gültige Werte der Felder sind
Type, Version: Ganzzahl [0..31256]
Name, File, Comments: String [0..n Zeichen]

Hab keine "uninitialized"-warnings gefunden.

Beta-User

Zitat von: uwetaz am 16 Mai 2021, 20:28:19
zu 1)
Doch finde ich besser als leer. Aber ich war trotzdem irritiert. Das Attribut war nämlich bei mir im GW nicht leer bzw. es war gesetzt. Ich hatte die Datei nur noch nicht wieder in den Ordner reingeschoben. Sie war also nicht da.
Wie wäre es mit "problem_with_atrr_OTA_firmwareConfig_in_GW"? Ist nur 5 Zeichen länger und erschlägt den Fall Datei nicht da und den Fall Attribut nicht definiert bzw. gesetzt.
Ah, ok, den Fall "gesetzt, aber keine (gültigen) Daten" hatte ich nicht bedacht.

Werde das bei Gelegenheit in "OTA_firmwareConfig_not_valid_at_GW" ändern; gefällt mir irgendwie besser, wenn der Attributname am Anfang (oder Ende) steht.

Zitat
zu 3)
Hab' was ergänzt; ob die Form der Fußnote so glücklich ist, weiß ich noch nicht, aber der Haupthinweis ist ja weiter, dass man sich am "Original" orientieren soll.

Zitat
Hab keine "uninitialized"-warnings gefunden.
Falls dir noch was über den Weg läuft, kannst du dich ja melden.

Bis dahin erst mal Danke für's Testen und die Anregungen!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files