aktuelle Firmwareupdates

[betateilchen]

Wieso nicht? Ich finde das hat sehr viel Charme!

Ja, die Idee ist gut. Das ändert aber nichts an meiner Meinung.

[Ich79]

oder 30ms

Code Auswählen Erweitern

select(undef, undef, undef, (0.03));# no wait necessary - FHEM is slow anyway

Juhu! Mit 30 ms Pause hat es nach 6 Minuten Laufzeit geklappt! Update ist durch. Habe es mit 2 RT's probiert. Die beiden sind im oberen Stockwerk (also einmal durch Stahlbeton). Keine Probleme soweit, d.h. war wohl wirklich etwas zu schnell.

Danke nochmal!
Boris

[martinp876]

ok - den Einbau der Wartezeit für HMUSB muss ich anders gestalten... eine CUL braucht dies nicht. Also wird die Position verschoben...

Selbstverständlich muss man den Update nicht mit FHEM machen - warum man aber mehrere Stunden Frust dabei hat verstehe ich nicht.
Klar, zu Beginn war die SW löchrig - genau wie bei diesem Versuch jetzt. Aber das wird, wie alles, sukzessive behoben. 
Mittlerweile klappt es recht gut - insbesondere der update der blind (mein letzter Test) hat ein paar Erkenntnisse gebracht - der Code war aber schon korrekt.

[gandy]

Hi Martin,

habe nun schon 3 von den HM-LC-Bl1PBU-FM erfolgreich mit HMUSB und flash-ota updaten können, darum habe ich nun auch den Update über FHEM versucht. Allerdings sind alle Versuche bislang gescheitert, jeweils mit Reading "fwUpdate: fail:BlockXX". Auch  deinen Tipp mit 30ms habe ich versucht, da kam ich zumindest bis Block239...

Danach hing der Aktor im Bootloader fest, was aber den Vorteil hatte, dass ich nahtlos mit flash-ota weitermachen und das Update erfolgreich zum Ende bringen konnte. Und das, ohne ihn ausbauen und stromlos machen zu müssen, ich verbuche das schonmal als deutlichen Vorteil

So wie ich deinen letzten Post verstehe, ist weiteres Hochsetzen des Delays auf z.B. 50ms weder elegant noch zielführend. Vielleicht hilft eine Beobachtung weiter, die ich eher zufällig gemacht habe, weil das Terminal mit dem ich hmland gestartet hatte noch offen war: Immer wenn ein FHEM fwUpdate fehlschlug, meldete hmland

Code Auswählen Erweitern


Not enough input available!


Die Meldung kommt im Macro CHECK_AVAIL() vor, in der die Länge eines Eingangsbuffers überprüft wird - ob dort aber die Daten geprüft werden, die von FHEM kommen oder vom HMUSB habe ich auf die Schnelle nicht eruieren können.

Grüße,
Andy.

[martinp876]

Danach hing der Aktor im Bootloader fest, was aber den Vorteil hatte, dass ich nahtlos mit flash-ota weitermachen und das Update erfolgreich zum Ende bringen konnte. Und das, ohne ihn ausbauen und stromlos machen zu müssen, ich verbuche das schonmal als deutlichen Vorteil

das funktioniert auch mit FHEM. Du kannst dann fwUpdate <file> 30 eingeben. FHEM wartet 30sec auf die "bin-im-bootmode" message und probiert es noch einmal.
Block 239 war sicher fast das Ende des Updates.

Ich habe erst einmal das dauernde Senden des "init" gestoppt - mit dem update von jetzt(svn)  oder morgen (fhem). Evtl hat dies den HMUSB "verunsichert".

Könnte auch sein, dass das Verarbeiten der HM-rückmeldungen nicht funktioniert.
Könnte auch sein, dass der HMUsb immer 100ms warten will. Den Verdacht bekommt man, wenn man die Rückmeldungen sieht. Die Quittung jeder message kommen im Abstand von ~100ms. Das Delay ist durch FHEM-trägkeit nicht zu erklären.
Der Update mit HMUSB sollte demnach insgesamt auch nicht länger dauern, wenn man 100ms einstellt, da schlussendlich auf ein ACK gewartet werden muss.
Falls jemand also morgen nach dem update noch einmal das device loaden will (einfach noch einmal die gleiche FW).

Übrigens kann man die neue(die aktuelle) FW version mit dem Kommando
set <dev> getSerial
erhalten
p.s.
sorry
set <dev> getVersion

[gandy]

das funktioniert auch mit FHEM. Du kannst dann fwUpdate <file> 30 eingeben. FHEM wartet 30sec auf die "bin-im-bootmode" message und probiert es noch einmal.
Block 239 war sicher fast das Ende des Updates.

Hatte ich einige Male auch so gemacht - bis FHEM kein fwUpdate mehr akzeptierte mit dem Hinweis "FW update in progress - please wait" - zu dem Zeitpunkt war aber schon ein MISSING ACK aufgelaufen. Da half jeweils nur noch ein shutdown restart - nach mehr als drei davon innerhalb einer halben Stunde hab ich dann den flash-ota-Ausgang gewählt

[Jens_B]

Sorry für meine doofe Frage, funktioniert das mit Firmware Updates auch mit einem alten hmlan Adapter (dem runden UFO formigen?)
Gruß
Jens

[martinp876]

nein. HMLAN können wir nicht auf die hohe Datenrate setzen.
Nur CUL und HMUSB gehen.

[Jens_B]

Ah danke, schade. Dann bleiben meine Rollladen aktoren wohl auf alter Firmware.
Hätte ich man gleich einen USB Stick gekauft...
Gruß
Jens

[CQuadrat]

Weil ich hier irgendwie den Faden verloren habe,  nochmal eine Frage dazu:

Ich habe einen HMLAN und würde meinen RTs gerne eine neue FW verpassen. Dazu würde ich mir auch einen HMUSB zulegen. Muss ich dann meine RTs von HMLAN nach HMUSB "umpairen"? Oder kann ich im bestehenden System einfach noch einen HMUSB integrieren und damit als IO-Device die RTs updaten?

[no_Legend]

Ich hab auch eine hmlan und zusätzlich noch einen cul.
Die Updates habe ich per cul gemacht. Ich hab dem cul nur die gleiche id gegeben wie dem hmlan.

So konnte ich die Updates ohne Probleme durchführen.
Ob man das mit der id unbedingt machen muss keine Ahnung.

[martinp876]

zum update braucht das IO die HMId, mit der das Device gepairt ist. Also die des HMLAN.
du musst das Attribut IODev des Device auf HMUSB setzen, dann wird dies genommen (VCCU hast du nicht, nehme ich an)

Später kannst du eine vcc einrichten - was immer sinn macht, aber inbesondere wenn du HMLAN und HMUSB parellel betreiben willst, also mehrere IOs (auch HMLAN und CUL, oder jede andere kombination)

[Mr. P]

Wieder einmal ein Firmwareupdate im ersten Post.
Diesmal für den HM-ES-PMSw1-Pl auf Version 1.6.

Edit: @Martin... kannst du entsprechende fwUpdate-Zeile in die HMConfig.pm aufnehmen? Thx!

[marc2]

Moin !

Habe mich heute mal mit dem Aktuellen Stand

Code Auswählen Erweitern

$Id: HMConfig.pm 6407

an das FW-Update meiner Rolladenaktoren gewagt. VCCU deaktiviert den HMUSB als IODev eingetragen. Folgendes Ergebnis bei allen
Aktoren:

Code Auswählen Erweitern

2014.08.16 14:13:23 2: CUL_HM fwUpdate started for Markise_Suedwest
2014.08.16 14:13:23 3: CUL_HM set Markise_Suedwest fwUpdate firmware/HM-LC-Bl1PBU-FM_update_V2_3_0002_131204.eq3 30
2014.08.16 14:13:24 2: CUL_HM fwUpdate Markise_Suedwest entered mode. IO-speed: fast
Use of uninitialized value $mNo in sprintf at ./FHEM/10_CUL_HM.pm line 5270.
Use of uninitialized value $mNo in sprintf at ./FHEM/10_CUL_HM.pm line 5270.
Use of uninitialized value $mNo in sprintf at ./FHEM/10_CUL_HM.pm line 5270.
2014.08.16 14:13:58 2: CUL_HM fwUpdate Markise_Suedwest end. IO-speed: normal

Vorteil, die Aktoren sind - wie schon mehrfach beschrieben - im Bootloader hängen geblieben, so dass ich das FW-Update mit
flash-ota bei allen Aktoren zu Ende bringen konnte, ohne an den Sicherungen spielen zu müssen 

Nachtrag: Bei einem fünften Aktor, hat das Update über FHEM funktioniert.

Gruß, Marc

[martinp876]

@Mr. P.
der Update des PMSw1 hat also funktioniert?

@Marc,
CUL_HM ist sicher auch aktuell - oder?
kannst du einen Log machen? Warum die Nummer ausser Kontrolle kommt ist mir nicht klar - wahscheinlich ist, dass bereits vorher ein Abbruch erfolgte