WAGO 750 mit MQTT: Was geht – und was nicht

Kurz vorweg: MQTT beherrschen nur die programmierbaren PFC-Controller der 750-Serie (PFC100/PFC200), nicht die einfachen Feldbus-Koppler. Steckt in deiner Station ein solcher Controller, kannst du deine I/O-Daten direkt an einen MQTT-Broker schicken.

Entscheidend ist der Kopf deiner Station. Ein reiner Feldbus-Koppler (z. B. der Ethernet-Koppler 750-352) spricht Modbus TCP bzw. EtherNet/IP – aber kein MQTT. MQTT liefern nur die Linux-basierten Controller PFC100 (Artikel 750-81xx) und PFC200 (750-82xx). Steht auf deinem Gerät 'PFC100' oder 'PFC200', bist du dabei. Steht dort nur 'Koppler'/'Coupler', brauchst du zusätzlich einen Controller oder ein Gateway davor.

Weg 1 – ohne Programmierung: Die PFC-Controller haben im Web-Based Management (WBM, die Browser-Oberfläche des Controllers) eine Cloud-/MQTT-Funktion. Dort trägst du Broker-Adresse, Port und Zugangsdaten ein, und der Controller publisht deine Prozessdaten. Weg 2 – mit CODESYS: Du programmierst den Controller in CODESYS und nutzt die MQTT-Bibliothek von WAGO, um Topics und Payload selbst zu bestimmen. Weg 1 ist schneller, Weg 2 gibt dir volle Kontrolle über Struktur und Zeitpunkt.

1) IP-Adresse des Controllers im Browser aufrufen und ins WBM einloggen. 2) Im Netzwerk-/Cloud-Bereich den MQTT-Broker eintragen: Host, Port (unverschlüsselt üblich 1883, mit TLS 8883), sowie Benutzer/Passwort bzw. Zertifikat. 3) Auswählen, welche Variablen/I/O gesendet werden und in welchem Intervall. 4) Verbindung speichern und den Status prüfen. Danach erscheinen die Werte am Broker – mit einem Tool wie MQTT Explorer kannst du direkt mitlesen.

Als Payload-Format hat sich JSON durchgesetzt, weil fast jedes Zielsystem (Datenbank, Dashboard, Gateway) es direkt weiterverarbeitet. Vergib klare, hierarchische Topics wie 'standort/wago01/messwert' statt kryptischer Kürzel – das erleichtert später das Filtern und Weiterleiten. Beim WBM-Weg gibt der Controller die Struktur teils vor; in CODESYS legst du Topic-Namen und JSON-Feldnamen komplett selbst fest.

Als Broker eignet sich ein lokaler Mosquitto genauso wie eine Cloud-Instanz. Für erste Tests reicht ein Mosquitto auf einem kleinen Server oder Raspberry Pi im selben Netz. Willst du die Daten weiterverarbeiten, hängst du hinter den Broker eine Bridge, die in eine Datenbank schreibt – so laufen bei uns die MQTT-Daten aus Feldgeräten am Ende in eine Zeitreihen-/Analyse-Datenbank.

Keine Daten am Broker? Prüfe der Reihe nach: richtiger Gerätetyp (PFC, nicht Koppler), passende Firmware auf dem Controller, offener Port (1883/8883) zwischen Controller und Broker, und korrekte Zugangsdaten. Bei TLS scheitert die Verbindung oft an einem falschen oder abgelaufenen Zertifikat. Und ein Klassiker: Der Broker verlangt Authentifizierung, im Controller ist aber kein Benutzer hinterlegt – dann bricht die Verbindung still ab.

Der Kernunterschied liegt in der Frage, wo der MQTT-Client sitzt. Bei WAGO-Controllern (750-8xxx / PFC200) ist MQTT kein fertiger Knopf, sondern eine Programmier-Aufgabe: Du bindest die MQTT-Bibliothek in CODESYS bzw. e!COCKPIT ein und mappst jeden Topic und jedes Payload per IEC-61131-3-Baustein selbst — oder du fährst auf dem PFC200 (Linux) einen eigenen Client im Container. Das bedeutet spürbaren Konfigurationsaufwand pro Datenpunkt, gibt dir aber die Freiheit, heterogene Feldebene (Modbus RTU/TCP, KNX, digitale/analoge I/O, Zählerpulse) in EINEM Controller zu sammeln und als konsolidierten MQTT-Strom herauszugeben. Genau hier skaliert WAGO stark: viele Signale unterschiedlicher Protokolle laufen über eine Steuerung zusammen, statt über viele Einzelgeräte. Gerätenahe Lösungen wie das Janitza UMG 96-EL oder Shelly EM3/EM3 Pro/Emonio arbeiten umgekehrt — sie bringen MQTT nativ mit, veröffentlichen ihre Messwerte direkt und werden über die Weboberfläche in Minuten eingerichtet (Broker, Topic, Intervall eintragen, fertig).

