[gelöst] Firmware-Update mit Fehler fail:Block2

[matkoh]

Gut, dann konzentrieren wir uns jetzt auf den "defekten" Aktor (Ankleide.RO).

LED blinkt nicht, auch nicht in längeren Abständen.

Hier ein paar Internals und Readings, die vielleicht interessant sind nachgesehen am 27.10. 9:01 Uhr:

Code Auswählen Erweitern

protCmdDel = 17
protLastRcv = 2017-10-27 06:33:14
protResnd = 45 last_at:2017-10-27 06:05:13
protResndFail = 15 last_at:2017-10-27 06:05:17
protSnd = 15 last_at:2017-10-27 06:04:59
protState = CMDs_done_Errors:1
rssi_at_HMLAN1 = cnt:2 min:-81 max:-72 avg:-76.5 lst:-81
rssi_at_HMLANGW = cnt:2 min:-53 max:-49 lst:-53 avg:-51
state = MISSING ACK


Dann Firmware-Update mit

Code Auswählen Erweitern

set Ankleide.RO fwUpdate /opt/fhem/FHEM/firmware/HM-LC-Bl1PBU-FM_update_V2_11_1_161212.eq3
LED bleibt dunkel, Einträge im Log:

Code Auswählen Erweitern

2017.10.27 09:07:58 2: CUL_HM fwUpdate started for Ankleide.RO
2017.10.27 09:07:58 3: CUL_HM set Ankleide.RO fwUpdate /opt/fhem/FHEM/firmware/HM-LC-Bl1PBU-FM_update_V2_11_1_161212.eq3
2017.10.27 09:08:08 2: CUL_HM fwUpdate Ankleide.RO end. IO-speed: normal
Internals / Readings nach ca. 8 Minuten:

Code Auswählen Erweitern

state = set_fwUpdate /opt/fhem/FHEM/firmware/HM-LC-Bl1PBU-FM_update_V2_11_1_161212.eq3
protState = CMDs_done_FWupdate
fwUpdate = fail:notInBootLoader

Wäre es jetzt sinnvoll, tatsächlich den Aktor vom Strom zu trennen, Taste runter festhalten und Strom wieder verbinden? Muss dann das fwUpdate nochmal gestartet werden? Oder ist das noch in der Pipeline, bis der Aktor reagiert?

Matthias

[CoolTux]

Also ich habe das Firmwareupdate dann noch mal aktiv angestoßen über FHEM und sofort Strom drauf gegeben.
Beim Thermostaten sieht man ja wenigstens was passiert. Aber vielleicht ist das genau Dein Problem. Es fehlt wohl das er in diesen besonderen Modul geht.

[Otto123]

Hi Matthias,

ab dem Moment fwUpdate = fail:notInBootLoader ist nix mehr in der Pipeline.
Es klingt so, als lässt er sich von Dir nicht zum Update bewegen. state = MISSING ACK

Das fw Update ist eine Handshake Prozess, er startet wartet auf bestimmte Reaktionen und macht weiter. Wenn die falsche Reaktion zwischenrein kommt wird abgebrochen.

fwUpdate versetzt das Gerät als erstes in den Bootloader, kontrolliert und startet dann den Datentransfer. Man muss es schaffen, dass das Gerät sich mit dem Bootloader meldet wenn fwUpdate es erwartet. Andernfalls bricht er mit einem Fehler ab.
Ich hatte Erfolg mit dieser Reihenfolge:
Gerät ausschalten.
fwUpdate starten und danach sofort das Gerät mit Strom versorgen/Bootloader starten

Aber!
Ich würde ein Gerät, was nicht richtig arbeitet und offenbar in FHEM nicht sauber funktioniert, nicht mit FW Updates traktieren.

Das Gerät ist ja offenbar nicht im bootloop, ich würde entweder ein normales Update versuchen oder es lassen und andere Fehler suchen.

Gruß Otto

[Beta-User]

Ich würde ein Gerät, was nicht richtig arbeitet und offenbar in FHEM nicht sauber funktioniert, nicht mit FW Updates traktieren.

Stimme dem ja grundsätzlich zu, aber wenn das Gerät auch auf Tastendrücke nicht mehr reagiert (auch nach einem Poweroff), ist es im Prinzip egal, ob man ihn ggf. "noch mehr" kaputt macht.

Einen Pairing-Versuch würde ich ggf. vorher noch machen (vielleicht ist die ID der Zentrale verrutscht, dann akzeptiert er natürlich keine Befehle). Dann sieht man auch, ob irgendeine Funkkommunikation stattfindet.

Bei meinen nicht-reagierenden hatte ich aber nach meiner Erinnerung (kann falsch sein) nur welche, bei denen die LED ziemlich kurzzyklisch geblinkt hat. Gleichmäßig, nur alle x Sekunden kurz unterbrochen. Die liesen sich jedenfalls wiederbeleben.

