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?
