MQTT-Integration

Eziwan verfügt über einen nativen MQTT-Client, der Felddaten (RS485-Sensoren, Netzwerkkennzahlen, Ereignisse) an jeden beliebigen MQTT-Broker – ob in der Cloud oder vor Ort – übermittelt.

---

Kompatible Broker

Broker	Typ	Anmerkungen
Eziwan MQTT	Verwaltet (im Lieferumfang enthalten)	mqtt.eziwan.com:8883 — TLS, keine Konfiguration erforderlich
Mosquitto	Selbst gehostet	Open Source – muss selbst gehostet werden
HiveMQ	Cloud / Vor Ort	Enterprise
EMQX	Cloud / Vor Ort	Hohe Leistung
AWS IoT Core	Cloud	Lambda-Integration, S3
Azure IoT Hub	Cloud	Azure Stream Analytics-Integration
Google Cloud IoT	Cloud	Pub/Sub-Integration
Scaleway IoT Hub	Cloud	In Frankreich gehostet

---

Broker-Konfiguration

Über das Eziwan-Dashboard

Gerät → Einstellungen → MQTT

Grafische Benutzeroberfläche zur Konfiguration des Brokers, der Anmeldedaten und der Themen.

YAML-Konfiguration

mqtt:
  enabled: true
  broker: "mqtt.eziwan.com"
  port: 8883
  tls: true
  client_id: "GW-Paris-01"

  # Auth — Token verfügbar im Dashboard → Einstellungen → MQTT
  username: "np_device"
  password: "np_mqtt_xxxxxxxxxx"

  # Servicequalität
  keepalive: 60
  qos: 1
  retain: false

  # Reconnexion automatique
  reconnect_delay_min: 1
  reconnect_delay_max: 60

  # Buffering si connexion perdue
  offline_buffer: true
  offline_buffer_size: 10000  # messages
  offline_buffer_ttl: 3600    # secondes

Offline-Pufferung

Wenn die LTE-Verbindung vorübergehend unterbrochen ist, puffert Eziwan die MQTT-Nachrichten lokal (bis zu offline_buffer_size Nachrichten) und veröffentlicht sie automatisch, sobald die Verbindung wiederhergestellt ist. Es gehen keine Daten verloren.

---

Aufbau der Themen

RS485-/Modbus-Sensordaten

eziwan/{device_id}/modbus/{slave_id}/{tag_name}

Exemple :
eziwan/d_a1b2c3d4/modbus/1/active_power
eziwan/d_a1b2c3d4/modbus/2/temperature

Sie können in der Modbus-Konfiguration auch benutzerdefinierte Topics pro Register festlegen:

mqtt_topic: "usine/paris/energie/compteur-01/puissance"

Systemkennzahlen (werden automatisch veröffentlicht)

Thema	Beschreibung	Intervall
.../system/rsrp	LTE-RSRP-Signal (dBm)	60 s
.../system/rsrq	RSRQ-Signalqualität (dB)	60 s
.../system/uptime	Betriebszeit (Sekunden)	60 s
.../system/sim_active	Aktive SIM-Karte (1 oder 2)	Bei Änderung
.../system/operator	Aktueller LTE-Betreiber	Bei Wechsel
.../system/wan_ip	WAN-IP	Bei Wechsel
.../system/vpn_latency_ms	VPN-Tunnel-Latenz	60 s

Echtzeit-Ereignisse

Thema	Auslöser
.../events/failover	Umschaltung von SIM1 auf SIM2
.../events/failover_recovered	Zurück zu SIM1
.../events/reboot	Neustart erkannt
.../events/vpn_connected	VPN-Tunnel aufgebaut
.../events/vpn_disconnected	VPN-Tunnel unterbrochen
.../events/modbus_timeout	Modbus-Slave antwortet nicht mehr

---

Format der Payloads

Standard-Nutzlast (Sensoren)

{
  "device_id": "d_a1b2c3d4",
  "name": "GW-Paris-01",
  "timestamp": "2025-06-15T14:23:45.123Z",
  "metric": "active_power",
  "value": 42.7,
  "unit": "kW",
  "quality": "good",
  "source": "modbus:slave=1:reg=0x0048"
}

Nutzdaten bei einem Failover-Ereignis

{
  "device_id": "d_a1b2c3d4",
  "event": "failover",
  "timestamp": "2025-06-15T14:23:45.123Z",
  "from_sim": 1,
  "to_sim": 2,
  "from_operator": "Orange",
  "to_operator": "SFR",
  "reason": "rsrp_below_threshold",
  "rsrp_sim1_dbm": -104,
  "duration_ms": 28340
}

Das Feld "quality" gibt die Zuverlässigkeit der Messung an:

• "good" — Modbus-Abfrage erfolgreich
• "timeout" — Der Slave hat nicht geantwortet
• "error" — Modbus-Fehler (Feld "error_code" vorhanden)
• "stale" — Letzter bekannter Wert (Slave vorübergehend nicht erreichbar)

---

Abonnement und Testversion

Schnelltest mit mosquitto_sub

# Alle Themen zu einem Gerät abonnieren
mosquitto_sub -h mqtt.eziwan.com -p 8883 \
  --cert ~/eziwan/client.crt \
  --key  ~/eziwan/client.key \
  --cafile ~/eziwan/ca.crt \
  -t "eziwan/d_a1b2c3d4/#" -v

