OTA Firmware Update von Z-Wave Geräten

Begonnen von l2fast4u, 06 September 2017, 18:20:18

Vorheriges Thema - Nächstes Thema

l2fast4u

Hallo zusammen,

besteht in FHEM die Möglichkeit, Firmwareupdates aus einer .bin oder .hex Datei an Z-Wave Geräte zu verteilen?

Konkret geht es um die 10 Jahres Rauchmelder von Popp (POPE009402). Ich habe vom Popp Support dankenswerterweise das Firmwareupdate auf Version 1.4 als .hex und .bin Datei erhalten, habe allerdings keine Ahnung wie es jetzt weitergeht. Die Suche war leider auch nicht erhellend (habe leider noch nicht viel Erfahrung mit Z-Wave/FHEM)...

Danke und viele Grüße
Lukas

krikan

Bisher nicht, da mangels Firmwaredateien nicht implementiert.

Ich wollte das genau für den Popp-Melder 10 Jahres-Melder zumindest versuchen zu implementieren, da ich die erste Charge mit falscher modelId hatte. Man hat mich seitens Popp aber immer wieder vertröstet, dass das Firmwareupdate noch nicht fertig sei. Zuletzt hieß es dann, dass es keins gibt.  Und nun das...  ::)

Gruß, Christian

krikan

Hallo!

Popp hat mein Verwunderung wohl zur Kenntnis genommen.  ;)
Das Firmwarefile steht hier http://www.zwave.de/over-the-air-updates/ seit heute zum Update bereit. Gestern stand es dort noch nicht.

Gruß, Christian

rudolfkoenig

Jetzt brauchen wir nur jemanden, der ein USB-Mitschnitt eines Firmware-Update-Vorgangs erstellt :)

krikan

Anhaengend meine wenigen Codereste aus dem vorigen Jahr bei Implementierungsbasteleien für CC FIRMWARE_UPDATE V1 und V2. Eventuell sind die recyclebar (ansonsten vergessen). Mir ist nur keine frei verfügbare Firmware für diese Class-Versionen bekannt. Popp nutzt beim Rauchmelder und der Außensirene V3.

rudolfkoenig

Ist eigentlich perfekt, ich wuerde bloss fwDataReport (06) nicht als Befehl drinlassen, da es als Antwort auf 05 vom Geraet zu senden ist, und nicht vom Benutzer auszuloesen ist. Aehnlich verhaelt es sich mit fwDataGet (05) und fwUpdateStartStatus(04), diese als Reading mitzufuehren belastet das System unnoetigerweise.

Bleibt nur noch der Inhalt fuer fwUpdate (03) und die Checksum-Methode fuer fwDataReport(06) zu loesen.

FunkOdyssey

Ich habe hier im Z-Wave.Me-Forum gelesen, dass es für die Steinel IS140-2 Z-Wave Bewegungsmelder ein OTA-Update gibt.

Es gibt wahrscheinlich in FHEM immer noch keine Möglichkeit, die Firmware zu flashen, oder?
Wie könnte ich das denn sonst machen? Nur über Z-Way?

rudolfkoenig


FunkOdyssey

Wenn ich das könnte, würde ich es machen. Ernsthaft. :-)

rudolfkoenig

Ernsthaft: mit genug Zeit und Wille kann das jeder :)

SamsonBox

Hallo Zusammen,

ich würde das Thema OTA Firmware Update von Z-Wave Geräten hier gerne noch einmal aufgreifen. Ich sehe, dass der Bedarf an der Funktionalität da ist. Ich persönlich habe einige Z-Uno Module im Haus verbaut, an die ich jetzt nicht so ohne weiteres mehr ein USB-Kabel mehr anschließen kann. Daher würde ich gerne eine FHEM-Erweiterung implementieren. Da Protokoll und die entsprechenden Kommandos sind ja Dokumentiert. Allerdings stellt sich mir die Frage, wie man das am besten integriert. Man benötigt für das Update zum Einen Firmware-Metadaten (z.B. Version) und zum anderen die Firmware selbst, die zunächst auf dem FHEM-Server gebracht werden muss. Das alles in ein "SET"-Kommando zu packen ist nahezu unmöglich. Meiner Meinung nach würde sich hier ein Update-Wizzard eignen. Gibt es so etwas schon für andere Funktionalitäten? Oder gibt es andere Vorschläge?

Danke für die Rückmeldung und Grüße

rudolfkoenig

Ich schlage vor Schritt-fuer-Schritt vorzugehen:
- ein set implementieren, was die Firmware-Datei in FHEM/firmware und alle Parameter in Readings und/oder als Argument voraussetzt.
- wenn das klappt, dann kann man imer noch stufenweise (mit Dialog/Wizard) das Leben der Benutzer vereinfachen.
Diese Loesug wuerde ermoeglichen, updates ohne GUI oder mit anderen Frontends durchzufuehren.


Wardancer

Guten Morgen,

ja das hört sich gut an! Ich persönlich würde das ganze auch gerne über FHEm laufen lassen.
Falls aber jemand in der Zwischenzeit einmal ein Z-Wave-Device OTA updaten möchte, und nicht genau weiss, wie er das tun soll, dem sei folgende URL empfohlen:

http://www.support.getzooz.com/kb/article/253-how-to-perform-an-ota-firmware-update-on-zooz-devices/

Ich habe heute morgen mit der PC Controller-Software und einem Z-Stick gen5. von AeonLabs einen POP Fenster/Tür-Sensor OTA auf Version 1.02 gebracht.
Musste dafür leider erstmal in einer virtuellen Maschine ein Windows 10 mit DotNet 3.51 installieren, daher wäre das ganze über FHEM schon deutlich einfacher!

Viele Grüße

Thomas

SamsonBox

Hallo Zusammen,

also ich habe jetzt eine Patch für das OTA Update. Allerdings mit folgeden Einschränkungen:
1) Unterstützung bis ClassVersion 3 (Wobei ich nur die Version 3 testen konnte)
2) kein Secure-Device. Hier stellt sich mir die Frage, ob das FW-Update überhaupt über die Verschlüsselung läuft.

Allerdings glaube ich, dass der Patch eine gute Diskussionsvorlage für das generelle vorgehen bietet. Wie soll ich denn den Patch einreichen?

Danke und Grüße

krikan



chopsor

Hoihoi,

Ich grabe diesesThema noch mal aus...

Ist die oben genannte v1.4 korrekt oder sollte das 1.14 sein (habe das gleiche Problem, die URL funktioniert nicht mehr und bis jetzt habe ich lediglich eine v1.14 gefunden -> wenn ich diese flashe (bekomme im Log Status: 01) bleibt das falsche model bestehen.

Danke
Hier könnte Ihre Werbung stehen !

Klaus.A

#17
Hallo zusammen,

nachdem diese Diskussion der neueste Stand for Z-Wave OTA ist, mache ich hier weiter:

Aktuelles FHEM, Z-Wave Device ist der Popp-10-Jahres-Rauchmelder mit falscher ID (alte FW).
Als fwMd erhalte ich:


fwMdManId: 0115, fwMdFwId_0: 0101, fwMdChkSum_0: 8ccb, fwMdUpgradeable: ff, fwMdNrTarg: 00, fwMdFrqSize: 001e


Die Firmware-Datei habe ich von zwave.de/zwave-ota per Download geholt und in FHEM unter "FHEM/firmware" abgelegt.
Name der Datei geändert in "popprm.bin" (statt des endlosen ursprünglichen Namens).

Versuch, in FHEM den OTA zu starten (im entsprechenden Device):


set fwUpdate 0 popprm.bin


Antwort von FHEM:


./FHEM/firmware/popprm.bin does not exists, or is empty


Verstehe ich nicht. Die Datei ist im entsprechenden Verzeichnis vorhanden, kein Tippfehler. Ob sie leer ("empty") ist? Es ist ein Binär-File, und es ist definitiv etwas drin.
Es ist die offizielle 1.14 aus dem Jahr 2017.

Mache ich etwas falsch, habe evtl. etwas übersehen?

Update: gerade gesehen: Im FHEM Log steht:


ZWave_firmwareUpdateParse: CMD: 02 MSG: 0154010f4d46ff00001e0000 Version: 3


Das sagt mir leider nichts. Datei defekt, nicht lesbar, fehlerhaft ....?

Danke! Gruß, Klaus

2 x CubieTruck mit 1) FHEM 5.9 und 2) IOBroker-mit Echo-Dot/Alexa und Homekit-/Siri-Integration. 1 x HMLAN, 3 x HM-LGW-O-TW-W-EU-2, mehr als 90 HomeMatic Sensoren und Aktoren, Velux-Fenster-IF, Fibaro ZWave-Sensoren und Aktoren, Philips Hue Bridge, IRTrans IR-Konverter, AutoMower via API

