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
.
