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 (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
./fhem.pl 7072 "set SWAP_17 flash /home/mgehre/binouts2.cpp.hex"
eine neue Firmware aufspielen.
Viele Grüße
Matthias
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
Zitat von: Matthias Gehre am 18 Dezember 2014, 00:54:00
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?
@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.
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.
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
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?
Zitat von: Matthias Gehre am 21 Dezember 2014, 15:09:28
@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.
@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.
Zitat von: justme1968 am 21 Dezember 2014, 22:45:14
@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. 8)
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.
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
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
danke.
habe eingecheckt.
gruss
andre
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
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 :D
Wie lange dauert das Flashen normalerweise ?
Gruss Peter
Hi,
ich bekomme in den nächsten Tagen mehrere neue NRG2. Ist da der Wireless Bootloader schon drauf? D.h. ich muss auch immer in der Arduino IDE die Wireless Bootloader Option aktivieren sonst läuft der Sketch nicht? Auch wenn ich das erste Mal per Kabel RX/TX flashe?
Im Panstamp Wiki steht, das der Wireless Bootloader nur in den Upgrademodus geht, wenn eine bestimmte Adresse auf 0 gesetzt wird. Muss ich also etwas in meinem Sketch berücksichtigen damit ein FW-Upgrade funktioniert?
Falls nicht, könnte dann also theoretisch jeder der Zugriff auf FHEM hätte und alles kennt ein FW-Upgrade starten?
Meine bevorzugte Methode wäre, das ein FW-Upgrade ggf. nur direkt nach einem Panstamp-Reset möglich wäre. Kann man das ev. im Sketch steuern? (FW-Upgrade nur innerhalb Setup-Methode: ja/nein)
Ich habe Fensterkontakte und Feuchtesensoren, erstere sollten nur nach einem Reset, letztere auch ohne Reset möglich sein.
kann keiner meine Frage beantworten?
Hi,
kann das sein das dieser Patch noch nicht im FHEM Repo liegt?
Mein FHEM ist up-to-date und in der Set Auswahlliste sehe ich kein Command "flash"
in der auswahl liste wollte ich es erst rein tun wenn man automatisch erkennen kann ob der betreffende panstamp das ota update unterstützt.
du kannst es von hand eingeben.
gruss
andre
Zitat von: justme1968 am 01 Juni 2016, 09:34:53
in der auswahl liste wollte ich es erst rein tun wenn man automatisch erkennen kann ob der betreffende panstamp das ota update unterstützt.
gruss
andre
Kann man das nicht an der übermittelten Hardwareversion erkennen? Ansonsten geht flash erst ab einer übermittelten Version > 0x14 (> version 2.0)
nein. leider nicht. es gibt kein register das für eine unterscheidung geeignet wäre und am am protokoll kann man auch nicht erkennen welche hardware tatsächlich verbaut ist.
das protokoll an sich funktioniert auch 'umgekehrt'. d.h. der panstamp fragt aktiv bei der zentrale die firmware an nach dem er in den update mode versetzt worden ist. ohne den update modus zu aktivieren und zu warten das die anfragen beginnen kann man nicht festlegen ob der betreffende panstamp das auch kann.
ich habe auch noch nicht probiert wie die alte und neue lib reagiert wenn man versucht zu flashen und es nicht unterstütz wird.
gruss
andre
nur um das zu verstehen... folgendes steht doch in den internals:
SWAP_00-ProductCode 0000004C00000003
SWAP_00.1-ManufacturerID 0000004C
SWAP_00.2-ProductID 00000003
SWAP_01-HardwareVersion 00000200
SWAP_02-FirmwareVersion 00000101
Die Hardwareversion kann der Entwickler doch selbst setzen, im Sketch nach AVR und NRG kann unterschieden werden und dementsprechend die Hardwareversion gesetzt werden.
Was anderes: ich habe ein set-flash abgesetzt, keine Fehlermeldung und im Log erscheint öfters:
panStamp TRANSMIT LIMIT EXCEEDED
Woran sehe ich nun das der sketch erfolgreich übertragen wurde? Reicht das verbose Log hochzusetzen? Vom spezifischen Device oder vom physischen device?
ja. die kann er selber setzen. es gibt aber keine sketch übergreifende vereinbarung wie man ganz allgemein erkennen könnte ob es ein avr oder nrg ist. ein entwickler könnte bit 1 verwenden und ein anderer bit 15. und du kannst den gleichen quelltext ja auch verwenden um einen sketch für einen avr und einen nrg zu erzeugen. für 'einfache' dinge sind die beiden ja kompatibel.
man müsste sich also auf ein bit einigen und am besten im quelltext einbauen das zur kompilierzeit das bit automatisch passend gesetz wird. da können wir fhem intern machen. noch besser wäre es aber das daniel berenguer vorzuschlagen damit es allgemein gilt.
aber bin ich mir auch nicht so ganz sicher ob man das flash kommando wirklich so einfach in einem menü haben möchte. ein 'set ...' einzugeben ist nicht wirklich aufwändig und hat den vorteil das man nicht mal aus versehen klickt.
die meldung kommt von der 1%regel. es ist aber tatsächlich nur eine meldung. das fhem modul sendet trotzdem weiter.
so viel ich weiss wird auch (anders wie bei hm) die übertragungsrare nicht hoch gesetzt beim flashen. d.h. es ist vermutlich sogar unmöglich einen sketch komplett zu übertragen und die 1%regel einzuhalten. das problem müsste man mal bei daniel berenguer ansprechen.
fhem selber weiss erst mal nichts davon wie weit der flash vorgang ist. der panstamp fragt an der zentrale nach und nach zeilen aus dem hex file an.
während des flashens hat das internal SWAP_03-SystemState der wert 05. ich vermute nach dem flashen bootet der panstamp neu und SystemState geht wieder auf 01.
wenn das so ist kann ich ins modul einbauen das ein event und eine log message erzeugt wird wenn der wert von 05 wieder auf etwas anderes zurück wechselt. ob das flashen erfolgreich war oder es probleme gab kann man damit aber nicht erkennen. ich weiss auch nicht ob man das auf eine andere art kann.
gruss
andre
Hi Andre,
ich habe Probleme mit dem flashen...
ich setze das kommando ab und im Log steht auch, das die neue firmware geflashed werden soll:
2016.11.02 14:25:26 1: Flashing ./FHEM/firmware/SWAP_WindowStatusSensor.hex to WW_EG_Kueche
2016.11.02 14:25:26 5: MyPanstamp sending 000002250305
2016.11.02 14:25:26 5: SW: 2501000002250305
Dann passiert aber nix mehr. Die Firmware ist 27kb gross. Auch nach 10minuten sehe ich nix mehr im Log. Der Panstamp meldet sich nicht mehr, ein "statusrequest" läuft ins leere. Erst wenn ich den Panstamp hat resette, wird neu bebootet und die alte Firmware ist wieder aktiv.
Den WirelesBootloader habe ich natürlich drauf, beim ersten falschen per IDE habe ich Wireless auch auf ON gestellt.
Was mache ich falsch?
ich habe immer noch keine nrg am laufen und auch noch nicht probiert.
wenn dem panstamp das flash kommando gesendet wird fängt er an nach und nach die daten anzufordern. das anfordern müsste man im log sehen und man müsste sehen das der panstamp und der panstick blinken. wenn das nicht passiert wird nichts angefordert. eventuell passt im sketch etwas nicht.
vielleicht hat mathias eine idee?
naja, ich seh eben im Log nix und der NRG hat (IMHO) keine LED onboard. Am Stick selbst habe ich nicht geschaut.
Das flashen des Sketches per seriell über die IDE funktioniert problemlos...
funktioniert das flashen denn über swapdmt-cmd?
Ich hatte mit dem flashen über Funk Probleme, wenn ich nicht als letztes nochmal den Wireless Bootloader per Panstick geflashed habe.