Zum Inhalt

MQTT

MQTT ist ein offenes IoT-Nachrichtenprotokoll. Es zeichnet sich durch leichtgewichtige Datenpakete und Zuverlässigkeit in Netzwerken mit hohen Latenzen oder unregelmäßigen Verbindungen aus.

Außerdem ist es ein Client-Server-Protokoll mit Publish/Subscribe. Der Server (auch MQTT-Broker genannt) speichert alle Daten, die Clients können Daten an den Server schicken (Publish) oder alle zukünftigen Änderungen an einem Wert abonnieren (Subscribe).

Von Simon A. Eugster - Eigenes Werk, CC BY-SA 4.0

Wenn MQTT als Übertragungskanal verwendet werden soll, tritt ATLAS als Client auf und sendet -immer wenn ein Sensor Daten ausgibt- alle dekodierten Sensordaten an einen MQTT-Broker.

Für jede Nachricht wird eine neue Verbindung zum Broker aufgebaut, dann das Datenpaket versendet und die Verbindung dann wieder getrennt

Bei der Zieladresse muss ein Public-TLS-Zertifikat hinterlegt sein, wenn Sie TLS verwenden möchten.

ATLAS kann nur eigene Sensordaten an einen MQTT-Broker senden, fragt aber nie Daten an.

Übersicht über alle MQTT-Verbindungen

Über den Button MQTT-Integration hinzufügen wird ein neuer Broker eingetragen, an den Daten gesendet werden sollen.

MQTT-Broker hinzufügen

Message Retain ist immer eingeschaltet und kann auch nicht deaktiviert werden.

Folgende Felder sind auszufüllen:

  • Name Ein Bezeichner, der diese MQTT-Verbindung beschreibt.
  • Hostname/IP Eine Domain oder eine IP, unter welcher der gewünschte MQTT-Broker ereichbar ist.
  • Port Der Port unter dem der MQTT-Broker auf Verbindungen wartet.
  • Benutzername und Passwort Die Zugangsdaten für diesen MQTT-Broker.
  • Sensordaten zu Übertragung hinzufügen Wenn Sie diese Option aktivieren, werden Name, Beschreibung, interner Vermerk und die weiteren Felder ebenfalls übertragen.

Der Button Verbindung testen überprüft, ob eine Verbindung mit dem angegebenen MQTT-Broker möglich ist.

QoS (Quality of Service)

Bei MQTT kann der QoS eingestellt werden. Die Einstellung bestimmt, ob der Client sicherstellt, dass die versendete Nachricht empfangen wurde.

  • QoS 0: Die Nachricht wird nur einmal verschickt - ohne Rücksicht, ob der Empfänger diese erhalten hat oder nicht.

  • QoS 1: Der Client wartet, bis der Broker sich nach dem Empfangen meldet. Wenn keine Rückantwort erfolgt, wird die Nachricht erneut versendet. Hierbei kann es zu Mehrfachauslieferungen kommen.

  • QoS 2: Hier wird die Nachrichte nur einmal verschickt und der Empfang bestätigt, wobei eine zweistufige Empfangsbestätigung verwendet wird.

Wildcards

Um vom Broker Nachrichten zu erhalten, muss ein Topic abonniert (subscribe) werden. Die Topics sind ähnlich wie eine URL aufgebaut. Zum Beispiel: building/firstfloor/room42/co2. Um mehere Topics auf einmal zu abonnieren, können die Operatoren + und # verwendet werden.

+-Operator (Single-Level-Wildcard)

Der +-Operator kann an beliebiger Stelle in den Hierarchiestufen stehen. Beispielanwendung: building/firstfloor/+/co2. So wird der CO2-Wert jedes Raumes im ersten Stock abonniert.

#-Operator (Multi-Level-Wildcard)

Der #-Operator kann nur am Ende der Hierarchie verwendet werden. Er abonniert alle nachfolgenden Topics. Beispielanwendung: building/firstfloor/#. So wird jeder verfügbare Wert jedes Raumes im ersten Stock abonniert.

Der Operator kann auch an erster Stelle stehen, um jedes Topic des Brokers zu abonnieren.

Aufbau einer MQTT-Nachricht

Nachfolgend ist ersichtlich, wie eine beispielhafte und für Sie kommentierte Nachricht aussieht:

{
"mqttIntegrationId": 4, // internal id of the integration (unique identifier for mqtt integrations)
"mqttIntegrationName": "Demo", // name of the integration
"externalSourceId": 3, // id of the external source system (unique identifier for external sources)
"messageId": "9c6eb7b9-c98d-483b-aee4-e2c381fda713", // internal id of the message (unique identifier for messages)
"internalDeviceId": 14, // internal id of the device (unique identifier for devices)
"externalDeviceId": "1122334455667788", // external id of the device (DevEUI in case of LoRa)
"messageType": "UPLINK", // type of the received message (Possible values are: UPLINK, DEVICE_JOIN, DOWNLINK_ACK, DEVICE_STATUS, UPLINK_ERROR, UNKOWN)
"timestamp": "2021-02-01T10:14:28.131Z", // timestamp on which the message was received
"dataFrame": "01012b02260401240501060235070e27", // hex encoded payload in case of LoRa; also json is possible here
"decoded": { // DEPRECATED: please use 'rawJson' instead
    "temperature": 29.9,
    "humidity": 38,
    "light": 292,
    "motion": 1,
    "co2": 565,
    "vdd": 3.623
},
"rawJson": { // parsed json from 'dataFrame'
    "temperature": 29.9,
    "humidity": 38,
    "light": 292,
    "motion": 1,
    "co2": 565,
    "vdd": 3.623
},
"metrics": [ // all extracted metrics for this message
    {
        "metricId": 3, // internal metric id (unique identifier for metrics)
        "metricName": "co2", // name of the metric
        "metricTypeId": 4, // internal metric type id (unique identifier for metric types, but can be used by multiple metrics)
        "metricTypeName": "co2", // name of the metric type
        "metricDataType": "INT", // data type of the metric (Possible values are: INT, FLOAT, BOOLEAN, STRING)
        "metricUnit": "ppm", // unit of the metric
        "metricValue": 565 // value of the metric (data type can be read from 'metricDataType')
    }
    // ... more possible
],
"rssi": -98, // only in case of LoRa
"framePort": 5, // only in case of LoRa
"loraSnr": 10.0, // only in case of LoRa
"dataRate": 2, // only in case of LoRa
"frameCounter": 176924 // only in case of LoRa
}