Implementierung CC FIRMWARE_UPDATE_MD

[krikan]

Da für eines meiner ZWave-Endgeräte ein Firmwareupdate als Binärdatei kommen soll und ich dafür die Unterstützung der CC FIRMWARE_UPDATE_MD in FHEM brauche, habe ich mir die Infos zur CC angeschaut:

Normalerweise bräuchte man zur ordnungsgemäßen Nutzung der CC wohl einen ZWave-Bridgecontroller, da nur der die massenhafte Übertragung von Daten an Endgerät mittels spezieller Funktion bietet. Mit der normalen Sendefunktion der Controller ZW_SENDDATA sind wohl Störungen beim Updatevorgang möglich. AEOTEC weist bei Nutzung eines normalen Controllers für Updates darauf hin, dass nur das mit dem Update zu versorgende Engerät inkludiert sein soll. Damit schließt man störende Einflüsse von Nachrichten anderer Nodes aus.

Mein ursprünglicher Ansatz war: FIRMWARE_UPDATE_MD blockierend wie backupCreate einzubauen, um Störeinflüsse von fremden Nodes auszuschalten und die Exklusion des Endgerätes aus dem Produktivsystem zu vermeiden. Aber ich bezweifel mittlerweile die Richtigkeit meiner Überlegung. Selbst wenn, das Update blockierend eingebaut ist, empfängt der Controller doch weiterhin spontane Nachrichten der anderen Nodes und das Update könnte daran scheitern. Bei backupCreate habe ich ein derartiges Problem bisher aber interessanterweise nicht festgestellt. Zufall?

Wenn mir blockierendes Einbauen in FHEM nichts bringt, könnte ich versuchen, das auch direkt in die vorhandene Struktur mit Nutzung der Sendstacks einzubauen und AEOTECs Weg (nur upzudatendes Gerät inkludiert) einzuschlagen.

Meinungen/Ideen? Danke.

[jeep]

Hallo Christian,

da kann ich Dir beim besten Willen weder mit Meinungen noch mit Ideen behilflich sein. Ich verfolge sein einigen Tagen einen Thread im Fibaro Forum. Fibaro hat ein update für das HC2 auf Version 4.090 vor ca 10 Tagen freigegeben und darin sind Updates für den Fibaro Dimmer von 3.2 auf 3.4 und den Motion Sensor von 2.6/2.7 auf 2.8 enthalten. Einige berichten dass der MS aufgeweckt werden muss, andere mit 15 Min wakeup interval haben dutzende Geräte ohne manuelles wakeUp upgedatet. Manche haben Netze mit über 100 devices. Da sind doch bestimmt laufend "Störeinflüsse", aber alle sagen das Update klappt recht gut. Ob jetzt das HC2 ein sogenannter Bridge Controller ist?

Grüße, Josef

[rudolfkoenig]

Theoretisch stoeren andere Knoten nicht: es geht "nur" um das Senden von Daten an einem Knoten. Praxis ist was anderes, hier spielt das ZWDongle Firmware und das steuernde Software (bei uns ZWDongle/ZWave) noch mit, und kann fehlerhaft sein. Man kann das Problem minimieren, indem das ZWave-Chip fremde homeIds ausfiltert. Sollte fuer erfahrene FHEM-ZWave-Benutzer inzwischen kein Problem sein, temporaer ein anderes homeId zu vergeben Langfristig muss das auch ohne solche Spielchen klappen.

FIRMWARE_UPDATE_MD blockierend wie backupCreate einzubauen, um Störeinflüsse von fremden Nodes auszuschalten

backupCreate ist nich ganz blockierend: Alle Nachrichten, die waehrend des Backups vom Controller geliefert werden, werden in FHEM verarbeitet (dank ZWDongle_ReadAnswer und sein Regexp Parameter). Events werden normal generiert, und notify/etc richtig ausgefuehrt. Aber kein Timer, und keine Daten von anderen Input-Kanaelen.

[A.Harrenberg]

