Implementierung CC FIRMWARE_UPDATE_MD

[krikan]

Hallo Andreas!

nach der Logdatei muss ich mal schauen, falls ich damals keine abgelegt habe müsste ich noch mal versuchen eine neue zu erzeugen, das ging ja zumindest bei der Version auch mehrmals.

Es geht auch mit der aktuellen Version noch mehrmals.  Mir war eingefallen, dass ich letztes Mal auch diese Probleme hatte. Also anderer PC, Sensor aus- und angesteckt und das Update lässt sich beliebig wiederholen. Also danke für Dein Angebot, ist aber nicht (mehr) notwendig.

Woher sich das Fibaro Homecenter die Daten zieht kriegt man wohl nur meinem Sniffer raus...

ZWave@culfw wäre noch eine Lösung. Jedoch befürchte ich, dass das angesichts der schwachen Checksumme ein größeres Risiko ist.
Irgendwie bin ich mit dem FGMS-Update auch noch nicht wirklich durch: HCL zeigte erfolgreiches Update, aber Version ist laut FHEM unverändert!? Muss wohl noch mal den Sensor am HCL ankoppeln, um das gegenzuchecken.

Gruß, Christian

[krikan]

Habe das Firmaware-Update des AEOTEC Multisensors komplett mitgeloggt:

Ablauf mit CC FIRMWARE_UPDATE_MD V2 sieht relativ simpel aus.

Mein Log ist mMn vollständig. Alle Firmeupdate-Nachrichten an den Sensor sind laut Telegrammen fortlaufend vorhanden. Zusätzliche Checksummen in den Nachrichten passen immer zu Ergebnis aus ZWave_CRC16($) in 10_ZWave.pm. Aber ich bekomme nicht die korrekte Checksumme laut Log zum Anstoßen des Updates berechnet: Zur Checksummenermittlung habe ich die reinen Updatecodes aus den Nachrichten nach Löschen von Doppelnachrichten fortlaufend in eine Binärdatei kopiert. Länge der Datei passt, aber Checksumme ist falsch. Mir fehlen gerade Ideen, wie ich ansetzen/probieren kann. Ohne die programmgesteuerte Ermittlung der Ckecksumme zum Anstoßen des Updates ist die CC nicht sinnvoll nutzbar  .

Ideen?

[A.Harrenberg]

Hmm,
ist zu lange her das ich mir das angeschaut habe. Hast Du denn diese ID die zu Anfang übertragen wird? Wenn Du die dazu nimmst?

Gruß,
Andreas.

[krikan]

ist zu lange her das ich mir das angeschaut habe. Hast Du denn diese ID die zu Anfang übertragen wird? Wenn Du die dazu nimmst?

Hallo Andreas!
Das war es! Nach Einfügen von 2 Bytes mit der FirmwareId am Anfang der Binärdatei bekomme ich die übermittelte Checksumme "b8e8". Vielen Dank für den Tipp! 

Also ist der Aufbau hier:
2 Bytes: FirmwareId
restliche Bytes: Firmwarecode

Mich wundert nur, dass die ManufacturerId in der Datei nicht gespeichert ist, um die Nutzung von falschen Firmwareupdate-Dateien zu verhindern. Insbesondere, wenn man wie hier als FirmwareId 0000 nutzt!?

Gruß, Christian

[krikan]

CC FIRMWARE_UPDATE_MD V2 ist mMn nicht abwärtskompatibel zur V1. Die 44 Bytes, die jeweils zur Übertragung der Firmware pro Funknachricht zur Verfügung stehen, werden unterschiedlich genutzt:

V1: 44 Bytes Firmwarecode
V2: 42 Bytes Firmwarecode, 2 Byte zusätzliche Checksumme über die 42 Bytes Firmwarecode

Für ein V1 Firmwareupdate habe ich leider kein Gerät mit entsprechender Firmwaredatei zum Testen.

Merkwürdigkeit am Rande:
Popp Rauchmelder meldet bei MANUFACTURER_SPECIFIC die eigene manufId und bei FIRMWARE_UPDATE_MD die manufId von Zwave.me.

[jeep]

Irgendwie bin ich mit dem FGMS-Update auch noch nicht wirklich durch: HCL zeigte erfolgreiches Update, aber Version ist laut FHEM unverändert!? Muss wohl noch mal den Sensor am HCL ankoppeln, um das gegenzuchecken.
Gruß, Christian