krikan

Zitat von: Klaus.A am 22 August 2020, 19:19:10

./FHEM/firmware/popprm.bin does not exists, or is empty


Verstehe ich nicht. Die Datei ist im entsprechenden Verzeichnis vorhanden, kein Tippfehler. Ob sie leer ("empty") ist? Es ist ein Binär-File, und es ist definitiv etwas drin.
Es ist die offizielle 1.14 aus dem Jahr 2017.
Dateinname richtig eingegeben? Pfad kontrolliert? Leserechte für FHEM auf die Datei vorhanden?

Probleme mit der Firmware-Datei von zwave.de oder im Code von FHEM kann ich nicht feststellen.
Beim Start des Firmwareupdates steht hier im Log:
2020.08.22 19:29:25.097 3: ZWave_firmware: Target: 0 FILE: ./FHEM/firmware/ZME_EI_ELCTRNCS_RAUCHMELDER_SLAVE_BOOT_NVM_2Mb_MF_0154_V1.01_V1.14_EU_FOR_OTA_01_02_2017.bin LENGTH: 98305 CRC b07e Version 2
Anschließend läuft das Update.

Gruß, Christian

Klaus.A

Danke - mein Fehler: Der Pfad war das Problem! Ich hatte ein Verzeichnis "firmware" unter "fhem" ... aber nicht unter "fhem/FHEM". Das war aus alten Zeiten, damals für erste Homematic Updates. Ist korrigiert.

OTA läuft an, scheint aber nicht erfolgreich zu sein - "Status 01" (irgendwo im Quellcode suchen?). Es gibt auch zwei PERL Warnungen:


2020.08.22 21:14:19 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/10_ZWave.pm line 5655.
2020.08.22 21:14:19 1: PERL WARNING: Use of uninitialized value in read at ./FHEM/10_ZWave.pm line 5656.
2020.08.22 21:14:21 3: ZWave_firmware: Target: 0 FILE: ./FHEM/firmware/popprm.bin LENGTH: 98305 CRC b07e Version 3
2020.08.22 21:14:23 3: ZWave_firmwareUpdateParse: CMD: 02 MSG: 011501018ccbff00001e0000 Version: 3
2020.08.22 21:14:23 3: ZWave_firmwareUpdateParse: Seding FIRMWARE_UPDATE_MD_REQUEST_GET
2020.08.22 21:14:23 3: ZWave_firmwareUpdateParse: CMD: 02 MSG: 011501018ccbff00001e0000 Version: 3
2020.08.22 21:14:43 3: ZWave_firmwareUpdateParse: CMD: 04 MSG: 01 Version: 3
2020.08.22 21:14:43 3: ZWave_firmwareUpdateFinish: MSG: Finished firmware update: FIRMWARE_UPDATE_MD_REQUEST_GET returned with Status: 01


Wenn ich dann ein "get model" mache dann habe ich immer noch die alte (falsche) ID und die "Sirene" statt des Rauchmelders:


2020.08.22 21:15:39 3: ZWave got config for popp/solar-siren.xml from ./FHEM/lib/openzwave_deviceconfig.xml.gz
2020.08.22 21:17:58 3: ZWave_firmwareUpdateParse: CMD: 02 MSG: 011501018ccbff00001e0000 Version: 3


Mit dem FHEM-Update ist natürlich erst mal die Modifikation der deviceconfig.xml weg, aber mit dem Firmware-Update sollte doch die ID korrigiert sein. Oder sind noch weitere Aktionen erforderlich?
Die Firmware Medadaten (get fwMetaData) zeigen auch den alten Stand.

Kann das Problem SECURITY sein (ist "enabled")?

Danke & Gruß, Klaus
2 x CubieTruck mit 1) FHEM 5.9 und 2) IOBroker-mit Echo-Dot/Alexa und Homekit-/Siri-Integration. 1 x HMLAN, 3 x HM-LGW-O-TW-W-EU-2, mehr als 90 HomeMatic Sensoren und Aktoren, Velux-Fenster-IF, Fibaro ZWave-Sensoren und Aktoren, Philips Hue Bridge, IRTrans IR-Konverter, AutoMower via API

krikan

Security ist das Problem. Der Status 01 bedeutet:
ZitatERROR. Device expected an authentication event to enable firmware update.The device will not initiate the firmware update
Befürchte Du musst das Gerät exkludieren und dann ohne Security neu inkludieren.

Das Firmwareupdate dauert übrigens länger (mehrere Minuten) und im Zwave-Netz sollte währenddessen möglichst wenig Funkverkehr stattfinden. Aeotec empfiehlt tlw. sogar für ein Firmwareupdate ein separates Netz nur mit dem upzudatenden Gerät...

Die Warnung sind normal und nur unschön; funktional haben sie keine Auswirkungen.

Gruß, Christian

Klaus.A

Excludiert, sogar Reset (am ZWave-Modul des Rauchwarnmelders) gemacht, dann neu inkludiert. Nichts von "SECURITY" in den Readings zu sehen, alle Infos können in FHEM abgerufen werden.

Nur der Firmware-Update geht nicht - immer noch Status "01".

Das hat doch jetzt nichts mehr mit der bekannten SECURITY zu tun, da ist irgendeine andere Autorisierung erforderlich, aber welche?

Ich befürchte die alte Firmware hat noch andere Fehler, nicht nur die falsche ID. Vielleicht ist ein FW-Update für dieses Gerät überhaupt nicht möglich.
Ich glaube fast, "Entsorgung" ist die Lösung. Eine Korrektur der Definitionsdateien scheint nicht mehr so einfach zu sein seit sich die Struktur verändert hat.

Für heute reicht es. Vielleicht habe ich morgen eine Idee. Gute Nacht.

Gruß, Klaus
2 x CubieTruck mit 1) FHEM 5.9 und 2) IOBroker-mit Echo-Dot/Alexa und Homekit-/Siri-Integration. 1 x HMLAN, 3 x HM-LGW-O-TW-W-EU-2, mehr als 90 HomeMatic Sensoren und Aktoren, Velux-Fenster-IF, Fibaro ZWave-Sensoren und Aktoren, Philips Hue Bridge, IRTrans IR-Konverter, AutoMower via API

krikan

Hast Du denn nach dem Absetzen des Updatebefehls in FHEM am Gerät mit Doppelklick des Zwavebuttons das Firmwareupdate freigegeben (Siehe Handbuch des Gerätes) ?

Gruß, Christian

Klaus.A

#23
OK, geschafft, neue Firmware ist drauf. Dieses Gerät macht einen wahnsinnig ...

Erst mal ganz großes DANKE für eine Nachricht zu später Stunde, und die Geduld das Problem zu lösen. Ich war echt genervt (obwohl ich sonst viel Geduld habe.)
Zweimal Taste drücken - ja, aber vermutlich zu bald, zu schnell oder zu spät. Der Popp Melder ist sehr empfindlich, verhält sich oft sonderbar.

Mit zweimal Taste drücken im richtigen Moment lief das los - mit extrem vielen Nachrichten im FHEM log.
Danach "Firmware Update successful" mit dem Hinweis, man soll bitte 5 Sekunden warten bis sich das Gerät neu konfiguriert hat.
Von wegen ... ich habe mehrere Minuten gewartet. Dann keine Reaktion mehr (No Ack). Das Ding war "tot".

Alle bekannten Aktionen waren nicht erfolgreich. Nochmal exclude/add node? Nein, bitte nicht nochmal ...

