MQTT-Nodes im Detail
Das Gateway betreibt einen eigenen HiveMQ-Broker auf derselben Maschine (Standardport 1883, TLS 1884). Das Standardmuster für die Anbindung an externe SCADA-/Cloud-IoT-Systeme.
Broker-Verbindungsdaten der 2026.05+ Box
- Broker URL:
tcp://127.0.0.1:1883(plain) /ssl://127.0.0.1:1884(TLS) - Username / Password:
app.propertiesausmqtt.server.user/mqtt.server.password— bei Serienboxen pro Box zufällig vergeben (nachzusehen unter/etc/kopens/credentials.txt). Der entrypoint synchronisiert die HiveMQ auth.properties automatisch. - MQTT 5 wird unterstützt (HiveMQ 2025.4): retained / will / session expiry / shared subscriptions als volle Feature-Palette.
- Gemeinsamer Broker mit Sparkplug B — gleichzeitiges Abonnieren von
spBv1.0/#zur Überwachung möglich.
1. Node-Typen
| Node | Zweck |
|---|---|
mqtt in | Abonniert ein Topic — der Flow startet bei jeder eintreffenden Nachricht |
mqtt out | Veröffentlicht Nachrichten (publish) |
2. Broker-(Server-)Konfiguration — einmal anlegen, von allen Nodes gemeinsam genutzt
Node mqtt in oder mqtt out doppelklicken → Stiftsymbol rechts neben dem Feld Server → neue Broker-Konfiguration.
| Tab | Feld | Empfohlener Wert |
|---|---|---|
| Connection | Server | 127.0.0.1 (gatewayeigener HiveMQ) oder IP des externen Brokers |
| Port | 1883 (bei TLS 8883) | |
| Client ID | Leer lassen → automatisch generiert. Im Produktivbetrieb feste ID empfohlen (z. B. edge-<gateway-id>-flow1) | |
| Keep alive | 60 Sekunden empfohlen | |
| Use TLS | Bei Anbindung an externe Cloud: ON | |
| Security | Username/Password | Bei aktivierter Broker-Authentifizierung |
| Messages | LWT (Last Will) | Topic edge/<id>/status + Payload offline — automatische Meldung, wenn das Gateway unerwartet ausfällt |
| Messages | Birth | Nach dem Verbindungsaufbau online als retain auf edge/<id>/status publizieren |
3. Publish (mqtt out) — Szenario: alle Tag-Werte in die Cloud
inject (1s) ──▶ 태그값 읽기 ──▶ change (topic 만들기) ──▶ mqtt out
Node change:
| Aktion | Property | To |
|---|---|---|
| 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) |
Konfiguration des Node mqtt out:
| Feld | Wert |
|---|---|
| Topic | (leer lassen → msg.topic wird verwendet) |
| QoS | 1 (mindestens einmalige Zustellung garantiert) — für einfache Telemetrie ist auch 0 OK |
| Retain | false (Echtzeitwerte) — bei zustandsbehafteten Daten true |
4. Subscribe (mqtt in) — Szenario: Tag schreiben über einen extern eintreffenden Befehl
mqtt in (plant/+/cmd) ──▶ change (tagId/value 추출) ──▶ 태그값 쓰기
mqtt in:
| Feld | Wert |
|---|---|
| Topic | plant/+/cmd (Wildcard + = eine Ebene) |
| QoS | 1 |
| Output | parsed JSON object — die Payload wird automatisch in ein Objekt umgewandelt |
change:
| Aktion | Property | To |
|---|---|---|
| Set | msg.tagId | msg.topic.split('/')[1] (JSONata) |
| Move | msg.payload.value → msg.payload | (unverändert in den Schreib-Node geben) |
Damit genügt es, dass ein externes SCADA {"value":"1"} auf das Topic plant/TAG_VALVE_01/cmd publiziert — das Gateway schreibt diesen Wert dann in die SPS.
5. Häufige Stolperfallen
| Symptom | Ursache / Abhilfe |
|---|---|
| Es kommt nie eine Nachricht an | Tippfehler in der Topic-Wildcard (#/+). Topic-Baum mit einem separaten Tool wie MQTT Explorer prüfen |
| Client bricht ständig ab | Client-ID-Konflikt (ein anderer Client verbindet sich mit derselben ID) — eindeutige ID vergeben |
| Retain-Nachrichten häufen sich endlos an | Bei jedem Publish auf dasselbe Topic retain true gesetzt. retain nur für zustandsbehaftete Daten verwenden (online/offline, letzter Alarm) |
| Reihenfolge der Nachrichten stimmt nicht | Grenze von QoS 0. Wenn die Reihenfolge wichtig ist, QoS 1+ verwenden |
6. Nächste Schritte
- OPC-UA-Nodes im Detail — Kommunikation mit externen OPC-UA-Servern
- Sparkplug B-Nodes im Detail — automatische Verarbeitung der Sparkplug-Spezifikation
- IIoT-Beispielsammlung