Gateway 2.0 und MQTT-Unterstützung

Erfahren Sie, wie Sie die Verbindung zwischen MQTT und dem leistungsstärksten Gateway herstellen.

MQTT-Unterstützung des PHANTOM® Gateway 2.0

Das Gateway 2.0 aus dem drahtlosen Sensorsystem ERBESSD INSTRUMENTS® PHANTOM® sowie der kabelgebundene Monitor DEFIANT™ unterstützen das IoT-Protokoll MQTT. Alle Sensordaten sind über MQTT verfügbar, einschließlich Temperatur, Drehzahl, Frequenzbändern und Kennwerten der kabelgebundenen Kanäle, ebenso die vollständigen Zeitsignale der Schwingungssensoren (die FFT muss der Anwender aus dem Zeitsignal selbst berechnen).

Das Gateway arbeitet als MQTT-Client, der sich mit einem MQTT-Broker Ihrer Wahl verbindet, und veröffentlicht alles Erfasste als einfaches, selbstbeschreibendes JSON.

Sie können die MQTT-Unterstützung gleichzeitig mit allen anderen vom Gateway unterstützten Protokollen nutzen, darunter EI-Analytic™, EI Monitor, OPC UA und Modbus.

Einige der hier beschriebenen Optionen wurden in späteren Gateway-Versionen ergänzt. Wenn Sie eine davon in Ihrer Admin-Konsole nicht finden, aktualisieren Sie das Gateway auf die neueste Firmware.

Protokollunterstützung im Überblick

MQTT-Unterstützung aktivieren

Um die MQTT-Unterstützung in der Admin-Konsole des Gateway 2.0 zu aktivieren, schalten Sie sie auf der MQTT-Konfigurationsseite über das Kontrollkästchen „Enable MQTT connection“ ein.

Füllen Sie anschließend die Optionen Ihres MQTT-Brokers aus. Für die Verbindung zum MQTT-Broker unterstützen wir die folgenden Protokolle:

• mqtt://
• mqtts:// (verschlüsselt)
• ws:// (WebSocket)
• wss:// (WebSocket verschlüsselt)

Sie müssen den Hostnamen bzw. die IP-Adresse Ihres MQTT-Brokers, den Port und optional Benutzername und Passwort für die Authentifizierung eingeben.

Wenn Sie die vollständigen Zeitsignale der Schwingungssensoren empfangen möchten, aktivieren Sie das entsprechende Kontrollkästchen. Zeitsignale sind große Nachrichten; wenn Sie sie nicht verwenden möchten, können Sie die Option deaktiviert lassen.

Die Option „Allow Gateway management though MQTT“ erlaubt Ihnen, das Gateway und seine Sensoren über die MQTT-Verbindung mit der vollständigen Management-API zu steuern.

Nach dem Speichern der Einstellungen startet das Gateway 2.0 neu. Nach dem Neustart versucht es, sich mit dem MQTT-Broker zu verbinden, und zeigt bei Problemen im selben MQTT-Abschnitt oben einen Status an: connecting, connected, reconnecting, closed oder error, einschließlich der Fehlermeldung des Brokers, wenn die Verbindung abgelehnt wird.

Feldreferenz

Sicherheit: TLS und Authentifizierung

Wählen Sie mqtts:// oder wss://, um die Verbindung zu verschlüsseln. Die Auswahl Certificate validation steuert, wie das Broker-Zertifikat geprüft wird:

Das Feld Advanced nimmt ein Client-Zertifikat und den zugehörigen privaten Schlüssel entgegen, beide im PEM-Format, und wird nur mit mqtts:// oder wss:// verwendet. Genau das erwarten Broker, die eine X.509-Geräteidentität verlangen, etwa AWS IoT Core.

Benutzername und Passwort werden im CONNECT-Paket von MQTT übertragen. Über mqtt:// oder ws:// gehen sie im Klartext über die Leitung; kombinieren Sie Zugangsdaten daher immer mit mqtts:// oder wss://.

Der MQTT-Broker im Gateway

Die PHANTOM®-Gateway-Hardware kann außerdem einen eigenen eingebetteten MQTT-Broker betreiben, sodass eine SPS, ein SCADA oder eine Edge-Anwendung im selben Netz das Gateway ohne externe Infrastruktur direkt abonnieren kann. Beim USB-/PC-Gateway steht das nicht zur Verfügung. Aktivieren Sie ihn mit Enable local MQTT broker.