Hallo Christian,

das HC2 zeigt nach erfolgreichem Update folgendes:

Device kind:  Motion Sensor
Device type: FGMS001 Motion Sensor EU
Producer:     Fibargroup
Version:       2.8

Und der gleiche Sensor jetzt in FHEM:
version  Lib 3 Prot 3.67 App 2.8 HW 1 FWCounter 1 FW 2.7

Davor stand 2 mal die 2.7 da. Und der Fehler ist auch weg.

Und falls es jemand interressiert, hier ist das Changelog:

• 2.8
• [fix] Fixed problem with to many reports from lux meter.
• [fix] Multichanel Associations are now set even when there is no single node set in association group.
• 2.7
• [fix] Removed error wit wrong multichanel association frames.
• [fix] Corrected tampernotification in seismograph mode.
• [fix] Improved range test.
• [fix] Minor Z-Wave improvements.
• 2.6
• [fix] Corrected error with removing associations.

Grüße, Josef

[krikan]

Hallo Josef,

mein Update des Fibaro FGMS (Ausgangsfirmware 2.7) war leider -wie befürchtet- nicht erfolgreich. Nach einer neuen Inklusion am HCL wurde mir erneut das Update zur Auswahl angeboten und ich habe es noch 2 Mal (erfolglos) probiert. HCL meldet zwar keine Fehler (bzw. ich habe keine Ahnung wo), aber Version des FGMS bleibt gleich und das Update wird nach eniger Zeit wieder angeboten. Habe dann nicht weiter probiert, weil auch das Loggen des Funkverkehrs nicht zufriedenstellend funktionierte. Probiere es evtl. demnächst noch mal, wenn die HCL-Firmware den Beta-Status verlässt.

Außerdem hoffe ich immer noch, dass Fibaro vielleicht die Firmewaredateien veröffentlicht...

Gruß, Christian

[krikan]

FGMS001-Firmwareupdate hat mit HCL und endgültiger Firmware funktioniert.
Erkenntnisse:
-meine FGMS reporten weder im NIF noch bei expliziter Abfrage mit versionClass die CC FIRMWARE_UPDATE_MD (versionClass=0)
-es werden 2 verschiedene Firmwareupdates nacheinander durchgeführt
-Fibaro nutzt bei FIRMWARE_UPDATE_MD Telegramme, die schon aufgrund der Byteanzahl für mich keine eindeutige Ermittlung der CC-Version zulassen. Sieht nach Versionsmischmasch oder eher eigener Erweiterung aus. Class-Version über 2 schließe ich aus, da verwendetes SDK dazu zu alt.

-> als Ideenlieferant für Einbindung der CC in FHEM ist das Update des FGMS mMn ungeeignet. 

[rudolfkoenig]

Fibaro hat offenbar keine Interesse daran, Frimwareupdates auch von anderen, Standard-Kompatiblen Software durchfuehren zu koennen. Ich rate mal: sie sind in Schwierigkeiten mit der Standard-Klasse gelaufen, und das Problem kurzerhand durch Protokollaenderung selbst geloest.

[A.Harrenberg]

Hi,

ob man mit so einer Vorgehensweise allerdings noch offiziell ein ZWave-Logo tragen darf ist fraglich...
Da würde mir höchstens einfallen das sie nicht genügend RAM haben um die Firmware komplett zu puffern bevor sie intern flashen und sie es deswegen "Stückweise" machen müssen. Das wäre aber auch nicht ganz ungefährlich... Da kann man nur hoffen das sie einen rudimentären Bootloader haben der dann ein erneutes Flashen erlaubt...

Mir ist aber schon die Inkompatibilität der V1 und V2 Implementierung in ZWave sehr suspekt. Das wäre dann ja ein Fall das man Befehle der niedrigeren Version unterdrücken MUSS damit es nicht zu Fehlfunktionen kommt.

Gruß,
Andreas.

[krikan]

ob man mit so einer Vorgehensweise allerdings noch offiziell ein ZWave-Logo tragen darf ist fraglich...

Um dem Thema aus dem Weg zu gehen, ist die CC vermutlich versteckt (nicht im  NIF, nicht mit versionClass abfragbar). So hat auch grds. nur Fibaro Kenntnis vom Vorhandensein der CC beim FGMS.

