SIMATIC S7-1200 an MQTT anbinden – geht das?
Die S7-1200 hat keinen MQTT-Client ab Werk, kann MQTT aber trotzdem sprechen. Du hast zwei erprobte Wege: die kostenlose Siemens-Bausteinbibliothek LMQTT direkt in der SPS oder ein vorgeschaltetes Edge-Gateway.
Im Standard-Firmware-Umfang der S7-1200 ist kein MQTT enthalten. Siemens stellt aber eine kostenlose Bibliothek bereit (LMQTT_Client, Applikationsbeispiel-ID 109748872), die den MQTT-Client als Funktionsbaustein in dein TIA-Projekt bringt. Damit kann die S7-1200 selbst Nachrichten publizieren und Topics abonnieren – ohne zusätzliche Hardware.
Die Bibliothek nutzt die Offene Benutzerkommunikation (TCON/TSEND/TRCV) über TCP. Du lädst den LMQTT_Client-Baustein in dein Programm, hinterlegst Broker-IP und Port (Standard 1883), gibst Topic und Payload vor und rufst den FB zyklisch auf. Unterstützt werden Publish/Subscribe mit QoS 0 und 1. Achtung: Verschlüsselung (TLS/Port 8883) ist bei der S7-1200 stark eingeschränkt – für abgesicherte Verbindungen ist die S7-1500 oder ein Gateway die bessere Wahl.
Alternativ liest ein kleiner Rechner (Raspberry Pi, SIMATIC IOT2050) die S7-1200 per S7-Protokoll aus – z. B. mit python-snap7 – und veröffentlicht die Werte per MQTT an den Broker. Vorteil: TLS, Pufferung, JSON-Formatierung und Datenweiterleitung an eine Datenbank sind sauber lösbar, ohne das SPS-Programm zu belasten. So laufen bei uns viele Kunden-Anbindungen: SPS/Zähler → Gateway → MQTT → Datenbank.
Auf der Gegenseite steht ein MQTT-Broker, meist Mosquitto. Lege einen Benutzer mit Passwort an, öffne Port 1883 (bzw. 8883 mit TLS) und definiere eine klare Topic-Struktur wie werk1/s7-1200/temperatur. Halte Topics pro Anlage/Gerät eindeutig, dann lassen sich neue Datenpunkte später ohne Umbau ergänzen.
Für die Offene Benutzerkommunikation braucht die S7-1200 Firmware V4.0 oder neuer. Prüfe außerdem, ob deine TIA-Portal-Version zur Bibliotheksversion passt (die LMQTT-Bibliothek gibt es für mehrere TIA-Stände). Reserviere genügend Verbindungsressourcen: Jede TCP-Verbindung der CPU belegt einen der begrenzten Kommunikationskanäle.
Nur ein paar Werte an einen internen Broker senden, ohne Verschlüsselung? Dann reicht LMQTT direkt in der SPS. Sobald TLS, Cloud-Anbindung, viele Datenpunkte oder eine saubere JSON-Aufbereitung gefragt sind, ist das Edge-Gateway robuster und entlastet die CPU. Beide Wege lassen sich auch kombinieren.
Kurze Antwort: Die S7-1200 bringt keinen fertigen MQTT-Client mit. Ab Werk spricht die CPU PROFINET/S7-Kommunikation, optional Modbus TCP und die Open User Communication (TCON/TSEND/TRCV) über offene TCP-Sockets. MQTT ist genau darauf aufsetzbar — deshalb gibt es zwei ernsthafte Wege. Weg 1: Du bringst den MQTT-Stack als TIA-Bibliothek in die CPU (Siemens veröffentlicht dafür Client-Bausteine im Industry Online Support, ursprünglich für die S7-1500), die intern nichts anderes tun als CONNECT/PUBLISH/SUBSCRIBE-Pakete über die Open User Communication zu schicken. Das läuft, kostet aber Bausteinarbeit, Zykluszeit und Sorgfalt bei Reconnect und Keep-Alive; ob TLS möglich ist, hängt an CPU-Typ und Firmware-Stand und muss vor der Planung im Handbuch deiner konkreten CPU geprüft werden. Weg 2 — in der Praxis der robustere: ein kleines Gateway daneben (Raspberry Pi, Industrie-PC oder Siemens IOT-Gerät) liest die Werte aus der Steuerung und publiziert sie an den Broker. Die SPS bleibt dann unangetastet, und ein Netz- oder Broker-Ausfall bringt kein Anlagenprogramm in Schieflage.
Konkret für Weg 2, so binden wir es: In TIA einen Datenbaustein mit den Werten anlegen, die nach außen sollen (Leistung, Zählerstände, Störbits, Betriebsart). Beim Zugriff per S7-Protokoll (snap7/node-snap7, Node-RED-S7-Node) musst du am DB den "optimierten Blockzugriff" abwählen und in den CPU-Eigenschaften unter Schutz den PUT/GET-Zugriff für Kommunikationspartner erlauben — sonst liest das Gateway nichts. Alternativ, oft sauberer und versionsunabhängiger: Modbus-TCP-Server in der CPU projektieren und feste Register statt DB-Offsets herausgeben. Das Gateway pollt in einem für die Größe sinnvollen Takt (bei Energiewerten reichen Sekunden, nicht Millisekunden), packt jede Messstelle als JSON in ein eigenes Topic nach dem Muster anlage/bereich/gerät/json und veröffentlicht mit QoS 1, damit beim Reconnect nichts verloren geht. Zwei Regeln, die sich im Feld bezahlen: Der Broker gehört über TLS und eigene Zugangsdaten pro Gerät abgesichert, und Schreibbefehle zurück in die SPS gehen nicht ungeprüft per MQTT — dafür braucht es Freigabe-Bits, Grenzwerte und Quittierung in der Steuerung selbst, plus ein Audit-Log auf dem Gateway. Wenn du ohnehin einen Zähler oder Wechselrichter am Gateway hast, kannst du dieselbe Strecke mitnutzen; der MQTT-Pfad ist derselbe, nur ein Topic mehr.