Dass man den Aktor durch die richtige Taste in den Bootloader-Modus versetzt hat, kann man daran erkennen, dass die LED blinkt. Wenn es nicht die Runter-Taste ist, solltest du die Hoch-Variante testen. Ich kann auch nicht mehr sagen, ob die Taste dann losgelassen werden muß oder bis zum Ende des Updates gedrückt bleiben...

[Otto123]

Und das er wirklich was hat?
https://forum.fhem.de/index.php?topic=56359.0

Ansonsten, Taste drücken bis er blinkt und dann loslassen - meine ich.  Ich finde meine Aufzeichnungen diesbezüglich gerade nicht 

[Beta-User]

Und das er wirklich was hat?

Kann schon sein, aber war das dort nicht so, dass die Funkverbindung noch ok war und der Aktor lediglich nicht mehr schalten wollte?

Daher erst mal der Hinweis, nochmal vorab ein pairing zu versuchen. Auch wenn es fehlschlägt, sieht man, ob der Aktor funktechnisch zu erreichen ist.... Wenn nicht und die Gewährleistung um ist: Versuch macht kluch .

[matkoh]

Habe den "defekten" Aktor aus fhem gelöscht incl. Filelog. Dann an VCCU gepaired, Fahrzeiten angegeben und umbenannt. Momentan läuft er ohne Probleme.

Ich werde das mal etwas beobachten und dann später nochmal ein Firmware-Update nach der Anleitung von Otto123 machen. Er hat z. B. vor dem Update den HMLAN deaktiviert und das könnte auch bei mir das Problem sein. Aber erst mal abwarten, ob der defekte Aktor die nächsten Stunden Probleme bereitet.

Vielen Dank bis hierhin für Eure Unterstützung.

Matthias

[Otto123]

Den HMLAN deaktivieren ist sozusagen doppelte Vorsicht und muss eigentlich nicht sein. In letzer Zeit habe ich nur mit dem IOgrp <VCCU>:<prefIO> Attribute gearbeitet und das funktioniert einwandfrei.

Das er jetzt erstmal funktioniert ist ja prima.

Bei dem Fall mit dem Netzteil kaputt war es meines Wissens auch so, das es ein paar Tage vor dem "stabilen" Ausfall schon mal ein Fehlverhalten gab. Aber ja, Funk war eigentlich in Ordnung aber eben nur zur Abfrage. Sobald man geschaltet hat hat er ja neu gestartet, da kam auch kein Ack.

Gruß Otto

[matkoh]

Ich kann eine Erfolgsmeldung geben. Nach der Anleitung von Otto123 habe ich das Firmware-Update für den "defekten" Aktor durchführen können. Nach Drücken der Config-Taste und getConfig wird die neue Version auch angezeigt.

Vielen Dank für Eure Unterstützung. Die restlichen Updates werden damit wohl auch funktionieren.

Matthias

[hoppel118]

Danke euch für diesen Thread. Hatte die gleichen Probleme "fail:Block2" und "fail:notInBootLoader" beim Versuch einen "HM-ES-PMSW1-PL" mit der aktuellen Firmware zu versehen.

Ich bin dann wie folgt vorgegangen:

• Device vom Strom nehmen

Code Auswählen Erweitern

set <device> fwUpdate /path/to/new/firmware[/li]
[li]Graue Taste am Device gedrückt halten und dabei das Device wieder an den Strom anschließen[/li]
[li]Die Status LED sollte nun schnell rot blinken, wenn nicht Vorgang wiederholen. Wenn die LED dann irgendwann aufhört zu blinken, noch folgenden Befehl ausführen, damit das Reading "D-firmware" aktualisiert wird[/li]
[li]

Code Auswählen Erweitern

set <device> getDevInfo

[/li]

Bei mir hat es auf diese Weise direkt beim ersten Mal geklappt. Ich hatte neulich schon einen Abend erfolglos 1 bis 2 Stunden damit verbracht, das Gerät einfach über den set-Befehl mit dem Update zu versorgen.

Wie dem auch sei, danke, läuft nun.


Frage an die Entwickler: Wäre es nicht sinnvoll, den Befehl "set <device> getDevInfo" nach einem Firmware Update automatisch auszuführen. So würde man direkt die neue Firmware sehen, wenn der Vorgang erfolgreich abgeschlossen wurde und nicht die ältere Firmware Version, die nun gar nicht mehr installiert ist.

Viele Grüße Hoppel

[Otto123]

Wäre es nicht sinnvoll, den Befehl "set <device> getDevInfo" nach einem Firmware Update automatisch auszuführen.

Hi,

was Du da ermittelt hast, dürfte nicht stimmen. Das Reading und das Attribute Firmware (und ein paar andere) werden im Allgemeinen durch getDevInfo nicht erneuert, ich habe das gerade nochmal bei ein paar Geräten (nicht bei dem von Dir erwähnten Schalter) probiert.
Man kann diese Infos meiner Erfahrung nach nur durch die Anlernmessage übertragen und nicht durch getDevInfo. 
Die Anlernmessage kann man durch entsprechendes Configtaster drücken oder bei manchen Geräte durch "set ... hmPairSerial ..." auslösen.

