Hallo,
ich versuche, an mehreren Rolladen-Aktoren (HM-LC-Bl1PBU-FM) ein Firmware-Update von 2.8 auf die aktuelle 2.11.1 durchzuführen. Ich habe die Firmware-Datei in /opt/fhem/FHEM/firmware auf dem Raspi gespeichert. In fhem habe ich das Update mit set Buero.RO fwUpdate /opt/fhem/FHEM/firmware/HM-LC-Bl1PBU-FM_update_V2_11_1_161212.eq3 gestartet. Im Reading fwUpdate erscheint nach kurzer Zeit "fail:Block2".
Ich habe eine VCCU definiert und darin ein HM-LGW und ein HMLAN. Das HMLAN habe ich testweise aus der IOList der VCCU entfernt, weil das nach meinen Recherchen kein Firmware-Update durchführen kann. Ich habe das Update mehrmals versucht, das Ergebnis ist immer gleich.
Hier die Einträge aus dem Log zum Update:
2017.10.26 12:43:40 2: CUL_HM fwUpdate started for Buero.RO
2017.10.26 12:43:40 3: CUL_HM set Buero.RO fwUpdate /opt/fhem/FHEM/firmware/HM-LC-Bl1PBU-FM_update_V2_11_1_161212.eq3
2017.10.26 12:43:40 2: CUL_HM fwUpdate Buero.RO entered mode. IO-speed: fast
2017.10.26 12:43:45 1: PERL WARNING: Use of uninitialized value $mNo in sprintf at ./FHEM/10_CUL_HM.pm line 7016.
2017.10.26 12:43:49 1: HMLAN_Parse: HMLAN1 new condition disconnected
2017.10.26 12:43:49 1: 192.168.178.30:1000 disconnected, waiting to reappear (HMLAN1)
2017.10.26 12:43:49 1: HMLAN_Parse: HMLAN1 new condition disconnected
2017.10.26 12:44:13 2: CUL_HM fwUpdate Buero.RO end. IO-speed: normal
2017.10.26 12:44:53 1: HMLAN_Parse: HMLAN1 new condition init
2017.10.26 12:44:53 1: 192.168.178.30:1000 reappeared (HMLAN1)
2017.10.26 12:44:53 1: HMLAN_Parse: HMLAN1 new condition ok
RSSI vom Lan-Gateway zum Device ist aktuell 33.
Hat jemand einen Tipp, wie ich das Firmware-Update durchführen kann? Zu dem Fehler habe ich nichts hilfreiches gefunden. Und nach diversen Berichten soll das Firmware-Update aus fhem eigentlich problemlos laufen.
Vielen Dank im voraus
Matthias
Ich hatte zwei verschiedenen Fehlerquellen mit "Block 2"
1. falsche FW Datei
2. falsche Dateirechte.
Wenn es die richtige FW ist und FHEM die Datei lesek kann sollte das Update durchlaufen.
Diese Aktoren sind sehr zickig! Hatte ähnliche Probleme mit 3 von >10.
Wenn es also nicht das Rechte-Problem sein sollte und du sie nach dem fehlgeschlagenen Update-Versuch noch bedienen kannst:
Hast du noch genug credits?
Wenn nein: Warten oder auf andere Weise "Platz schaffen", ggf. pending-Befehle per "clear all" abbrechen.
Dann nie mehr als 3 in einer Stunde updaten.
Wenn sie sich nicht mehr bedienen lassen und die config-LED vor sich hin blinkt:
(Ohne Gewähr: Strom weg, config-Knopf drücken, Strom ein, update versuchen).
Sch... Teile, die!
Die Firmware Datei habe ich aus dem eq3 fw-check und auch über die Suche auf der Download-Seite. Der Link ist: http://www.eq-3.de/Downloads/Software/Firmware/HM-LC-Bl1PBU-FM_update_V2_11_1_161212.tgz
Und die Rechte sollten auch stimmen:
-rwxr-xr-x 1 fhem dialout 140616 Dez 12 2016 HM-LC-Bl1PBU-FM_update_V2_11_1_161212.eq3
Matthias
Man gibt den Pfad relativ zum FHEM root an
set Buero.RO fwUpdate FHEM/firmware/HM-LC-Bl1PBU-FM_update_V2_11_1_161212.eq3
das update wird blockweise übertragen. nach jedem empfang eines blocks sollte der aktor ein ack senden. wenn die antwort ausbleibt, gibt es ein fail.
ZitatRSSI vom Lan-Gateway zum Device ist aktuell 33.
eventuell ist der funkabstand zu gering. mindestens 1-2m.
Muss mal kurz fragen. Kann das HMLAN Gateway überhaupt Firmwareupdates. Ich dachte immer das ginge nicht.
der "neue" hmlan (hmlgw) kann updaten, der "alte" nicht.
ah, danke dir
Aufruf Update mit relativem Pfad führt zum gleichen Ergebnis, das macht keinen Unterschied zum absoluten Pfad.
Mit credits habe ich mich bisher noch nicht beschäftigt. Ich weiß, dass es Beschränkungen gibt, wieviele Befehle in einem bestimmten Zeitraum übertragen werden können. Kann man die verbliebenen Credits abfragen?
Jedenfalls habe ich bisher an mehreren Tagen in größeren Abständen die Versuche durchgeführt. Und immer nur für 1 Gerät, nicht für mehrere gleichzeitig.
Der Abstand zwischen LAN Gateway und Aktor ist ca, 3 m, also nicht ganz so kurz.
Matthias
Unter den beschriebenen Bedingungen sollte das mit den credits nicht das Thema sein, die load sollte sich abfragen lassen (habe andere IO's). Aber wie beschrieben: Im "regulären Betrieb" gingen bei mir bis zu 3 Update (-versuche) pro Stunde mit einem HMUART (PI-Modul).
Dann dürfte auch nichts mehr "cmd_pending" sein, oder? Und ein getconfig reibungslos laufen und die Aktoren bedienbar sein.
Hmmm...
Vielleicht nochmal die update-Datei runterladen, nicht dass die einen Hau bekommen hat beim Runterladen/Kopieren.
Und für den speziellen update-Modus dürfte es doch die "hoch"-Taste gewesen sein, die bei power-on gedrückt sein muß... Aber Achtung: wenn dann was schiefgeht, ist es schlimmer als jetzt!
Gruß, Beta-User
Nach dem letzten Versuch von gerade eben wird angezeigt:
protState = CMDs_done_Errors:1
fwUpdate = fail:Block2
state = IOerr
Trotzdem kann ich den Aktor normal über fhem bedienen.
Die Firmware-Datei habe ich nochmal über wget direkt auf dem Raspi heruntergeladen, entpackt, ins richtige Verzeichnis verschoben und Owner geändert. Falls die Datei nicht schon auf dem Download-Server defekt ist, sollte es daran nicht liegen.
Was ich noch nicht erwähnt habe:
Ich habe 6 von den Rolladen-Aktoren und auch noch einige andere HomeMatic-Geräte. Eines der Rolladen-Aktoren hat seit ein paar Tagen das Problem mit "Missing ACK", das auch in einigen Beiträgen erwähnt ist. Ich habe den schon stromlos gemacht, auch Werksresett und auch Taste nach unten festgehalten (so hatte ich es in einem Beitrag gelesen) beim Verbinden mit Phase. Hat alles nichts gebracht. Ich habe EQ3 kontaktiert und die sagen, der Aktor wäre defekt und müsste eingeschickt werden. Aktuell habe ich ihn aus fhem gelöscht und neu gepaired, ist aber wieder nicht bedienbar und im Log erscheint jede 30 Minuten die Meldung:
CUL_HM set Ankleide.RO statusRequest
Wegen dieses defekten Aktors bin ich überhaupt auf die Idee mit dem Firmware-Update gekommen. Das scheitert auf diesem Aktor, aber eben auch auf anderen Aktoren.
Jedenfalls sind alle Versuche, ich bisher geschildert habe, auf einem anderen Rolladen-Aktor passiert, der ansonsten normal funktioniert. Möglicherweise spielt aber der defekte Aktor doch eine Rolle bei den credits, weil ja öfter eine Kommunikation versucht wird. Ich werde den jetzt endgültig aus fhem löschen, bis ich ein Ersatzgerät habe.
Allerdings würde ich auch gerne die Firmware-Updates durchführen und ich habe momentan keine Idee mehr, wo der Fehler liegen könnte.
Gestern Abend habe ich versucht, den HMLAN, der auch noch über die VCCU verwendet wird, aus fhem zu entfernen. Ich hatte vermutet, dass die Kommunikation für das fwUpdate darüber, statt über den HM-LGW läuft. Das hat aber zu einem nicht bedienbaren fhem geführt und daher habe ich eine Rücksicherung der fhem.cfg vorgenommen.
Matthias
Ich habe gestern auch mal, Dank Deines Ansporns, mich mit Firmwareupdates probiert.
Ergebnis
https://forum.fhem.de/index.php/topic,78527.0.html
Ich könnte das ganze retten da ich die Batterien (geht bei Dir ja leider nicht) rausgenommen habe, dann noch mal set DEVICE fwUpdate ./FHEM/firmware/FIRMWAREFILE
eingegeben habe und dann sofort die Batterien eingesetzt habe. Danach hat es super geklappt. Eventuell kannst Du Deinen Aktor ja mal Stromlos machen.
Nochmal: Das update für diese Aktoren ist teilweise extrem hakelig, wenn man sucht, findet man dazu auch Material.
Blinkt die config-LED an dem nicht bedienbaren Aktor? Ich meine, das war dann unregelmäßig bzw. mit Lücken alle 30 Sek.. Der verbraucht dann auch nur eigene credits.
Dann würde ich mit dem anfangen. Man muß den in den speziellen Boot-Update-Modus bringen (wie mit den Batterien beim RT-DN), und welche Taste das ist, habe ich auch gerätselt und mehrfach probieren müssen, und er geht auch nach einiger Zeit wieder aus dem Modus.
Also: mit dem "kaputten" Aktor weiter Testen, das klappt irgendwann!
Gruß, Beta-User
Moin,
ich kann hier mal noch meine Erfahrung (https://heinz-otto.blogspot.de/2016/11/homematic-firmwareupdate.html) und Vorgehensweise einbringen.
Am Anfang erschien es mir auch ziemlich unklar was passierte, aber seitdem bekomme ich das ganz gut hin.
Gruß Otto
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:
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
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:
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:
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
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.
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.
ZitatfwUpdate 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
Zitat von: Otto123 am 27 Oktober 2017, 09:30:36
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...
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 :-X
Zitat von: Otto123 am 27 Oktober 2017, 10:33:33
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 ;) .
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
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
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
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:
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]
set <device> getDevInfoBei 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
Zitat von: hoppel118 am 27 Juni 2019, 09:17:05
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
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.
Zitat von: Otto123 am 01 Juli 2019, 10:10:06
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
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:
ZitatDa 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.
Zitat von: Otto123 am 01 Juli 2019, 11:49:53
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.
Zitat von: Otto123 am 01 Juli 2019, 11:49:53
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.
Zitat von: Otto123 am 01 Juli 2019, 11:49:53
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
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 :)
Echt, wo wird darauf verwiesen? Ich bin wohl blind... ;)
Ich schau mir das nochmal genauer an, wenn die anderen Aktoren angekommen sind.
Viele Grüße
dann lies doch einfach nochmal mein Zitat im Post #27 :-X nur die Worte - ohne Wunschlesemodus.