Balkonkraftwerk Teil 9: MQTT und REST-API

Helmut 5. März 2023 29 Kommentare

Wieder geht es um das Thema Monitoring eines Balkonkraftwerks, zu dem ich bereits zwei Artikel verfasst hatte. Hier sprechen wir aber nicht über Geräte, die das Monitoring eines BKWs ermöglichen, sondern über die Monitoringdaten selbst, also vor allem Leistung und Energie. Und wie wir diese Daten von DTUs (Data Transfer Units) und Shellies in andere Systeme hinein bekommen. MQTT (Message Queuing Telemetry Transport) ist dabei das Mittel der Wahl, wenn Monitoringgeräte von sich aus Daten exportieren sollen. Und per REST-API (Representational State Transfer) können wir in umgekehrter Richtung Daten von einem Monitoring Device abfragen. Beide Protokolle MQTT und REST-API kann man als Bestandteile der Internets der Dinge (IoT) betrachten und für ein Balkonkraftwerk bilden sie die Brücke zur Hausautomation.

MQTT- Message Queuing Telemetry Transport

Was ist MQTT?

MQTT ist ein Client-Server-Protokoll aus dem Bereich der Maschine-zu-Maschine-Kommunikation oder Internet der Dinge. Clients sind dabei im BKW-Umfeld die Monitoring Geräte, wie etwa Shelly-Devises oder DTUs. Sie sprechen mit einem so genannten MQTT-Broker (Server). Die Kommunikation beruht dabei auf einem Publish und Subscribe von Topics. Diese Begriffe muss ich aber erst einmal erklären:

Ein Topic ist eine Art Titel, Ordnungsbegriff oder Namen und hierarchisch aufgebaut, zum Beispiel:

shellies/shellyplug-s/relay/0/power

Das wäre die Leistung eines Shelly Plug S, die dieses Gerät periodisch oder bei Änderungen per Publish an den MQTT-Broker sendet. Der Broker braucht dafür nicht extra konfiguriert werden, wenn er die erste Nachricht dieser Art bekommt, legt er den Topic automatisch an und aktualisiert mit jeder neuen Meldung den Dateninhalt, also hier den Leistungswert.

Ein anderer Client kann nun einen Topic (oder mehrere) abonnieren (Subscribe). Damit sagt er dem MQTT-Broker, dass er an diesen Daten interessiert ist und künftig Updates dafür erhalten möchte. Der MQTT-Broker versorgt dann alle Subscriber mir den abonnierten Topics.

Der MQTT-Broker ist also eine Art Datenverteiler, der den gesamten Datenwust, denn ein Publisher wie der Shelly Plug S anliefert, zwischenspeichert und einzelne Topics dann an interessierte Subscriber ausliefert. Der Shelly Plug S muss sich nicht darum kümmern, wer alles seine Daten und welche davon bekommen möchte und einem Abonnenten kann es egal sein, woher die Daten ursprünglich stammen. Diese Vereinfachung und Abstraktion der Datenentstehung und ihrer Verwendung ermöglicht der MQTT Broker. Aber Obacht, der MQTT-Broker speichert keine historischen Daten sondern nur immer den letzten Momentanwert zu jedem Topic, er ist also keine Datenbank, aus der man schöne Grafiken generieren könnte.

Mehr müssen wir über MQTT erst mal gar nicht wissen. Sehen wir uns als nächstes an, wie man einen Client für MQTT konfiguriert.

MQTT Client Konfiguration

Nehmen wir als Beispiel im Bild oben OpenDTU und konfigurieren dort unter Einstellungen – MQTT-Einstellungen einen MQTT-Broker samt Topic. Das ist denkbar einfach, es muss nur die URL oder IP-Adresse des MQTT-Servers eingegeben werden und der Basis Topic (hier: dtu/open/). Die Möglichkeit einer Anmeldung mit Benutzername und Passwort ist optional. Der Standard-Netzwerk-Port für MQTT ist 1883.

Sobald die Einstellung gespeichert ist, wird OpenDTU versuchen, Daten an den MQTT-Broker zu liefern und zwar alle 5 Sekunden. Wie das aussieht und was alles an Daten ankommt zeigt das Bild rechts. dtu/open/ war der konfigurierte Basis Topic, die gesamte Datenstruktur darunter stammt von OpenDTU und sie wird ständig aktualisiert.

Der interessierte Subscriber kann sich nun aussuchen, welche einzelnen Sub-Topics er für seine Zwecke abonnieren möchte, ohne sich mit dem ganzen Rest zu belasten. Ein Subscribe auf die DC-Leistung des ersten Solarmoduls (hier 30,40W) würde also hier im Beispiel auf den Topic dtu/open/11218/1/power gehen. (Die Seriennummer des Wechselrichters, IP und Hostname habe ich hier aus Datenschutzgründen gekürzt oder gelöscht.)

Weiter erkennt man, dass es unter dtu noch einen Topic ahoy gibt mit zusätzlichen 32 Unter-Topics. Es lässt sich also mit den Topics eine schön geordnete Datenstruktur aufbauen.

Beispiele

Ich hatte es in meinem Artikel über Ahoy und OpenDTU erwähnt, dass diesen DTUs im Gegensatz zum Original der Zugang zur Hoymiles Cloud fehlt und damit auch eine grafische Darstellung des Leistungsverlaufs zum Beispiel. Wie wäre es nun, wenn wir mit Hilfe von MQTT und einigen anderen Tools eine eigene Lösung für die grafische Darstellung der Balkonkraftwerksdaten erstellen?

Grafana Server für das Balkonkraftwerk

Der Grafana Desktop ist eine mächtige Plattform zur Visualisierung von allen möglichen Daten aus dem Bereich des Internet-of-Things, warum also nicht auch für ein Balkonkraftwerk. Hier ein Bild, wie das aussehen könnte.

Was braucht man dazu?

Neben einer Datenquelle (einer DTU oder einem Shelly) ist vor allem ein Server erforderlich. Das kann beispielsweise ein Raspberry Pi sein, oder auch eine virtuelle Linux-Maschine auf einem PC. Weiter werden folgende Softwareprodukte benötigt (alle kostenlos unter Linux im Internet herunterladbar und als Docker-Images installierbar):

• Mosquitto als MQTT-Broker,
• Node Red als grafische Programmierumgebung,
• InfluxDB als Zeitreihen-Datenbank und
• Grafana für die Grafik.
• Zusätzlich als Empfehlung den MQTT Explorer um einen Einblick in die MQTT-Strukturen zu erhalten

Installation

Eine Installationsanleitung für die fünf eben genannten Softwareprodukte würde den Umfang dieses Artikels bei weitem sprengen, deshalb verweise ich zu diesem Zweck auf ein sehr gutes Youtube-Video von Dennis Schröder bei „Raspberry Pi Cloud“:

TUTORIAL: Shelly und Tasmota mit MQTT, Node-Red, InfluxDB ins Grafana Dashboard – Balkonkraftwerk

Zu diesem Video muss ich allerdings ergänzen, dass in der aktuellen Version von Mosquitto (im März 2023) anonyme MQTT-Clients (also ohne Usernamen und Passwort) nur zulässig sind, wenn dies in der Mosquitto Konfiguration explizit erlaubt wurde. Und das machen wir durch Editieren der mosquitto.conf Datei wie folgt:

sudo nano /var/lib/docker/volumes/mosquitto_conf/_data/mosquitto.conf

In der Datei folgende Zeilen suchen und das voranstehende # Zeichen entfernen, so dass die Statements wirksam werden:

• listener 1883
• allow_anonymous true

Strg-x zum Beenden, j zum Speichern und Enter zum bestätigen des Dateinamens. Alles Weitere wird im Video wunderbar erklärt.

Iobroker als Einstieg in die Hausautomation

Ein weiteres Beispiel, wie sich MQTT-Daten aus DTUs, Shellies und anderen Geräten weiterverarbeiten lassen, ist iobroker. Iobroker ist eine Plattform für die Hausautomation, in die sich über viele verschiedene Adapter unterschiedliche Geräte, Systeme und auch Visualisierungen einbinden lassen. Auch Automatisierungen sind mit iobroker sehr einfach möglich, wie wir noch sehen werden.

Was braucht man dafür

Auch für iobroker ist ein eigener Server in Form eines Raspberry Pi oder einer virtuellen Maschine erforderlich. Dazu folgende Softwareprodukte, wobei einige nur Beispiele sind und es dazu auch Alternativen gibt:

• iobroker selbst
• in iobroker der Adapter Javascript, mit dem auch visuell über Blockly programmiert werden kann
• in iobroker der Adapter MQTT als MQTT Broker
• in iobroker der Adapter für Influxdb
• in iobroker der Adapter Jarvis als Visualisierung (alternativ auch Vis)
• Influxdb als Datenbank

Zentrale Objektdatenbank, Programmierung und Visualisierung in iobroker

Für die Installation von iobroker und den benötigten Adaptern gibt es zahlreiche Videos im Internet. Der Vorteil von iobroker im Vergleich zur oben dargestellten Lösung mit Mosquitto ist, dass mit iobroker der MQTT-Broker, die Programmierung, die Datenspeicherung und die Visualisierung an einer Stelle zusammengeführt werden. Alle Daten liegen zentral und gemeinsam in einer Objektstruktur, egal ob sie von MQTT stammen, aus anderen Datenquellen oder ob sie von Hand erstellt wurden. Wir haben immer eine gemeinsame Hierarchie aller Objekte und können direkt dort mit einem Klick für jedes Objekt entscheiden, ob eine Langzeitdatenhaltung in Influxdb erfolgen soll. Bei Mosquitto mussten wir bereits dafür in Node Red programmieren.

Oben sieht man das Beispiel einer Visualisierung mit Jarvis. Dort fließen die Daten aus OpenDTU und eines Shelly Plus 1PM ein. Jarvis ist ein Visualisierungs-Adapter in iobroker, er ist relativ einfach gehalten und durch sein reponsible design automatisch auch fürs Smartphone geeignet. Standardmäßig wird in iobroker der Adapter Vis zur Visualisierung verwendet. Mit dem ist wirklich alles möglich inclusive der Einbindung eigener Grafiken und freier Positionierung aller Elemente. Vis ist allerdings auch sehr komplex. Beiden ist gemeinsam, dass (im Unterschied zu Grafana) auch Steuerelemente möglich sind, die Lampen oder Shellies aus der Visualisierung heraus steuern lassen.

Rechts ist ein Beispiel einer Blockly-Programmierung innerhalb von iobroker dargestellt. Hier habe ich die Waschmaschinen-Steuerung aus Teil 7 dieser Artikelreihe mit Blockly umgesetzt anstelle von Shelly Szenen. Blockly ist quasi eine grafische Oberfläche zu Javascript. Die einzelnen Programmelemente können aus einem Vorrat ausgewählt und dann nach Wunsch in einander verschachtelt werden. Blocky generiert daraus dann Javascript Code, der sofort und ständig in iobroker ausgeführt werden kann.

MQTT versus proprietärer Benutzeroberflächen

Shellies und DTU bringen alle ihre eigenen Bedien- und Visualisierungsoberflächen mit, die keinesfalls schlecht sind. Warum sollte man also die Daten der Geräte per MQTT verschicken, um sie dann woanders anzuzeigen? Hier einige gute Gründe für MQTT:

• Der MQTT Broker kann Daten von ganz unterschiedlichen Systemen zusammenführen.
• Auf einen MQTT Broker können unterschiedliche Systeme zur Speicherung, Verarbeitung oder zur Visualisierung der Daten zugreifen.
• Ein eigener MQTT Broker hält die Daten im eigenen Netzwerk, es gehen keine Informationen in fremde Clouds (Stichwort Datenschutz).
• Sensoren ohne eigene Datenhaltung (das sind Ahoy und OpenDTU und die meisten Shellies, wenn man die Shelly Cloud nicht betrachtet) können durch MQTT und eine dahinter liegende Datenbank eine History für ihre Daten bekommen.

REST-API – Representational State Transfer Application Programming Interface

Was ist die REST-API

Representational State Transfer (REST) ist eine Möglichkeit der Maschine-zu-Maschine-Kommunikation. Dabei setzt REST auf das HTTP-Protokoll, also das selbe Protokoll, das wir im Webbrowser verwenden um einen Web-Server abzufragen. Das ist wohl auch ein Grund, warum OpenDTU diese Schnittstelle Web API nennt und nicht REST-API. Betrachten wir hier Web API einfach als Subset einer vollständigen REST-Implementierung – gemeint ist im Balkonkraftwerk-Umfeld immer das selbe, die Abfrage eines Geräts über das HTTP Protokoll.

Das schöne an REST ist, dass wir die Abfragen (zumindest was die GET-Methode angeht) auch im Browser machen können. Dazu gleich ein Test mit folgender Eingabe in der URL-Zeile im Browser:

http://192.168.0.33/api/livedata/status

Wobei 192.168.0.33 die IP-Adresse einer OpenDTU ist. Das Ergebnis sieht dann aus wie im Bild rechts. Dazu zwei Anmerkungen:

• Den blau hinterlegten Topic 0 habe ich eingeklappt, dahinter verbirgt sich eine Unmenge an weiteren Informationen, die ich aus Platzgründen hier verborgen habe.
• Nicht jeder Browser stellt JSON-Daten so schön strukturiert dar, wie Firefox, möglicherweise werden die Daten auch in Rohform angezeigt.

Alle Shelly Geräte, Ahoy- und OpenDTU und viele weitere Geräte bieten eine REST API an, über die sie ausgelesen und auch gesteuert werden können. Die Befehls- ebenso wie die Datenstruktur unterscheiden sich allerdings von Gerät zu Gerät.

REST (Web) API Befehlsumfang

Hier eine kurze Linksammlung zu den entsprechenden Dokumentationen:

• Shelly API Doku, unterschieden nach Shelly Geräten der ersten und der zweiten Generation
• Doku der Web API von OpenDTU
• Bei AhoyDTU findet man die REST API Aufrufe im Ahoy-Menü unter REST API

Was unterscheidet REST von MQTT?

Beides sind Kommunikationsprotokolle mit denen wir an die Daten von Shellies und DTUs kommen können und über die diese Geräte auch gesteuert werden können. Dabei werden allerdings unterschiedliche Wege gegangen. Bei MQTT gibt es einen zentralen Server, den MQTT Broker, an den die Daten geschickt werden und von dem sie dann bezogen werden können. Bei REST gibt es keine zentrale Instanz, hier wird immer direkt mit dem entsprechenden Gerät kommuniziert. Das ist unkompliziert und schnell, der Client muss aber die Adressen der Geräte kennen, die er ansprechen will, er kann sich nicht einfach aus dem Datenreservoir eines Brokers bedienen. Und der Client muss das Gerät aktiv pollen, also von sich aus immer wieder ansprechen, wenn er aktualisierte Daten möchte.

Ein Praxisbeispiel

Das folgende Python-Script ist wieder die Waschmaschinenautomatisierung, die ich oben bereits in iobroker-Blockly realisiert hatte. Diesmal erfolgt die Abfrage der Solarleistung allerdings nicht von einem Shelly Plus 1PM sondern von einer AhoyDTU.

import time
import requests
EINSCHALTSCHWELLE = 100

while True:
 try:
  dtu = requests.get("http://192.168.0.36/api/live")
  shelly = requests.get("http://192.168.0.25/relay/0")
 except:
  print("Kommunikationsfehler bei der Abfrage von DTU oder Shelly")
  continue

 if dtu.json() is None: continue
 if shelly.json() is None: continue
 leistung = dtu.json()["inverter"][0]["ch"][0][2]
 schalter = shelly.json()["ison"]
 print(f"Solarleistung: {leistung:5.1f} W, Schalterstatus: {schalter}")

 if not schalter and leistung > EINSCHALTSCHWELLE:
  try:
   requests.get("http://192.168.0.25/relay/0?turn=on")
  except:
   print("Kommunikationsfehler beim Einschalten der Waschmaschine")
   continue
  print("Waschmaschine eingeschaltet")
 time.sleep(0.5)

Um HTTP-Abfragen absetzen zu können verwende ich das Modul requests und die EINSCHALTSCHWELLE definiert die Leistung in Watt, bei der die Waschmaschine eingeschaltet werden soll. In einer großen Endlos-While-Schleife habe ich drei Blöcke:

Im ersten Block wird von der AhoyDTU die Live-Datenstruktur abgerufen und gleich danach vom Shelly Plug S der Zustand des Relay 0.

Im zweiten Block werden die abgerufenen Daten geprüft, ob überhaupt Inhalte geliefert wurden und dann werden aus den JSON-Datenstrukturen die Daten extrahiert, die hier von Interesse sind. Das ist bei der DTU die aktuelle Leistung in Watt und beim Shelly der Zustand des Schalters (also des Relais), der ist entweder False oder True. Per print werden diese Daten ausgegeben.

Im dritten Block erfolgt die Ausscheidung, ob der Schalter aus ist und gleichzeitig die aktuelle Leistung den Schwellwert überschreitet. Nur in diesem Fall wird am Shelly das Relais geschlossen und die Waschmaschine läuft an. Andernfalls, also wenn die nötige Leistung nicht erreicht ist, oder wenn die Waschmaschine bereits läuft, passiert nichts. Nach einer halben Sekunde Zeitverzögerung wiederholt sich der ganze Vorgang.

Die try-except Klammerungen dienen nur dazu, dass das Script nicht mit Fehler abbricht, wenn bei der Kommunikation über das Netzwerk etwas schief geht.

Weitere Artikel in dieser Kategorie:

• Balkonkraftwerk Teil 1: Solaranlage für den Eigenbau
• Balkonkraftwerk Teil 2: Hardware und Aufbau
• Balkonkraftwerk Teil 3: Planung eines eigenen BKWs
• Balkonkraftwerk Teil 4: Passende Komponenten finden
• Balkonkraftwerk Teil 5: Elektrotechnik Grundlagen für Balkonkraftwerker
• Balkonkraftwerk Teil 6: Monitoring
• Balkonkraftwerk Teil 7: Steuerung der Waschmaschine
• Balkonkraftwerk Teil 8: OpenDTU und AhoyDTU für Hoymiles Wechselrichter
• Balkonkraftwerk Teil 10: Home Assistant mit DTU und Shelly
• Balkonkraftwerk Teil 11: Visualisierung für AhoyDTU und OpenDTU mit Grafana
• Balkonkraftwerk Teil 12: Maximum Power Point Tracking MPPT
• Balkonkraftwerk Teil 13: Parallel- und Reihenschaltung
• Balkonkraftwerk Teil 14: Verschattung
• Balkonkraftwerk Teil 15: Ost-West-Ausrichtung
• Balkonkraftwerk Teil 16: Ost-West parallel oder in Reihe
• Balkonkraftwerk Teil 17: Ost-West, rechnet sich das?
• Balkonkraftwerk Teil 18: Ost-West – die ultimative Anleitung