ioBroker wenn online-sonst OpenCCU

[Wichtelmann]

Ich habe fast alle Programme bisher in Raspberrymatic/ObenCCU erstellt.
Nun teste ich parallel mit Blockly, und es gefällt mir immer mehr, vor allem ist es schneller!
Ich möchte nun eie Routine erstellen, die in ioBroker eine SV erstellt, wenn ein bestimmtes Script läuft. Quasi Setze SV-io-online auf wahr wenn aktiv. Ggf auch eine globale SV wenn io überhaupt online ist.
Diese würde ich dann in die HM Programme als Prüfkriterium mit einbauen, so dass immer nur ein Programm für den geichen Anwendungsfall aktiv wäre.

Was haltet ihr davon?
Wie würdet ihr es umsetzen? lasse ich iobroker sobald online, eine globale SV in OpenCCU auf wahr setzen?

[Samson71]

@wichtelmann sagte in ioBroker wenn online-sonst OpenCCU:

Was haltet ihr davon?

Sofern ich die Idee dahinter richtig verstanden habe und das Ganze dazu dienen soll, die Programme/Logiken sowohl in ioBroker als auch in der CCU/Raspberrymatic vorzuhalten - gar nichts.

Wenn in ioBroker neu angelegt, in der CCU erstmal einfach deaktivieren und und testen. Falls Test bestanden, das Programm in der CCU löschen. Beide parallel aktiv - keine gute Idee.

[CäptnBlaubär]

@samson71 das sehe ich ein wenig differenzierter.

Hintergrund:
-Ansammlung von Steuerung von div. HM-Komponenten (Licht/Steckdosen) über mehrere Jahre
-Umstieg auf ioBroker
-Nachbau der entsprechenden Logik/Programme, deaktivieren der Scripts in HM (Homematic/Raspmatic/openCCU)

-nun der erlebte 'Worst'-Case:
NAS ist kollabiert, obwohl ioBroker auf separatem Mini-PC läuft(lief),
sind in Proxmox scheinbar?durch die Zuweisung des Backup-Pfades auf die NAS,
die LXC-Container (ioBroker/influxdb) gestoppt worden
->Folge:
der aktuelle Zustand von Lampen und sonstigen HM-Gedöns wurde 'eingefroren'

Da brauchts sicherlich eine Weile um das Ganze wieder zum Fliegen zu bringen.
Ging nur über den Neuaufbau der NAS, neue Freigaben, Storage-Konfiguration in Proxmox.....

Natürlich kann manuell der entsprechende Status(ca 50 Komponenten) auf dem HM-System gesetzt werden,
aber eben nur durch Personen im Haushalt, die was davon verstehen.

Das alte HM-System könnte durchaus als Backup-System für die HM-Komponenten dienen.

(?)Überlegung :

• Variable für die Kommunikation zwischen ioBroker + HM in beiden Systemen anlegen
• Versorgung der Variable in ioBroker mit aktuellem Zeitstempel, z.B. alle 10 Min.
• Abfrage des Zeitstempels in HM nach Inhaltsänderung oder Intervall
• wenn Zeitstempel in HM älter als x-Minuten, dann Flag in zusätzlicher HM Variable 'ioBroker-aktiv' false/true setzen
• in allen HM-Scripts diese Variable mit in die Abfragen nehmen (analog der, hoffentlich bekannten, Reboot-Variable)
  ob ein Script ausgeführt wird oder nicht

[Samson71]

@cäptnblaubär sagte in ioBroker wenn online-sonst OpenCCU:

@samson71 das sehe ich ein wenig differenzierter.

Das ist Dein gutes Recht, rettet Dich aber im umgekehrten Fall eines "Ablebens" von HM-CCU/SD-Karte aber auch nicht. Dann ist eh alles weg, auch wenn ioBroker selbst noch läuft, da den HM-Komponenten dann das Gateway fehlt.

Wenn man ioBroker in Zwangsabhängigkeit zu einem NAS oder anderer Speicherhardware betreibt, würde ich eher da beim Thema Ausfallsicherheit ansetzen statt mit wildem Variablengebastel zu versuchen 2 Systeme parallel zu betreiben, die sich dann ins Gehege kommen, wenn das Setzen einer Variablen mal nicht sauber klappt.

Mein ioBroker läuft auch weiter wenn das NAS ausfällt, auch wenn da die Backups hinlaufen. Hatte ich tatsächlich erst am Anfang des Jahres durch ein kaputtes Synology-Netzteil. Das kann also kein generelles Problem sein, sondern ist im beschriebenen Case wohl eher der konkreten Umgebung zuzuschreiben.

Meine Raspimatic läuft auf einem separaten Asus TinkerS. Exakt so eins incl. großem Funkmodul liegt gleich konfiguriert als direkt einsetzbare Ersatzhardware bereit. Ebenso die Proxmox Umgebung. Ein identisches und gleich konfiguriertes ThinkCentre Tiny steht für den Totalausfall des Hauptsystems bereit und braucht nur angeschaltet zu werden.

[CäptnBlaubär]

@samson71 Soweit verstanden.
Die Zwangsabhängigkeit in Proxmox wegen fehlendem (Ziel-)storage war mir bis dato nicht bewußt.
Bin strikt nach Vorgaben zum Einbinden eines QNAP-NAS als Backup-Ziel vorgegangen.
Doppelte Hardware ist immer gut-stellt sich nur die Frage wie synchron halten,
um beim Einschalten des Zweitgerätes auf dem neuesten Stand zu sein ?
Bin am Überlegen den RM auch auf den proxmox als VM (iobroker läuft dort z.Zt. als LXC) zu legen,
um dann über einen Proxmox-Backup Server das komplette Paket zu sichern und ggf. im Ernstfall auf die Ersatzhardware einzuspielen ?

[BananaJoe]

@cäptnblaubär sagte in ioBroker wenn online-sonst OpenCCU:

Die Zwangsabhängigkeit in Proxmox wegen fehlendem (Ziel-)storage war mir bis dato nicht bewußt.
Bin strikt nach Vorgaben zum Einbinden eines QNAP-NAS als Backup-Ziel vorgegangen.

Das wird irgendetwas anders gewesen sein, etwas wichtiges des Containers oder der VM muss dort gelegen haben. Und wenn es nur eine ISO oder eine andere Datei war. War wohl dann nicht per Proxmox Backup Server?
Wäre aber ein separates Thema.

Ich sehe das wie @Samson71 : Ein System richtig redundant halten bzw. auf den Ausfall vorbereitet sein. Und das geht mit ioBroker nun mal super, gerade wenn es als VM (von mir aus auch als Container) und insbesondere mit Proxmox. Mit 2 Stück kann man eine Replikation einrichten so das das 2. Gerät sogar mitlaufen kann und bei Hardwareausfall schnell übernehmen kann. Do kann man dann auch im laufenden Betrieb Updates einspielen und dafür die VMs (geht nicht kit Container) ohne Unterbrechung (Herunterfahren) verschieben. Mit dem Proxmox Backup Server (der gerne ein NAS als Ziel haben kann) kann man duzende Backups bei geringen Speicherbedarf vorhalten. Dahin kann man auch gut das ioBroker Backup senden lassen.

Ganz nebenbei kann man vor Upgrades, insbesondere vor größeren Umbauten, z.B. Update Debian von Bookworm auf Trixie, neue NodeJS Version etc. mal eben vorher einen Snapshot (aka Spielstand speichern) machen und so bei Bedarf wieder zurück springen (aka Spielstand laden)

Das geht mit einem Bare-Metal-System eher schlecht, und die CCU wäre Bare-Metal, oder?