Für die Skalierung heißt das zwei unterschiedliche Muster. Native-MQTT-Geräte (Janitza, Shelly, Emonio) skalieren horizontal: Du hängst ein weiteres Gerät ins Netz, es publiziert sich selbst — minimaler Aufwand pro Messpunkt, aber jedes Gerät liefert nur, was es selbst misst, ohne Aggregations- oder Verrechnungslogik. WAGO skaliert vertikal: hoher Aufwand einmal beim Engineering, danach bündelt ein Controller viele Punkte, kann vor dem Publizieren rechnen/filtern/normieren und spricht auch Feldgeräte an, die von sich aus kein MQTT können. Die ehrliche Ja-Nein-Empfehlung: Willst du wenige, klar umrissene Messstellen (z. B. Einspeisung, ein paar Abgänge) schnell in den IoT-Datenfluss bekommen, ist ein natives Messgerät der geringere Aufwand und die robustere Wahl — Setup per Weboberfläche statt SPS-Projekt. Musst du dagegen eine gewachsene Anlage mit gemischten Protokollen und eigener Logik anbinden, rechtfertigt der höhere WAGO-Konfigurationsaufwand sich durch die bessere Skalierbarkeit über Datenpunkte und Protokolle hinweg. Faustregel: Gerätenativ, wenn 'messen und melden' reicht; WAGO, sobald 'sammeln, rechnen, übersetzen' dazukommt.

Der Unterschied liegt nicht in der MQTT-Qualität, sondern in der Rolle des Geräts. Ein WAGO 750-8xxx (PFC100/PFC200) ist ein Gateway mit programmierbarem MQTT-Client: Broker, Port, Topic, TLS und Zugangsdaten stellst du im Web-Based Management ein, aber welche Werte in welchem Payload rausgehen, baust du selbst im Steuerungsprogramm (CODESYS/e!COCKPIT) zusammen. Geräte mit firmware-nativem MQTT gehen den anderen Weg — der Janitza UMG 96-EL, Shelly EM3/EM3 Pro und Emonio veröffentlichen ihr Messdaten-Set ohne eine Zeile Code, dafür in der Struktur, die der Hersteller vorgibt. Konkret heißt das für den Konfigurationsaufwand: Beim nativen Gerät zahlst du pro Gerät (Formular ausfüllen, Broker eintragen, fertig), bei WAGO zahlst du einmalig für das Programm und danach fast nichts mehr, weil du das Projekt auf den nächsten Controller kopierst. Erste Anlage: WAGO ist deutlich aufwendiger. Zehnte Anlage: WAGO ist die geringere Arbeit — vorausgesetzt, du hast das Projekt als Vorlage sauber gehalten.

Bei der Skalierbarkeit zählt, was hinter dem MQTT-Client hängt. Der WAGO-Controller skaliert über Klemmen und Modbus: Er sammelt viele Messpunkte ein und veröffentlicht sie über eine einzige Broker-Verbindung mit einem Topic-Baum, den du selbst schneidest — du kannst also vorverdichten, Zykluszeiten drosseln und nur senden, was gebraucht wird. Native MQTT-Geräte skalieren linear: Jeder Zähler ist ein eigener Client mit eigenen Zugangsdaten, eigenem Topic und eigenem Sendetakt. Bei fünf Geräten ist das egal, bei fünfzig wird die Verwaltung von Credentials, Topic-Namen und Firmware-Ständen zur eigentlichen Arbeit — und Payload-Änderungen nach einem Firmware-Update triffst du auf der Empfängerseite, nicht am Gerät. Entscheidungsregel: Wenige Messstellen, Standardgrößen, kein SPS-Know-how im Haus — nimm die nativen Geräte. Viele Messpunkte pro Standort, gemischte Protokolle (Modbus RTU/TCP, S0, Digital-I/O), eigene Topic-Struktur oder Schaltbefehle in Gegenrichtung — nimm den WAGO-Controller als Sammler und lass die Feldgeräte über Modbus dranhängen. Mischbetrieb ist normal und kein Fehler: WAGO für die Anlagentechnik, native Zähler dort, wo nur ein Wert gebraucht wird.