crandler hat geschrieben: ↑06.11.2021, 10:01
Meiner Meinung nach ist Homematic für "größere" Installationen einfach ungeeignet, wenn man regelmäßig alle Updates einspielen möchte.
Es gibt Anwender, die wohl recht große Installationen betreiben. Von denen liest man hier aber bezüglich dieser Problematik weniger. Aber
Homematic trägt ja das Home schon im Namen und ist eben für Installationen bis zur Größe von normalen Einfamilienhäusern gedacht. Und das packt das System im Normalfall auch problemlos. Hier wird der Updateproblematik aber eine Bedeutung zugemessen, die dem Problem nicht ansatzweise gerecht wird. Was stört es, wenn das System mehrere Wochen braucht, um alle gleichartigen Aktoren upzudaten? Im Normalfall läuft das System währenddessen doch problemlos (zwar mit erhöhtem Duty Cycle) weiter. Der Duty Cycle ist aber auch das einzige wirkliche Problem daran. Die einzige Limitierung die besteht, ist nun mal in repeateten Netzen oder welche die den HAP enthalten, weil hier die implementierte Duty Cycle-Begrenzung auf 50% nicht greift und das System sich selbst auf den Bauch legt. Bei den Updates geht es bisher in keinem Fall um sicherheitsrelevante Fehlerbeseitigung, sondern maximal funktionelle Updates oder welche, die die Stabilität verbessern. Der Zwang, diese in kurzer Zeit einzuspielen ist einfach nicht gegeben und das Problem wird hier m.E. nur künstlich aufgebauscht. Noch dazu kommt, das solche Updates nur in vergleichsweise großen Abständen veröffentlicht werden. Es ist ja definitiv nicht so, dass die Aktoren mehrmals im Jahr ein Update benötigen. Im Gegenteil!
Meines Erachtens ist es sogar zielführend, in repeateten Funkstrecken keine Updates zu fahren, da hier die Belegung des Funkbandes schlichtweg verdoppelt wird, weil der Repeater jedes empfangene Funkpaket für den entfernten Empfänger nochmals aussenden muss. Gerade bei den IP-Geräten ist wegen des "listen before talk" ein möglichst wenig dauerhaft belegtes Funkband notwendig. Die Sache mit dem HAP ist wieder ein anderes Ding. Hier handelt es sich um eine nachträglich angeflanschte Krücke für Anwender mit flächenmäßig ausgedehnter Installation, um die Funkabdeckung zu gewährleisten. Vermutlich lassen sich in der gewachsenen Struktur der Firmware solche nachträglichen Zusätze nicht voll funktional implementieren, so dass zwar die Steuerung und Konfiguration gelingt, aber eben keine Updates. Schließlich ist der Unterbau ja auch schon etwa betagt und wird seit der CCU1 mitgeschleppt. Darum halte ich persönlich auch nichts von den Installation der Zentrale im Keller um dann das selbst geschaffene Defizit mit irgendwelchen Repeatern, Gateways und Accesspoints auszugleichen. Die CCU gehört in die Mitte des abzudeckenden Funkbereiches und schon gar nicht in den Keller. So, wie man es bei WLAN auch macht. Das ist nun mal bei Funksystemen so. Und wer es anders betreibt, muss eben mit Einschränkungen leben. Um mal wieder einen Autovergleich zu bemühen: Wer sein Auto unbedingt tieferlegen will, muss bei Schlaglöchern, Bordsteinkanten und schlechter Fahrbahn eben vorsichtig fahren, damit das geliebte Fahrzeug nicht aufsetzt. Das ist dann weder dem Hersteller noch dem Eigner der Straße (wobei Schlaglöcher beseitigt gehören) anzulasten, sondern eine Entscheidung des Besitzers.
Als Lösung des Problems kann man entweder den Propheten (sprich: Aktor) zum Berg (sprich: CCU) schicken oder den Berg zum Propheten bringen. In Systemen mit HAP sollte der Tausch CCU gegen HAP das kleinere Problem sein, wenn man nicht wieder ein Konstrukt gewählt hat welches einen solchen Tausch verhindert (Virtualisierung auf einem anderen Rechner, den man nicht mal so schnell woanders aufbauen kann). In allen anderen Fällen muss man eben den Aktor ausbauen und in die Nähe der CCU bringen (ja, ich weiß, dass das mit gewissem Aufwand verbunden ist) oder eben den Workaround mit einer zweiten CCU (die alte 2er aus dem Reserveregal) benutzen. Einfach Aktor lokal werksresetten --> an der Reserve-CCU anmelden --> updaten --> werksresetten --> und am produktiven System "drüberanlernen" --> fertig. Das sollte in einem Minimum der Zeit abgelaufen sein. Dass man in der Zeit des Updates mit einer Kommunikationsstörung auf dem produktiven System leben muss, versteht sich von selbst, weil der Aktor ja währenddessen wegend es Werksresets nicht mehr auf den ehemaligen Herrn hört. Möglichkeiten gibt es schon. Es ist nur nicht so einfach, wie man es sich wünschen würde und mit etwas "Arbeit" verbunden - aber lösbar. Die Energie, die manche reinstecken, um den Status Quo hier im Forum zu beweinen und bejammern, wäre in einer solchen Lösung des Problems besser angelegt. Ich gehe mit dem Updateproblem noch pragmatischer um. Ich schaue, ob ich vom "Problem" betroffen bin und lasse dann das Update einfach sein, wenn ich es nicht benötige. Im Falle eines FSI16 (und der hatte wirklich ein funktionelles Problem, welches das ganze System in die Knie gezwungen hat) habe ich den Weg mit der Reserve-CCU gewählt. Wobei der Aktor immer noch im Probebetrieb dran hängt, weil ich inzwischen am gepanten Einbauort etwas anderes verbaut habe.
Das Grundproblem ist mehr der dem Anwender durch viele Geräte, die eines Updates aus Sicherheitsgründen bedürfen, antrainierte "Beißreflex" sofort jedes "Update" einspielen zu müssen, weil sonst das eigene Gerät "gefährdet" ist.
Gruß Xel66