HCS hat gerade in das jeelink modul die möglichkeit eingebaut direkt aus fhem heraus das flashen der firmware anzustossen (http://forum.fhem.de/index.php/topic,14786.msg173160.html#msg173160 (http://forum.fhem.de/index.php/topic,14786.msg173160.html#msg173160)). im cul modul ist das schon möglich, bei homematic ist es gerade für das oha update der atkoren in arbeit und ich möchte den ota update für panstamp/swap einbauen.
wie wäre es mit einem standardisierten ablageort für die firmware (hex) files und einer namenskonvention um zu sehen zu welchem modul und für welche funktion das hex file ist?
sollte man das kommando zum anstossen des flashen selber auch vereinheitlichen?
gruss
andre
Ich habe CULflash gebaut, erst als Teil von autocreate (damit ungeflashte Module direkt beim FHEM-Start geflasht und eingebunden werden), spaeter wurde es in eine separate Datei ausgegliedert. update liefert die CUL*.hex Dateien aus, und speichert sie in fhem/FHEM.
Ich habe kein Problem mit einer Vereinheitlichung, viele Synergieeffekte sehe ich aber nicht, hoechstens wird es fuer Leute, die mehrere Systeme verwenden, sauberer. Eine Vorreiterrolle will ich nicht spielen, falls es eine Entscheidung gibt, werde ich CULflash & co nachziehen.
Hallo zusammen,
was spricht dagegen, die hex-Dateien im Verzeichnis firmware abzulegen?
Ich würde mir dann folgende Nomenklatur vorstellen:
<Hardwarebezeichnung | Sketchbezeichnung>_<HWVersion>_<FW_Version>
z.B.
CUL_V3_V1.58.hex oder
PCA301_V1_V10i
Ggf. kann man über den Programmertyp rausbekommen, welche Hardware dranhängt, aber bestimmt habe ich auf die Schnelle nicht alles bedacht ...
Vielleicht gibt es dann für die Sketche auch (für mich) nachvollziehbarere Namen ;)
Gruß PeMue
ja. so etwas hatte ich mir auch vorgestellt. eventuell noch den namen des fhem moduls das dafür zuständig ist.
das mit dem rausbekommen/auflisten/... ist aber eher die kür und kommt bestimmt erst wenn es wirklich viele anwender gibt.
gruss
andre
Ich würde dieses Thema gerne angehen, zumindest mal initial für den LaCrosse sketch.
Es gibt doch immer wieder Anwender, die mit dem Compilieren Probleme haben und nur mit Hilfestellung den JeeLink geflasht bekommen.
Aus dem bisher Diskutierten leite ich mal Folgendes ab:
Ablage der HEX-Files: im neuen (@rudolfkoenig: OK?) Verzeichnis firmware
nach dem Schema Hardwarebezeichnung_FirmwareName_Version
Beispiele:
firmware/JeeLink_LaCrosse_V10.1d.hex
firmware/JeeLink_PCA301_x.y.hex
Im 36_JeeLink.pm würde ich set flash dann so anpassen:
set myJeeLink flash /myHexFiles/LaCrosse.hex
-> verwendet /myHexFiles/LaCrosse.hex
set myJeeLink flash <SketchName>
-> verwendet das HEX File in firmware, das mit JeeLink_ beginnt und danach mit <SketchName> weiter geht
Beispiele:
set myJeeLink flash LaCrosse
-> nimmt firmware/JeeLink_LaCrosse_V10.1d.hex
set myJeeLink flash PCA301
-> nimmt firmware/JeeLink_PCA301_x.y.hex
Kommentare / Vorschläge?
Ich habe nichts gegen ein firmware Verzeichnis einzuwenden, aber die Versionierung sollten wir SVN ueberlassen. Das Einbinden ins update muss eine Woche noch warten, und jedes Unterverzeichnis muss von mir explizit eingetragen werden.
OK, dann wäre das Namensschema: Hardwarebezeichnung_FirmwareName
Ohne Version ist auch das Bilden angenehmer, da man nicht immer die Namen anpassen muss.
Beispiele:
firmware/JeeLink_LaCrosse.hex
firmware/JeeLink_PCA301.hex
firmware/FHEMduino_default.hex
JoWiemann hat mich noch per PM (magels Schreíbrechten hier) angetriggert, ob man etwas universelles gemeinsames bauen könnte da er es in FHEMduino auch benötigt.
Zumindest für alles, was einen ATmega328 hat, sollte das ja universell machbar sein.
Hat jemand einen Überblick, was es außer JeeLink und FHEMduino noch an Hardware mit einem ATmega328 in FHEM gibt, das von dem Flash profitieren könnte?
Zitat von: rudolfkoenig am 27 Juli 2014, 22:09:18
Das Einbinden ins update muss eine Woche noch warten, und jedes Unterverzeichnis muss von mir explizit eingetragen werden.
Ja, das eilt ja nun auch nicht so sehr.
Ist nur ein Verzeichnis. In firmware sind ja keine weiteren Verzeichnisse vorgesehen?
alles was sich per avrdude flashen lässt oder sich sollte direkt gehen. die konfiguration ist aber jetzt schon so flexibel das auch exotischere dinge gehen sollten. wie wäre es den flash teil in eine flash.pm auszulagern und dann in mehr als einem modul zu nutzen?
ich würde das verzeichnis gerne auch für die panstamps nutzen. vermutlich aber erst mal mit extra anstecken und dann flashen. ota update muss ich erst noch einbauen.
die homebrew hm devices fallen mir noch ein. vielleicht gibt es dort auch Interesse den ablageort und das namensschema mit zu nutzen.
homematic selber hat firmware updates auch schon implementiert. vielleicht wäre ein allgemeiner ablageort hier auch interessant.
firmata könnte noch ein kandidat sein.
gruss
andre
Zitat von: justme1968 am 27 Juli 2014, 23:09:59wie wäre es den flash teil in eine flash.pm auszulagern und dann in mehr als einem modul zu nutzen?
Ja, genau das habe ich JoWiemann vor drei Minuten vorgeschlagen, um den "Kern" mit FHEMduino gemeinsam zu verwenden.
Zitat von: justme1968 am 27 Juli 2014, 23:09:59firmata könnte noch ein kandidat sein.
firmware oder firmata, ist mir beides gleich recht.
ich meinte firmata module könnten auch ein kanditdat sein dort firmware abzulegen :)
Ah ...
das hatte ich ja ganz falsch verstanden :) :)
Das neue Verzeichnis firmware soll parallel zu docs, FHEM, log, ... liegen?
Ich haette es lieber in FHEM.
wie wäre FHEM/lib/firmware ?
Ich habe jetzt:
- FHEM/firmware angelegt. CUL*.hex wird aber weiterhin direkt aus dem culfw SVN geladen.
- CULflash verallgemeinert. Ich werde es nach flash umbenennen (mit CULflash als alias), nachdem man mir die ersten Patches dazu geschickt hat.
- deusche Doku geschrieben.
- CULflash konsultiert nicht mehr controls_fhem.cfg, sondern laedt die Datei direkt von fhem.de herunter, letzteres war aber auch bisher der Fall. Die zum flashen heruntergeledanen Dateien werden in FHEM/firmware gespeichert. Sie werden als OK betrachtet, wenn sie ein ":00000001FF" enthalten (Intel standard .hex File)
- CUL*.hex wird nicht mehr per update ausgeliefert.
Ich habe jetzt die JeeLink_LaCrosse.hex in FHEM/firmware/ reingelegt.
@justme1968: machst Du die Anpassung in 36_JeeLink.pm oder soll ich da ran?
Meine Idee ist, dass man im 36_JeeLink ein Attribut mit der Auswahl der Firmware hat (LaCrosse, PCA301, ...)
Wenn man das gesetzt hat, dann ist für den "set flash" klar, was genommen werden muss:
./firmware/JeeLink_ + FirmwareName + .hex
Und da ich gerade gesehen habe, dass Du der maintainer für die PCA301 bist: könntest du die aktuelle JeeLink_PCA301.hex dazukippen?
meine idee war die firmware Auswahl von der aktuell installierten firmware abhängig zu machen. d.h. per default immer die gleiche zu flashen und beim flash kommando anzugeben wenn es doch eine andere sein soll. ich glaube das ist unterm strich einfacher als ein extra attribut.
wenn du gerade zeit hast kannst du den neuen pfad gerne ein einbauen. ich komme vermutlich erst in ein paar tagen dazu.
den aktuellen pca sketch checke ich ein.
Zitat von: justme1968 am 31 August 2014, 10:10:40
meine idee war die firmware Auswahl von der aktuell installierten firmware abhängig zu machen. d.h. per default immer die gleiche zu flashen und beim flash kommando anzugeben wenn es doch eine andere sein soll. ich glaube das ist unterm strich einfacher als ein extra attribut.
Ja, die Idee finde ich auch gut.
Dann wird es
set flash [FirmwareName]FirmwareName optional LaCrosse, PCA301, ...
ohne FirmwareName angegeben:
wenn in model "LaCrosse" vorkommt, dann LaCrosse
wenn in model "pcaSerial" *1) vorkommt, dann PCA301
*1) stimmt das?
Zitat von: justme1968 am 31 August 2014, 10:10:40
wenn du gerade zeit hast kannst du den neuen pfad gerne ein einbauen. ich komme vermutlich erst in ein paar tagen dazu.
Es regent. Somit besteht eine Chance auf "Zeit haben" ;D
ja. genau. das war die idee.
pcaSerial stimmt auch.
hier (noch) nicht :)
gruss
andre
Was ist denn der "offizielle" Weg, ein Attribut loszuwerden?
Wenn man es aus AttrList rausnimmt, gibt es ja beim nächsten Lesen der fhem.cfg eine Reklamation.
myJeeLink: unknown attribute hexFile. Type 'attr myJeeLink ?' for a detailed list.
ich denke da gibt es keinen "offiziellen" weg. das einfachste ist die meldung zu ignroieren. beim nächsten mal ist sie ja weg.
du könntest eine version der attrFn bauen die das setzen ignoriert und das gesetzte attribut löscht und dann später in einem zweiten update das attribut entfernen. das hilft aber auch nicht wenn jemand das erste update übersprungen hat. ist also den aufwand eigentlich nicht wert....
gruss
andre
Zitat von: justme1968 am 31 August 2014, 10:40:38
pcaSerial stimmt auch.
Ich hätte den Sketch gerne pca301 genannt, da mich das serial irgendwie irritiert. Allerdings geht wohl ein pca301.c, pca301.h und ein pca301.ino nicht. Daher heißt es jetzt wieder pca301serial (http://forum.fhem.de/index.php/topic,11648.msg194105.html#msg194105). Warum der Sketch dann auch noch genau im gleich benamten Verzeichnis liegen soll, ist mir schleierhaft (http://www.smiliecenter.de/smilies/nachdenkliche/nachdenkliche_smilies_0004.gif) ...
Gruß PeMue
mir würde pca301.hex auch besser gefallen.
schau mal ob du pca301.ino in sketch.ino umbenennen kannst. mit dem ino tool würde das gehen. ich weiss aber nicht ob die ide damit klar kommt.
selbst wenn beim kompilieren nicht automatisch ein pca301.hex raus kommt spricht je nichts gegen umbenennen vor dem einchecken.
gruss
andre
pca301.ino, pca301lib.cpp und pca301lib.h
geht.
Dann kann's (oder muss ;D ;D) auch wieder ein pca301 Verzeichnis sein.
Die Arduino IDE ist der absolute Supergau.
Tip: Wer vernünftig arbeiten will und ein VisualStudio hat, kann sich mal VisualMicro anschauen.
Mit IntelliSense, SVN Integration und allem, was VS halt so zu bieten hat.
die arduino ide ist wirklich ein krampf. das ino tool macht es was die projekt organisation angeht schon deutlich besser. leider nicht mehr ganz so platform unabhängig. und genau das ist das k.o. kriterium für visual studio :) das gibt es nur unter windows und sogar dort ist das kompilieren auf kommandozeile schon nicht mehr optimal.
einer der wirklichen gründe von problemen mit der arduino ide ist aber eigentlich das verwenden der dort vorgesehen lib und include mechnismen und ino files. wenn man den teil komplett aussen vor lässt und die 'normale' standard c/c++ include und deklarations mechnissmen verwendet hat man hier deutlich weniger probleme und das ganze ist auch noch portabler.
gruss
andre
Das firmware-Verzeichnis ist beim FHEM-Update leider nicht mitgekommen
Stimmt, ich habe die firmware Dateien aus dem update control File ganz entfernt. Sie werden aber weiterhin auf http://fhem.de/fhemupdate/FHEM/firmware/ hochgeladen.
Ich habe sie rausgenommen, da:
- CULflash die .hex Datei von der Webseite laedt. Die frueher im update vorhandene Datei wurde schon immer ignoriert. Und wenn es nie verwendet wird, wozu per update verteilen.
- CULFlash laedt die Version von der Webseite, weil es auch beim ersten FHEM-Start durch "usb create" getriggert wird (um die angesteckten Geraete zu flashen), und da is noch kein FHEM-update gelaufen.
- Wenn ein CUL schon einmal geflasht ist, dann wird nicht mehr automatisch geflasht, deswegen wollte ich die neueste Version haben.
Ja, man koennte es auch anders machen, sehe aber z.Zt noch nicht, wieso.
Der Sketch, der auf den JeeLink geflasht ist und die 36_JeeLink.pm (jetzt mal die beiden als Beispiel genommen) sollten ja zusammenpassen.
Ist es da nicht eher ungeschickt, wenn zu einer evtl. nicht aktuellen 36_JeeLink.pm (weil lange kein Update gemacht) die aktuellste Version vom Sketch genommen wird?
Wenn das Update den Sketch mitnimmt, dann hätte man die "Pärchen"immer zusammenpassend.
die idee hinter den firmware verzeichniss war es anwendern die nicht selber kompilieren wollen oder damit probleme haben an einer stelle automatische aktuelle versionen bereitzustellen die dann auch direkt aus fhem heraus geflashed werden können. das ist besonders für die arduino/jeeljnk/panstamp basierten dinge bei denen mehr wie eine firmware gibt und sich auch mehr oder weniger oft änderungen oder ergänzungen ergeben vielleicht wichtiger als beim cul.
wenn die firmware files nicht automatisch im update verteilt werden können wir auch beim contrib/arduino verzeichniss bleiben. mit gebau den bisherigen nachteilen.
das konzept eines zentralen verzeichnisses an dem hoffentlich noch weitere module teil nehmen (siehe oben für mögliche kandidaten) ist für normale endanwender nur dann praktikabel wenn es einfach und automatisch funktioniert.
wenn du angst hast das zu viel daten unnötig verteilt werden könnte ein parameter oder eine option um das firmware verzeichniss zu aktivieren/deaktivieren helfen.
aber ich denke das der vorteil aktuelle daten zu verteilen die paar k bei weitem aufwiegt.
Habe die im SVN befindlichen FHEM/firmware/.* Dateien zum update hinzugefuegt, danach fhemupdate.pl durchgefuehrt und update getestet:
Zitat2014-09-03 09:52:31 Global global UPD FHEM/firmware/JeeLink_LaCrosse.hex
Da die CUL*.hex Dateien aus einem anderen Verzeichnis spaeter hinzugefuegt werden, sind diese nicht im update enthalten, was aber fuer mich kein Bug sondern Feature ist.
Hallo Rudolf,
momentan stehen die ganzen Sketche (und vielleicht auch die hex-files) im Ordner contrib/arduino. Wenn jetzt die hex-files per update verteilt werden, sollte dann derjenige, der die hex-files erstellt diese auch (nach einer ausreichenden Testphase) in FHEM/firmware stellen, damit sie per update verteilt werden?
Danke + Gruß
PeMue
Entweder ist die Frage trivial, und die Antwort: ja, oder ich verstehe die Frage nicht.
Aus meiner Sicht wäre die Antwort auch "ja"
Die hex Files (LaCrosse, PCA301, ...) kommen nach firmware, dass sie ein "set flash" verwenden kann, der Quellcode, der ja auch irgendwo aufgehoben werden muss, bleibt in contrib/arduino. In den dortigen zips sollte dann kein .hex File mehr drin sein.
ja. dir quelltexte bleiben in contrib/arduino. die hex files gehen nach firmware.
Ok, dann sollte nur sichergestellt werden, dass die Version der Quelltexte und die Version der hex-files übereinstimmt ;)
Zitat von: PeMue am 04 September 2014, 05:01:26
Ok, dann sollte nur sichergestellt werden, dass die Version der Quelltexte und die Version der hex-files übereinstimmt ;)
ich glaube, dass das nicht zwingend so sein muss. Es kann durchaus sein, dass der Quellcode schon weiterentwickelt wurde, man das aber noch nicht als "offizielle" Version zum flashen für "die Allgemeinheit" bereitstellen will.
Dann können Tester sich den quellcode aus contrib holen und erst wenn es OK ist, kommt das hex nach firmware.
Wenn alle erforderlichen Einstellungen von FHEM aus gesetzt werden können (Beispiel data rate, LED, ... beim LaCrosse) gibt es auch keinen Grund, warum ein Anwender sich eine Arduino IDE installieren müsste, nur um die Firmware auf den JeeLink zu bekommen.
Eigentlich sollte es so sein, dass ein Anwender (von irgend welchen Ausnahmen abgesehen) immer das hex aus firmware verwendet.
Und der Quellcode ist für Entwickler.
Und noch ein Vorschlag zur Diskussion:
Da die Versionsnummern aus den Namen der hexfiles entfallen sind, könnte man in das firmware Verzeichnis eine Datei versions.txt / xml legen, die der Entwickler, der ein neues hex reinlegt, dann aktualisiert.
Name und Format wären noch zu diskutieren. Vorschlag:
[JeeLink_LaCrosse.hex]
Version=10.0h
Title=JeeLink firmware for LaCrosse sensors
[JeeLink_PCA301.hex]
Version=5.1
Title=JeeLink firmware for the PSA301 power meter plug
oder
<firmwarelist>
<firmware hexfile="JeeLink_LaCrosse.hex" Version="10.0h" Title="JeeLink firmware for LaCrosse sensors" />
<firmware hexfile="JeeLink_PCA301.hex" Version="5.1" Title="JeeLink firmware for the PSA301 power meter plug" />
</firmwarelist>
ich würde die versions nummer in den svn commit text schreiben dann kann man auch ohne langes auscheckdn und suchen in einem file geziehlt bestimmte versionen auschecken.
ich würde die version auch nur dort rein schreiben und nirgends sonst. wenn es zwei oder noch mehr stellen gibt kann es ganz schnell passieren das es nicht mehr eindeutig ist.
Habe das 36_JeeLink.pm umgebaut. Anbei der Patch und das komplette file.
set myJeeLik flash [firrmwareName]
"set myJeeLik flash" ohne Parameter erkennt PCA301 und LaCrosse und macht den flash dann mit dieser Firmware.
Wenn auf dem JeeLink noch keine bekannte Firmware drauf ist, erfolgt ein Hinweis, dass man den firrmwareName Parameter verwenden soll.
"set myJeeLik flash xxx" verwendet ./FHEM/firmware/JeeLink_xxx.hex
Falls das errechnete .hex File nicht vorhanden ist, erfolgt eine entsprechende Meldung.
Ich habe mir dazu testweise eine JeeLink_PCA301.hex nach firmware dazugelegt, da die beim Update leider noch nicht mitkommt.
@justme1968: schau es bitte mal an und committe es oder beauftrage mich damit.
Ergebnis sieht dann so aus:
flashing JeeLink myJeeLink
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/ttyUSB0
log file: ./log/JeeLinkFlash.log
myJeeLink closed
command: avrdude -p atmega328P -c arduino -P /dev/ttyUSB0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: reading input file "./FHEM/firmware/JeeLink_LaCrosse.hex"
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: writing flash (16314 bytes):
Writing | ################################################## | 100% 2.44s
avrdude: 16314 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: load data flash data from input file ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex contains 16314 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 1.95s
avrdude: verifying ...
avrdude: 16314 bytes of flash verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
myJeeLink opened
Habe gerade einem Anwender geholfen, der LaCrosse mit dem JeeLink nicht ans Laufen bekommen hat.
Es waren die üblichen zwei Probleme:
- Sketch compilieren
- LaCrossePairForSec nicht bekannt gewesen
Punkt 1 erledigen wir ja gerade und im wiki sollte dann das als bevorzugte Variante genannt werden, mit dem Hinweis, dass man nur in Ausnahmefällen selbst compilieren muss.
Punkt 2: wenn die 36_JeeLink LaCrosse-firmware geflasht hat, könnte sie einen Hinweis geben, dass Devices nur angelegt werden, wenn man LaCrossePairForSec setzt.
Damit hätte der Anwender es vermutlich hinbekommen, ohne sich Hilfe im Forum holen zu müssen.
zu 1.: ich hab die version von eben eben eingecheckt.
zu 2.: die frage ist wo die meldung her kommen soll. hard kodiert mag ich es eigentlich nicht ein einem anderen modul und eigentlich steht es ja in der commandref.
alternativ vorschlag: ich habe eben ins LaCrosse modul eingebaut das ein hinweis auf LaCrossePairForSec ins log geschrieben wird wenn eine LaCrosse nachricht empfangen wird und es noch kein LaCrosse device im system gibt.
gruss
andre
Zitat von: justme1968 am 07 September 2014, 12:44:25
zu 1.: ich hab die version von eben eben eingecheckt.
Habe es nochmal getestet, nachdem es mit dem Update kam.
Das ist jetzt wirklich einfach:
1. JeeLink draufstecken
2. set myJeeLink flash LaCrosse
und erledigt.
PCA301 fehlt aber leider noch.
Zitat von: justme1968 am 07 September 2014, 12:44:25zu 2.: ...
alternativ vorschlag: ich habe eben ins LaCrosse modul eingebaut das ein hinweis auf LaCrossePairForSec ins log geschrieben wird wenn eine LaCrosse nachricht empfangen wird und es noch kein LaCrosse device im system gibt.
Ja, das erfüllt den Zweck ebenfalls.
Nachtrag: gibt es jemanden, der das wiki anpasst? Falls erforderlich schreibe ich die Fakten zusammen, dass man es einarbeiten kann.
Und den doppelten Post habe ich auch gelöscht :-[
ich habe eben das hex file aus diesem post http://forum.fhem.de/index.php/topic,11648.msg194105.html#msg194105 (http://forum.fhem.de/index.php/topic,11648.msg194105.html#msg194105) als JeeLink_PCA301.hex eingecheckt
gruss
andre