Da würde mir höchstens einfallen das sie nicht genügend RAM haben um die Firmware komplett zu puffern bevor sie intern flashen und sie es deswegen "Stückweise" machen müssen. Das wäre aber auch nicht ganz ungefährlich... Da kann man nur hoffen das sie einen rudimentären Bootloader haben der dann ein erneutes Flashen erlaubt...

Möglich. Ich werde aber den  Updateprozeß vom FGMS erst mal nicht weiter analysieren. Bei den höheren CC-Versionen gibt es nach meinem Verstaendnis die eingebaute Möglichkeit mehrere Firmwares zu installieren.

Mir ist aber schon die Inkompatibilität der V1 und V2 Implementierung in ZWave sehr suspekt. Das wäre dann ja ein Fall das man Befehle der niedrigeren Version unterdrücken MUSS damit es nicht zu Fehlfunktionen kommt.

Davon gehe ich derzeit aus. Auch bei V3 habe ich meine Zweifel an der Abwaertskompatibilitaet. Mehr dazu, wenn ich noch mal mit der HCL spielen darf und einen Dimmer 2 update. Der hat V3 und die CC wird gemeldet.
Insgesamt ist das Thema bei mir noch lange nicht abgeschlossen. Ich habe noch zu wenig Infos und Testobjekte. Wer bietet schon Firmewareupdates  an!?
Kann sich also noch manches an meiner Meinung aendern...

[krikan]

OffTopic und erst einmal nur zur Dokumentation:

CRC_16_ENCAP wird bisher von FHEM nur dekodiert und nicht zum Versenden genutzt. Scheint nicht im Sinne des Standards zu sein, aber negative Effekte erkenne ich nicht und sehe bisher keinen Handlungsbedarf:

Nach den Logs werden Anfragen auf CRC_16_ENCAP-eingeschlossene Nachrichten auch mit CRC_16_ENCAP beantwortet. Sind die Anfragen nicht mit CRC_16_ENCAP eingeschlossen ist das bei der Antwort entsprechend. Ein Umschalten zwischen eingeschlossen und nicht eingeschlossen findet waehrend der laufenden Kommunikation zwischen Controller und Endegeraet statt: bspw. erfolgte Kommunikation komplett mit CRC_16_ENCAP bis auf OK zum Firmwareupdate und die Übertragung der reinen Firmwaredaten.

[A.Harrenberg]

Hallo Christian,

um das zu implementieren müssen man einen ähnlichen "Hook" einbauen wie für SECURITY, man müsste beim Versenden nachschauen ob CRC16 unterstützt wird und das entsprechend codieren und erst dann senden. Die "Abhängigkeit" von der Anfrage ist aber nicht ganz trivial zu lösen, dazu müsste man sich "merken" wie die Anfrage gestellt wurde. Ich habe jetzt nicht in den Code geschaut, aber das dekodieren der CRC16 geschieht glaube ich irgendwo "mitten" im Code, noch bevor die eigentliche Nachricht geparst wird.

Das wird dann eine spannende Sache das transparent zu implementieren ,-)

Gruß,
Andreas.

[krikan]

Implementierung ist vermutlich komplex.
Notwendigkeit erkenne ich aber noch nicht, weil
- meiste Kommunkation vom Controller (FHEM) ausgeht und das ohne CRC_16_ENCAP passiert und Antwort entsprechend ist.
- Kommunikation ausgehend vom Endgeraet mit Antworterwartung die Ausnahmen ist (bei FIRMWARE_UPDATE_MD gibt es das, V2 und V3-Beispiele sind aber ohne CRC_16_ENCAP-Antworterwartung)
- Sinn/Vorteil einer komplett CRC_16_ENCAP-eingeschlossenen Kommunikation bspw. beim FGMS001 sehe ich nicht.

[A.Harrenberg]

Hallo Christian,

angesichts der schwachen Checksumme in den normalen Nachrichten wäre die Nutzung der CRC16 Kapselung schon ein Gewinn an Übertragungssicherheit. Es gibt ja immer wieder Fehlübertragungen mit richtigen Checksumme, die dann in Unparsed landen oder wie bei METER dann "unsinnige" Readings anlegt weil da angeblich die Steckdosen die Regenmenge messen... ,-)

Eine dringende Notwendigkeit sehe ich da momentan auch nicht, in vielen Fällen sind ja leere Batterien der Auslöser.

Gruß,
Andreas.