[patch] Zwave OTA Firmware Update

Begonnen von SamsonBox, 02 Juli 2019, 23:25:14

Vorheriges Thema - Nächstes Thema

SamsonBox

Hallo Zusammen,

also ich habe jetzt eine Patch für das OTA Update. Allerdings mit folgenden 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

rudolfkoenig

Ich habe den Patch ueberflogen, hier ein paar Bemerkungen:

- vclasses steht als $hash->{.vclasses} gesplittet zur Verfuegung
- ich habe nirgendwo gelesen, das sysread gerantiert, $l auf einmal zu lesen.
- Log3 "ZWave_firmware" sollte Log3 $hash heissen.
- Loglevel 3 ist info, Error ist 1 (https://fhem.de/commandref_modular.html#verbose)
- Eine Meldung "ERR: <zahl>" oder "RET: <zahl>" im Log ist nicht ausreichend, sowas kriegt man nach eine Weile auch als Issue hier im Forum gemeldet.
- ZWDongle_ReadAnswer ist mindestens "deprecated", blockiert FHEM (bis auf gelieferte Daten vom Dongle).
- die timeoutbehandlung in ZWDongle_ReadAnser ($to lang _keine_ Daten) war eigentlich so gemeint, und ist mAn kein Bug.
- bei einem Konstrukt wie "while(1) {... usleep(35000); }" kriege ich Bauchschmerzen. Statt Sleep sollte man InternalTimer verwenden (ja, mir ist bewusst, dass das ein Umbau bedeutet).

Welches preisguenstige Geraet bietet OTA?




SamsonBox

Hallo

Zitat
vclasses steht als $hash->{.vclasses} gesplittet zur Verfuegung
Danke für den Hinweis. Habe ich eingearbeitet.

Zitat
ich habe nirgendwo gelesen, das sysread gerantiert, $l auf einmal zu lesen.

Stimmt. Das habe ich wie folgt umgebaut


open(IN, $fName) || return "Cant open $fName: $!";
binmode(IN);
my $buf;
while (1)
{
    my $part = $l - length($buf);
    my $success = read(IN, $buf, 100, length($buf));
    if( not defined $success)
    {
      return "Cant read $l bytes from $fName";
    }
    last if not $success;
}
close(IN);


Das könnte man dann auch in 00_ZWDongle.pm Zeile 328 entsprechend nachziehen.

Zitat
Log3 "ZWave_firmware" sollte Log3 $hash heissen.
Loglevel 3 ist info, Error ist 1 (https://fhem.de/commandref_modular.html#verbose)
Eine Meldung "ERR: <zahl>" oder "RET: <zahl>" im Log ist nicht ausreichend, sowas kriegt man nach eine Weile auch als Issue hier im Forum gemeldet.

Danke für den Hinweis. Habe ich eingearbeitet.

Zitat
ZWDongle_ReadAnswer ist mindestens "deprecated", blockiert FHEM (bis auf gelieferte Daten vom Dongle).

Ok. Das war mir nicht bewusst. Könnte man das als Kommentar vor der Funktion vermerken? Zusammen mit der Anmerkung

Zitat
- bei einem Konstrukt wie "while(1) {... usleep(35000); }" kriege ich Bauchschmerzen. Statt Sleep sollte man InternalTimer verwenden (ja, mir ist bewusst, dass das ein Umbau bedeutet).

läuft dann alles auf einen asynchronen Mechanismus raus. Wie würde man denn am besten die Antworten vom Device wieder einsammeln und verarbeiten? Über einen $zwave_parseHook?

Zitat
die timeoutbehandlung in ZWDongle_ReadAnser ($to lang _keine_ Daten) war eigentlich so gemeint, und ist mAn kein Bug.

Ok, das würde bei einem asynchronen Mechanismus wegfallen, aber dann ist das ganze an sich schon gefährlich. Wenn immer der ganze Timeout im select gewartet wird und keine auf die regex passende Antwort kommt, ist man auf immer und ewig in der Funktion "gefangen". Es sei denn es herrscht mal, für den Zeitraum des Timeouts, kein Traffic im Netzwerk. Sehe ich das richtig, oder habe ich da einen Kniff übersehen?

Zitat
Welches preisguenstige Geraet bietet OTA?

Kann ich nicht sagen. Ich habe eine Hand voll z-uno Devices, deren Firmware ich selber baue. Dafür ist das super!

Wie soll man mit Versionen > 3 umgehen? Ich kann das Protokoll schon "blind" einhacken. Das ist kein Hexenwerk. Allerdings kann ich das nicht testen. Auch über eine Secure-Verbindung kann ich nichts sagen, weil ich kein solches Device habe. Bzw. weiß ich auchgar nicht, ob die Update Kommandos überhaupt Secure gekapselt werden. Hat da jemand infos?

Grüße

krikan

Zitat von: SamsonBox am 03 Juli 2019, 22:23:19
Bzw. weiß ich auch gar nicht, ob die Update Kommandos überhaupt Secure gekapselt werden. Hat da jemand infos?
Nur indirekte Infos:
Die Class wird von den Geräten als secure bei einer secure-Inklusion gemeldet (siehe bspw. https://manuals.fibaro.com/content/manuals/en/FGR-223/FGR-223-EN-T-v1.2.pdf Seite 22).
Hinweis in https://www.silabs.com/documents/login/miscellaneous/SDS13782-Z-Wave-Management-Command-Class-Specification.pdf bei der Ermittlung des verfügbaren Payloads für Firmwareupdate unter anderem die Nutzung von security encapsilation zu berücksichtigen (page 76).
Allerdings halte ich Firmwareupdate mit Security in der derzeitigen FHEM-Implementierung für einen störamfälligen Weg.

Zitat von: rudolfkoenig am 03 Juli 2019, 16:08:50Welches preisguenstige Geraet bietet OTA?
Afaik alle ZwavePlus-zertifizierten Geräte, aber kenne fast keinen Hersteller, der frei zugängliche Update-Files zur Verfügung stellt. AEOTEC bietet für einige Geräte .hec-Files (Format?), Popp (jetzt wohl auch AEOTEC) stellt auf https://zwave.de/zwave-ota/ .bin-Files zur Verfügung.

Testgerät AEOTEC Nano-Dimmer oder POPP 10-Jahresmelder-ZWave-Modul ohne Melder könnte ich Dir schcken, aber ob das ideale Testgeräte sind: ?
Oder evtl. mal Aeotec anschreiben, ob Du  für Deinen Aeotec-Switch ein Test-Firmwarefile bekommst.

rudolfkoenig

#4
ZitatWie würde man denn am besten die Antworten vom Device wieder einsammeln und verarbeiten? Über einen $zwave_parseHook?
Ja, genau.

ZitatWenn immer der ganze Timeout im select gewartet wird und keine auf die regex passende Antwort kommt, ist man auf immer und ewig in der Funktion "gefangen".
Da kann ich nicht widersprechen, und sehe ein, dass dein Bugfix berechtigt ist :)
ZWDongle_ReadAnswer war eigentlich nur fuer Dongle-Abfragen (neighborList, nodeInfo, isFailedNode, etc) gedacht, und da ist es sehr unwahrscheinlich, dass keine Antwort kommt.

ZitatWie soll man mit Versionen > 3 umgehen?
Einbauen, und es (auch in der Doku) mit einem Kommentar "untested, feedback welcome" (oder so) versehen.
Auf secure wuerde ich erstmal auch verzichten, sehe ich genauso wie krikan.

ZitatOder evtl. mal Aeotec anschreiben, ob Du  für Deinen Aeotec-Switch ein Test-Firmwarefile bekommst.
Habs gemacht, bin gespannt, ob die sich noch erinnern, immerhin ist das 3+ Jahre her.

SamsonBox

Also zusammenfassen werde ich das OTA-Update auf eine asynchronen Mechanismus umbauen. Die ClassVersions > 3 baue ich nach besten Wissen und gewissen ein. Secure-Update werdeich nichtweiter betrachten. Ich werde erst wieder nächste Woche dazukommen daran zu arbeiten. Ich reiche dann einen neuen Patch ein.

Danke für die Diskussion und das Feedback

SamsonBox

Hallo,

ich habe noch eine kurze Frage:
Wenn ich in einer zwave_parseHook-Funktion bin, wie kann ich da Fehlermeldungen ausgeben (z.B. in Form eines Popups)? Bzw. wie kann ich darüber informieren, dass das fw-update zu Ende ist und mit welchem Status?

Danke und Grüße

rudolfkoenig

Am Anfang $hash->{CL} merken, und dann per asyncOutput($cl, "Fehlermeldung")

SamsonBox

Hallo Zusammen,

so ich habe in dem neuen patch das OTA-Update auf einen asynchronen mechanismus umgestellt. Auch die Version 4 habe ich "blindeingebaut".Versionen > 4 haben einen zusätzlichen request, resonse Schritt, den ich ungern blind implementieren will. Da bräuchteich wirklich ein Device, das eine entsprechende class version implementiert.

Grüße

rudolfkoenig

Danke, und bitte um etwas Geduld, vmtl. komme ich erst am WoEnde dazu.

rudolfkoenig

Habe doch reingeschaut...

Ich gehe davon aus, dass Du den alten Code hinter return(ZWave_WibMsg...) nicht entfernt hast, inkl while(1) mit ZWDongle_ReadAnswer. Kannst Du das bitte pruefen?

Weiterhin ist noch ein usleep drin, was FHEM bis zu 18 Stunden komplett (inkl FHEMWEB und alle anderen Geraete) blockieren kann, dafuer muessten wir noch eine andere Loesung finden, z.Bsp. dem Benutzer melden, er soll das Geraet solange in Ruhe lassen.

Sonst habe ich keine Einwaende.

SamsonBox

Zitat
Ich gehe davon aus, dass Du den alten Code hinter return(ZWave_WibMsg...) nicht entfernt hast, inkl while(1) mit ZWDongle_ReadAnswer.
Grrrrrrr. Dahabe ich vergessen meinen Spickzettel zu löschen. Sorry. Ist jetzt raus.
Zitat
z.Bsp. dem Benutzer melden, er soll das Geraet solange in Ruhe lassen.
habeich eingebaut.
Danke für die schnellen Hilfen und Grüße

rudolfkoenig


Parallix

Prima, dass man nun auch mit FHEM ein Fw-Update von Z-Wave basierten Geräten durchführen kann.

Super wäre es, wenn der dazu erforderliche Befehl fwUpdate <decimal Target> <filename> etwas näher beschrieben würde. Schließlich taucht die Bezeichnung decimal target im Device specific help nur einmal auf und wird dort nicht wirklich erläutert. Vielmehr ist lediglich ein Verweis auf fwMetaData angebracht, der z.B. bei Abfrage für eines meiner Geräte zu folgenden fwMd-Readings führt: fwMdManId: 0234, fwMdFwId_0: 030c, fwMdChkSum_0: 85cf.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.59) und 7591 (8.0) - Goodwe: GW25K-ET (DSP V8 / ARM V9) - BYD: 2 x HVS 5.1 (BMS V3.29-A, BMU V3.23-A) - EnOcean - Z-Wave - FS20/HMS

db7

Moin Moin,

OTA Firmware-Update hört sich spannend an. Besteht nun auch die Möglichkeit Fibaro-Devices zu aktualisieren, oder scheitert dies nach wie vor an den seitens fibaro nicht freigegeben Update-Files?

Grüße
Detlev.