Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[RaBe52]

Was mir beim ioBrooker [auch] gut gefällt, ist die Stabilität. Auch dann, wenn man beim Konfigurieren mal Mist baut :hankey: .

Aber gestern habe ich es tatsächlich mal hinbekommen, ihn vermutlich durch eine Blockly-Fehlkonfiguration in eine Endlosschleife zu schicken. Da ging kaum noch was. Zum Glück läuft der bei mir in einem Proxmox LXC, so dass nur dessen vCPUs am Anschlg waren. Bei dessen Neustart kam ich irgendwann dazwischen und konnte das bereinigen.

Die Frage, wie erkennt und behandelt man im ioBrocker Ausfälle/massive Fehler beschäftigt mich latent von Anfang an, aber nach der Erfahrung ist es akut geworden. Dass da mein Haus dran hängt ist nicht so wichtig, aber ein schwindender WAF wäre fatal :face_palm:. Da könnte ich weitere Invest-Anträge gleich vergessen.

Daher folgende Fragen in die Runde:

• habe ich hier im Forum was zu dem Thema übersehen? Ich habe nichts dazu gefunden (von Diskussionen zu ganz spezielen Fehlern mal abgesehen).

• wie erkennt man am besten einen klemmenden/eingeschlafenen Adapter? Einzelne Datenpunkte könnte man ja aufgrund der letzten Aktualisierung prüfen, aber das wäre in Summe extrem mühsam.

• Wie baut man am Besten in ioBroker eine Strategie, die sicherstellt, dass alle (kritischen) Zustände beim Start und bei Ausfällen in einen fail-safe-state kommen? Vielleicht über eine Art "Emergency-Adapter" mit speziellen Rechten/hoher Prio.

Vielen Dank im voraus für Eure weiterführenden Hinweise :pray:

[MartinP]

@rabe52 Vor den Problemen habe ich auch Respekt ...
Bisher habe ich das so gelöst, dass ich Lebenswichtiges nur "Lose" an Iobroker gekoppelt habe ...

Meine automatisierten Heizkörperthermostate funktionieren z. B. auch ohne iobroker. Nur die Veränderung der Solltemperatur muss dann von Hand erfolgen, wenn iobroker zickt...

Proxmox kann Cluster, Failover usw. habe mich damit aber noch nicht beschäftigt ...

Bis jetzt habe ich mich darauf beschränkt sicherzustellen, dass Backups auf Proxmox-Ebene und iobroker existieren, die eine gewisse Zeit in die Vergangenheit reichen ... Ein Recovery habe ich daraus aber noch nicht exerziert ...

[RaBe52]

@martinp
Grundsätzlich mache ich das ähnlich. Aber wenn es z.B. darum geht, den PV-Überschuss mit mehreren Geräten (z.B. E-Speicher, E-Auto, Heizstab, Klimaanlage,...) verteilt zu nutzen, dann kommt man um eine zentrale Instanz nicht mehr drum herum.
Und grundsätzlich gilt: ein Automatismus, den man nicht abschalten kann, taugt nichts!

Proxmox habe ich auch, aber das wäre ja noch eine Ebene darunter. Außerdem nützt das denke ich nur was, wenn der Container komplett ausfällt, bzw. (woher?) einen Befehl zum Umschalten bekommt. Da sind wir wieder bei der Frage, wie stellt man das fest?

[MartinP]

@rabe52 Vielleicht kann man iobroker dazu nutzen ...

Eine sehr einfach gestrickte ioBroker Instanz in einem LXC-Container, deren einzige Aufgabe es ist, ein oder zwei vorbereitete ioBroker Instanzen in je eigenem Container zu überwachen, ggfs. starten, stoppen backups einspielen usw, wenn Probleme detektiert werden ...

Ich habe davor bisher zurückgeschreckt.
Mein Bauchgefühl hat mir gesagt, dass das ggfs. gar nicht Ausfallsicherer ist, wenn man nicht in allen Details alles "richtig" gemacht hat ...

[arteck]

ich sag nur redundanz und das Thema wurde shon zig mal behandelt..

Ha, redis, Ausfallsicherung USV und und und

[RaBe52]

@martinp Das könnte ein Ansatz sein! Manchmal denkt man einfach zu kompliziert. Bleibt die Frage, was man genau überwachen kann/muss.

Wenn noch eine Entität dazu kommt, stellt sich die Frage "wer kontrolliert den Kontrolleur?". Wenn ich schon ein weiters (Teil-)System dazu nehme ( deinen Gedanken finde ich gar nicht schlecht), sollte der m.E. so schlicht wie möglich sein. Von daher wüde ich dann eher ungern einen ioBroker mit einem ioBroker überwachen und umschalten wollen.

Mal zum Vergleich: zwei beliebig komplexe Proxmox-Server kann man ja mit einem eher schlichten Corosync QDevice (https://blog.ordix.de/two-node-cluster-mit-proxmox-einrichten) verwalten. Mit etwas ähnlich Schlichtem könnte ich mich anfreunden. Wenn man das Teil mit Totmannsignalen aus ioBroker versorgt, könnte man sich damit um die Erkennung kümmern und das beliebig filigran verwalten.

Bleibt das Thema fail-safe-state erreichen (außer "binär" durch Umschaltung bzw. ohne zweiten Server).

[Shadowhunter23]

@rabe52 sagte in Wie umgehen mit Ausfällen (fail safe):

Von daher wüde ich dann eher ungern einen ioBroker mit einem ioBroker überwachen

War und ist meine erste Überwachung und zusätzlich habe ich per Push bei statuscake.com eine Überprüfung. Das Hilft zwar nur beim Javascript Adapter aber reicht mir.
Das einzelne Instanzen ausfallen kommt bei meinem iobroker so gut wie gar nicht vor. In der Regel ist es dann eine Beta Version welche man im Normalfall nicht einsetzen soll. Ich für mich kann sagen dass die Ausfälle von iobroker sehr oft vom Fehler 60 entstanden sind.

edit
Dieser Adapter überprüft auch Instanzen, läuft auch bei mir:
https://github.com/iobroker-community-adapters/ioBroker.device-watcher

[MartinP]

@rabe52 Ein weiterer Aspekt bei dem Spiel mit Acceptance Factor ist auch, was man da als Energieverbrauch zubilligt ... Das Zeug muss ja 24/7 durchlaufen ....Wenn man dann einen ganzen Zoo von Mini-PCs an den Start bringt ....

[RaBe52]

@shadowhunter23
Der device-watcher scheint mir eher was für physikalische Geräte zu sein. Danke für den Hinweis, dafür merke ich mir das.
Für "verklemmte Logik" ist der auf den erstenBlick eher nicht so das Richtige.

statuscake.com als Service im Web? Da macht mein Bauchgefühl nicht so richtig mit. Ich brauch ja schon was Externes, um die Störung mitzubekommen (z.B. Meldung per Telegram). Mich stört ja schon, dass bei vielen ioBroker Adaptern sentry dabei ist.
Da könnte man ja auch lokal was wie checkmk benutzen. Das ist mir aber dafür reichlich überdimensioniert.

[Codierknecht]

@rabe52 sagte in Wie umgehen mit Ausfällen (fail safe):

Da könnte man ja auch lokal was wie checkmk benutzen

Mache ich mit Zabbix. Finde ich persönlich einfacher und zugleich mächtiger als CheckMK.