Die Lösung:

  • "Factory Reset" am Gerät (Taste 10 Sekunden drücken - aber Achtung, alle Dokumentationen zu diesem Popp Rauchwarnmelder sind FALSCH! Es dauert länger als 10 Sekunden, man muss warten bis das Blinken ganz aus ist und es ertönt auch - anders als in allen Dokus genannt - kein Signal!
  • Die Node in FHEM als "failed Node" setzen
  • Rauchwarnmelder neu anlernen mit "replaceFailedNode"
  • Ein paar Sekunden warten
Danach ist wieder alles in Ordnung. Wichtig ist es, dem Gerät immer sehr viel Zeit zu geben, sonst gibt es ständig "timeouts" bei nachfolgender Interaktion.

Gruß, Klaus

Update #2:

Alles gut, der Rauchwarnmelder verhält sich jetzt auch so wie er soll. Vorher - mit alter Firmware - hatte er ein periodisches "WakeUp" mit Meldung des Batteriestandes - obwohl er kein WakeUp-Device ist sondern ein FLiRS. Jetzt, mit neuer Firmware ist das weg und man muss "Battery" explizit anfordern. Das macht Sinn, u.a. weil damit die Batterie weniger beansprucht wird. Ob sich da in der Firmware wirklich nur die "ID" des Geräts geändert hat ...?

Angeblich meldet das Gerät rechtzeitig wenn die Batteriekapazität zu Ende geht. Oder man macht eine Abfrage per "at" einmal in der Woche oder im Monat.
Ich habe zwei dieser Rauchwarnmelder von Popp, einer davon hatte bereits die aktuelle Firmware - da war mir der Unterschied aufgefallen.

Der Grund weshalb ich so auf diesen Rauchwarnmelder fokussiert bin ist die Qualität des Basisgeräts (von EI Electronics). Das hat die HomeMatic (BidCos) und die Fibaro (Z-Wave) Melder klar geschlagen was Zuverlässigkeit und Vermeidung von Fehlalarmen betrifft. Das Z-Wave Modul von Popp ist zwar etwas "gewöhnungsbedürftig", reagiert nach meinen Beobachtungen etwas träge. Damit sind Aktionen manchmal etwas problematisch (siehe Bestätigung des FW-Updates). Es ist aber nach meinem Wissen das einzige Modul für diesen Melder das eine Kommunikation per Z-Wave ermöglicht ohne bestimmte herstellerspezifische Zentralen zusätzlich zu erfordern.

OTA läuft prima. Vielleicht könnte man das Log noch etwas reduzieren, oder diese gigantische Anzahl Einträge auf einen bestimmten Verbose Level legen. Ich habe aus der OTA Aktion 3.277 Einträge zu je 2 Zeilen im Log - jetzt kann FHEM das Log nicht mehr anzeigen (kein Problem, ich komme auch mit WinSCP ran). FAlls das mit Verbose n bereits möglich ist wäre ein Hinweis in der CommandRef für den fwUpdate Command von Vorteil.

Ich meine diese Einträge (hier Nr. 3.277):

2020.08.22 23:56:40 3: ZWave_firmwareUpdateParse: CMD: 05 MSG: 010ccd Version: 3
2020.08.22 23:56:40 3: ZWave_firmwareUpdateParse: GET reports: 1 reportNr: 3277

Ein erfolgreicher Abschluss wird wie folgt gemeldet:

2020.08.22 23:56:40 3: ZWave_firmwareUpdateSendSingleReport: sending report: 36045
2020.08.22 23:56:48 3: ZWave_firmwareUpdateParse: CMD: 07 MSG: ff0005010000 Version: 3
2020.08.22 23:56:48 3: ZWave_firmwareUpdateFinish: MSG: Finished firmware update: Firmware Update succsessful. The device needs 5 seconds to reconfigure. Please do not use it within this time span.


Gruß, Klaus
2 x CubieTruck mit 1) FHEM 5.9 und 2) IOBroker-mit Echo-Dot/Alexa und Homekit-/Siri-Integration. 1 x HMLAN, 3 x HM-LGW-O-TW-W-EU-2, mehr als 90 HomeMatic Sensoren und Aktoren, Velux-Fenster-IF, Fibaro ZWave-Sensoren und Aktoren, Philips Hue Bridge, IRTrans IR-Konverter, AutoMower via API