MQTT-Node
Das Gateway startet einen eigenen HiveMQ-Broker auf derselben Maschine (Standard-Port 1883, TLS 1884). Standardmuster für die Verbindung mit externer SCADA / Cloud-IoT.
Broker-Verbindungsinformationen für Boxen ab 2026.05+
- Broker-URL:
tcp://127.0.0.1:1883(plain) /ssl://127.0.0.1:1884(TLS) - Username / Password:
app.propertiesdermqtt.server.user/mqtt.server.password— bei Produktions- boxen ist jedes Exemplar randomisiert (siehe/etc/kopens/credentials.txt). Der Entrypoint synchronisiert automatisch die HiveMQ auth.properties. - MQTT 5 Unterstützung (HiveMQ 2025.4): Retained / Will / Session Expiry / Shared Subscriptions als vollständige Funktion.
- Gemeinsame Nutzung des Brokers mit Sparkplug B — gleichzeitig
spBv1.0/#abonnieren und überwachen.
1. Node-Typen
| Node | Zweck |
|---|---|
mqtt in | Abonniert ein Topic — der Flow startet bei jedem eingehenden Message |
mqtt out | Veröffentlicht (publish) eine Message |
2. Broker-Server-Einstellungen — einmal erstellt, von allen Nodes gemeinsam genutzt
Doppelklicken Sie auf den mqtt in- oder mqtt out-Node → Stiftsymbol rechts im Server-Feld → neue Broker-Konfiguration.
| Tab | Element | Empfohlener Wert |
|---|---|---|
| Connection | Server | 127.0.0.1 (eigener HiveMQ des Gateways) oder externe Broker-IP |
| Port | 1883 (bei TLS 8883) | |
| Client ID | Leer lassen für automatische Generierung. In Produktionsumgebungen ist eine feste ID empfohlen (edge-<gateway-id>-flow1 etc.) | |
| Keep alive | 60 Sekunden empfohlen | |
| Use TLS | Bei externer Cloud-Verbindung einschalten | |
| Security | Username/Password | Bei Broker-Authentifizierung |
| Messages | LWT (Last Will) | edge/<id>/status Topic + Payload offline — automatische Benachrichtigung, wenn das Gateway plötzlich ausfällt |
| Messages | Birth | Bei Verbindung online retained auf edge/<id>/status veröffentlichen |
3. Veröffentlichen (mqtt out) — Szenario: Alle Tag-Werte in die Cloud
inject (1s) ──▶ 태그값 읽기 ──▶ change (topic 만들기) ──▶ mqtt out
change-Node:
| Aktion | Eigenschaft | Zu |
|---|---|---|
| Set | msg.topic | plant/${msg.payload.tag_id}/value (J-Expression ${...} oder mustache) |
| Set | msg.payload | { "ts": $millis(), "v": msg.payload.value, "q": msg.payload.value_read_status } (JSONata) |
mqtt out-Node-Einstellungen:
| Element | Wert |
|---|---|
| Topic | (leer lassen → msg.topic wird verwendet) |
| QoS | 1 (Zustellung garantiert) — für normale Telemetrie ist 0 auch in Ordnung |
| Retain | false (Echtzeitwerte) — bei Zustandsdaten true |
4. Abonnieren (mqtt in) — Szenario: Tag-Schreiben durch externe Befehle
mqtt in (plant/+/cmd) ──▶ change (tag_id/value 추출) ──▶ 태그값 쓰기
mqtt in:
| Element | Wert |
|---|---|
| Topic | plant/+/cmd (Wildcard + = eine Ebene) |
| QoS | 1 |
| Output | Parsed JSON object — die Payload wird automatisch in ein Objekt umgewandelt |
change:
| Aktion | Eigenschaft | Zu |
|---|---|---|
| Set | msg.tag_id | msg.topic.split('/')[1] (JSONata) |
| Move | msg.payload.value → msg.payload | (direkt in den Schreib-Node) |
Auf diese Weise schreibt das Gateway den Wert in die PLC, sobald die externe SCADA {"value":"1"} auf dem plant/TAG_VALVE_01/cmd-Topic veröffentlicht.
5. Häufige Fallstricke
| Symptom | Ursache / Lösung |
|---|---|
| Nachrichten kommen nie an | Tippfehler im Topic-Wildcard (#/+). Topic-Baum mit einem separaten Tool wie MQTT Explorer überprüfen |
| Client verbindet sich ständig neu | Client-ID-Konflikt (anderer Client nutzt dieselbe ID) — eindeutige ID vergeben |
| Retained-Messages sammeln sich endlos an | Bei jedem true Publish auf dasselbe Topic retain setzen. Retain nur für Zustandsdaten (online/offline, letzter Alarm) verwenden |
| Reihenfolge der Nachrichten ist falsch | Einschränkung von QoS 0. Wenn Reihenfolge wichtig ist, QoS 1 oder höher |
6. Nächste Schritte
- OPC-UA-Node im Detail — Kommunikation mit externem OPC-UA-Server
- Sparkplug-B-Node im Detail — Automatische Verarbeitung des Sparkplug-Spezifikation
- IIoT-Beispielsammlung