Gruß Otto

[hoppel118]

Hmm... Das sehe ich anders. Habe in letzter Zeit einige davon in Betrieb genommen und dabei immer wieder das gleiche Verhalten festgestellt.

- Zuerst lerne ich das Gerät an, dafür betätige ich natürlich die Taste.
- Dann führe ich das Firmware-Update durch.
- Danach getDevInfo, um das Reading und das attr für die Firmware zu aktualisieren.

Die Anlernmessage kann man durch entsprechendes Configtaster drücken oder bei manchen Geräte durch "set ... hmPairSerial ..." auslösen.

Die Taste am Gerät (Ist das der Configtaster?) habe ich nach dem Firmware-Update grundsätzlich nicht mehr betätigt. Lediglich bei diesem einen Gerät habe ich die Taste nochmal betätigt, um das Gerät aufgrund der Fehlermeldungen in den Bootloader-Modus zu versetzen. Auch "set ... hmPairSerial ..." habe ich ausschließlich bei der Initialen Inbetriebnahme ausgeführt.

Hier hatte ich irgendwann dazu auch schonmal was geschrieben:

https://forum.fhem.de/index.php/topic,100830.msg942767.html#msg942767

,,getVersion" gibt es anscheinend nicht mehr. Ich habe 7 verschiedene Homematic Modelltypen im Einsatz.

Gruß Hoppel

[Otto123]

naja gut. Zum Einen finde ich über getDevInfo nichts in der Doku. Damit kann ich nicht sagen was es wirklich tun soll.
Ich hätte gedacht, wenn es wirklich die Informationen vom Gerät neu holen würde, würden die Readings neu geschrieben. Kann sein, das bei mir nichts neu geschrieben wird, weil keine Änderung erfolgt ist. Siehe Edit unten
In dem von Dir verlinktem Artikel und dem Bezug aufs Wiki steht auch erstmal nicht anderes:

Da nach dem Update immer noch die alte FW-Version in FHEM steht, kann man entweder bei einigen Geräten die Version mit

set <device> getVersion
auslesen oder wenn das Kommando wie z.B. bei den oben genannten Heizkörperventilen nicht zur Verfügung steht, genügt es, am Gerät selbst die Anlerntaste zu drücken (was am Beispiel der RTs bedeutet, dass die Boost-Taste für mindestens drei Sekunden gedrückt werden muss). Nach der Aktualisierung der Firmware-Information in FHEM, muss die Konfiguration noch gespeichert werden.

Ich kann derzeit keine Firmware Updates testen, es gibt für mich nichts neues

Edit: Ok Du hast scheinbar genau für diesen Schalter Recht! Wenn man beim HM-ES-PMSW1-PL getDevInfo ausführt werden diese Informationen neu übertragen. Funktioniert bei mir aber erstmal bei keinem anderen HM-Geräte Typ.

[hoppel118]

naja gut. Zum Einen finde ich über getDevInfo nichts in der Doku. Damit kann ich nicht sagen was es wirklich tun soll.
Ich hätte gedacht, wenn es wirklich die Informationen vom Gerät neu holen würde, würden die Readings neu geschrieben.

Ja, genau das passierte, wenn ich getDevInfo ausgeführt habe.

Kann sein, das bei mir nichts neu geschrieben wird, weil keine Änderung erfolgt ist. Siehe Edit unten
In dem von Dir verlinktem Artikel und dem Bezug aufs Wiki steht auch erstmal nicht anderes:
Ich kann derzeit keine Firmware Updates testen, es gibt für mich nichts neues

Jo, das ist denkbar. Evtl. hast du ein Gerät bei dem du testweise erst ein Down- und dann ein Upgrade machen kannst.

Ansonsten habe ich mir gerade ein paar weitere davon bestellt. Insofern die auch noch auf v1.6 laufen, könnte ich den gesamten Vorgang vom Pairing bis zum getDevInfo damit nochmal nachvollziehbar wiederholen.

Edit: Ok Du hast scheinbar genau für diesen Schalter Recht! Wenn man beim HM-ES-PMSW1-PL getDevInfo ausführt werden diese Informationen neu übertragen. Funktioniert bei mir aber erstmal bei keinem anderen HM-Geräte Typ.

Ok, aber getVersion, darauf wird im Wiki verwiesen, gibt es bei gar keinem meiner Devices (mehr). Sieht das bei dir anders aus?

Gruß Hoppel

[Otto123]

Naja der Wiki Artikel ist von 2014. Und dort wird ja auch schon darauf verwiesen, dass es getVersion nicht gibt ...
Ich bin zu faul zum suchen