SPS: MQTT oder Polling – was nimmst du für welche Daten?
Beim Polling fragt ein Master (deine SPS oder ein Gateway) jeden Datenpunkt in festen Zeitabständen aktiv ab – Request, Antwort, warten, wiederholen. Bei MQTT dreht sich das um: Das Gerät schickt seinen Wert von selbst an einen Broker, sobald er sich ändert oder ein Intervall abläuft, und alle Interessenten bekommen ihn zugestellt.
Für die schnelle Steuerungsschleife direkt an der Maschine (Regelung, Verriegelung, harte Zykluszeiten) nimmst du Polling – meist Modbus TCP/RTU. Für Monitoring, viele verteilte Sensoren und den Weg in eine Cloud oder Datenbank nimmst du MQTT. Beides schließt sich nicht aus: Sehr oft pollt ein Edge-Gateway die SPS lokal per Modbus und veröffentlicht die Werte dann per MQTT nach außen – genau so laufen bei uns z. B. der Modbus-Poller (`janitza-poller`) und der MQTT-Publisher parallel auf demselben Edge-Rechner.
Beim Polling bestimmt der Master das Timing. Er liest z. B. alle 1–5 Sekunden die Register ab – ob sich der Wert geändert hat oder nicht. Vorteil: vorhersehbar, einfach, keine zusätzliche Broker-Infrastruktur, und du merkst sofort, wenn ein Slave nicht antwortet (Timeout). Nachteil: Jede Abfrage kostet einen Roundtrip, auch wenn sich nichts geändert hat. Deine schnellste Reaktionszeit ist immer maximal dein Poll-Intervall, und bei vielen Slaves summiert sich die Zykluszeit. Typisch bei Modbus, klassischem OPC und den meisten Feldbussen.
MQTT ist Publish/Subscribe über einen Broker. Das Gerät (oder ein Gateway) publiziert auf ein Topic wie `standort/bhkw/leistung`, der Broker verteilt an alle Subscriber. Der große Hebel ist Report-by-Exception: Du sendest nur, wenn sich der Wert wirklich ändert. Das senkt die Netzlast deutlich und bringt Änderungen mit minimaler Latenz zu allen Empfängern gleichzeitig. QoS-Stufen (0/1/2) regeln die Zustellsicherheit, „Retained Messages“ liefern neuen Subscribern sofort den letzten Stand. Preis dafür: Du brauchst einen Broker, und die SPS selbst spricht oft kein MQTT – dann übersetzt ein Edge-Gerät.
Latenz bei Änderungen: MQTT nahezu sofort, Polling erst beim nächsten Zyklus. Netzlast: MQTT niedrig (nur bei Änderung), Polling konstant hoch. Determinismus/harte Echtzeit: Polling gewinnt, weil das Timing fest im Master liegt. Skalierung auf viele Datenpunkte/Standorte: MQTT gewinnt, weil Sender und Empfänger entkoppelt sind. Ausfallerkennung: Polling merkt Stille sofort per Timeout; bei MQTT brauchst du dafür Last-Will-Nachrichten oder Heartbeats. Infrastruktur: Polling braucht nichts extra, MQTT braucht einen Broker.
Moderne Steuerungen (z. B. viele Codesys-basierte, Siemens mit passender Bibliothek, Wago, Beckhoff) können MQTT direkt publizieren. Ältere oder einfache SPSen sprechen nur Modbus/Feldbus – dort setzt du ein kleines Edge-Gerät (Industrie-PC oder Raspberry Pi) davor, das per Polling liest und per MQTT weiterschickt. Das ist das gängigste Muster für Bestandsanlagen und genau der Weg, über den bei uns Loxone-Miniserver und Zähler ihre Werte an den Ingest-Hub liefern.
Trenne die zwei Ebenen sauber. Ebene 1 – Steuerung an der Maschine: Polling per Modbus, kurzes deterministisches Intervall, keine Cloud dazwischen. Ebene 2 – Monitoring, Datenhaltung, Fernzugriff, mehrere Standorte: MQTT mit Report-by-Exception, QoS 1 für wichtige Werte, Last-Will für Ausfallerkennung. Wenn du nur ein einzelnes Gerät lokal ausliest, ist Polling oft schon genug – MQTT lohnt sich, sobald mehrere Empfänger, mehrere Standorte oder eine Datenbank/Cloud ins Spiel kommen.