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.