HM-LC-Bl1PBU-FM Firmware-Update

Begonnen von kossmann, 01 August 2014, 10:11:49

Vorheriges Thema - Nächstes Thema

Andre

Hallo,

bei mir hat es auch gut geklappt, ich musste allerdings meine culfw vorher updaten, mit Version 1.55 hat es irgendwie nicht geklappt und brach immer bei Block 1 ab (?). Danach hat es problemlos geklappt. Einen Aktor musst ich hinterher neu pairen, bei einem anderen brach das Update ab, da habe ich es wie von Martin beschrieben mit


set <device> fwUpdate <fwFile> 60


nochmal gestartet. Lief problemlos. Strom musste ich nicht abklemmen, die Frage gab es ja hin und wieder.

Super Arbeit Martin!

Gruß
André

frank

Zitatmit Version 1.55 hat es irgendwie nicht geklappt
funktioniert auch nur mit fw >= 1.58.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

martinp876

FW 1.55 kann keinen speed-change.

getVersion sollte man machen (alternativ config drücken)
Config drücken ist bei einbaugeräten.... schade, das Kommando ist eleganter.
Aber: bei einigen geht es nicht (z.B. RTs)

Offen ist noch der Test und die Stabilität beim HMUsb.
Die 1. Änderung habe ich erst jetzt eingecheckt. Falls also jemand einen test fahren  könnte - und loggen.
Die Zeit ist noch nicht "verlangsamt" - um zu sehen, ob es am häufgen "channel-Init gelegen hat, dass der USB nicht mittkommt.

Mr. P

Hej Martin,

FW Update mit HM-CFG-USB-2 funktioniert mit der heutigen Version aus dem SVN einwandfrei.
Ich war zwar ein wenig skeptisch, da zwischen Speed switch und der completed Meldung 4 Minuten lagen, aber nach dem Neustart war ganz klar am Display des RT zu erkennen, dass jetzt eine 1.3er darauf läuft. ;-)
Falls du noch etwas benötigst... einen RT hab ich noch mit 1.2 laufen und steht für Tests bereit.
Greetz,
   Mr. P

martinp876

Die "Bremse" hast du nicht mehr drin? Das Problem war dann ausschließlich das (unnötige) init des Device.

Ich denle, da brauche ich nichts mehr.
Zum Testen kann man auch immer auf die 1.3 noch einmal die 1.3 laden - wir können es also jederzeit nachvollziehen.
Danke


Mr. P

Zitat von: martinp876 am 12 August 2014, 08:25:23
Die "Bremse" hast du nicht mehr drin? Das Problem war dann ausschließlich das (unnötige) init des Device.
So ist es. Einfach den Code 1:1 ausgecheckt und FHEM neu gestartet.
Aber vielleicht könntest du bei der Ausgabe ins Logfile (einfach zum Beruhigen des Logfile-Lesers) noch hinein schreiben, dass nach Abschluss bzw. auch ggf. bei einem Abbruch die Geschwindigkeit wieder zurück geswitched wurde. Irritiert ein wenig, dass beim Starten laut Logfile geswichted wird, beim Beenden steht dann aber nichts mehr.
Thx a lot! :-)
Greetz,
   Mr. P

martinp876


Ralli

Hallo Martin,

ich hole den Thread mal hoch, da nun die Update-Thematik für den HM-LC-Sw1PBU-FM und den HM-LC-Bl1PBU-FM mit der Version 2.8.2 wieder aktuell wird.

Update per HM-CFG-LAN geht ja nicht, wohl aber per HM-CFG-USB. Nun ist ja mittlerweile in den hmland eingebaut, dass sich der HM-CFG-USB auch als solcher identifiziert. Könntest Du nun einbauen, dass bei einem über fhem abgesetzten fwUpdate das aktuelle IO (bei konfigurierter vccu) auf einen (den besten der verfügbaren) HM-CFG-USB geändert wird, sofern vorhanden?

Gruß,
Ralli

Proxmox 8.2 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.7.20240420) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

martinp876


Ralli

Das wäre eine super Sache. Dankeschön!
Gruß,
Ralli

Proxmox 8.2 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.7.20240420) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

martinp876

die BLs habe ich schon einmal upgedated.
Jetzt hat es bei mir nicht geklappt - liegt an der CUL-FW. Die schaltet nicht in den Speedmode, der zum update notwendig ist.
Werde ich einmal die alten CUL_FW  suchen müssen.

Ralli

Hallo Martin,

hast Du da mal dran geschraubt?

Wenn ja, ich habe jetzt mal versucht, meine Sw1-PBU "automatisch" zu updaten. Das hat nicht wie erwartet geklappt.

Vorab: vCCU mit 3xHMLAN und 2xHMUSB in der IOList.

Bei einem Device war mit o.a. IOgrp das aktuelle IODev ein HMLAN, bei einem anderen Device war bei o.a. IOgrp das IODev ein HMUSB. Beide Devices wurden in den Bootloader versetzt, ein Update funktionierte bei beiden aber nicht. Das musste ich dann manuell nachschieben.
Gruß,
Ralli

Proxmox 8.2 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.7.20240420) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

martinp876

Den swpbu habe ich nicht, somit auch nicht getestet.wenn er danach noch funktioniert und nicht upgedated ist hat der update nie begonnen. Dann ist es eher ein Problem des io devices, nicht in den speeemode zu kommen

Ralli

Mit meinen Bl-PBUs habe ich das gleiche "Problem" gehabt. fhem versucht brav, ein Update durchzuführen und versetzt die Devices auch brav in den Bootloader. Allerdings wählt es dafür wahrscheinlich nicht eines der vorhandenen HM-USB (oder einen CUL), der Update-Prozess ging jedes mal in fail:Block. .

Dazu war ja meine Frage bzw. mein "Verbesserungsvorschlag", dass fhem vor dem Update-Prozess auf einen in der IOList/IOgrp für dieses Device konfigurierten HM-USB oder CUL mit der besten rssi umschaltet. Ein manuelles Update über Shell hat problemlos geklappt.
Gruß,
Ralli

Proxmox 8.2 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.3 dev, virtualisierte RaspberryMatic (3.75.7.20240420) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.57), FBDECT, Siri und Alexa

martinp876

Das macht fhem doch. Die ioliste ist festzulegen.