Hi,
ich hatte ja sogar mal angefange mir das näher anzuschauen, habe aber dummerweise meine ersten Versuche nicht dokumentiert und überschrieben... ,-(

Soweit ich das noch weiß soll für das Senden nicht "13" verwendet werden sondern was anderes. Ob das damit zusammenhängt das der Datenstrom nicht "abreißen" soll kann ich nicht sagen, würde ich aber vermuten...

Soweit ich das verstanden habe gibt es zu Anfang erst mal ein wenig Informationsaustausch, und man schickt soetwas wie eine ID mit Checksumme des Firmwarefiles an das Gerät. Wenn die Informationen stimmen (Firmware passt zum Gerät), geht das blockweise senden der Firmware los. Meiner Meinung nach wird das ganze erst dann geflasht wenn alles übertragen ist UND die Checksumme stimmt. Von daher hätte ich jetzt vor Übertragungsfehlern erst mal nicht sooo viel Angst.

Diese Frage-Antwort Spiel als Einleitung hatte ich schon mal implementiert, ist aber nicht mehr vorhanden (ist aber auch nicht kompliziert gewesen).

Ich weiss nicht wie sinnvoll / aufwändig es ist das ganze erst mal mit dem CUL als Dummy-Empfänger zu implementieren...

Gruß,
Andreas.

[krikan]

Ich verfolge sein einigen Tagen einen Thread im Fibaro Forum. Fibaro hat ein update für das HC2 auf Version 4.090 vor ca 10 Tagen freigegeben und darin sind Updates für den Fibaro Dimmer von 3.2 auf 3.4 und den Motion Sensor von 2.6/2.7 auf 2.8 enthalten. Einige berichten dass der MS aufgeweckt werden muss, andere mit 15 Min wakeup interval haben dutzende Geräte ohne manuelles wakeUp upgedatet. Manche haben Netze mit über 100 devices. Da sind doch bestimmt laufend "Störeinflüsse", aber alle sagen das Update klappt recht gut. Ob jetzt das HC2 ein sogenannter Bridge Controller ist?

Glaube nicht, dass die "BlackBox" HC2 einen BrigdeController enthält. Fibaro empfiehlt max. 2m Abstand zu den upzudatenden Geräten. Also direkte Verbindung zwischen Controller und Endgerät.
Btw.: wo bekommen nicht HC-Anwender denn die Firmwaredateien her? Download-Link finde ich nirgends

Man kann das Problem minimieren, indem das ZWave-Chip fremde homeIds ausfiltert. Sollte fuer erfahrene FHEM-ZWave-Benutzer inzwischen kein Problem sein, temporaer ein anderes homeId zu vergeben Langfristig muss das auch ohne solche Spielchen klappen.

Als fortgeschrittener Anfänger finde ich so ein Gefrickel an homeIds nicht ideal. Es sei denn, es gibt einen ganz einfachen Weg, den ich nicht verstehe/kenne.

backupCreate ist nich ganz blockierend: Alle Nachrichten, die waehrend des Backups vom Controller geliefert werden, werden in FHEM verarbeitet (dank ZWDongle_ReadAnswer und sein Regexp Parameter). Events werden normal generiert, und notify/etc richtig ausgefuehrt. Aber kein Timer, und keine Daten von anderen Input-Kanaelen.

Also ist das "halb" blockierend und bringt mich mMn auch nicht wirklich weiter. Dann kann ich auch direkt probieren es in den normalen Sendstack-Ablauf einzubauen und nicht irgendwelche Ausnahmen zu machen. Oder ist das falsch, weil man dadurch mehr Fehlerquellen hat?

Soweit ich das noch weiß soll für das Senden nicht "13" verwendet werden sondern was anderes. Ob das damit zusammenhängt das der Datenstrom nicht "abreißen" soll kann ich nicht sagen, würde ich aber vermuten...

Mein "Wissen" beruht auch nur auf interpretierenden Vermutungen  . Es soll wohl ZW_SENDDATAMETA, wie der Name der Class suggeriert, verwendet werden. Das habe ich bei einem normalen Controller noch nie gesehen und ist Bestandteil der Bridge-API.

Soweit ich das verstanden habe gibt es zu Anfang erst mal ein wenig Informationsaustausch, und man schickt soetwas wie eine ID mit Checksumme des Firmwarefiles an das Gerät. Wenn die Informationen stimmen (Firmware passt zum Gerät), geht das blockweise senden der Firmware los. Meiner Meinung nach wird das ganze erst dann geflasht wenn alles übertragen ist UND die Checksumme stimmt. Von daher hätte ich jetzt vor Übertragungsfehlern erst mal nicht sooo viel Angst.

Mich beunruhigt auch kein kaputtes Gerät, weil ich das genauso wie Du verstehe. Vielmehr dass ich mir etwas stunden-/tagelang zurechtbastel, was nachher wegen Übertragungsproblemen immer scheitert. Wenn ich dann wieder alles umstellen muss, ...

ist aber auch nicht kompliziert gewesen

Schreibst Du; für fortgeschrittene Anfänger aber schon 
Über Dummy-Empfänger denke ich erst gar nicht nach. Da bräuchte ich schon mehr Hilfestellung.

[jeep]

Glaube nicht, dass die "BlackBox" HC2 einen BrigdeController enthält. Fibaro empfiehlt max. 2m Abstand zu den upzudatenden Geräten. Also direkte Verbindung zwischen Controller und Endgerät.

Hallo Christian,

hier die Aussage eines User aus dem Fibaro Forum und ich sehe keinen Grund warum ich das anzweifeln soll, vor allem weil das HC2 eine gute Außenantenne hat. Mittlerweile kenne ich das Gerät recht gut und bin über die Distanzen angenehm überrascht. Diese Blackbox ist ein vollwertiger Mini PC mit Intelplatine, Atomprozessor mit 2 Kernen und Linux. Ich werde demnächst eines von innen anschauen. 

Posted 12 July 2016 - 08:09 PM
Updated to 4.090, more then 100 devices, all went smooth and already on 5 days uptime
Also happy to report that 8 motion sensors were updated to 2.8 from 2.6/2.7 without moving them and without waking them up Some of them located quite far from HC2.

Hier der Link zum nachlesen: http://forum.fibaro.com/index.php?/topic/21804-updating-to-4090/page-5

Btw.: wo bekommen nicht HC-Anwender denn die Firmwaredateien her? Download-Link finde ich nirgends

Ja da bin ich genau wie Du noch am suchen. Habe schon überlegt meine mittlerweile 4 MS zu exkludieren, in einem HC2 zu inkludieren, update zu machen, resetten und wieder in FHEM zu includieren, scheue aber den Aufwand, vor allem weil ich bis auf einem, mit den anderen 3 keine Probleme habe.
Wenn man im HC2 auf dem Updatevorschlag klickt, sieht es dann so wie im angehängten screenshot  aus.

Grüße, Josef

[krikan]

Hallo Josef!
Den Thread hatte ich mir neben den Vorgaben von Fibaro schon durchgelesen. Bleibe dennoch vorsichtig wegen der Abstände und evtl. Übertragungsprobleme. Zum HC2 kann ich nichts schreiben, außer das ich persönlich keine "BlackBox" mehr haben möchte. Nach 2 "profesionellen" Systemen bin ich bei FHEM gelandet und habe endlich die gewünschte Freiheit. Hätte Zugriff auf HCL für das es aber das Update mit den Firmwareupdates (noch?) nicht gibt. Die reinen Firmwaredateien kann ich nirgends zum Download finden. Also abwarten oder "Support" fragen. Als Übungsobjekt wären die Firmwaredateien sehr interessant.
Gruß, Christian

[jeep]

Hallo Josef!
Zum HC2 kann ich nichts schreiben, außer das ich persönlich keine "BlackBox" mehr haben möchte. Nach 2 "profesionellen" Systemen bin ich bei FHEM gelandet und habe endlich die gewünschte Freiheit. Hätte Zugriff auf HCL für das es aber das Update mit den Firmwareupdates (noch?) nicht gibt. Die reinen Firmwaredateien kann ich nirgends zum Download finden. Also abwarten oder "Support" fragen. Als Übungsobjekt wären die Firmwaredateien sehr interessant.
Gruß, Christian

Hallo Christian,

da sind wir schon zu zweit - ich will ja auch keine "Blackbox" haben. Ich habe 3 RPIs mit FHEM und ich bin damit restlos zufrieden, was natürlich auch mit der wahnsinnigen update Geschwindigkeit und dem guten Support hier im Forum zusammenhängt. Ich musste das mal sagen den ich hatte den Eindruck das Du meine Äußerungen zum HC2 und den Updates als Vergleich zu FHEM genommen hast. Das war nicht so beabsichtigt.
Ich habe remote Zugriff auf zwei HC2, deshalb kann ich da immer schauen was sich tut. Auf das letzte Bugfix hat einer 4 Monate warten müssen.
Manchmal ist es nicht schlecht wenn man weiß was die Gegenseite macht. Beide HC2 sind nicht gerootet, sonst hätte ich schon nach den Firmwaredateien gesucht.

Grüße, Josef

[krikan]

den ich hatte den Eindruck das Du meine Äußerungen zum HC2 und den Updates als Vergleich zu FHEM genommen hast. Das war nicht so beabsichtigt.

Hallo Josef!
So entstehen Mißverständnisse. Keine Sorge, hatte ich so nicht aufgefasst. 
Also alles gut.
Grundätzlich soll jede nutzen was er mag. Darum versuche ich auch erst gar nicht den mir bekannten HCL-User zu FHEM zu bringen .

Ich befürchte nur, dass Fibaro die Updates ausschließlich über die HC-Boxen verteilt und das wäre blöd.
Gruß, Christian

[A.Harrenberg]

Hi,

ich hatte damals mal Kontakt mit dem technischen Support von AEOTEC in China...

Update-Binary nur gegen NDA UND wenn es in der Applikation eingebunden wird und nicht "offen" rumliegt. Habe dann dankend abgelehnt so ein NDA zu machen, bei einem Open-Source system sowas halt nicht.

Hatte mir damals eigentlich vorgenommen das Update mal "mitzuschneiden" und mir das File dann selbst zu machen, bin dann aber doch nicht dazu gekommen. Keine Ahnung warum die da alle so eine Geheimniskrämerei draus machen. Als ob da einer das Ding dekompiliert... Die meisten Funktionen sind doch sowieso im DEV-Kit von enthalten und müssen nur gelinkt werden...

Gruß,
Andreas.

[krikan]

Openzwave wird die CC aus Rücksicht vor einem Unterstützer (AEOTEC?) und von dem befürchteter Probleme nicht einbauen/veröffentlichen, obwohl der Code intern schon existiert: https://github.com/OpenZWave/open-zwave/issues/937#issuecomment-234292384
Ob wir bei Firmwareupdates doch etwas zerstören können?

[A.Harrenberg]

Hi Christian,

Openzwave wird die CC aus Rücksicht vor einem Unterstützer (AEOTEC?) und von dem befürchteter Probleme nicht einbauen/veröffentlichen, obwohl der Code intern schon existiert: https://github.com/OpenZWave/open-zwave/issues/937#issuecomment-234292384
Ob wir bei Firmwareupdates doch etwas zerstören können?

schade, da hätte man schauen können ob die was besonderes eingebaut haben...

"Bricken" geht wahrscheinlich immer irgendwie, ich würde es aber eigentlich nicht erwarten, solange man das passende File hat... Der Test ob das File richtig ist besteht nur darin das man eine Art Device-ID und eine Checksumme übertragt. Wenn die Device-ID stimmt akzeptiert das Gerät die Datei und falls dann die Checksumme stimmt wird des dann wohl auch geflasht.

Das Hauptproblem wird sein das jeder Hersteller da sein eigenes Format und Updateverfahren entwickeln wird. Im Fall von AEOTEC ist das File nicht verfügbar und im Updateprogramm "versteckt". Selbst wenn man an ein File kommt kennen wir den internen Aufbau nicht, muss ja kein reines bin-File sein, könnte einen Header oder weitere Datenfelder haben die nicht für das Gerät gedacht sind.

Mal sehen vielleicht schaue ich mir das doch noch mal an...

Gruß,
Andreas.

[krikan]

Abhalten wird mich eine mögliche  "Zerstörungsgefahr" am Basteln mit meinen  Geräten nicht. Fürchte eher um fremde Geräte.
Momentan hält mich eher die fehlende Firmwaredatei auf. Popps angekündigte Datei verzögert sich auf unbestimmte Zeit.

[krikan]

Hallo Andreas!

Hast Du zufällig noch ein Log von einem Firmware-Update des AEOTEC Multisensors, das Du mir zur Verfügung stellen kannst?
Ich habe unvorsichtigerweise ein Update auf Version 1.7 gemacht ohne ein Log zu erzeugen. Das wollte ich später machen. Leider verweigert der Updater bei mir ein nochmaliges Update der 1.7  .

Gestern habe ich ein Update eines Fibaro FGMS über ein Fibaro Homcenter Lite durchgeführt. Das hat funktioniert. Nur an die Firmwaredatei komme ich dort nicht. Im aktuellsten Updateimage auf dem Fibaro-Server finde ich nichts. Es macht den Eindruck als würde die Firmwareupdate-Datei nach Anstoßen des Updates im HCL vom Fibaro-Server geladen. Nur von wo!?

Gruß, Christian

[A.Harrenberg]

Hallo Christian,

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.
Ich schau mal, wird aber wohl erst am Sonntag was.

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

Gruß,
Andreas.

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

[tomspatz]

Ich hänge mich hier mal dran.
Habe einen Multisensor 6 der stammt von Anfang des Jahres also vermutlich noch nicht die aktuellste FW drauf. Ansonsten ist der noch jungfräulich.
Wie ich es verstehe braucht man für das FW Update den Z Stick vom selbigen Hersteller. Dann geht es wohl auch mit Windows Bordmitteln.
Wenn es auch ota mit fhem geht.... bin ich bereit das mit eurer Hilfe gerne mitzuloggen.
LG
Tom

[krikan]

Hallo Tom!
den Multisensor kannst Du mit jedem Stick updaten. Dafür ist kein AEOTEC-Stick notwendig. Ich habe es mit UZB und Vision-Stick schon erfolgreich durchgeführt. Musst allerdings Windows nutzen. Das Update habe ich schon vollstaendig analysiert. Brauchst nichts mitloggen.
Gruß, Christian