Der lokale Broker hat sein eigenes Publish Topic sowie eigene Schalter für Append serial, Zeitsignale, Komprimierung und Verwaltung, unabhängig von den Einstellungen des entfernten Brokers. Beide können gleichzeitig laufen: Dieselbe Messung wird dann an Ihren entfernten Broker und an den lokalen veröffentlicht.

mosquitto_sub -h <gateway-ip> -p 1883 -t "phantom/#" -v

Da der lokale Broker keine Authentifizierung hat, betreiben Sie ihn in einem vertrauenswürdigen OT-Netzsegment.

Topic-Struktur

Mit deaktiviertem Append gateway and sensor serial number as subtopics werden alle Nachrichten auf dem eingegebenen Publish Topic veröffentlicht.

Ist die Option aktiviert, baut das Gateway einen Topic-Baum auf. Mit dem Basis-Topic phantom, der Gateway-Seriennummer EIGW12345 und der Sensor-Seriennummer (phantomCode) 40217:

Abonnieren Sie alles mit phantom/#, ein einzelnes Gateway mit phantom/EIGW12345/# oder einen einzelnen Sensor mit phantom/EIGW12345/40217/#.

Unterscheiden Sie immer über das Feld dataType, nicht über das Topic. Wenn Append serial aus ist, treffen alle Nachrichtentypen auf demselben Topic ein.

Payload-Format

Das Gateway beginnt Nachrichten zu veröffentlichen, sobald ein Sensor seine Daten aktualisiert (in seinem eigenen internen Aktualisierungsintervall) oder eine Zeitsignalmessung erfolgt. Die Nachrichten sind UTF-8-JSON-Objekte, ein Objekt pro Nachricht. Nichts ist binär, proprietär oder von einer Schema-Registry abhängig: Sie können sie mit JSON.parse, json.loads, einem json-Node in Node-RED, dem json_v2-Parser von Telegraf oder jedem SCADA-JSON-Tag-Reader verarbeiten.

Für alle Nachrichten gelten zwei Regeln:

• Felder, die ein Sensor oder eine Firmware nicht liefert, werden weggelassen und nicht als null gesendet. Lesen Sie defensiv.
• timestamp ist Unix-Zeit in Sekunden, nicht in Millisekunden.

Gemeinsame Variablen aller Sensoren

Dies sind die Eigenschaften, die für jeden Sensortyp enthalten sind.

Triaxialer Beschleunigungssensor (3, 5, 6, 8 und 9)

Beispiel für eine stateupdate-Nachricht:

{
  "rssi": -63,
  "type": 6,
  "version": 195,
  "phantomCode": 40217,
  "gwSerial": "EIGW12345",
  "timestamp": 1756231043,
  "dataType": "stateupdate",
  "friendlyName": "Pumpe 3 - Motor AS",
  "seq": 184,
  "advFlags": 0,
  "batteryType": 1,
  "battery": 3.61,
  "temperature": 41.25,
  "updateInterval": 300,
  "txPower": 4,
  "minRMSFreq": 10,
  "maxRMSFreq": 1000,
  "rms": [1.42, 0.88, 2.07],
  "range": 16,
  "recordingSettings": 3,
  "minRMSFreqAccel": 1000,
  "maxRMSFreqAccel": 10000,
  "arms": [0.412, 0.298, 0.677]
}

Triaxialer Beschleunigungssensor mit dataType „collection“

{
  "serialNumber": 40217,
  "sampleRate": 3200,
  "gwSerial": "EIGW12345",
  "timestamp": 1756231043,
  "type": 6,
  "dataType": "collection",
  "friendlyName": "Pumpe 3 - Motor AS",
  "isAlarm": false,
  "rpm": 1478,
  "temperature": 41.25,
  "data": [
    [0.0123, -0.0044, 0.0187],
    [0.0091, 0.0102, -0.0058],
    [-0.021, 0.0176, 0.0031]
  ]
}

Die drei Sample-Arrays sind in diesem Beispiel gekürzt; eine echte Nachricht enthält die vollständige Aufzeichnung. Die Anzahl der Samples je Achse ist data[n].length, und die Dauer der Aufzeichnung in Sekunden ist data[n].length / sampleRate.

Nachricht der Frequenzbänder (dataType „bandsUpdate“)

Triaxiale Sensoren, die erweiterte Banddaten senden, veröffentlichen zusätzlich zur Statusaktualisierung ein bandsUpdate.

{
  "dataType": "bandsUpdate",
  "serialNumber": 40217,
  "phantomCode": 40217,
  "type": 6,
  "version": 195,
  "gwSerial": "EIGW12345",
  "timestamp": 1756231043,
  "seq": 184,
  "rpmMin": 1450,
  "rpmMax": 1495,
  "bands": [
    {
      "min": 1.0,
      "max": 2.5,
      "measurement": "velocity",
      "unit": "orders",
      "output": "rms",
      "values": { "x": 1.12, "y": 0.74, "z": 1.88 },
      "valueUnit": "mm/s"
    }
  ]
}

