Firmwareupdate Geräte - dauert ewig

[shartelt]

weil die meisten Updates vermutlich ohnehin nur bei neuen Installationen notwendig sind, bei denen sonst noch noch nicht viel läuft.

nee wir hatten ja schon Nutzer hier mit relativ großen Installationen (15 Rolladenaktoren) die dann Wochen gebraucht haben....
In den Threads gings dann glaub nur mit 2ter Zentrale und rüberholen -> Updaten -> zurückholen

[Roland M.]

Hallo!

nee wir hatten ja schon Nutzer hier mit relativ großen Installationen (15 Rolladenaktoren) die dann Wochen gebraucht haben....

Ja, ok, die gibt es natürlich auch, aber hier schließe ich mich auch der Meinung an, who cares? Soll es eben Wochen dauern - solange es überhaupt fertig wird.
Meine eigene Erfahrung war eben, dass die meisten Updates nur bei den Erstinstallationen notwendig waren. Da waren auch noch Kombinationen aus CCU2- und Geräte-Firmwares dabei, die ein erneutes Anlernen benötigten, um alle (neuen) Funktionen zu bieten. Das war dann blöd, in der leeren Wohnung zu sitzen (na ja, via VPN ) und zu warten, während die größte Aufgabe der CCU war, die FW-Updates nur häppchenweise abzugeben...

Aber wie man diese Funktion dann benennt, ist ja ohnehin sekundär.


Roland

[Xel66]

Wenn die USB-Schnittstelle an der Vorderseite des Aktors ist, muss man diesen auch nicht aus der Wand rupfen. Dann reicht das abnehmen des Tasters und ein Laptop.

Nein, reicht eben nicht und würde den Aktor massiv verteuern. Die USB-Schnittstelle ist das eine Ding (eine serielle Schnittstelle ist auf den Geräten für das Aufspielen der initialen Firmware bereits vorhanden), aber ein galvanisch getrenntes Netzteil für die interne Versorgung des Aktors ist ein anderes. Im Moment sind die Geräte als solche schutzisoliert in ihrem Gehäuse verbaut. In dem Moment, in dem der Hersteller irgendwelche Schnittstellen nach außen verlagert (und das würde schon mit dem Herausführen der internen Antenne beginnen, darum auch die hier im Forum im Zusammenhang mit solchen Ideen mehrfach lesbaren Warnungen), muss er für einen entsprechenden Schutz vor Berührungsspannung sorgen.

Dieses würde das Netzteil für einen mehr als überschaubaren Effekt (wenige Updates innerhalb der Lebenszeit des Aktors) massiv verteuern. Und einen Hinweis, dass die Geräte für Updates vom Netz zu nehmen sind, würde sowieso niemand lesen. Sieht man beim Thema "Portweiterleitungen" eindrucksvoll. Es funktioniert ja so wie es designt ist. Das einzige Problem ist die Ungeduld des Anwenders. Es gibt keinen Zwang, die Updates schnell einspielen zu müssen. Das System funktioniert ja weiter. Dafür hat der Hersteller Sorge getragen. Insofern kann man noch so oft um des Kaisers Bart diskutieren. Ich glaube kaum, dass der Hersteller daran was ändern wird. Er ist gezwungen, ein paar vorgeschriebene bzw. sicherheitstechnische Dinge einzuhalten. Und hier ist die Nutzung der Luftschnittstelle der einfachste Weg.

Und bezüglich der Ausschöpfung der 36 Sekunden für Updates. Dann würde für den Rest der Stunde in diesem System gar nichts mehr gehen. AUßerdem bezieht die Milchmädchenrechnung keinerlei Protokolloverhead mit ein. Sieht man ja schon, dass für das derzeitige Verfahren der DC auf Grundlevel bis 50% ausgelastet wird. Mehr steht eben nicht zur Verfügung, wenn man einen ungestörten Betrieb sicherstellen will. Für IP-Geräte böte sich allerdings der Weg der zweiten Frequenz an, die die Nutzung eines 10%igen DC erlaubt. Aber auch der Effekt ist überschaubar und würde vermutlich ein Redesign der Kommunikationsbasis (HmIP-Server, Gerätefirmware, Funkmodulfirmware aller HmIP-Geräte etc.) erfordern und vermutlich mehr Probleme schaffen als es löst. Insofern, Tee trinken und (Update) abwarten.

Gruß Xel66

[dtp]

Ich hatte mich auch schon einige Male über die FW-Update-Strategie bei HMIP geärgert. Lange Wartezeiten sind ja eine Sache, aber wenn ich den auf dem Dach montierten Wettersensor abmontieren muss, um ihn für zwei Wochen in die Nähe der CCU zu bringen (früher ging das HMIP-FW-Update ja noch nicht über das Gateway), dann ist das schon eine sehr ärgerliche Sache. Glücklicherweise hat sich das ja deutlich verbessert, so dass es eigentlich nur noch die Warterei ist. Und da heißt es dann einfach Abwarten und Tee trinken sowie Ruhe bewahren.

Da wäre das System ja wochenlang blockiert...

Genau das wird ja wirksam vermieden. Alle Geräte funktionieren während der Übertragung der FW weiterhin. Lediglich für den kurzen Moment des tatsächlich angestoßenen Updates ist das betreffende HMIP-Gerät "außer Gefecht gesetzt".

[Matsch]

Wenn die USB-Schnittstelle an der Vorderseite des Aktors ist, muss man diesen auch nicht aus der Wand rupfen.

Wunderbar, zu welchen Schlussfolgerungen Klein-Hänschen ungetrübt jeder fachlicher Kenntnis gelangt.
Soo einfach isses - Stromtod inklusive.

[Matthias K.]

36 Sekunden Sendezeit pro Stunde: Wenn ich jetzt mal von einem Durchsatz von nur 20kB/sec ausgehe (wie z.b. bei ZigBee),
dann wären die 100kb in 5 Sekunden übertragen.

20kB/s halte ich schon für sehr hoch angesetzt.
Ich glaube es geht eher um wenige B/s.
Weiß das jemand genauer wie hoch der Durchsatz bei HM/HmIP ist?

[Sven_A]

Soo einfach isses - Stromtod inklusive.

Ja gell, und Wandler auf ein serielles Protokoll braucht auch kein Mensch, die USB Buchse wird direkt an den Speicherbaustein angeschlossen... weil kosten darf das ja nichts.

[jp112sdl]

36 Sekunden Sendezeit pro Stunde: Wenn ich jetzt mal von einem Durchsatz von nur 20kB/sec ausgehe (wie z.b. bei ZigBee),
dann wären die 100kb in 5 Sekunden übertragen.

20kB/s halte ich schon für sehr hoch angesetzt.
Ich glaube es geht eher um wenige B/s.
Weiß das jemand genauer wie hoch der Durchsatz bei HM/HmIP ist?

Es gibt bei HM Funk 2 Übertragungsgeschwindigkeiten:
10k im Normalbetrieb für alle Datentelegramme im Normalbetrieb
100k für die Übertragung von Updates

100k bezieht sich auf die Symbolrate. 1 Symbol entspricht lt. Datenblatt 1 bit.
Ich weiß nur gerade nicht, wie viele Bit es braucht, um 1 Byte zu übertragen (8, 9 oder 10?).
Ganz grob laufen die Updates also 10...12,5 kByte/s

Dazu kommen Re-Transmits bei Störungen (wenn z.B. andere Geräte dazwischenfunken).

[Matsch]

Was nicht heißt, bei HmIP ist es auch so?
Dann dürfte ein Update ja nicht 2 Tage dauern. Auch nicht unter der Berücksichtigung von Wiederholungen und DC.

[Xel66]

Dann dürfte ein Update ja nicht 2 Tage dauern.

Der limitierende Faktor ist und bleibt der Duty Cycle. Dieser wird möglichst unter 50% gehalten. Bei einem Grundpegel von vielleicht 20% blieben noch 30% für die Übertragung von Updates (bei optimalen Empfangsverhälnissen mit Maximaldatenrate). Bei miserabler CCU-Programmierung ist das Verhältnis vielleicht noch schlechter. Macht in dem Beispiel von 36 Sekunden innnerhalb einer Stunde noch runde 12 Sekunden mit fein verteilten Pakteten von wenigen Millisekunden mit viel Protokolloverhead. Würde für die Größe der Updatedateien auch ausreichen, um damit in überschaubarer Zeit fertig zu werden. Irgendwo existierte mal eine Präsentation zum Aufbau der Funkpakete und der Unterschied zwischen HM und HmIP. Der Anteil der Nutzdaten (speziell bei HmIP) war IRC sehr überschaubar. Nicht zuletzt wegen der gesicherten Kommunikation. Sprich, die mögliche Bruttodatenrate des Kommunikationskanals ist das Eine, die Datenrate des übertragenen Contents das Andere.

Gruß Xel66