S7-1500 und MQTT — geht das direkt?
Kurz: Eine S7-1500 bringt MQTT nicht als fertigen Klick im TIA Portal mit — du musst es über eine Bibliothek nachrüsten oder ein Gateway davorsetzen. Welcher der drei Wege für dich passt, hängt davon ab, ob du in die SPS eingreifen darfst und ob TLS gefordert ist.
Die S7-1500 spricht von Haus aus S7-Kommunikation, PROFINET, OPC UA (lizenzpflichtig je nach CPU) und offene TCP/UDP-Verbindungen. MQTT ist keine eingebaute Funktion. Du hast drei praktikable Wege: (1) den MQTT-Client im SPS-Programm mit der kostenlosen Siemens-Bibliothek LMQTT_Client nachbauen, (2) ein Gateway/Edge-Gerät davorsetzen, das die SPS ausliest und selbst als MQTT-Client publiziert, (3) den Umweg über OPC UA mit einem OPC-UA-zu-MQTT-Bridge-Dienst. Weg 1 ist am saubersten, wenn du das SPS-Projekt anfassen darfst; Weg 2, wenn die Anlage nicht angefasst werden soll.
Siemens stellt im Support-Portal (SIOS) die freie Bibliothek LMQTT_Client bereit. Sie setzt intern auf die offene Kommunikation (TCON/TSEND/TRCV) auf und bildet Connect, Publish und Subscribe als Funktionsbausteine ab. Vorgehen: Bibliothek herunterladen und ins Projekt einbinden, einen Instanz-DB anlegen, Broker-IP/Port (1883 unverschlüsselt, 8883 mit TLS), Client-ID, User und Passwort parametrieren, Topic und Payload als String/Array of Byte übergeben und den Baustein zyklisch aufrufen. Wichtig: Prüfe im SIOS-Eintrag die geforderte Mindest-Firmware deiner CPU und TIA-Version — ältere CPUs und ältere TIA-Stände unterstützen nicht alle Funktionen, TLS erst ab neueren Firmware-Ständen.
Das ist der Weg, den wir bei Anlagen fahren, die im Bestand laufen und nicht neu programmiert werden sollen. Ein kleines Edge-Gerät liest die SPS über S7-Kommunikation (z. B. Snap7 oder der s7-Node in Node-RED) oder über Modbus TCP aus und publiziert die Werte als JSON auf Topics wie anlage/bhkw/1/json. Zwei Fallstricke: In der CPU muss unter Schutz/Sicherheit der Zugriff über PUT/GET erlaubt sein, und die zu lesenden Datenbausteine brauchen deaktivierten optimierten Bausteinzugriff — sonst hast du keine feste Absolutadresse zum Lesen. Vorteil: Das Gateway puffert bei Netzausfall, die SPS bleibt unberührt.
Wenn deine CPU eine OPC-UA-Server-Lizenz hat, kannst du die Variablen dort veröffentlichen und einen Bridge-Dienst (z. B. Node-RED, Telegraf oder ein Edge-Gerät) auf MQTT umsetzen lassen. Das lohnt sich, wenn ohnehin schon OPC UA genutzt wird oder mehrere Konsumenten unterschiedliche Protokolle brauchen. Nachteil: eine Schicht mehr, zusätzliche Latenz und je nach CPU Lizenzkosten für OPC UA.
Baue Topics hierarchisch nach Standort/Anlage/Gerät/json statt flach — das macht Wildcard-Abos später möglich. Publiziere JSON statt Rohbytes, dann kann jede Datenbank direkt andocken. Publiziere nicht im schnellen OB1-Zyklus: Ein Sende-Takt von 1 bis 60 Sekunden oder ereignisgesteuert bei Wertänderung (Deadband) reicht für Energie- und Zustandsdaten und hält die CPU-Last klein. Setze eine Last-Will-Nachricht (LWT), damit der Broker meldet, wenn die Anlage still wird.
Port 1883 ist unverschlüsselt — nur innerhalb eines geschlossenen Anlagennetzes akzeptabel. Sobald Daten über Internet oder VPN-Grenzen gehen, nimm 8883 mit TLS und Benutzer/Passwort je Anlage, nicht einen gemeinsamen Account für alle Standorte. TLS direkt aus der S7-1500 heraus hängt an der Firmware-Version deiner CPU; kann sie es nicht, terminiert das Gateway die Verschlüsselung. Gib jedem Client eine eigene Client-ID — doppelte IDs werfen sich gegenseitig vom Broker.