Verschiedenes > MySensors

Probleme mit OTA via mysbootloader und FHEM

<< < (3/4) > >>

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

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

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

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln