[PATCH] [PANSTAMP] Support for over-the-air flash von panstamp NRG

[Matthias Gehre]

Hallo,

mit angehängtem Patch kann man ein Panstamp NRG per Funk flashen.
Voraussetzung ist, dass
1) Der offizielle Panstamp Wireless bootloader installiert ist https://github.com/panStamp/panstamp/wiki/SWAP-firmware-loader
2) man hat eine *.hex datei, welche z.B. aus der arduino GUI kompiliert wurde; darauf achten, dass Tools->Wireless Bootloder->Yes aktiviert ist (d.h. die firmware hat Startadressse 0x9000)

Dann kann man per

Code Auswählen Erweitern

./fhem.pl 7072 "set SWAP_17 flash /home/mgehre/binouts2.cpp.hex"
eine neue Firmware aufspielen.

Viele Grüße
Matthias

[justme1968]

hallo matthias,

klasse das du das eingebaut hast. ich habe noch zwei ergänzungswünsche kann es aber nicht selber machen und auch noch nicht testen da ich noch keine nrg im einsatz habe. würdest du bitte noch folgendes einbauen:

- wenn kein filename angegeben wird dann wird der filename auf ./FHEM/firmware/SWAP_<aktueller-product-code>.hex gesetzt
- wenn ein product code und kein absoluter pfad angegeben wird dann wird der filename auf ./FHEM/firmware/SWAP_<arg>.hex gesetzt

damit kann man dann firmware und updates für standard sketches im dafür vorgesehenen fhem verzeichnis per update verteilen. das hat sich beim jeelink schon für die anwender bewährt die probleme mit dem selber kompilieren haben.

hat der standard sketch aus dem ausliefunrgszustand die voraussetzungen direkt ota zu flashen? wenn nicht würde ich das bei daniel berenguer vorschlagen.

gruss
  andre

[klausw]

2) Eine Firmware geflasht ist (nicht nur der bootloader; denn als erstes muss man der firmware sagen, dass sie den wireless bootloader aktivieren soll, indem man einen bestimmten Wert in Register 03 schreibt; dafür muss eine firmware laufen)

wie kann ich die Firmware denn das erste mal flashen?

[Matthias Gehre]

@klausw: Habe eben herausgefunden, dass man keine initiale firmware flashen muss. Habe meinen ersten Beitrag korrigiert.

@andre: Werde deine Vorschläge einbauen. Ich weiß leider nicht, ob die Panstamps NRG das schon im Auslieferungzustand können; habe meine schon alle überflasht.

[Matthias Gehre]

Habe den Patch jetzt geupdated.

Folgendes Problem taucht noch auf: Wenn man einen panstick auf einen andere Firmware flasht, sodass sich der Productcode ändert,
dann muss man die fhem.cfg ändern.
Momentan wird der Productcode im define, als attr, und im $hash->{SWAP_00-ProductCode} angegeben.

M.E. wäre es am besten, wenn man den ProductCode in einem Reading hat (aus $hash->{SWAP_00-ProductCode} erzeugt), und ihn aus dem define und dem attr löscht. Dann wäre es einfach, ihm im Code zu ändern. Über fhem.save würde er nach Neustarts wiederhergestellt. Was hältst du davon?

Im angehängten Patch ist schon etwas Code dabei, der eine ProductCode Änderung behandelt. So werden z.B. all SWAP-HEX-* Einträge aus dem $hash und all Readings gelöscht. Das define und attr aus der fhem.cfg wird aber noch nicht umgeschrieben.

[justme1968]

das product code handling gefällt mir zur zeit auch noch nicht.

für alle änderungen ist es wichtig devices im batterie betrieb im hinterkopf zu behalten. die lassen sich beim start nicht nach dem product code fragen.

der product code im define ist eigentlich sowieso optional und nicht für den anwender gedacht gewesen. er wird benötigt um im autocreate fall das attribut setzen zu können. ich würde vorschlagen das define so zu ändern das der product code parameter weiterhin übergebenwerden kann und auch ausgwertet wird um das attribut zu setzen danach aber aus DEF entfernt wird. so landet er nicht im fhem.cfg und stört nicht wenn sich der product code beim umflashen ändert.

im prinzip finde ich es gut die readings und internals automatisch aufzuräumen wenn sich der productcode ändert. ich fand es aber schon öfter nützlich den product code absichtlich auf einen anderen wert zu setzen als ihn der sketch sendet. die möglichkeit hätte man dann nur noch bis zum nächsten senden des productcode. ich denke damit kann man erst mal leben.

den product code in einem reading statt im attribut zu haben bringt aber glaube ich keinen vorteil. gespeichert wird es im attribut genau so. das reading hätte aber den nachteil das man kein drop down zur auswahl anbieten kann.

ich habe eben eine version eingecheckt die:

• den productcode aus dem DEF entfernt
  nach einem fhem neu start sollte so sogar alles automatisch und rückwärts kompatibel bereinigt sein
• deinen patch zum oat update enthält
  ich habe aber die namen für die hex files im firmware verzeichniss auf SWAP_ statt PANSTAMP_ geändert. das hat den grund das der oat update ja mit dem SWAP modul passiert. ich würde auch den PANSTAMP_ namen gerne für einen update verwenden bei dem der panstamp mit dem panstick ans fhem system gesteckt wird verwenden. die beiden firmware varianten sind aber auf grund der startadresse und architektur nicht kompatibel.
