Verschiedenes > MySensors

Probleme mit OTA via mysbootloader und FHEM

<< < (2/4) > >>

Beta-User:

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

--- Ende Zitat ---
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 [...]

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

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

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

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

--- Ende Zitat ---
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:

--- Code: ---  ack => 0,

--- Ende Code ---

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?

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

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

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

uwetaz:
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:


--- Code: ---    #my $payload = $+{payload} // q{};

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

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?

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln