Martin Weissenböck

Was ist ... MQTT?

MQTT ist ein Protokoll, das zur Übertragung geringer Datenmengen, zum Beispiel von Messstationen, entwickelt wurde. Ursprünglich war MQTT die Abkürzung für Message Queueing Telemetry Transport, seit der Version 3.1.1 gilt MQTT als Eigenname. Die aktuellen Versionen sind 3.1.1 und 5. Geringe Datenmengen, keine extremen Anforderungen an die Übertragungsgeschwindigkeit, einfach zu implementieren: deshalb ist MQTT für das Smart Home (die Haus-Automatisierung) oder allgemeiner für das Internet-of-Things (IoT) sehr gut geeignet. MQTT kann als inoffizieller Standard für das IoT angesehen werden.

Wie die Signale übermittelt werden, ist für das MQTT-Protokoll unwichtig. Nachrichten werden mittels TCP/IP - das Protokoll, über das auch unsere Internetanfragen laufen - übertragen. Dafür sind die Ports 1883 (unverschlüsselt) und 8883 (verschlüsselt) reserviert.

Auf der Webseite der MQTT-Organisation sind alle technischen Details dokumentiert. Von HiveMQ gibt es das kostenlose eBuch MQTT Essentials (englisch).

Was erwartet Sie in diesem Beitrag?

Sie werden…

• den Einsatz von MQTT kennenlernen

• Aufbau und Übertragung einer Nachricht kennenlernen

• den Ablauf einer MQTT-Übertragung verstehen

• eigene Versuche mit MQTT durchführen

• die Verwendung von MQTT in ZigBee und Node-RED kennenlernen

• die Unterschiede zwischen MQTT und HTML verstehen

• die wichtigsten Fachausdrücken von MQTT verstehen

Ein ☝ im Text weist darauf hin, dass in der Langversion an der Stelle mehr Text, ein Programmcode oder eine detaillierte Anleitung zu finden ist. Die Langversion kann über den Link und den QR-Code am Ende des Beitrags abgerufen werden.

Die Grundlagen

Jedes MQTT-Netzwerk hat genau einen Server, auch Broker oder central hub genannt. Häufig wird im Smart Home dazu ein Raspberry oder ein kleiner Linux-Desktoprechner verwendet. Da dieser Rechner ständig eingeschaltet sein muss, sollte auf den Energiebedarf geachtet werden.

Alle anderen Mitglieder des Netzwerks sind Clients. Jeder Client muss vorerst beim Server registriert werden. Die Registrierung heißt pairing, oft übersetzt mit anlernen. Clients tauschen keine Nachrichten direkt untereinander aus, vielmehr geht alles immer über den Server (Broker):

• Clients senden Nachrichten an den Broker und geben an, von welchem Thema (Topic) die Nachricht handelt. Beispiel: Lufttemperatur im Badezimmer.

• Clients können Nachrichten zu Themen abonnieren, auf die sie reagieren sollen. Beispiel: ein Client fragt nach der Lufttemperatur im Badezimmer und entscheidet, ob er zum Thema Badezimmerheizung den Nachrichteninhalt "Heizung ein" oder "Heizung aus" senden soll --- abhängig von der Temperatur und bei Bedarf auch von anderen Faktoren, wie etwa der Tageszeit. Ein weiterer Client hat das Thema Badezimmerheizung abonniert und schaltet über ein Relais die Heizung ein oder aus.

Aufbau einer Nachricht

Nachrichten bestehen aus einem Thema (Topic) und einem Nachrichteninhalt (Payload).

• Ein Topic ist eine Zeichenkette, die (im Smart Home) ein konkretes Gerät oder eine Funktion benennt.

  Beispiel: der Temperatursensor wurde als "Temp" benannt. Durch Schrägstriche können Hierarchieebenen eingerichtet werden, Beispiele: "Bad/Temp" oder "Wohnzimmer/Temp" oder "Bad/Heizung".

• Der Nachrichteninhalt wird oft in JSON-Form angegeben. JSON steht für "JavaScript Object Notation". Wie der Name schon sagt, ist dieses Format zur Speicherung und Übertragung von strukturierten Daten (das heißt von Objekten) für die Programmiersprache JavaScript entwickelt worden. JSON ist programmiersprachenunabhängig und wird auch gerne auf Webseiten zur Übertragung von Daten zwischen einem Client (zum Beispiel einem Webbrowser) und dem Server verwendet.

• Der Aufbau eines Objekts in JSON-Notation:

  • Jeder JSON-Eintrag ist ein Paar, bestehend aus einem Schlüsselbegriff (Key) und einem Wert (Value). Der Schlüsselbegriff ist in gerade Doppelapostrophe (" ") eingeschlossen. Zulässige Datentypen für Werte sind null, true, false (alle drei ohne Apostrophe!), eine Zeichenkette, eine Zahl, ein Array oder wieder ein Objekt, das selbst in JSON-Form angegeben wird.

  • Mehrere Key-Value-Paare werden durch Beistriche getrennt.

  • Das Ganze wird von geschwungenen Klammern umgeben.

  • Zeichen werden in der Regel mit UTF-8 kodiert.

  Beispiele:

  • Befehl zum Einschalten eines Verbrauchers:

    xxxxxxxxxx
    2
    1
    { "state":"on"
    2
    }
    

    Meldung eines Temperatursensors:

    xxxxxxxxxx
    2
    1
    {  "temperature": 24.00
    2
    }
    

    Meldung eines Zwischensteckers über den aktuellen Zustanf (state) und Strom-, Energie-, Wirkleistungs- und Spannungsmesswerte (vereinfacht):

    xxxxxxxxxx
    6
    1
    { "current":0.27,  
    2
      "energy":3.97,   
    3
      "power":60,  
    4
      "state":"ON",  
    5
      "voltage":229  
    6
    }
    

Bei der Ausgabe werden die Einträge nach dem Schlüsselbegriff oft alphabetisch sortiert.

Übertragen einer Nachricht

Ein Client kann Nachrichten an den Server senden, etwa wenn sich eine Messgröße (wie etwa die Raumtemperatur) ändert oder wenn der Client aufgefordert wird, etwas zu melden. In den Tasmotaeinstellungen kann eingestellt werden, in welchen Abständen der Client seinen Status meldet.

Dieses Senden von Nachrichten heißt publish (veröffentlichen).

Beispiel einer Nachricht (vereinfacht):

xxxxxxxxxx
7
1
`{
2
  `"topic":"Bad/Temp",
3
    "payload": {
4
        "humidity":42.63,
5
        "temperature":24.00
6
    }
7
}`

Das bedeutet: in einem Smart Home ist im Bad der Temperatursensor Temp installiert und der meldet eine relative Feuchtigkeit von 42.63% und eine Temperatur von 24.00°C

Beispiel einer echten Nachricht :

Die tatsächliche Meldung wurde mit dem Programm JSON Beautifier "verschönert" und sieht so aus

xxxxxxxxxx
190
1
{
2
  "topic": "zigbee2mqtt/EG/SR/TempS02",
3
  "changed": {
4
    "old": {
5
      "battery": 100,
6
      "humidity": 43.05,
7
      "linkquality": 32,
8
      "temperature": 20.99,
9
      "voltage": 3000
10
    },
11
    "new": {
12
      "battery": 100,
13
      "humidity": 42.63,
14
      "linkquality": 36,
15
      "temperature": 20.99,
16
      "voltage": 3000
17
    }
18
  },
19
  "payload": {
20
    "name": "SR",
21
    "time": "2024-05-29T17:12:35.366Z",
22
    "timestamp": 1717002755366,
23
    "temp": true,
24
    "humidity": 42.63
25
  },
26
  "payload_raw": {
27
    "battery": 100,
28
    "humidity": 42.63,
29
    "linkquality": 36,
30
    "temperature": 20.99,
31
    "voltage": 3000
32
  },
33
  "homekit": {
34
    "TemperatureSensor": {
35
      "CurrentTemperature": 20.99
36
    },
37
    "HumiditySensor": {
38
      "CurrentRelativeHumidity": 42.63
39
    },
40
    "Battery": {
41
      "BatteryLevel": 100,
42
      "StatusLowBattery": 0
43
    }
44
  },
45
  "format": {},
46
  "selector": "zigbee2mqtt_EG_SR_TempS02",
47
  "item": {
48
    "date_code": "",
49
    "definition": {
50
      "description": "Temperature & humidity sensor",
51
      "exposes": [
52
        {
53
          "access": 1,
54
          "description": "Remaining battery in %",
55
          "name": "battery",
56
          "property": "battery",
57
          "type": "numeric",
58
          "unit": "%",
59
          "value_max": 100,
60
          "value_min": 0
61
        },
62
        {
63
          "access": 1,
64
          "description": "Measured temperature value",
65
          "name": "temperature",
66
          "property": "temperature",
67
          "type": "numeric",
68
          "unit": "°C"
69
        },
70
        {
71
          "access": 1,
72
          "description": "Measured relative humidity",
73
          "name": "humidity",
74
          "property": "humidity",
75
          "type": "numeric",
76
          "unit": "%"
77
        },
78
        {
79
          "access": 1,
80
          "description": "Voltage of the battery in millivolts",
81
          "name": "voltage",
82
          "property": "voltage",
83
          "type": "numeric",
84
          "unit": "mV"
85
        },
86
        {
87
          "access": 1,
88
          "description": "Link quality (signal strength)",
89
          "name": "linkquality",
90
          "property": "linkquality",
91
          "type": "numeric",
92
          "unit": "lqi",
93
          "value_max": 255,
94
          "value_min": 0
95
        }
96
      ],
97
      "model": "WSD500A",
98
      "options": [
99
        {
100
          "access": 2,
101
          "description": "Number of digits after decimal point for temperature, takes into effect on next report of device.",
102
          "name": "temperature_precision",
103
          "property": "temperature_precision",
104
          "type": "numeric",
105
          "value_max": 3,
106
          "value_min": 0
107
        },
108
        {
109
          "access": 2,
110
          "description": "Calibrates the temperature value (absolute offset), takes into effect on next report of device.",
111
          "name": "temperature_calibration",
112
          "property": "temperature_calibration",
113
          "type": "numeric"
114
        },
115
        {
116
          "access": 2,
117
          "description": "Number of digits after decimal point for humidity, takes into effect on next report of device.",
118
          "name": "humidity_precision",
119
          "property": "humidity_precision",
120
          "type": "numeric",
121
          "value_max": 3,
122
          "value_min": 0
123
        },
124
        {
125
          "access": 2,
126
          "description": "Calibrates the humidity value (absolute offset), takes into effect on next report of device.",
127
          "name": "humidity_calibration",
128
          "property": "humidity_calibration",
129
          "type": "numeric"
130
        }
131
      ],
132
      "supports_ota": false,
133
      "vendor": "TuYa"
134
    },
135
    "disabled": false,
136
    "endpoints": {
137
      "1": {
138
        "bindings": [],
139
        "clusters": {
140
          "input": [
141
            "genPowerCfg",
142
            "genIdentify",
143
            "msTemperatureMeasurement",
144
            "msRelativeHumidity",
145
            "genBasic"
146
          ],
147
          "output": [
148
            "genIdentify",
149
            "genOta",
150
            "genTime"
151
          ]
152
        },
153
        "configured_reportings": [],
154
        "scenes": []
155
      }
156
    },
157
    "friendly_name": "EG/SR/TempS02",
158
    "ieee_address": "0xa4c13890d5649310",
159
    "interview_completed": true,
160
    "interviewing": false,
161
    "manufacturer": "_TZ3000_xr3htd96",
162
    "model_id": "TS0201",
163
    "network_address": 61298,
164
    "power_source": "Battery",
165
    "supported": true,
166
    "type": "EndDevice",
167
    "current_values": {
168
      "battery": 100,
169
      "humidity": 42.63,
170
      "linkquality": 36,
171
      "temperature": 20.99,
172
      "voltage": 3000
173
    },
174
    "homekit": {
175
      "TemperatureSensor": {
176
        "CurrentTemperature": 20.99
177
      },
178
      "HumiditySensor": {
179
        "CurrentRelativeHumidity": 42.63
180
      },
181
      "Battery": {
182
        "BatteryLevel": 100,
183
        "StatusLowBattery": 0
184
      }
185
    },
186
    "format": {}
187
  },
188
  "_msgid": "0d5f3b18305b3dc5",
189
  "_event": "node:c7742d2455f00b41"
190
}

Das bedeutet: in dieser Smart Home Steuerung wird zigbee2mqtt verwendet und deshalb beginnen alle Topics mit zigbee2mqtt Im Erdgeschoß (EG) im Raum SR ist der Temperatursensor TempS02 und der meldet eine relative Feuchtigkeit von 42.63% und eine Temperatur von 20,99°C

Da war doch die Rede von kurzen Nachrichten. Ganz schön gesprächig, so ein einfacher Temperatursensor!

Erklärungen zu einigen ausgewählten Zeilen:

Abonnieren

Ein (anderer) Client kann Nachrichten abonnieren. Das heißt, der Client teilt dem Server über die Mitteilung subscribe (anmelden) mit, dass er Nachrichten zu einem Topic (im Beispiel oben zum Topic "Bad/Temp") bekommen möchte, etwa um den Temperaturwert für die Steuerung der Heizung zu verwenden.

Auch mehrere Topic können auf einmal abonniert werden:

Mit "#" werden alle Topics einer Hierarchieebene und aller folgenden abonniert. mit "+" nur die Topics der jeweiligen Ebene.

Beispiel: "Erdgeschoß/Wohnzimmer/#" abonniert alle Geräte im Wohnzimmer, "Erdgeschoß/#" alle Geräte im Erdgeschoß.. Mit "Erdgeschoß/+/Temp" können alle Temperatursensoren im Erdgeschoß ausgelesen werden.

Eine Nachrichtenübertragung im Detail

Experimente mit MQTT

Dazu benötigen wir einen MQTT-Broker, mindestens einen Client und ein Programm, mit dem wir die PUBLISH- und SUBSCRIBE-Befehle an den Broker senden können

Der Broker: Mosquitto

Häufig wird Mosquitto eingesetzt: es gibt Versionen für Linux, Mac, Windows und andere. Die Installation wird auf der Mosquitto-Webseite sehr detailliert beschrieben.

Bei mir ist der Mosquitto-Broker unter der Adresse 192.168.12.71 zu finden, die Beispiele sind darauf ausgerichtet. Diese IP-Adresse bitte entsprechend dem eigenen Netz ändern.

Der Client: ESP32

Dann brauchen wir wenigstens ein Gerät, das auf MQTT-Befehle reagiert. Wir können dazu den ESP32 verwenden, der in den PCNEWS 180 beschrieben worden ist. Die Adresse des Brokers muss in Configuration →  Configure MQTT eingetragen sein:

Der ESP32 hat (bei mir) die Adresse 192.168.50.1, GPIO2 ist (wie in den PCNEWS 180 beschrieben) als Relais konfiguriert. Um den Zustand des Ausgangs 2 anzuzeigen, wird entweder eine LED angeschlossen oder der Ausgang in der Benutzeroberfläche kontrolliert:

Das Programm: MQTTX CLI

MQTTX ist nützliches Programm, mit dem alle MQTT-Befehle erprobt werden können und das ohne zusätzlich installierte Programme auskommt. Es wird für verschiedene Betriebssysteme angeboten.

Hier zeige ich den Aufruf über die Windows-Kommandozeile (CLI). Warum über die CLI? Weil damit am besten zu sehen ist, worauf es ankommt!

• Mit einem Klick in der Download-Seite auf v1.9.10.cli.win64.exe wird die Datei mqttx-cli-win-x64.exe in den Download-Ordner gestellt.

• Im Startmenü im Suchfenster PowerShell eingeben und damit die Windows PowerShell öffnen.

• Ins Download-Verzeichnis navigieren, üblicherweise mit cd \users\EigenerBenutzername\Downloads

• Dort sollte mqttx-cli-win-x64.exe zu finden sein — mit dir überprüfen.

Jetzt kann es losgehen!

Ein erster Test

Mosquitto bietet einen Testserver an. Können wir den erreichen? Wir geben ein:

mqttx-cli-win-x64.exe pub -h test.mosquitto.org -t 'test/topic' -m 'hallo martin'

und erhalten:

xxxxxxxxxx
19
1
PS C:\users\martin\Downloads> .\mqttx-cli-win-x64.exe pub -h test.mosquitto.org  -t 'test/topic' -m 'hello martin'``
2
[2024-6-2] [14:26:11] » ...  Connecting...
3
[2024-6-2] [14:26:11] » √  Connected
4
[2024-6-2] [14:26:11] » ...  Subscribing to test/topic...
5
[2024-6-2] [14:26:11] » √  Subscribed to test/topic
6
[2024-6-2] [14:26:11] » mqtt-packet: Packet {
7
  cmd: 'publish',
8
  retain: true,
9
  qos: 0,
10
  dup: false,
11
  length: 26,
12
  topic: 'test/topic',
13
  payload: <Buffer 48 49 7e 0a 6d 71 74 74 20 74 65 73 74>
14
}
15
topic: test/topic
16
qos: 0
17
retain: true
18
payload: HI~
19
mqtt test

Die Verbindung klappt!

Publish

Beim ESP32 mit der Adresse http://192.168.50.1 ist der Ausgang GPIO2 im Zustand OFF .

Ein Klick auf Information zeigt das Topic dieses ESP32:

Das Topic zur Steuerung von Tasmota-Komponenten beginnt immer mit cmnd/tasmota_, gefolgt von den letzten 6 Stellen der MAC-Adresse, hier F8:29:14.

Um den Power-(Relay-)Ausgang umzuschalten, ist ein MQTT-Befehl mit dem Topic cmnd/tasmota_F82914/power und dem Payload toggle zu senden:

PS C:\users\martin\Downloads> .\mqttx-cli-win-x64.exe pub -h 192.168.12.71 -p 1883 -t 'cmnd/tasmota_F82914/power' -m 'toggle'

Der Reihe nach:

• mqttx-cli-win-x64.exe ist der Name des Programms. Wer will, kann die Datei auf m.exe umgenennen -- spart Tipparbeit!

• pub steht für publish - wir wollen etwas senden.

• -h 192.168.12.71 Der Befehl geht an den Host 192,.168.12.71 - da ist der Mosquitto-Server installiert

• -p 1883 Die Postnummer ist 1883. Da das der Standard ist, kann sie auch weggelassen werden

• -t cmnd/tasmota_F82914/power Das Topic

• -m toggle Die Mitteilung (Message = Payload) besteht aus einem einzigen Wort: toggle (umschalten)

Absenden! Die Antwort von Mosquitto in der PowerShell

xxxxxxxxxx
4
1
[2024-6-2] [17:07:39] » ...  Connecting...
2
[2024-6-2] [17:07:39] » √  Connected
3
[2024-6-2] [17:07:39] » ...  Message publishing...
4
[2024-6-2] [17:07:39] » √  Message published

Im Browser wird auf der ESP32-Benutzeroberfläche die Änderung angezeigt. Wer eine LED angeschlossen hat, sieht die Zustandsänderung auch dort.

Details zu den möglichen Formaten des Message (Payload):

https://www.emqx.com/en/blog/how-to-process-json-hex-and-binary-data-in-mqtt

Subscribe

Nun wollen wir etwas von unserem ESP32 empfangen. Der Prozessor bietet viele Anschlussmöglichkeiten für Peripheriekomponenten. Programme müssen nicht geschrieben werden, alles kann über die Configuration eingestellt werden.

Der ESP32 hat aber auch eine Reihe von Sensoren eingebaut: so kann das Magnetfeld über eine Hallsonde oder die Prozessortemperatur direkt ausgelesen werden. (Das Handbuch weist darauf hin, dass diese Messwerte nicht sehr genau sind.)

Um das Magnetfeld anzeigen zu können, ist über Configuration → Configute Module GPIO36 auf HallEffect1 zu setzen. Nicht vergessen: danach Save anklicken!

Der interne Temperatursensor wird über Tools → Console und den Befehl SetOption146 1 eingeschaltet. Es folgt wieder Tools und Main Menu.

In der Benutzeroberfläche erscheint:

Mit subscribe teilen wir dem Broker mit, dass wir diese Daten gerne (regelmäßig, bei jeder Änderung) hätten:

PS C:\users\martin\Downloads\> .\mqttx-cli-win-x64.exe sub -h 192.168.12.71 -t 'tele/tasmota_F82914/SENSOR' -p 1883

Zu den Teilen des Befehls:

• sub steht für subscribe

• -t 'tele/tasmota_F82914/SENSOR' ist das Topic zum Anfordern der Messwerte

• -h und -p sind schon bekannt.

Und schon treffen die Antworten ein:

xxxxxxxxxx
15
1
[2024-6-2] [18:42:39] » ...  Connecting...
2
[2024-6-2] [18:42:39] » √  Connected
3
[2024-6-2] [18:42:39] » ...  Subscribing to tele/tasmota_F82914/SENSOR...
4
[2024-6-2] [18:42:39] » √  Subscribed to tele/tasmota_F82914/SENSOR
5
[2024-6-2] [18:42:40] » topic: tele/tasmota_F82914/SENSOR
6
qos: 0
7
payload: {"Time":"2024-06-02T17:42:39","ESP32":{"Temperature":72.2,"HallEffect":36},"TempUnit":"C"}
8

9
[2024-6-2] [18:42:50] » topic: tele/tasmota_F82914/SENSOR
10
qos: 0
11
payload: {"Time":"2024-06-02T17:42:49","ESP32":{"Temperature":72.8,"HallEffect":31},"TempUnit":"C"}
12

13
[2024-6-2] [18:43:00] » topic: tele/tasmota_F82914/SENSOR
14
qos: 0
15
payload: {"Time":"2024-06-02T17:42:59","ESP32":{"Temperature":72.2,"HallEffect":22},"TempUnit":"C"}

Hier noch einmal die erste Payload etwas übersichtlicher:

xxxxxxxxxx
8
1
{
2
  "Time": "2024-06-02T17:42:39",
3
  "ESP32": {
4
    "Temperature": 72.2,
5
    "HallEffect": 36
6
  },
7
  "TempUnit": "C"
8
}

Zusammenfassung

MQTT kommuniziert vor allem mit den beiden Befehlen PUBLISH und SUBSCRIBE. Mit MQTTX CLI ist deren Funktion einfach zu erproben.

Für alle wichtigen Programmiersprachen gibt es Programmbibliotheken, um MQTT-Befehle direkt aus Programmen absetzen zu können.

Darüber hinaus gibt es eine große Zahl anderer Programme zur Kommunikation. Hier ein paar Beispiele.

Weitere Programme…

MQTTX

MQTTX (ohne CLI) liefert dieselben Informationen, allerdings mit einer grafischen Benutzeroberfläche. _~~

MQTT.js

MQTT.js ist eine Programmbibliothek für JavaScript bzw. ab Version 5.0 in TypeScript. Die Bibliothek kann im Browser und in Node.js-Projekten verwendet werden. Dadurch werden auch Anwendungen in JavaScript-basierenden Apps, zum Beispiel Svelte, möglich.

Ferner kann MQTT.js auch über die Kommandozeile verwendet werden. Dazu reicht die Installation mit

xxxxxxxxxx
1
1
npm install mqtt -g

Zur Demonstration wird in einem Terminalfenster in dem öffentlich zugänglichen Testserver test.mosquitto.orgein subscript gestartet:

xxxxxxxxxx
1
1
mqtt sub -t 'hallo998877' -h 'test.mosquitto.org' -v

Von einem anderen Fenster wird der Text "Von MQTT.js" mit publish gesendet.

xxxxxxxxxx
1
1
mqtt pub -t 'hallo998877' -h 'test.mosquitto.org' -m 'Von MQTT.js'

Erfolg — der Text kommt im ersten Fenster an!

Zum Topic hallo998877: Der Testserver kann aus dem gesamten Internet verwendet werden. Um nicht von anderen Nutzern gestört zu werden, sollte ein Topic verwenden, das höchstwahrscheinlich sonst niemand verwendet.

MQTT Explorer

Der MQTT Explorer ist ein weiteres Programm, um Mitteilungen an einen Server zu senden (über publish) oder von dem Server zu empfangen (über subscribe), Die Benutzeroberfläche ist etwas gewöhnungsbedürftig, aber nach kurzer Einarbeitung leicht zu bedienen.

Die Anmeldeseite zeigt hier den Testserver test.mosquitto.org und meine eigenen Testserver.

Bei den bisher besprochenen Programmen ist es notwendig, schon beim Schreiben eines MQTT-Befehls zu wissen, wie die zu verwendenden Topic heißen. Der MQTT Explorer zeigt dagegen alle Topics, die im Netzwerk erreichbar sind.

In dem Beispiel wird an das Topic Hallo998877 der Text "Von MQTT-Commander" gesendet. Der gesendete Text ist rechts unten zu senden, der empfangene links oben und rechts in der Mitte. Einfach einmal ausprobieren!

MQTT und Node-RED

Node-RED ist ein grafischer Werkzeugkasten für die Programmierung von ereignisgesteuerten Abläufen. In einer Smart Home Steuerung treten Signale (Ereignisse) ohne vorhersehbaren Ablauf auf und erfordern daher spezielle Programmiertechniken.

Node-RED kann durch Paletten (Programmpakete) erweitert werden, daher kann die MQTT-Kommunikation zwischen Broker (Server) und Clients in Node-RED implementiert werden. Die einzelnen Funktionen werden in Nodes implementiert und mit einander verknüpft. Das Node-RED-Programm kann gemeinsam mit einem MQTT-Broker (wie etwa Mosquitto) und Zigbee2MQTT auf einem Rechner installiert werden. Noide-RED wird als Webseite über einen beliebigen Browser bedient. Übliche Adresse: http://<Rechner-Adresse>:1880. Bei mir also http://192.168.12.71:1880.

MQTT und Zigbee2MQTT

ZigBee ist ein eigener Funkstandard, der wegen der geringeren Datenmenge weniger störungsanfällig ist. ZigBee-Komponenten bauen darüber hinaus dazu über ZigBee-Router ihr eigenes Mesh-Netzwerk auf und können damit auch große Flächen abdecken. ZigBee-Router sind, vereinfacht gesprochen, jene ZigBee-Komponenten, die ständig (über das Stromnetz) mit Energie versorgt werden und deshalb Signale an andere Komponenten weitergeben können. Das Mesh-Netzwerk wird von ZigBee selbstständig aufgebaut und bei Bedarf, zum Beispiel beim Ausfall einer Komponenten, selbstständig reorganisiert. Viele Komponenten für Smart Homes werden in zwei Varianten, nämlich für ZigBee und WLAN, angeboten. Zigbee2MQTT erlaubt die Verbindung von ZigBee-Geräten über MQTT.

MQTT und HTTP

Eine Gegenüberstellung zeigt die wichtigsten Unterschiede.

Quelle: basierend auf Unterlagen von HIVEMQ

Wichtige Begriffe

Connection:

Eine Verbindung zwischen Broker und Client (nach dem Pairing) zum Zweck des Datenaustauschs. Zwei Clients tauschen Daten nie direkt aus, immer nur über den Broker. Da der Broker ja den Überblick hat, entscheidet er selbst, wann Daten gesendet werden. Wenn ein Client etwas senden will, sendet er ein CONNECT-Ansuchen an der Broker. Dieser antwortet mit CONNACK (Connection acknowledge, Verbindung bewilligt).

Friendly name:

Jedes Gerät hat eine eindeutige MAC-Adresse, bestehend aus 12 Hexadezimalziffern und geschrieben beispielsweise als 94:B5:55:F8:29:14 oder 0x94b555f82914. Die Geräte können immer darüber angesprochen werden. Da das aber wenig benutzerfreundlich ist, kann zusätzlich ein friendly name, ein freundlicher Name, angegeben und in der Konfigurationsdatei des Brokers eingetragen werden. Beispiel: "Erdgeschoß/Küche/Deckenlampe".

ISO-Schichtenmodell:

MQTT ist in den Schichten 5-7 angelegt. Darunter (in der Schicht 4) ist TCP, das transmission control protocol und (in der Schicht 3) IP (das internet protocol).

Last will and testament (LWT):

Wenn ein Client eine Verbindung aufbaut, kann er zusätzlich eine Nachricht im Broker hinterlegen, die gesendet wird, wenn die Verbindung unterbrochen wird. Genannt last will and testament, (Letzter Wille und Testament) oder kurz nur will

Pairing:

Bevor eine Verbindung mit CONNECT angefordert werden kann, muss ein neues Gerät angemeldet werden. Der Vorgang heißt pairing, übersetzt oft mit anlernen. Dazu muss einerseits am MQTT Broker das Anlernen aktiviert werden und andererseits das neue Gerät selbst in den pairing-Modus versetzt werden.

• Beim Broker geschieht dies mit einem Software-Befehl. zigbee2mqtt verwendet die Konfigurationsdatei configuration.yaml. Dort kann das pairing mit permit_join: true aktiviert werden. Nicht vergessen: nach dem paiting wieder auf false setzen.

• Ein neues Gerät wird meistens bereits mit dem ersten Anschließen automatisch in den Pairing-Modus versetzt. Aber natürlich geht das auch nachträglich:

  • Oft wird dazu eine Taste solange gedrückt, bis eine LED blinkt.

  • LED-Lampen haben keine Tasten, daher werden sie vier- oder fünfmal kurz hintereinander ein- und ausgeschaltet. (Nicht vergessen: die Lampe muss zum Pairing natürlich zuletzt eingeschaltet bleiben.) Die Lampe beginnt dann im Zwei-Sekunden-Rhythmus zu "atmen", wird also langsam heller und wieder dunkler.

  • Gute Anleitungen zum Pairen sehr vieler Geräte sind in den ZigBee2MQTT-Gerätebeschreibungen zu finden.

• Empfehlung: beim Pairen sollten Broker und neues Gerät möglich nahe beisammen sein. Das dürfte ein Sicherheitsmaßnahme sein, um unbeabsichtigtes Pairing zu verhindern.

Payload:

Der aktuelle Nachrichteninhalt; anders formuliert die Daten, die gesendet oder empfangen werden. Payloads werden häufig als JSON-Zeichenkette geschrieben, da diese Schreibweise sehr leicht (für Menschen) lesbar und (für Programme) analysierbar ist.

Publish:

Der Mechanismus zum Senden von Daten

Publisher, Subscriber:

Clients können als Publisher oder Subscriber verwendet werden. Ein Publisher sendet Daten aus (Beispiel: Temperaturwerte), ein Subscriber empfängt Daten und wertet sie aus (Beispiel: ein Microcontroller, der einen Verbraucher schaltet). Viele Clients sind Publisher und Subscriber zugleich.

Quality of Service (QoS):

Welche Qualität der Datenübertragung ist in einem konkreter Anwendungsfall erforderlich, welche Maßnahmen zur Sicherung werden gefordert? Es gibt die Stufen 0, 1 oder 2.

• Stufe 0: Client und Server hängen über eine direkte Drahtverbindung zusammen, daher ist es unwahrscheinlich, dass Daten verloren gehen. Oder der Verlust einzelner Datenpakete ist zu verschmerzen

• Stufe 1: Jedes Datenpaket muss tatsächlich ankommen, doppelte Pakete werden erkannt und aussortiert. Oder Stufe 2 ist zu aufwändig.

• Stufe 2: Jedes Datenpaket muss genau einmal verarbeitet werden.

Retain:

Wenn der aktuelle Zustand eines Clients auf Anforderung nicht übertragen werden kann, wird der letzte Zustand übertragen. Dazu ist natürlich eine Zwischenspeicherung im Broker notwendig. Beispiel: ein batteriebetriebener Temperatursensor schickt -- um Energie zu sparen -- nur dann Daten, wenn sich ein Wert ändert, .

Subscribe:

Der Mechanismus für das Anmelden zum Empfangen von Daten

Subscriber:

Siehe Publisher

Topic:

Übersetzt: Thema. Die Adresse eines Geräts oder einer Funktion eines Geräts als Zeichenkette

WebSocket:

WebSocket baut auf TCP auf und erlaubt eine bidirektionale Verbindung. MQTT-Befehle können in WebSockets "verpackt" werden und damit über HTTP/HTTPS übertragen werden. Das gestattet, MQTT-Befehle über Webbrowser zu senden und zu empfangen.

Zur Langversion

Link und QR-Code: https://pcnews.at/markdown/n181/index.html oder https://t.ly/lblE0

Copyright