MQTT, API und IoT-Protokolle: So sprechen deine Geräte miteinander

Dein Shelly 3EM misst den Stromverbrauch, dein OpenDTU kennt die Solarproduktion und Home Assistant soll beides zusammenbringen. Aber wie reden diese Geräte eigentlich miteinander? Hinter den Kulissen deines Smart-Home-Setups laufen Kommunikationsprotokolle, die den Datenaustausch regeln. Dieser Artikel erklärt dir die drei wichtigsten - MQTT, REST-API und Modbus - so, dass du verstehst, warum dein System funktioniert und fundiert entscheiden kannst, welches Protokoll du wofür brauchst.

TL;DR

• MQTT ist das Rückgrat der Balkonkraftwerk-Automatisierung: leichtgewichtig, schnell, zuverlässig
• REST-APIs eignen sich zum gezielten Abfragen von Daten - etwa vom Wechselrichter oder von Wetterdiensten
• Modbus ist der Industriestandard für Energiemessgeräte und größere Wechselrichter
• Für ein Balkonkraftwerk-Setup reicht in 90 Prozent der Fälle MQTT allein aus
• Du musst kein Protokoll-Experte werden, aber das Grundverständnis hilft bei der Fehlersuche enorm

Warum Protokolle wichtig sind

Stell dir vor, du hast drei Leute in einem Raum: Einen, der nur Deutsch spricht, einen, der nur Französisch kann, und einen, der Mandarin redet. Ohne gemeinsame Sprache oder Dolmetscher passiert nichts. Genau so ist es bei deinen Smart-Home-Geräten: Der Shelly spricht HTTP und MQTT, der Hoymiles-Wechselrichter funkt ein proprietäres Protokoll, Home Assistant versteht MQTT, HTTP und Dutzende andere Formate.

Die IoT-Protokolle sind die gemeinsame Sprache. Sie legen fest, wie Daten verpackt, adressiert und übertragen werden. Und sie bestimmen maßgeblich, wie schnell und zuverlässig dein System reagiert.

Für die Überschusssteuerung eines Balkonkraftwerks sind schnelle Reaktionszeiten entscheidend. Wenn zwischen der Messung eines Überschusses und dem Schalten einer Steckdose fünf Sekunden vergehen, ist das okay. Wenn es 30 Sekunden dauert, schaltet dein Boiler bei jeder Wolke zu spät ein und zu spät aus. Das richtige Protokoll macht den Unterschied.

MQTT: Das Arbeitstier

MQTT (Message Queuing Telemetry Transport) ist das mit Abstand wichtigste Protokoll für die Balkonkraftwerk-Automatisierung. Es wurde 1999 von IBM für die Kommunikation mit Ölpipeline-Sensoren entwickelt - also für Situationen, in denen Bandbreite knapp und Zuverlässigkeit lebenswichtig ist. Genau diese Eigenschaften machen es perfekt für Smart-Home-Anwendungen.

Wie MQTT funktioniert

MQTT arbeitet nach dem Publish-Subscribe-Prinzip. Es gibt drei Rollen: den Broker, die Publisher und die Subscriber.

Der Broker ist die Nachrichtenzentrale. Er nimmt Nachrichten entgegen und verteilt sie an alle Interessenten. In deinem Setup ist das Mosquitto - ein Open-Source-MQTT-Broker, der als Add-on in Home Assistant läuft oder standalone auf einem Raspberry Pi.

Ein Publisher ist ein Gerät, das Daten sendet. Dein OpenDTU veröffentlicht zum Beispiel alle paar Sekunden die aktuelle Leistung deines Wechselrichters auf dem Topic "solar/inverter/0/power". Dein Shelly 3EM veröffentlicht den Netzbezug auf "shellies/shellyem3/emeter/0/power".

Ein Subscriber ist ein Gerät, das Daten empfängt. Home Assistant abonniert beide Topics und bekommt jede Nachricht, sobald sie veröffentlicht wird.

Das Elegante an diesem System: Publisher und Subscriber kennen sich nicht. Dein OpenDTU weiß nicht, dass Home Assistant zuhört. Es veröffentlicht seine Daten einfach auf einem Topic, und jeder, der dieses Topic abonniert hat, bekommt sie. Du kannst jederzeit neue Geräte hinzufügen, ohne die bestehenden umkonfigurieren zu müssen.

Topics: Die Adresse der Nachricht

Topics sind hierarchisch aufgebaut, ähnlich wie Dateipfade. Zum Beispiel:

• solar/inverter/0/power - Leistung des ersten Wechselrichters
• solar/inverter/0/yieldday - Tagesertrag des ersten Wechselrichters
• solar/inverter/0/ch/1/power - Leistung des ersten Panels am ersten Wechselrichter

Der Broker speichert keine Nachrichten dauerhaft (außer du aktivierst "Retain"). Wenn Home Assistant gerade offline ist, verpasst es die Nachricht. Deshalb veröffentlichen die meisten Geräte ihre Werte alle paar Sekunden erneut. Mit der Retain-Flag bleibt die letzte Nachricht auf dem Topic erhalten - wenn Home Assistant neu startet, bekommt es sofort den letzten bekannten Wert.

QoS: Zuverlässigkeit in drei Stufen

MQTT kennt drei Quality-of-Service-Level:

QoS 0 (At most once): Die Nachricht wird einmal gesendet, ohne Bestätigung. Schnell, aber es kann passieren, dass sie verloren geht. Für Messdaten, die alle zwei Sekunden kommen, völlig ausreichend - wenn eine Nachricht fehlt, kommt zwei Sekunden später die nächste.

QoS 1 (At least once): Die Nachricht wird so lange gesendet, bis der Empfänger sie bestätigt. Kann zu Duplikaten führen, aber keine Nachricht geht verloren. Gut für Steuerbefehle.

QoS 2 (Exactly once): Jede Nachricht kommt genau einmal an. Das Protokoll ist aufwändiger (vier Nachrichten statt einer), aber garantiert keine Duplikate. Für Balkonkraftwerk-Anwendungen in der Regel nicht nötig.

In der Praxis nutzen die meisten Balkonkraftwerk-Geräte QoS 0 für Messdaten und QoS 1 für Steuerbefehle. Das ist ein guter Kompromiss zwischen Geschwindigkeit und Zuverlässigkeit.

MQTT in deinem Balkonkraftwerk-Setup

Konkret sieht der MQTT-Datenfluss so aus:

1. OpenDTU liest die Daten vom Hoymiles-Wechselrichter per Funk (nRF24L01 oder CMT2300A)
2. OpenDTU veröffentlicht die Daten per MQTT auf dem Broker (Mosquitto in Home Assistant)
3. Home Assistant abonniert die relevanten Topics und erstellt daraus Sensoren
4. Eine Automatisierung in Home Assistant prüft den Sensor-Wert
5. Home Assistant veröffentlicht einen Steuerbefehl per MQTT
6. Der Shelly Plug S empfängt den Befehl und schaltet den Verbraucher

Der gesamte Durchlauf von der Messung bis zur Schaltung dauert typischerweise unter einer Sekunde. Das ist schnell genug für jede Art von Überschusssteuerung.

MQTT einrichten: Die Kurzversion

In Home Assistant: Mosquitto-Add-on installieren, starten, MQTT-Integration hinzufügen. Der Broker lauscht auf Port 1883 (unverschlüsselt) oder 8883 (TLS-verschlüsselt). Für ein lokales Netzwerk reicht Port 1883.

In OpenDTU: Die IP-Adresse des MQTT-Brokers, Port, Benutzername und Passwort eintragen. Topic-Präfix setzen (z.B. "solar/"). Nach dem Speichern sollten die Daten sofort fließen.

Beim Shelly: In den Einstellungen unter "MQTT" die Brokeradresse eintragen und aktivieren. Der Shelly meldet sich mit seiner Geräte-ID an und veröffentlicht seine Daten automatisch.

REST-API: Daten auf Anfrage

Während MQTT ein Dauerkanal ist, über den Daten fließen, sobald sie entstehen, ist eine REST-API eher wie ein Informationsschalter: Du stellst eine Frage, du bekommst eine Antwort.

Wie REST-APIs funktionieren

REST (Representational State Transfer) ist das Protokoll des Internets. Jede Webseite, die du aufrufst, nutzt REST. Und genau so funktioniert es bei deinen Smart-Home-Geräten: Du sendest eine HTTP-Anfrage an eine URL und bekommst Daten zurück - typischerweise im JSON-Format.

Beispiel: Du willst den aktuellen Verbrauch deines Shelly 3EM wissen. Du rufst im Browser http://192.168.1.100/rpc/Shelly.GetStatus auf und bekommst eine JSON-Antwort mit allen Messwerten. Oder du fragst den OpenDTU-Status ab: http://192.168.1.101/api/livedata/status.

Wann REST statt MQTT?

REST-APIs sind ideal, wenn du Daten gezielt und einmalig brauchst - nicht als Dauerstrom. Typische Anwendungsfälle:

Wetterdaten abrufen: Forecast.Solar und Solcast liefern Ertragsprognosen über REST-APIs. Du fragst einmal pro Stunde ab und bekommst die Vorhersage für die nächsten Tage.

Dynamische Stromtarife: Die Tibber-API und die aWATTar-API liefern Börsenstrompreise per REST. Du fragst die Preise einmal am Tag ab und planst deine Verbrauchsstrategie.

Wechselrichter-Konfiguration: Über die REST-API von OpenDTU kannst du nicht nur Daten auslesen, sondern auch die Leistungsbegrenzung setzen - also deinen Wechselrichter drosseln. Das ist die Grundlage für die Nulleinspeisung.

Einmalige Statusabfragen: Das Shelly-Skript, das alle 10 Sekunden den Shelly 3EM nach dem aktuellen Netzbezug fragt, nutzt die REST-API. Es braucht keinen MQTT-Broker, keine permanente Verbindung - nur eine einfache HTTP-Anfrage.

REST vs. MQTT: Wann was?

Die Faustregel: MQTT für Echtzeit-Datenströme (Leistungswerte, die alle paar Sekunden kommen), REST für gelegentliche Abfragen (Wetterprognosen, Konfigurationsänderungen, Strompreise).

In der Praxis ergänzen sich beide Protokolle. OpenDTU liefert die Erzeugungsdaten per MQTT (Echtzeitstream) und bietet die Leistungsbegrenzung per REST-API (gelegentlicher Steuerbefehl). Der Shelly kann beides: MQTT für die Dauerüberwachung, REST für gezielte Abfragen und Befehle.

Modbus: Der Industriestandard

Modbus ist das Urgestein der industriellen Kommunikation - entwickelt 1979 von Modicon (heute Schneider Electric). Im Smart-Home-Bereich begegnest du Modbus vor allem bei professionellen Energiemessgeräten und größeren Wechselrichtern.

Modbus RTU vs. Modbus TCP

Es gibt zwei Varianten:

Modbus RTU nutzt eine serielle Schnittstelle (RS-485). Die Geräte sind per Kabel verbunden, die Kommunikation ist robust und störungsfrei. Im Balkonkraftwerk-Kontext findest du Modbus RTU vor allem bei professionellen Energiezählern und Hutschienen-Messgeräten. Die Einbindung in Home Assistant erfordert einen RS-485-zu-USB-Adapter (10 bis 20 Euro) oder einen Modbus-zu-MQTT-Gateway.

Modbus TCP läuft über das Netzwerk (Ethernet oder WLAN). Es ist einfacher einzubinden, da keine spezielle Hardware nötig ist - nur eine Netzwerkverbindung. Manche Smart Meter und Wechselrichter bieten Modbus TCP als Alternative zu MQTT oder REST.

Modbus im Balkonkraftwerk-Kontext

Für die meisten Balkonkraftwerk-Betreiber ist Modbus weniger relevant. Die gängigen Mikrowechselrichter (Hoymiles, Deye, APSystems) kommunizieren über WLAN, Funk oder Cloud - nicht über Modbus. Du stößt auf Modbus, wenn du:

• Einen professionellen Energiezähler (z.B. Eastron SDM630) einsetzen willst
• Einen Hybrid-Wechselrichter mit Modbus-Schnittstelle hast (SolarEdge, Fronius, SMA)
• Die evcc-Software (Ladesteuerung für Wallboxen) nutzt, die Modbus für die Wechselrichter-Kommunikation bevorzugt

Home Assistant hat eine eingebaute Modbus-Integration, die beide Varianten (RTU und TCP) unterstützt. Die Konfiguration ist allerdings technischer als bei MQTT: Du musst Register-Adressen, Datentypen und Abfrageintervalle manuell definieren.

Weitere Protokolle im Überblick

Neben den drei großen gibt es weitere Protokolle, denen du im Balkonkraftwerk-Umfeld begegnen kannst.

Websocket

Websocket ist eine Erweiterung von HTTP, die eine dauerhafte Verbindung zwischen Client und Server ermöglicht. Manche Wechselrichter-Weboberflächen nutzen Websocket für Live-Daten. Für die Integration in Home Assistant spielt Websocket eine untergeordnete Rolle - die meisten Geräte bieten MQTT oder REST als Alternative.

SML (Smart Message Language)

SML ist das Protokoll moderner digitaler Stromzähler in Deutschland. Wenn du einen IR-Lesekopf auf deinen Zähler klebst, liest er SML-Daten aus. ESPHome und Tasmota können SML dekodieren und die Werte über MQTT oder HTTP bereitstellen. Für dich als Nutzer ist SML transparent - du konfigurierst den IR-Lesekopf, und die Software macht den Rest.

Cloud-APIs der Hersteller

Hoymiles, Deye, APSystems und andere Hersteller bieten Cloud-Plattformen, über die du die Daten deines Wechselrichters abrufen kannst. Diese nutzen in der Regel REST-APIs, die allerdings nicht offiziell dokumentiert sind und sich ohne Vorwarnung ändern können. Für die Überschusssteuerung sind Cloud-APIs zu langsam (Verzögerung von 15 Sekunden bis mehrere Minuten) und zu unzuverlässig (abhängig von Internet und Herstellerserver).

Die klare Empfehlung: Nutze lokale Kommunikation (MQTT über OpenDTU oder direkte WLAN-Verbindung) statt Cloud-APIs. Das ist schneller, zuverlässiger und unabhängig von Dritten.

Protokolle in der Praxis: Drei Setups

Setup 1: Minimalistisch (nur REST)

Du hast einen Shelly 3EM und einen Shelly Plug S. Der Plug fragt alle 10 Sekunden per HTTP-API den 3EM nach dem Netzbezug ab und schaltet entsprechend. Kein Broker, kein Home Assistant, keine Cloud.

Vorteile: Einfach, robust, keine zusätzliche Hardware. Nachteile: Nur ein Verbraucher steuerbar, keine Protokollierung, keine Visualisierung.

Setup 2: Standard (MQTT mit Home Assistant)

OpenDTU sendet Erzeugungsdaten per MQTT an Mosquitto in Home Assistant. Der Shelly 3EM sendet Verbrauchsdaten per MQTT. Home Assistant kombiniert beides, berechnet den Überschuss und steuert smarte Steckdosen per MQTT.

Vorteile: Echtzeitfähig, erweiterbar, mit Visualisierung und Protokollierung. Nachteile: Braucht einen Raspberry Pi oder Mini-PC.

Setup 3: Fortgeschritten (MQTT plus REST plus Modbus)

Wie Setup 2, aber zusätzlich: REST-API-Abruf der Wetterprognose von Forecast.Solar, REST-API-Steuerung der Wechselrichter-Leistung über OpenDTU für Nulleinspeisung, Modbus-Anbindung eines professionellen Energiezählers mit Phasenauflösung.

Vorteile: Maximale Kontrolle, vorausschauende Steuerung, professionelle Messtechnik. Nachteile: Höherer Einrichtungsaufwand, mehr Fehlerquellen.

Fehlersuche: Wenn nichts ankommt

Das häufigste Problem bei der Ersteinrichtung: Daten kommen nicht an. Hier die typischen Ursachen.

MQTT-Verbindung prüfen

Starte mit dem MQTT Explorer (kostenlose Software für Windows, Mac, Linux). Verbinde dich mit deinem Broker und schau, welche Topics existieren und welche Daten fließen. Wenn du nichts siehst, stimmt entweder die Broker-Adresse im Gerät nicht, oder Benutzername/Passwort sind falsch.

Firewall und Ports

Port 1883 (MQTT) und Port 80 (HTTP) müssen im lokalen Netzwerk offen sein. Manche Router blockieren die Kommunikation zwischen WLAN-Geräten standardmäßig (Client Isolation). Prüfe die Router-Einstellungen, wenn Geräte sich sehen, aber nicht kommunizieren können.

DNS und IP-Adressen

Verwende feste IP-Adressen statt Hostnamen. Wenn dein OpenDTU "homeassistant.local" als Broker-Adresse hat, funktioniert das nur, wenn mDNS in deinem Netzwerk korrekt läuft. Mit einer festen IP (z.B. 192.168.1.100) umgehst du dieses Problem.

Welches Protokoll für welchen Zweck?

Die Entscheidung ist einfacher, als es klingt:

Für Echtzeit-Messdaten zwischen Geräten: MQTT. Für gelegentliche Datenabfragen und Konfiguration: REST-API. Für professionelle Energiemessgeräte und größere Wechselrichter: Modbus.

Und wenn du gerade erst anfängst: MQTT ist dein Freund. Es ist das Protokoll, das OpenDTU, Shelly, Tasmota und Home Assistant gemeinsam sprechen. Lerne MQTT, und du verstehst 90 Prozent der Kommunikation in deinem Balkonkraftwerk-Setup.