Nachricht der Wärmebildkamera (10)

Bei dataType: "stateupdate" meldet die Kamera avgImageTemperature, die mittlere Bildtemperatur in Grad Celsius.

Bei dataType: "collection" wird das vollständige Bild veröffentlicht:

{
  "phantomCode": 60912,
  "serialNumber": 60912,
  "gwSerial": "EIGW12345",
  "timestamp": 1756231400,
  "type": 10,
  "dataType": "collection",
  "columns": 32,
  "rows": 24,
  "frames": 1,
  "frameRate": 1,
  "data": [
    [
      [24.31, 24.55, 25.02],
      [24.28, 24.61, 25.14]
    ]
  ]
}

Nachricht des Thermoelement-Temperaturknotens (20, 21 und 22)

Nachricht des Infrarot-Temperaturknotens (25)

4-20-mA-Sensor (26) und Spannungsmesser (27)

Drehzahlsensor (RPM) (40)

Abstandssensor (50)

Universalmodul (60)

Stromsensor (30 und 32)

{
  "dataType": "stateupdate",
  "type": 32,
  "phantomCode": 51844,
  "gwSerial": "EIGW12345",
  "timestamp": 1756231102,
  "rssi": -71,
  "version": 118,
  "battery": 3.58,
  "batteryType": 4,
  "temperature": 33.1,
  "instCurrent": [12.4, 12.1, 12.8, 0.0],
  "averageCurrent": [12.3, 12.0, 12.7, 0.0],
  "minCurrent": [11.9, 11.6, 12.2, 0.0],
  "maxCurrent": [13.1, 12.9, 13.4, 0.0],
  "accumulatedCurrent": [842.5, 838.1, 851.9, 0.0],
  "accumulatedStart": 1753553200,
  "accumulatedEnd": 1756231102
}

Trockenkontaktsensor (31)

Kabelgebundene Kanäle des DEFIANT™

Die Kennwerte der kabelgebundenen Kanäle werden gemäß der Kadenz von Send wired channels overalls veröffentlicht (Never, As fast as possible oder begrenzt durch Wired overall send timeout). Im Payload beginnt wiredChannel bei 1, und es werden nur die Kennwerte aufgenommen, die für diesen Kanal tatsächlich berechnet werden.

{
  "dataType": "wiredOveralls",
  "wiredChannel": 1,
  "gwSerial": "EIDF98765",
  "timestamp": 1756231500,
  "sensorType": "accelerometer",
  "friendlyName": "Ventilator 12 - innen",
  "accel_rms": 0.482,
  "velocity_rms": 2.14,
  "displacement_rms": 18.7,
  "gE": 0.93,
  "rpm": 1786,
  "accel_truepeak": 1.84,
  "accel_peaktopeak": 3.52,
  "accel_kurtosis": 3.11
}

Verfügbare Schlüssel:

Solange sich der DEFIANT™ im Projektmodus (Route/Aufzeichnung) befindet, ist die Veröffentlichung von wiredOveralls ausgesetzt.

Kabelgebundene Zeitsignale werden als wiredCollection veröffentlicht, mit einem einzelnen data-Array, das bereits mit der Kanalkalibrierung und der Sensorempfindlichkeit skaliert ist:

{
  "dataType": "wiredCollection",
  "wiredChannel": 1,
  "gwSerial": "EIDF98765",
  "timestamp": 1756231500,
  "sensorType": "accelerometer",
  "sampleRate": 25600,
  "data": [0.0041, -0.0093, 0.0128]
}

Modbus- und benutzerdefinierte Tags

Werte, die das Gateway von Modbus-Geräten anderer Hersteller oder von kabelgebundenen benutzerdefinierten Einheiten liest, werden über MQTT als customUnitStateUpdate weiterveröffentlicht. units und values sind parallele Arrays, und ein Feld wiredChannel kommt hinzu, wenn der Wert von einem kabelgebundenen Kanal des DEFIANT™ stammt.

{
  "dataType": "customUnitStateUpdate",
  "gwSerial": "EIGW12345",
  "timestamp": 1756231600,
  "source": "gateway",
  "clientName": "Kompressor-SPS",
  "tagName": "DischargePressure",
  "functionType": "holdingRegister",
  "address": 40012,
  "byteOrder": "ABCD",
  "tagDataType": "float32",
  "machineCode": "COMP-01",
  "pointIndex": 2,
  "units": ["bar"],
  "values": [7.42]
}

