Fragen Sie einen PLC-Verkäufer nach MQTT und Sie erhalten einen Fahrplan: "nächstes Jahr, vielleicht, beim Premium-Modell." Dann schauen Sie sich das Kleingedruckte an und finden ein Gateway, einen Konverter oder ein Cloud-Abonnement, das sich hinter der Funktion versteckt. Die MQTT-Unterstützung auf den xLogic Ethernet-CPUs hat nichts davon — sie ist seit der Revision 1.04 in der Firmware und veröffentlicht direkt vom Controller.
Das verändert, was eine Budgetmaschine tun kann, und die meisten Integratoren haben es nicht bemerkt.
Warum MQTT für einMicro PLC
MQTT ist genau für diese Situation gebaut: ein Gerät in einem unzuverlässigen Netzwerk, das kleine Nachrichten an einen Broker veröffentlicht, mit Abonnenten, die kommen und gehen. Eine Maschine in einer Fabrik, eine Pumpstation auf einem Feld, ein Gewächshaus zwei Stunden vom Büro entfernt — jede veröffentlicht ihren Status; das Cloud-Dashboard, die Telefon-App und der Laptop des Ingenieurs abonnieren alle dasselbe Thema. Kein Polling, keine offenen Ports in die Anlage, kein SCADA-Server, der die Verbindung überwacht.
Der Broker bewältigt das Chaos. Die PLC veröffentlicht einfach.
Was Sie tatsächlich konfigurieren
Die Verbindungsblöcke leben im Programm: Broker-Adresse, Thema, Veröffentlichungsintervall festlegen und festlegen, welche Werte in die Nutzlast gehen. Die CPU verwaltet den Verbindungslebenszyklus — Wiederverbindung nach einem Abbruch, erneutes Veröffentlichen nach einer Lücke — was der Teil ist, der handgefertigte Implementierungen killt.
Kombinieren Sie es mit dem Webserver und der Alarm-SMS, und Sie haben drei unabhängige Fernkanäle auf einem Controller. Cloud-Dashboard für das Büro, Browserseite für den Bediener, SMS für den diensthabenden Ingenieur. Wählen Sie Ihren Kanal je nach Publikum.
Echter Fall: Fernüberwachung von Gewächshäusern
Eine Baumschule mit vier Buchten wollte Cloud-Sichtbarkeit, ohne das Standortnetzwerk neu zu gestalten. Jeder Buchtencontroller veröffentlichte Temperatur, Luftfeuchtigkeit und Ventilstatus an einen Broker auf einem gemieteten VPS; ein einfaches Dashboard abonnierte und zeigte alle vier Buchten auf einem Bildschirm. Als das Internet an einem Nachmittag ausfiel, veröffentlichten die Controller weiterhin in eine lokale Warteschlange, und die Werte holten beim Wiederverbinden auf.
Die Zusammenfassung des Züchters, übersetzt aus Begeisterung: "Ich habe das Temperaturdiagramm von meinem Handy aus im Urlaub beobachtet. Es war besser, als dort zu sein."
Wo MQTT die falsche Antwort ist
Seien Sie ehrlich über Grenzen. MQTT ist ereignis- und telemetryorientiert — es ist kein deterministischer Regelkreis. Wenn Sie garantierte Lieferung und Millisekundenreaktion benötigen, verwenden Sie Modbus TCP lokal. MQTT ist für Überwachung und Berichterstattung, nicht für Sicherheitsverriegelung. Gestalten Sie es so, und es wird Ihnen jahrelang dienen.
Und halten Sie die Broker-Anmeldeinformationen klar. Eine PLC, die an ein öffentliches Thema veröffentlicht, ist eine PLC, die ihr Geschäft ausstrahlt. Private Themen, ein lokaler Broker oder mindestens TLS beim Broker — die Einrichtungskosten betragen Minuten, und die vermiedene Peinlichkeit ist real.
Das Muster, das es wert ist, gestohlen zu werden
Thema Design, das skalierbar ist
MQTT ist nur so sauber wie Ihre Themenstruktur, und die Themenstruktur ist der Ort, an dem kleine Projekte leise unüberschaubar werden. Der naive Ansatz — ein Thema pro Gerät, eine Nutzlast mit allem darin — funktioniert für eine Maschine und bricht bei zehn zusammen. Jeder Abonnent analysiert jede Nutzlast erneut, jede Änderung an der Nutzlast bricht jedes Dashboard, und das Debuggen wird zu einer Jagd von Thema zu Thema.
Gestalten Sie die Hierarchie vor der ersten Veröffentlichung. Ein Muster, das mir gut gedient hat:standort/gerät/kategorie/wert. Alsoplant1/pump1/status/run, plant1/pump1/sensor/level, plant1/pump2/alarm/high-level. Die Wildcard-Abonnenten — ein Dashboard für plant1, eine Seite für pump1, ein Alarmhörer für alles — abonnieren jeweils genau den Teil, den sie benötigen. Neue Geräte fügen sich ein, ohne die alten Themen zu berühren, und die Nutzlasten bleiben klein und typisiert.
Halten Sie die Nutzlasten einfach: ein Wert und ein Zeitstempel. Keine verschachtelten JSON-Blobs mit elf Feldern, es sei denn, Sie benötigen sie wirklich. Einfache Nutzlasten sind debugbar — Sie können eine im Broker-Konsolen lesen und sofort wissen, ob sie richtig ist. Und setzen Sie das Beibehalten-Flag bei Status-Themen, damit ein neuer Abonnent sofort den letzten bekannten Zustand sieht, anstatt auf die nächste Veröffentlichung zu warten. Der beibehaltene Zustand ist der Unterschied zwischen einem Dashboard, das sofort bereit ist, und einem, das minutenlang leer starrt.
Die letzte Regel ist die, gegen die sich die Leute wehren: versionieren Sie das Thema, wenn sich das Nutzlastformat ändert.plant1/pump1/status/v2. Es ist hässlich. Es schützt Sie davor, fünf Abonnenten in der Produktion mit einer Änderung zu brechen. Hässliche Themen, die funktionieren, schlagen saubere Themen, die explodieren.
Die Daten, die es wert sind, veröffentlicht zu werden
Alles zu veröffentlichen ist genauso schlecht wie nichts zu veröffentlichen — es überflutet den Broker, bläht das Protokoll auf und begräbt die Werte, die wichtig sind. Beginnen Sie mit der Frage, die der Abonnent stellen wird, nicht mit der Liste der Register. Ein Bediener möchte Status, Alarme und die laufenden Summen. Ein Ingenieur möchte Trends: Temperatur, Druck, Laufstunden. Ein Manager möchte Betriebszeiten und Zählungen. Veröffentlichen Sie diese und nur diese.
Raten sind ebenfalls wichtig. Alarmübergänge: sofort veröffentlichen, immer. Status: bei Änderung plus ein Herzschlag. Analoge Werte: in dem Intervall, das tatsächlich den Prozess zeigt — zehn Sekunden für eine langsame Gewächshaus-Temperatur, eine Sekunde für ein Werkzeugmaschinen. Jedes schnelle Thema, das Sie nicht benötigen, ist verschwendete Brokerlast und verschwendete SIM-Daten bei den drahtlosen Modellen.
Und protokollieren Sie die wichtigen auch lokal. Die Datenprotokollierung der CPU plus die beibehaltenen Nachrichten des Brokers gibt Ihnen zwei Kopien der kritischen Historie. Wenn der Broker einen schlechten Tag hat — das haben sie alle — ist das Maschinenprotokoll die Quelle der Wahrheit, und das Wiederherstellungsgespräch ist kurz.
Lokale Kontrolle auf der CPU, Cloud-Sichtbarkeit über MQTT, und die beiden stören sich nie. Diese Trennung ist die Architektur moderner kleiner Automatisierung, und sie passt auf eine DIN-Schiene. Der Fahrplan des Verkäufers ist nicht angekommen. Die Firmware wurde bereits ausgeliefert.