# Spezifische Themen
mosquitto_sub -h mqtt.eziwan.com -p 8883 \
  --cert ~/eziwan/client.crt --key ~/eziwan/client.key \
  --cafile ~/eziwan/ca.crt \
  -t "eziwan/d_a1b2c3d4/modbus/1/active_power" \
  -t "eziwan/d_a1b2c3d4/events/#"

Laden Sie Ihre Client-Zertifikate unter Einstellungen → MQTT → Zertifikate hochladen hoch.

---

Integration von InfluxDB 2.x und Grafana

Architektur

Telegraf-Konfiguration

# /etc/telegraf/telegraf.conf

[[inputs.mqtt_consumer]]
  servers = ["ssl://mqtt.eziwan.com:8883"]
  topics  = ["eziwan/+/modbus/#", "eziwan/+/system/#"]
  qos     = 1

  # Certificats MTLS
  tls_ca   = "/etc/telegraf/eziwan-ca.crt"
  tls_cert = "/etc/telegraf/eziwan-client.crt"
  tls_key  = "/etc/telegraf/eziwan-client.key"

  # Parsing JSON
  data_format = "json"
  json_time_key    = "timestamp"
  json_time_format = "2006-01-02T15:04:05.999Z07:00"
  tag_keys = ["device_id", "name", "metric", "unit"]

[[outputs.influxdb_v2]]
  urls         = ["http://influxdb:8086"]
  token        = "votre-token-influx"
  organization = "acme-corp"
  bucket       = "eziwan"

Flux-Abfrage für Grafana

from(bucket: "eziwan")
  |> range(start: -24h)
  |> filter(fn: (r) => r._measurement == "mqtt_consumer")
  |> filter(fn: (r) => r.metric == "active_power")
  |> filter(fn: (r) => r.device_id == "d_a1b2c3d4")
  |> aggregateWindow(every: 1m, fn: mean, createEmpty: false)
  |> yield(name: "puissance_active")

---

Node-RED-Integration

Mit Node-RED lassen sich visuelle Datenverarbeitungsabläufe erstellen:

[
  {
    "type": "mqtt in",
    "topic": "eziwan/d_a1b2c3d4/modbus/1/active_power",
    "broker": "eziwan-mqtt",
    "qos": 1
  },
  {
    "type": "json"
  },
  {
    "type": "function",
    "func": "if (msg.payload.value > 100) { msg.alert = true; } return msg;"
  },
  {
    "type": "http request",
    "method": "POST",
    "url": "https://hooks.slack.com/services/xxx",
    "comment": "Alerte Slack si puissance > 100 kW"
  }
]

---

Empfohlene QoS nach Anwendungsfall

Anwendungsfall	QoS	Begründung
Systemkennzahlen (RSSI, Verfügbarkeit)	0	Redundante Daten – akzeptabler Verlust
Prozesssensoren (Energie, T°, P)	1	Zuverlässigkeit erforderlich, Duplikate werden verwaltet
Alarme und kritische Ereignisse	1	Mindestens einmal empfangen
Aktorbefehle	2	Genau einmal – verhindert doppelte Ausführung

---

Zertifikate und Sicherheit

Die MTLS-Client-Zertifikate sind unter Einstellungen → MQTT → Zertifikate herunterladen verfügbar. Sie sind mandantenabhängig und können jederzeit neu generiert werden.

Support kontaktieren → | REST-API →

Häufig gestellte Fragen

Warum hat sich MQTT im industriellen IoT durchgesetzt?

Weil es ressourcenschonend ist (ideal für 4G), nach dem Publish/Subscribe-Prinzip funktioniert (die Geräte initiieren die Verbindung, keine eingehenden Ports) und unterbrochene Verbindungen mit QoS-Stufen und zurückgestellten Nachrichten nativ unterstützt.

Welches QoS-Niveau sollte man wählen?

QoS 1 (mindestens einmal) ist die richtige Voreinstellung für die Telemetrie: Es gewährleistet die Übermittlung, ohne den hohen Overhead von QoS 2 mit sich zu bringen. Reservieren Sie QoS 0 für verlusttolerante Hochfrequenzmessungen.

Wie lässt sich ein MQTT-Stream sichern?

Systematische TLS-Verschlüsselung (Port 8883), Authentifizierung über Client-Zertifikat oder gerätespezifische Anmeldedaten sowie Trennung der Topics nach Standort. Der Broker darf niemals anonyme Verbindungen akzeptieren.

Ersetzt MQTT Modbus?

Nein, sie ergänzen sich: Modbus erfasst die Daten direkt an den Geräten (Feldbus), MQTT überträgt sie effizient in die Cloud. Das Gateway übernimmt die Konvertierung von Modbus nach MQTT.

Weiterführende Ressourcen

• Industrielles MQTT – die Lösungsseite
• OPC UA und MQTT – Kombination beider Standards
• Modbus RTU zu MQTT – die Konvertierung vom Feld zur Cloud
• Eziwan-REST-API – der andere Integrationsweg
• MQTT und RS-485 in der Praxis – der Hintergrundartikel