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

[Homoran]

Ich werde immer mal wieder gefragt wie man denn z.B. die Vitalwerte anderer Minicomputer überwachen könnte, so wie ich es in einer meiner Views mache.

<size size="150">Vorgeschichte</size>

Seit einiger Zeit teste ich hier für das Forum diverse Hardware auf Eignung als ioBroker Server. Dazu habe ich jeweils (fast) die identische Installation auf diesen Rechnern installiert und die Leistungsfähigkeit verglichen. Damals hatte ich seit langem für meine produktives System eine Multihost-Umgebung mit einem Cubietruck und einem RaspberryPi 2 aufgesetzt.

Der Cubietruck war immer schon mein Favorit, da er über eine echte S-ATA Schnittstelle eine HDD/SSD anbinden konnte, eine Echtzeituhr enthielt, 2GBRAM und einen Dual-Core Prozessor. Die beiden letzten Punkte waren damals unübertroffen. Außerdem hat er einen Anschluß für einen LiPoly-Akku mit integriertem Lademanagement. Mit einem solchen Akku war trotz HDD eine autarke Laufzeit von >6h möglich.

Auf der HDD konnte außerdem eine SQL-Datenbank installiert werden, so dass der Cubie ein echter kleiner Server war.

Der RasPi kam ins Spiel als ich immer mehr Hardware eingebunden hatte und im Keller den Stromzähler über den Smartmeter-Adapter auslesen wollte.

und genau damit begann das "Problem":

Ein Multihost -auch mit vielen Slaves- ist eigentlich ein super System. Da ich aber gerne auf allen meinen Installationen alle Informationen (auch wegen gleicher Sytembelastung) haben wollte, war ein Multihost-System nicht mehr ausreichend, da zwar ein Master viele Slaves haben, aber ein Slave nur an einen Master angebunden werden kann.

Also musste ich nach einer anderen Lösung suchen. Ich erinnerte mich an einen Vortrag von hobbyquaker auf einem Homematic Usertreffen über MQTT. Auch im HM-Forum und zunehmend hier wurde MQTT in Zusammenhang mit ESP, arduino und anderen preiswerten Möglichkeiten für Sensoren immer wieder erwähnt. Also entschloss ich mich mich darin schlau zu machen, auch um die Doku dafür schreiben zu können.

Je mehr ich mich damit beschäftigte, desto mehr Möglichkeiten taten sich auf. Abgesehen von den weiteren Möglichkeiten an Sensoren, sollte meine Multihost/Multiserver Installation auch später irgendwie als Redundanzsystem herhalten sollen.

Außerdem wollte ich gelichzeitig eine einheitliche Datenstruktur haben, damit auf jedem Rechner der gleiche View, die gleich flot Charts usw. laufen konnten ohne, dass die Datenpunkte angepasst werden mussten.

Leider habe ich im Verlauf auch diverse Issues erlebt, die ich https://forum.iobroker.net/viewtopic.php?f=22&t=12894&p=139601#p136762 mal zusammengeschrieben habe. Da ich immer noch nicht von mir behaupten möchte, dass ich MQTT vollkommen verstehe, können diese Issues auch meiner Unfähigkeit zuzuschreiben sein.

Nach den letzten Änderungen bin ich sowieso zu dem Entschluss gekommen alles nochmal neu aufzusetzen. Vielleicht läuft es dann rund.

<size size="150">Vorbereitung</size>

Als erstes sollte man sich über die Struktur der Daten auf dem Ziel Gedanken machen. Der erste Ansatz auch eine eigene Baumstruktur "eigene_Messwerte.0" auf dem Ursprungsrechner zu erzeugen scheiterte daran, dass ich nicht in der Lage bin z.B. mit javascript alle Informationen aus der Hardware zu erhalten. Ich arbeite mit Blockly, node-red, rpi2-Adapter und parser-Adapter. Lediglich mit Blockly konnte ich in die eigene Struktur schreiben.

Die Zielstruktur sah dann so aus, dass ich eine Obereinheit HardwareDaten erzeugt habe und darunter für jeden Rechner im Netz ein Verzeichnis:

Jedes dieser Verzeichnisse (hier am Beispiel Cubie) enthält die entsprechenden Datenpunkte:

was die Daten des dazugehörigen Views enthält.

<size size="150">Installation</size>

wenn man jetzt diese Strukturen auf die Server verteilen will braucht man ein "MQTT-System".

Dieses besteht aus einem Broker (der alles verwaltet) und vielen Clients. Die letzteren können ihre States veröffentlichen (publish) oder andere States abonnieren (subscribe). Die Veröffentlichung wird an den Broker geschickt. Die Anfrage auf subscribe wird auch dort verwaltet.

Wenn man jetzt wie ich die gesamten Daten auch loggen will sollte man sich bewusst sein, dass dabei eine immense Anzahl I/O Vorgänge stattfinden wird, die einerseits bei langsamen Rechnern die Load in die Höhe treibt und andererseits den Ausfall einer SD Karte bei Stromausfall wegen der höheren Wahrscheinlichkeit dass dieser während eines Schreibvorgangs stattfindet deutlich wahrscheinlicher macht.

Während der Testphase hatte ich für den "Hauptrechner" ein Tinkerboard, da dieses ein Dual-Channel DDR3 RAM und den schnellsten Cardreader eines Einplatinencomputers besitzt. Aus "historischen Gründen" befindet sich der MQTT-Adapter, der als Broker fungiert auf einem weiteren Tinkerboard.

Dies sollte der Ausfallsicherheit dienen, was natürlich Blödsinn ist, denn wenn der Broker aussteigt läuft der Rest nicht mehr (zumindest theoretisch - bei mir kamen trotzdem noch Daten bei den Subscribern an).

Der Broker kann auch ein ganz anderer Rechner mit z.B. Mosquitto sein, muss also nicht zwingend ein ioBroker-Adapter sein.

In meinem Beispiel installieren wir also auf einem Rechner den MQTT-Adapter und konfigurieren ihn als Broker

Die Konfiguration des Brokers besteht aus zwei Seiten. Auf der ersten wird nur eingestellt, ob der Adapter in Broker oder ein Client sein soll:

Hier kann man noch ein Passwort für den Zugriff vergeben

Auf der nächsten Seite wird eigentlich nichts weiter eingegeben

Die Maske für Bekanntgeben eigener States soll ein Schema sein, welche Daten von dem MQTT-Adapter selber gesendet werden sollen (scheint aber nur im Client-Modus zu funktionieren). Deshalb hat bei mir dieser Rechner zusätzlich einen Client.

Die Konfiguration des clients ist wesentlich umfangreicher:

(1) Hier muss die IP des Brokers eingegeben werden

(2) Hier ein eindeutiger Name für den Client. (ACHTUNG! sollte man ein Backup wie ich mit einem restore auf einem anderen Rechner installieren muss vor dem Start der Instanz dieser Name UNBEDINGT geändert werden - und bei den States ebenfalls)

(3 - 6) Informationen, die der Broker erhalten soll wenn die Instanz hochfährt oder beendet wird

(7) Datenstrukturen, die der client abonnieren soll

to be continued!

[Homoran]

Nachdem wir jetzt den Broker und den Subscriber konfiguriert haben müssen jetzt noch irgendwie diese Daten ins MQTT System gebracht werden.

Bei jeder ioBroker Installation bei dem ein MQTT-client installiert wurde gibt es ähnlich wie bei History unter Objekte zu jedem Datenpunkt die Möglichkeit diesen Datenpunkt zu publishen.

Daher ist es vollkommen egal wie die Datenstruktur auf dem publishing Client ist, alleine anhand der Vergabe des Datenpfades (topic) in den Einstellungen wird daraus die gewünschte Struktur im Broker und im subscribing client. Daher können Die Informationen von rpi2, javascript, parser und node-red in einer einheitlichen Struktur münden. Selbst Daten von ESP oder Arduino können unter Angabe des entsprechenden topics in die gleiche Struktur gebracht werden.