Payload-Komprimierung

Die Option Compress (gzip) payload verpackt jeden JSON-Payload vor dem Veröffentlichen in einen gzip-Strom, was Zeitsignal-Nachrichten üblicherweise um 60 bis 80 % verkleinert. Der Payload besteht dann aus rohen gzip-Bytes, nicht aus Text, und muss vor dem Parsen dekomprimiert werden:

import gzip, json
import paho.mqtt.client as mqtt

def on_message(client, userdata, msg):
    raw = msg.payload
    if raw[:2] == b"\x1f\x8b":            # gzip-Magic-Number
        raw = gzip.decompress(raw)
    data = json.loads(raw)
    print(data["dataType"], data.get("phantomCode") or data.get("serialNumber"))

client = mqtt.Client()
client.username_pw_set("phantom", "ihr-passwort")
client.tls_set()                          # erforderlich für mqtts://
client.on_message = on_message
client.connect("broker.example.com", 8883)
client.subscribe("phantom/#", qos=1)
client.loop_forever()

Lassen Sie die Komprimierung aus, wenn Ihre Plattform Payloads nicht dekomprimieren kann; viele SCADA-JSON-Tag-Reader können das nicht.

Fernverwaltung über MQTT

Wird Allow Gateway management through MQTT aktiviert, abonniert das Gateway das Subscribe topic und führt die dort empfangenen JSON-Befehle aus. Antworten werden auf dem normalen Publish-Topic veröffentlicht, mit angehängtem /<gwSerial>, wenn Append serial aktiv ist. Jeder Befehl muss die Seriennummer des Ziel-Gateways in gwSerial enthalten; ein Gateway ignoriert Befehle, die an eine andere Seriennummer gerichtet sind.

Ein Zeitsignal von einem bestimmten Sensor anfordern:

{
  "type": "requestWaveform",
  "gwSerial": "EIGW12345",
  "phantomCode": 40217
}

Die Gateway-Management-API aufrufen:

{
  "type": "observeerequest",
  "gwSerial": "EIGW12345",
  "action": "getstate"
}

Das Gateway antwortet mit denselben JSON-Dokumenten, die die Admin-Konsole über WebSocket erhält, ergänzt um ein Feld gwSerial, damit Sie die Antworten zuordnen können. Das action-Vokabular deckt den vollen Funktionsumfang der Konsole ab, darunter getstate, deviceinfo, setbasicconfig, setfriendlyname, pair, unpair, restart, startfwupdate, getofflinefiles und wiredcollectnow. Wenden Sie sich an einen Support-Mitarbeiter von ERBESSD INSTRUMENTS®, um eine Kopie der Dokumentation der Management-API zu erhalten.

Dies ist ein privilegierter Steuerkanal. Aktivieren Sie ihn nur auf einem authentifizierten, TLS-geschützten Broker mit einer ACL, die einschränkt, wer auf dem Subscribe-Topic veröffentlichen darf. Lassen Sie ihn deaktiviert, wenn Sie nur Telemetrie benötigen.

MQTT-Version und Payload-Format

MQTT-Version. Der Client des Gateways verbindet sich auf Protokollebene 4, also MQTT 3.1.1. Das ist die interoperable Basis: MQTT-5.0-Broker akzeptieren 3.1.1-Clients, eine MQTT-5.0-Infrastruktur funktioniert also ohne Änderungen. Was die Gateway-Sitzung nicht nutzt, sind die 5.0-exklusiven Funktionen wie Shared Subscriptions, Topic-Aliase, Request/Response-Korrelationseigenschaften, Session-Ablauf und Reason Codes. Wenn Sie diese weiter hinten in der Kette brauchen, beenden Sie die 3.1.1-Sitzung des Gateways an Ihrem Broker und sprechen Sie 5.0 zwischen Broker und Anwendungen.

Ist der Payload proprietär? Nein. Es ist offenes JSON mit stabilen Feldnamen, oben vollständig dokumentiert. Zum Lesen sind weder eine Schema-Registry noch eine Lizenz oder ein SDK erforderlich.

Schnellstart mit mosquitto_sub

mosquitto_sub -h broker.example.com -p 8883 --cafile /etc/ssl/certs/ca-certificates.crt -u phantom -P "ihr-passwort" -t "phantom/#" -q 1 -v

Nur die schlanken Statusaktualisierungen filtern:

mosquitto_sub -h broker.example.com -t "phantom/+/+/stateupdate" -v