Siemens, MQTT und API — einfach erklärt

MQTT ist ein leichtgewichtiges Nachrichten-Protokoll, das Messwerte automatisch von deiner Anlage an einen Sammelpunkt schiebt; eine API ist eine Schnittstelle, über die eine Software gezielt Daten anfragt oder Befehle sendet. Bei Siemens-Geräten wie SIMATIC-Steuerungen begegnen dir beide — hier erfährst du direkt, was sie unterscheidet und wann du welches nimmst.

MQTT (Message Queuing Telemetry Transport) ist ein sparsames Publish/Subscribe-Protokoll: Ein Gerät (Publisher) sendet einen Messwert unter einem "Topic" an einen Broker (Vermittler), und alle, die dieses Topic abonniert haben (Subscriber), bekommen den Wert automatisch. Ein Topic ist wie eine Adresse mit Ebenen, z. B. anlage/bhkw/leistung/json. Du fragst nicht ab — die Daten kommen von selbst, sobald sich etwas ändert. Genau das macht MQTT ideal für viele Sensoren mit wenig Bandbreite.

Eine API (Application Programming Interface) ist eine definierte Schnittstelle, über die zwei Programme miteinander reden. Die häufigste Form ist eine REST-API über das Web (HTTP): Deine Software stellt eine Anfrage ("Gib mir die Leistung von jetzt") und bekommt eine Antwort zurück. Anders als MQTT ist das ein aktives Frage-Antwort-Spiel — du fragst, wenn du etwas wissen willst.

Faustregel: MQTT für laufende Live-Daten, die "gepusht" werden sollen (Leistung, Zählerstände, Zustände sekündlich/minütlich). API für gezielte Einzelabfragen oder Aktionen ("hol mir den Tagesbericht", "setze diesen Sollwert"). MQTT ist ereignisgesteuert und dauerhaft, eine REST-API ist anfragegesteuert und punktuell. In der Praxis kombiniert man beides: Messwerte laufen per MQTT rein, Auswertungen und Steuerbefehle laufen über die API.

Siemens-Steuerungen der SIMATIC-Reihe (etwa S7-1200/S7-1500) und Edge-Geräte (SIMATIC IOT-Serie) können MQTT-Nachrichten verschicken, sodass Prozessdaten an einen Broker fließen. Zusätzlich bietet Siemens für seine Cloud-/Edge-Plattform (Insights Hub, früher MindSphere) REST-APIs zum Abrufen und Verwalten von Daten. Neben MQTT und API ist bei Siemens auch OPC UA verbreitet — ein weiteres Standardprotokoll für die Maschinenkommunikation. Prüfe bei deinem konkreten Gerät immer die Doku, welche dieser Wege freigeschaltet sind.

Ein typischer Weg: Die Anlage (z. B. BHKW, Wechselrichter, Zähler) sendet ihre Werte per MQTT unter Topics wie anlage/bhkw/json an einen Broker. Ein kleiner Dienst abonniert diese Topics und schreibt die Werte in eine Datenbank; von dort holt sich ein Dashboard oder Optimierer die Daten über eine API. So läuft Telemetrie kontinuierlich rein (MQTT), während Berichte, Abrechnung oder Steuerbefehle gezielt über die Schnittstelle (API) laufen — beide ergänzen sich, statt sich zu ersetzen.

MQTT und APIs übertragen deine Betriebsdaten — sichere sie ab. Nutze verschlüsselte Verbindungen (TLS), vergib eigene Benutzer/Passwörter oder Tokens statt offener Zugänge und öffne nur die Ports, die du wirklich brauchst. Bei Steuerbefehlen (Schreibzugriff) gilt besondere Vorsicht: Trenne Lese- und Schreibrechte und protokolliere, wer was gesendet hat. So bleibt aus "einfach erklärt" auch "sicher betrieben".

→ Passend dazu: zendure mqtt

→ Passend dazu: mqtt port

→ Passend dazu: redispatch 2.0 einfach erklärt

MQTT ist ein schlankes Publish/Subscribe‑Protokoll: Ein Gerät (der Client) veröffentlicht Messwerte unter einem "Topic" an einen zentralen MQTT‑Broker, andere Systeme abonnieren dieses Topic und bekommen die Daten in Echtzeit. Und ja – aktuelle Siemens‑Steuerungen der Reihen S7‑1200 und S7‑1500 können als MQTT‑Client arbeiten. Sie brauchen dafür keine fremde Hardware, sondern nutzen die offene Kommunikation über TCP (Open User Communication) zusammen mit der kostenlosen Siemens‑Bibliothek "LMQTT_Client", die du im TIA Portal einbindest. Ältere S7‑300/400 sprechen MQTT nicht direkt – hier setzt du ein kleines Gateway (z. B. einen IoT‑Router oder Raspberry Pi) davor, das die SPS‑Werte per S7‑ oder Modbus‑Protokoll ausliest und als MQTT weiterreicht.

So bindest du eine S7 konkret an: 1) Einen MQTT‑Broker bereitstellen – im einfachsten Fall Mosquitto auf einem kleinen Server oder Pi. 2) Im TIA Portal die LMQTT‑Bibliothek importieren, den Client‑Baustein in einem Funktionsbaustein aufrufen und dort Broker‑IP, Port (1883 unverschlüsselt bzw. 8883 mit TLS) und eine eindeutige Client‑ID hinterlegen. 3) Die Topics festlegen und die gewünschten SPS‑Variablen – etwa Zählerstände, Leistung oder Temperaturen – als Payload (üblicherweise im JSON‑Format) publishen. 4) Auf der Gegenseite abonniert der Empfänger den Broker; beim Stromfee Tagebuch landen die Werte so über den Broker automatisch in der Zeitreihen‑Datenbank und stehen zur Auswertung bereit. Damit hängt deine Siemens‑Anlage ohne Cloud‑Zwang und mit minimaler Last an deinem Energiemonitoring.

MQTT ist ein schlankes Publish-/Subscribe-Protokoll: Ein Gerät schickt seine Werte unter einem Topic an einen Broker, und alle Systeme, die dieses Topic abonniert haben, bekommen sie zugestellt — niemand muss die Steuerung zyklisch abfragen. Die ehrliche Antwort auf „Siemens MQTT" lautet: Ab Werk spricht eine Siemens-S7 kein MQTT. Es gibt keinen Haken im TIA-Portal, den du setzt, und danach publiziert die CPU. Du hast genau zwei Wege. Weg A: Du holst dir einen MQTT-Client-Baustein ins Projekt — für S7-1200 und S7-1500 stellt Siemens eine offene Bibliothek bereit, die auf den offenen TCP-Kommunikationsbausteinen aufsetzt; die Steuerung wird damit selbst zum MQTT-Client. Weg B: Du stellst ein Gateway oder Edge-Gerät daneben, das die SPS über die S7-Kommunikation oder über deren OPC-UA-Server ausliest und die Werte als MQTT weitergibt. Für ältere S7-300/400 bleibt praktisch nur Weg B, weil dort die nötige Client-Funktionalität in der CPU fehlt. Weg A spart Hardware, kostet aber SPS-Zykluszeit und einen Eingriff ins laufende Anlagenprogramm — Weg B lässt die Steuerung unangetastet und ist deshalb im Bestand meist der ruhigere Weg.

Konkret gehst du so vor. Erstens: Broker festlegen — im Werk oder extern — und dir Adresse, Port und Zugangsdaten geben lassen; üblich sind Port 1883 unverschlüsselt und 8883 mit TLS, und wenn Daten das Werksnetz verlassen, nimmst du TLS. Zweitens: Datenpunkte definieren, bevor du Technik anfasst — welche DB-Variablen oder Merker, in welcher Einheit, in welchem Sendeintervall und ob zyklisch oder nur bei Wertänderung. Drittens: Topic-Struktur festlegen, typischerweise nach Standort/Anlage/Gerät/Messgröße, und den Inhalt als JSON mit Zeitstempel packen, damit der Empfänger nichts raten muss. Viertens: Zugriff klären — bei Weg B brauchst du je nach Verfahren die Freigabe des S7-Zugriffs beziehungsweise einen aktivierten OPC-UA-Server samt Benutzer, und die Firewall-Freigabe sollte nur ausgehend zum Broker gehen. Fünftens: den Störfall vorher regeln — Verhalten bei Verbindungsabriss, Last-Will-Nachricht, Retain-Flag und ob das Gateway Werte zwischenpuffert, solange der Broker weg ist. Sechstens die Gegenprobe: Abonniere dein eigenes Topic mit einem beliebigen MQTT-Client und vergleiche die ankommenden Werte gegen HMI-Anzeige oder Zählerstand. Erst wenn diese beiden Zahlen zusammenpassen, ist die Anbindung fertig — vorher hast du nur einen Datenstrom, aber noch keine belastbaren Messwerte.