Hallo zusammen,
der Adapter MoMa soll Betrieb und Wartung einer Multi-Host Umgebung erleichtern.
Known Issue:
Mit der aktuellen ioBroker-Umgebung funktioniert er ohne Workaround noch nicht auf Slaves. Da muss ich auf die Korrektur von diesem Issue
warten.
LG
AWhiteKnight
Hallo zusammen,
der Adapter letrika_comgw liest Daten der Letrika SMI 260 Modulwechselrichter über das Letrika Kommunikations-Gateway (nicht über den SMI USB Stick!!).
Aktuell werden die Leistungsdaten der registrierten Wechselrichter in ioBroker States bereitgestellt.
Repository: https://github.com/AWhiteKnight/ioBroker.letrika_comgw
LG
AWhiteKnight
@e-s
Der moma tab dient der übersicht über alle iobroker rechner im multihost verbund. Er soll die ausstehenden updates auf den Rechnern anzeigen (derzeit nur linux updates).
Das popup hinter dem i soll mal die wesentlichen infos zu dem jeweiligen rechner anzeigen.
Die Version im latest repository beherrscht updates von linux os, adapter updates und js-controller updates.
Welches Betriebssystem hat Deine Installation?
Nutzt Du die latest oder die stable Version?
Nein, ich betreibe aus Sicherheitsgründen 5 Netzwerksegmente geschachtelt in 3 Ebenen. Innerhalb einer Ebene sind die Netze strikt getrennt.
Firewall 1 ( Internetzugang, nur hier gibt es WLAN)
Firewall 2 (sitzt hinter Firewall 1, nur Kabelgebunden, WLAN bei Bedarf einschaltbar)
Firewall 3 (sitzt hinter Firewall 2, definitiv nur kabelgebunden)
Bei mir sind es 3 USV in 2 Räumen:
Idee ist, bei der geplanten Hochverfügbarkeitslösung die redundanten ioBroker-Master auf verschiedene USV zu legen
Hallo zusammen,
eine neue Version (0.0.2) ist in NPM eingestellt. Sie erstellt die wesentlichen States aus dem Gateway automatisch. Die registrierten Wechselrichter werden angelegt und ebenso die Settings (Cloud, System, Export) und die Infos (Plant, Network).
LG
AWhiteKnight
Hallo zusammen,
der Adapter letrika_comgw liest Daten der Letrika SMI 260 Modulwechselrichter über das Letrika Kommunikations-Gateway (nicht über den SMI USB Stick!!).
Aktuell werden die Leistungsdaten der registrierten Wechselrichter in ioBroker States bereitgestellt.
Repository: https://github.com/AWhiteKnight/ioBroker.letrika_comgw
LG
AWhiteKnight
Hallo apollon77,
ich bin bisher davon ausgegangen, das ioBroker keine HA-Implementierung hat und macht. Mit den für mich neuen Informationen sieht die Welt anders aus.
Der Ansatz ist natürlich besser und zu bevorzugen.
Dann warte ich mal auf Version 2.0 des js-controller und sehe dann weiter.
Punkt 2 der Liste und von 4 die Mini-USV bleiben zum Werkeln bestehen.
3 Odroid C2 liegen noch in der Bastelkiste.
Der Docker-Swarm kriegt dann andere Aufgaben 
Hallo zusammen,
hier hat sich eine Weile nichts getan. Lebt das Thema noch?
Für mich ist das Thema Ausfallsicherheit/Verfügbarkeit aus leidvoller Erfahrung wichtig geworden.
Ich hatte vor einigen Jahren mal den Ausfall der Zentralheizung, weil der Zündtrafo gesponnen hat.
Es war glücklicherweise nicht so kalt, das die Leitungen eingefroren sind, aber als ich aus dem Urlaub wiederkam, war die Haustemperatur auf 5° C abgesunken und es hat 3 Tage gedauert, bis das Haus wieder angenehm durchgewärmt war.
Das war der Auslöser mir Gedanken über das Thema Ausfallsicherheit im privaten Bereich zu machen.
Alles ausfallsicher zu gestalten ist zu teuer bis unmöglich. Schliesslich gilt dafür immer noch: 2n+1 Instanzen müssen existieren, damit davon n Instanzen ausfallen dürfen.
Also braucht es clevere Ideen, um ein Maximum an Sicherheit zu bekommen. Das Zauberwort heißt dabei Ausfalltoleranz.
Der Beitrag Nr 24 von Karl_999 zeigt die grundsätzliche Konzeption einer solchen Lösung auf:
Beim ersten Punkt kommt bei mir der Bedarf an einem HA-IoBroker-Server auf und einem leistungsfähigen Monitoring innerhalb des IoBroker.
Für letzteres entwickle ich gerade einen Adapter (https://forum.iobroker.net/topic/22026/neuer-adapter-iobroker-moma bzw. https://github.com/AWhiteKnight/ioBroker.moma).
Meine HA-Lösung des Servers plane ich auf Basis von einem Docker-Swarm mit 3 Knoten im Swarm-Mode.
Docker hat laut Doku die Thematik der "Hochverfügbarkeit" bei der Swarm-Implementierung ermöglicht.
Also warum das Rad nochmal erfinden?
Hardwarebasis werden SBC der Raspi-Klasse sein. Ich habe ein paar Odroid C2 in der Bastelkiste, die haben mehr RAM as ein Raspi und arbeiten mit EMMC + SD-Karte.
Docker läuft auch drauf, Anleitung: https://magazine.odroid.com/article/odroid-c2-docker-swarm/.
Als Betriebssystem habe ich Armbian genommen, das ist beim Kernel aktueller als das Ubuntu von Hardkernel.
Ein Docker-Swarm läuft bei mir, aktuell nur mit einem Manager/Master, auf jedem Rechner läuft direkt auf dem Armbian auch schon eine IoBroker Instanz. Portainer läuft auf dem Swarm als grafisches Verwaltungstool, soll aber optional bleiben.
Aktuelle To Dos:
Bevor jemand fragt. Ich habe jetzt 3 weitgehend unabhängige Heizsysteme zu Hause:
Die Stromversorgung erfolgt über Photovoltaik und inselfähigem Hauskraftwerk im netzparallelen Betrieb.
Ein paar kleine USV für Steuerungsrechner, NAS etc. gibt es auch schon.
Ausfallstolerante Grüße
Zur Zeit nicht.
Muss mir die verschiedenen Fritzbox Adapter anschauen.
Eventuell kann der TR-064 Adapter genutzt werden
Ok jetzt habe ich einen Container auf meinem NAS am laufen (das ioBroker-Image von buanet).
Erster Eindruck - MoMa funktioniert prinzipiell. Werde die nächsten Tage mal alles durchtesten.
Finding1:
Die ioBroker-Installation im container ist noch etwas älter und hat die sudo Rechte nicht, die bei der aktuellen Installation vergeben werden.
Lösung:
Als root im container folgenden Befehl absetzen
echo "iobroker ALL=(ALL:ALL) ALL" > /etc/sudoers.d/iobroker
Docker ist bei mir noch nicht am laufen - bin ich gerade in der Einarbeitung
Entwicklung und Tests mit VirtualBox und VMWare haben mir gezeigt, dass die verschiedenen Virtualisierungsumgebungen nicht alle Hardware-Daten durchreichen (z.B. CPU-Temperatur) und bei manchen eigene Werte belegen (z.B. Motherboard, CPU-Typ).
