Diskussion: HmIP-System im Hardware Replacementfall

[Black]

so schön und auch sicher HmIP auch sein mag, ich sehe einen Punkt im Handling, der eine üble Archillesferse sein kann.

Im Servicefall (Hardwaredefekt, Gerätetausch) sollte sich meiner Meinung nach eine Gerätefunktionalität durch Rückspielen eines ordnungsgemäß erstellten Backups wieder schnell wiederherstellen lassen um eine möglichst hohe Verfügbarkeit zu erreichen.

IM HM Classic Bereich ist dieses erfüllt.
Ein gesichertes System lässt sich bei abgerauchter CCU auf eine neue CCU zurückspielen und sofort wieder nutzen.

Im HmIP bereich ist dieses NICHT gegeben. Hier ist man, obwohl man sich als Anwender BEWUSST gegen eine cloudbasierte Lösung entschieden hat, um nicht auf das Wohlwollen eines Herstellers angewiesen zu sein sowie nicht der Abhängigkeit von dessen IT-Verfügbarkeit unterworfen zu sein, darauf angewiesen, das EQ3 seine Rekeying Server funktional online hat. Geht bei EQ3 mal wieder Servertechnisch irgendwas daneben, kann daraus auch mal eine Nacht oder ein Wochenede werden.

auch wenn man im Besitz der Seriennummen und der STGIN ist, nutzt das nix, man kann lokal anlernen, toll, muss die Geräte aber alle vorher mit Werksreset ablernen. Heisst: Programme zerstört, aus Gewerken und Räumen gelöscht, Mastersets weg, DVs weg. Im zweifelsfall nutz einen das beste Backup nichts, wenn man mit der bisherigen Vorgehensweise sein System trotzdm quasi neu aufsetzen muss, so EQ3 Serverseitig down ist.

Ich denke, hier sollte EQ3 auf der CCU produktlinie nachbessern. es geht lokales Anlernen mit den beiden Nummern, also muss es auch eine lokale Schlüsselgenerierung geben.

Black

[Matthias K.]

Für mich als Cloud-Phobiker klar: Sollte auch lokal möglich sein. Hat mich neulich erst beim Wechsel auf das neue Funkmodul einige Zeit gekostet, weil meine Firewall mit der Kommunikation zu EQ-3 nicht einverstanden war und geblockt hat.

Die Frage ist nur: nutzt so eine Umfrage etwas?

[jp112sdl]

also muss es auch eine lokale Schlüsselgenerierung geben.

Schade, dass sich eQ-3 hier nicht öffentlich geäußert hat: https://github.com/eq-3/occu/issues/107
Sonst könnte man ja mal schauen, was die HMIPServer.jar so im Detail treibt

[JPS]

auch wenn man im Besitz der Seriennummen und der STGIN ist, nutzt das nix, man kann lokal anlernen, toll, muss die Geräte aber alle vorher mit Werksreset ablernen. Heisst: Programme zerstört, aus Gewerken und Räumen gelöscht, Mastersets weg, DVs weg. Im zweifelsfall nutz einen das beste Backup nichts, wenn man mit der bisherigen Vorgehensweise sein System trotzdm quasi neu aufsetzen muss, so EQ3 Serverseitig down ist.

Ich denke, hier sollte EQ3 auf der CCU produktlinie nachbessern. es geht lokales Anlernen mit den beiden Nummern, also muss es auch eine lokale Schlüsselgenerierung geben.

Fragt sich, ob man IP-Geräte nicht von vorneherein mit Seriennummern und STGIN lokal anlernen sollte

[deimos]

Hi,

man kann das teilweise jetzt schon anschauen, einfach mal mit den Settings in der crRFD Config etwas spielen und einen Reverse Proxy zwischenschalten.

Ich hatte vor Ewigkeiten schonmal überlegt einen kleinen lokalen Webservice zu erstellen, bei welchem man die SGTIN und den Key aller Geräte einträgt und welcher dann genau für den Tausch des Funkmoduls den Webservice von eQ-3 ersetzt. Bisher war ich einfach zu faul dafür. Wobei ich das Risiko für mich auch überschaubar ansehe, weil ich notfalls an alle Geräte rankomme zum neu Anlernen und eigentlich keine Logik mehr in der CCU habe. Und von den Direktverknüpfungen habe ich alles mit Screenshots dokumentiert. An einen Nachmittag wäre das also notfalls alles wieder frisch hochgezogen.

Viele Grüße
Alex

[deimos]

Hi,

Fragt sich, ob man IP-Geräte nicht von vorneherein mit Seriennummern und STGIN lokal anlernen sollte

Das ändert an der Sache nichts, weil die auch dann nicht im Filesystem der CCU gespeichert werden, sondern nur im Funkmodul.

Viele Grüße
Alex

[JPS]

Hi,

Fragt sich, ob man IP-Geräte nicht von vorneherein mit Seriennummern und STGIN lokal anlernen sollte

Das ändert an der Sache nichts, weil die auch dann nicht im Filesystem der CCU gespeichert werden, sondern nur im Funkmodul.

Viele Grüße
Alex

Ah, danke.

[Black]

(....) Wobei ich das Risiko für mich auch überschaubar ansehe, weil ich notfalls an alle Geräte rankomme zum neu Anlernen und eigentlich keine Logik mehr in der CCU habe. Und von den Direktverknüpfungen habe ich alles mit Screenshots dokumentiert. An einen Nachmittag wäre das also notfalls alles wieder frisch hochgezogen.

Das einige dafür FallBack Strategien haben, logisch. ich würde mein System auch relativ schnell wieder rekonstruiert bekommen.
von allen Geräten sind die Mastersets und die Linksets separat als Script gesichert, die Programme, Favoriten Räume und Gewerken auch.
Bei mir wäre der HardcoreFallback, Script 1 laufen lassen, elimiere alle IP geräte mit Werksreset. Script 2 Laufen lassen eliminiere alle WebUI programme und Favoriten.
Dann Fleissarbeit, die geräte werksresetten wenn nötig und wieder alle anlernen
anschliessend die einzelnen Restore Scripte laufen lassen und das System steht wieder.

das kriege ich hin, im Problemfall meine Frau aber nicht, wenn ich mal nicht greifbar bin, weil ich mich beruflich irgendwo in der Welt rumtreibe und im bösestenfall nicht per VPN zuhause auf die Systeme komme. und auch dann muss einer nach anweisung durch geführt durchs haus laufen und resets machen bzw anlernknöpfe drücken. Als ein Restore Szenario vollkommener Murks meiner Meinung nach.

Vor allem, wenn EQ3 den Schritt gehen will, sich neben KNX in der grossen Welt der Wired DDC Systeme etablieren zu wollen. Mit einer derartigen FallBack Strategie ? Ne Danke.

Da würde ICH eher auf ein offenes Bussystem setzen, berufsbedingt würde bei mir in einem Wired Schaltschrank eine 1200er SPS von Siemens sitzen. Im Crash Case, Klemmen lösen, alte CPU raus, neue Rein, klemmen festziehen, speicherkarte rein, spannung ein, 10 sekunden warten, system leuchtet grün und geht in run, durchatmen, zum kaffeeautomaten gehen.

Ich erwarte von EQ3 als hersteller in der CCU Linie eine Möglichkeit, entweder die Funkmodulkeys in einem Separaten Backup zu sichern und bei modulwechsel auch separat laden zu können oder das diese auch Teil des Backups werden, so dass ein restore entsprechend schnell und professionell abgewickelt ist. Den AP betrifft diese Diskussion nicht, ist dort EQ3 Serverseitig nicht erreichbar, ist bei einem AP dann ja auch schon direkt automatierungstechnisch Dunkelheit.

Black

[jp112sdl]

teilweise jetzt schon anschauen

Ja, aber halt nur den Teil, den der Prozess nach außen kommuniziert.

Das ändert an der Sache nichts, weil die auch dann nicht im Filesystem der CCU gespeichert werden, sondern nur im Funkmodul.

Auch bei der CCU2? Alles im internen EEPROM des Mega644?

[Ondas[tm]]

Heißt dann ja auch, wenn EQ3 mal den Bach "runter" geht, sind die Geräte [1] Kernschrott?!
Sowas mag ich gar nicht...

[1] So bald man etwas verändern will, also verkaufen / ankaufen will. Der laufende Betrieb wird nicht gestört