FHEM - Hausautomations-Systeme > ZWave

[patch] Zwave OTA Firmware Update

(1/5) > >>

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

--- Ende Zitat ---
Danke für den Hinweis. Habe ich eingearbeitet.


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

--- Ende Zitat ---

Stimmt. Das habe ich wie folgt umgebaut


--- Code: ---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);

--- Ende Code ---

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.

--- Ende Zitat ---

Danke für den Hinweis. Habe ich eingearbeitet.


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

--- Ende Zitat ---

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).

--- Ende Zitat ---

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.

--- Ende Zitat ---

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?

--- Ende Zitat ---

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?

--- Ende Zitat ---
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:50 ---Welches preisguenstige Geraet bietet OTA?
--- Ende Zitat ---
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:

--- Zitat ---Wie würde man denn am besten die Antworten vom Device wieder einsammeln und verarbeiten? Über einen $zwave_parseHook?
--- Ende Zitat ---
Ja, genau.


--- Zitat ---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".
--- Ende Zitat ---
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.


--- Zitat ---Wie soll man mit Versionen > 3 umgehen?
--- Ende Zitat ---
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.


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

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln