IFM-Sensoren und MQTT im industriellen Energiemonitoring: Was wirklich funktioniert
Die kurze Antwort: IFM-Sensoren sprechen von Haus aus IO-Link, kein MQTT – du brauchst dazwischen einen IO-Link-Master oder ein Edge-Gerät als Übersetzer. Hier siehst du, welche Kette in der Praxis stabil läuft und wo die typischen Stolperfallen liegen.
IFM-Sensoren (Strom, Durchfluss, Temperatur, Druck) liefern ihre Werte über IO-Link an einen IO-Link-Master. Erst der Master oder ein nachgeschaltetes Edge-Gerät veröffentlicht die Werte als JSON-Payload per MQTT an einen Broker. Direkt vom Sensor auf MQTT geht nicht – plan die Übersetzungsschicht von Anfang an ein. In unseren Anlagen läuft genau dieses Muster: Edge-Gerät sammelt, publiziert per MQTT zum zentralen Broker, von dort in die Zeitreihen-Datenbank (z. B. ClickHouse).
MQTT ist für Monitoring die richtige Wahl, weil es leichtgewichtig ist, mit instabilen Verbindungen umgeht (QoS, Retain, Last-Will) und viele Sensoren an einen Broker skaliert. Nutze pro Sensor/Anlage saubere Topic-Strukturen (z. B. `kunde/anlage/sensor/json`) und JSON-Payloads – so kann ein Bridge-Service die Nachrichten ohne Sonderlogik in die Datenbank schreiben. Für harte Regelaufgaben mit Millisekunden-Anspruch ist MQTT dagegen nicht gedacht; da bleibst du bei Feldbus/Modbus näher am Prozess.
Setz einen zentralen MQTT-Broker (z. B. Mosquitto) und einen schlanken Bridge-Service, der die abonnierten Topics in deine Zeitreihen-Datenbank schreibt. Bewährt: lokal rotierend puffern (InfluxDB oder SQLite auf dem Edge) und parallel per MQTT zentral spiegeln. Fällt die Leitung aus, gehen Werte nicht verloren, und der Bridge-Dienst holt nach. Ein eigener systemd-Service pro Bridge hält den Datenfluss überwachbar.
Leg pro Edge-Gerät fest: Broker-Adresse und Zugangsdaten (nie im Klartext im Code – Umgebungsvariablen nutzen), Topic-Präfix pro Kunde/Anlage, IO-Link-Master-Register bzw. Sensor-Zuordnung und Puffer-/Rotationsgrenzen. Vergib eindeutige Client-IDs, sonst werfen sich zwei Edge-Geräte gegenseitig vom Broker. Benenne Hostnamen sprechend (z. B. edge-<kunde>), damit du in großen Installationen die Quelle jeder Nachricht erkennst.
Vier Klassiker: (1) Erwartung, IFM spreche direkt MQTT – tut es nicht. (2) Doppelte Client-IDs führen zu ständigen Verbindungsabbrüchen. (3) Kein Retain/QoS gesetzt – nach Reconnect fehlen Werte. (4) Payload ohne Zeitstempel und Einheit – später nicht sauber auswertbar. Schreib Zeitstempel, Einheit und Sensor-ID immer in die JSON-Payload, dann bleibt die Datenbasis später belastbar.
Die Sensor-MQTT-Kette lohnt sich, sobald du mehrere Messpunkte über eine Anlage verteilst und zentral auswerten willst – Lastgänge, Blind-/Wirkleistung, Verbrauchsprofile. Für einen einzelnen Zähler ist es Overkill; ab mehreren Sensoren pro Standort spielt MQTT seine Skalierung aus. Starte mit einem Edge-Gerät, einem sauberen Topic-Schema und einem Bridge-Dienst, und wachse von dort.