• deinen code zum aufräumen der internals enthält
  aber in die AttrFn verschoben. dann greift das auch wenn das attribut von hand gesetzt wird.

gruss
  andre

[Matthias Gehre]

Hey, soweit schon mal sehr gut.

Ist nicht das Problem beim ProductCode in attr, dass man nach dem Umflaschen per Hand "Save Config" machen muss, damit die attr in fhem.cfg geändert werden? Bei Readings hat man das nicht. Oder habe ich es falsch in Erinnerung?

[klausw]

@klausw: Habe eben herausgefunden, dass man keine initiale firmware flashen muss. Habe meinen ersten Beitrag korrigiert.

Ah ok, ich hatte inzwischen eine erste Firmware über Ardunio geflashed. Es kommt zwar eine Fehlermeldung, funktioniert aber problemlos.
Allerdings bleibt ein Problem. Wie soll ich sie flashen, wenn ich die Id nicht kenne. Oder ist die im Auslieferzustand immer gleich?
Die NRGs (ich habe den 5er Pack bestellt) hatten alle den Modem sketch drauf. Ich bin mir relativ sicher das kein Wireless Bootloader drauf war. Sonst hätten sie ja nach dem Bootloader flashen noch als Modem funktionieren müssen.

[justme1968]

@Matthias Gehre: jein...

die readings landen auch nicht automatisch auf platte sondern erst nach einem save. sie werden aber bei shutdown restart automatisch gesichert.

ich habe eben noch eine kleine änderung nachgeschoben die automatisch ein save macht wenn sich der ProductCode geändert hat und autosave in autocreate nicht deaktiviert ist.


@klausw: normalerweise sollten sie im auslieferungszustand die ID FF haben und werden von fhem wärend des autocreate auf eine freie adresse ab F0 geschoben. von dort solltest du sie dann per regSet auf die adresse schieben die du möchtest.

[klausw]

@klausw: normalerweise sollten sie im auslieferungszustand die ID FF haben und werden von fhem wärend des autocreate auf eine freie adresse ab F0 geschoben. von dort solltest du sie dann per regSet auf die adresse schieben die du möchtest.

Die Info mit der Id FF habe ich auf der panstamp Seite nicht gefunden oder einfach überlesen.
Soweit bin ich noch nicht.
Die Panstamps werden erstmal ohne Fhem betrieben. Ich will bisschen Erfahrung sammeln und dann einen Sketch für Ultraschall Abstandsmessung schreiben (Messung des Füllstands im Öltank/Zisterne) Das soll dann in Fhem rein.

Ich scheitere aber schon am Binout Sketch. Da ist es mir nicht möglich, die Register der einzelnen Ports zu ändern. Es macht den Eindruck als wären sie schreibgeschützt. Im swapdmt kommt die Meldung, das er sie nicht ändern kann.

[justme1968]

die FF kommen implizit aus dem nicht initialisierten flash. das ist der default wert wenn nichts anderes geschrieben wurde.

es kann sein das das für die nrg modelle anders ist da hier der permanente speicher anders funktioniert.

zu swapdmt kann ich dir nichts sagen. ich habe es nie benutz weil ich es damals auf meinem mac nicht zum laufen gebracht habe und dann statt dessen die fhem module geschrieben habe.

wenn es nicht möglich ist ein register zu setzen liegt es meist daran das der panstamp nicht empfängt. das kann z.b. passieren wenn die adressen falsch sind, wenn der sketch nicht läuft, wenn sich etwas aufhängt oder wenn die Antenne nicht richtig angeschlossen ist.

in fhem würde ich dir jetzt sagen setze verbose auf 5 und drücke mal reset auf dem sensor bzw trenne ihn vom strom und schliess ihn wieder an und schau ob du im log irgendetwas siehst.

du kannst auch versuchen ein paar kleine! serial.print Anweisungen einzubauen und eine serielle console dran zu hängen.

gruss
  andre

[Matthias Gehre]

Hey,

hier noch ein kleines Update. Das Attr setzen hatte nicht geklappt, da SWAP_Attr statt CommandAttr benutzt wurde,
und SWAP_Attr gar nicht das $attr-> ändert.

Jetzt klappt alles.

Viele Grüße
Matthias

[justme1968]

danke.

habe eingecheckt.

gruss
  andre

[fidel]

Hallo,

ich habe ein paar grundsätzliche Fragen.

Funktioniert das flashen auch mit einem avr mit dem modem Sketch an fhem?  Oder muss ein nrg sein?

Panstamp nrg habe ich via arduino mit Beispiel Sketches mit wireless bootloader on geflasht.

Hex files liegen im oben genannten Verzeichnis und wenn ich den Befehl mit absolutem Pfad absetze,  lande ich auf der fhem Hauptseite und es passiert nichts.
Die Rechte habe für die Dateien habe ich jetzt auch noch angepasst.

Gruß

Steven

[PeterS]

Hallo Zusammen

Ich teste gerade den OTA-Update mit einem NRG1.1 und einem leicht modifizierten NTC-Sketch (Softwareversionsnummer + Tempkorrektur)

Nach Eingabe des Flash-Befehls "set SWAP_12 flash 0000000100000004" erscheint der Status "set-flash" und der Sender + Flash-Panstamp blinken ca. alle 10s.

Es erscheint keine Fehlermeldung dass die Datei nicht gefunden wurde, wie bei anderen Versuchen 

Wie lange dauert das Flashen normalerweise ?

Gruss Peter