Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[mariohbs]

Ja mit VMs zu Arbeiten ist sicherlich auch eine, wenn nicht sogar die Lösung aber aktuell glaub ich, dass ich doch erst einmal beim Raspi bleibe und dann ggf. auf Tinkerboard wechsele.

Nachdem ich den Artikel zum RAM bei Linux durchgelesen habe und mich dann noch mal mit den blöden Angaben zur CPU Auslastung unter Linux beschäftigt habe bin ich grad zu dem Schluß gekommen, dass der PI3 noch was Luft hat. Wenn dann geht ihm echt zuerst der RAM aus und dann kommt nen Tinkerboard.

Tja und was die Ausfall-Sicherheit angeht - ich habe 4 PI im Einsatz, 2 davon könnten schon mal ne ganze Weile aus sein ohne das es nennenswerte Auswirkungen hätte. Backup-Hardware ist also da :-)

Wenn ich was ändere, mach ich immer ne Kopie der SD Karte und habe so allein vom IOBroker immer 3 32GB SD Karten, welche ich nur reinstecken müsste. Für mich bin ich damit gut gegen Ausfälle gewappnet.

[Creator]

Eine Master/Slave Lösung auf einer anderen Art und weise wäre auch Nice.

Quasi ein Master IoBroker, aber alle Daten werden immer Syncron mit allen Slaves gehalten.

Die Slaves machen nichts als die Daten aufzunehmen. Bricht der Master weg kann man einen Slave zum Master machen.

Den alten Master "reparieren" und als Slave wieder einhängen.

Wüsste nur nicht so recht wie man das mit der Ip Adresse lösen könnte. Dafür brauchte es wohl eine Art Failover IP.

Aber so was, wäre schon sehr charmant.

[Homoran]

So was versuche ich schon länger (halbherzig) z.B. mit MQTT. ein solch redundantes System wäre einfach nur toll.

Aber:

irgendwo muss einer sein, der das ganze synchronisiert. und wenn der ausfällt ist Essig!

Gruß

Rainer

[Creator]

> irgendwo muss einer sein, der das ganze synchronisiert. und wenn der ausfällt ist Essig!

MySql als Beispiel läuft sehr gut in so einer Umgebung.

Der Master verteilt halt an alle Salves weiter.

Bricht der Master weg muss man natürlich eingreifen, aber aus einem Slave einen Master zu machen ist ja nicht so kompliziert.

Eine Wirkliche Synchronisation wäre dies ja nicht, weil es ja nur in eine Richtung gehen würde.

[Dutchman]

Was du hier beschreibst ist nicht nur Master/Slave sondern richtig failover das ist programmiertechnisch etwas schwieriger.

Bei Datenbanken ist das etwas einfacher als laufender Software

–-----------------------

Send from mobile device

Das schöne ios hat Auto Korrektur zum k****

Wer Schreibfehler findet darf sie behalten oder auf eBay verkaufen, mindest Umsatz 10% für die community

[Creator]

Wahrscheinlich weil iobroker die Daten nicht live speichert sondern das nur alle x Sekunden macht?

Also die Daten im RAM verweilen.?

[Dutchman]

@Creator:

Wahrscheinlich weil iobroker die Daten nicht live speichert sondern das nur alle x Sekunden macht?

Also die Daten im RAM verweilen.? `

Nein!

Die Daten werden in einen object Datenbank als Datei gespeichert auf der Festplatte oder in einer redis DB (wie man möchte beides ist Acer local auf den Gerät. Redis Remote währe möglich).

Aber alle Installationen zb Adapter liegen im File System auf der Festplatte.

Eine Software die zB failover hat speichert alles in einer Datenbank und hat halt verschiedene Webserver die auf dieselbe Datenbank zugreifen.

Fällt eine aus kann die andere weiterlaufen.

Datenbank dahinter muss natürlich auch redundant sein.

Wie gesagt ist nicht einfach komplett zu integrieren

–-----------------------

Send from mobile device

Das schöne ios hat Auto Korrektur zum k****

Wer Schreibfehler findet darf sie behalten oder auf eBay verkaufen, mindest Umsatz 10% für die community

[Zippolighter]

Ich mache einfach Master / Slave und habe einen zweiten Master mit gleicher IP-Adresse ausgeschaltet.

Zwischen durch nehme ich den orginal Master mal eben vom Netz und spiele aktuelles Backup oder iobroker Ordner in den Master (Reserve) ein.

Wenn der Master ausfällt ist der Reserve in 5min Betriebsbereit.

[Creator]

Auch eine gute Idee.

Ich halte meine VM an und mache dann einen Export der VM.

Also die wird nicht neugestartet.

Aber da schweifen wir dann wohl auch vom Thema ab.

Von einem PI hat mich immer die microSd Karte abgeschreckt. Wir nutzen ca. 200 PIs von Version 1-3 für wirklich einfache aufgaben welche kaum auf der Karte schreiben.

Dennoch stirbt im Schnitt eine Karte die Woche. Manche laufen seit Jahren manche schaffen nicht mal 2 Monate.

Leider sind slc micro sd Karten oder USB Sticks doch recht teuer.

[knopers1]

eine micro SD Karte ist mir beim Pi auch schon mal hops geganngen. Dafür aber ein USB Stick noch nie…

Habe ständig zwei RPI am laufen. Ich finde die USB-Datenträger sehr robust. Meine zwei VU+Zero Receiver im Schlaff und Gästezimmer zeichnen schon seit Jahren auf den USB Stick auf. Bis heute noch nichts passiert.