MQTT Installation und best practices

MQTT Voraussetzungen und Übersicht

• Ich verwende mein Raspberry Pi als MQTT-Server, derzeit mit Raspberry Pi OS Buster.
• Darauf werde ich mosquitto als MQTT-Server installieren und ein paar Konfigurations-Details hier dokumentieren.
• Ich werde best practices anwenden und in ein konkretes Schema empfehlen

Was ist MQTT und warum brauchst du es?

Bei „Message Queuing Telemetry Transport“ handelt es sich um ein Protokoll zum Austausch von Nachrichten in einer hierarchischen Anordnung. Es lässt sich dazu verwenden, Meldungen von und an verschiedenen Geräten oder Instanzen innerhalb eines Netzwerks in eine Ordnung zu bringen. Mithilfe dieser Ordnung lässt sich der Austausch knapper Daten vereinheitlichen und ist damit für SmartHome-Geräte innerhalb eines IP-Netzwerkes ein sehr geeigneter Standard.

Mittels ZigBee2MQTT wird eben das wieder aufgegriffen und auch ZigBee-Signale entsprechend übersetzt. Aufgrund der weiten Verbreitung und da MQTT einfach in Betrieb genommen werden kann, halte ich es für einen unverzichtbaren Bestandteil in einem SmartHome-Konzept, welches mehr als einen Gerätetypen unterstützen soll.

Installation auf Raspberry Pi OS Buster (und anderen Debian-Derivaten)

sudo apt update && sudo apt -yf upgrade
sudo apt -yf install mosquitto mosquitto-clients arping

Zunächst werden die Quellen aktualisiert, das System auf den aktuellen Stand gebracht und die notwendigen Pakete installiert.

mosquitto_passwd -c passwordfile [username]
#Ein Passwortfile [passwordfile] wird angelegt
#und [username] als Benutzer eingetragen.
#Ein Password wird abgefragt und verschlüsselt gespeichert

Im Anschluss kann ein Benutzer und Passwort konfiguriert werden. Diese werden in einer separaten Datei gespeichert.

# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example

#necessary path to the process-id file
pid_file /var/run/mosquitto/mosquitto.pid

#listen for data on port 1883 on all addresses
listener 1883 0.0.0.0

#autosave the database, default is every 30 minutes
#(connection, subscription and message data)
persistence true
persistence_location /var/lib/mosquitto/

#the log file destination
log_dest file /var/log/mosquitto/mosquitto.log

#just in case you want to have a big configuration structure
#include_dir /etc/mosquitto/conf.d

#this is the standard value
#allow_anonymous false

#path to the previously created passwordfile
password_file /etc/mosquitto/passwordfile

Und letztlich unter /etc/mosquitto/mosquitto.conf ein paar Konfigurationen gesetzt. Eine vollständige Dokumentation ist auf mosquitto.org beschrieben

sudo systemctl start mosquitto.service

Schnell noch mosquitto starten und schon sollte es funktionieren.

#Test:
mosquitto_sub -h 192.168.22.3 -u [username] -P [password] -t '#'

Mit diesem Befehl lässt sich mal schnell überprüfen, ob sich was auf dem Server tut

MQTT-Topics ordnen und best practices

Grundlagen

MQTT unterstützt ein paar Verhaltensweisen, welche Grundlegend für die folgenden Empfehlungen sind.

Grundsätzlich Ordnen sich MQTT-Geräte in ein mit „/“ getrennten Schema ein, ähnlich Ordnerstrukturen: myHome/1OG/livingRoom/couch/light/hue01/in

Wildcards

Single level: myHome/1OG/livingRoom/+/light/hue01/in

Ein „+“ ersetzt einen einzelnen Pfadknoten (Topics). Von diesem Kanal werden dann alle Nachrichten gelesen, die in irgendeinem Knoten untergeordnet sind, welche der übrigen Struktur entspricht. Das „+“ sucht nach allen Ordnern in dieser Ebene.

Multi level: myHome/1OG/livingRoom/#

Eine „#“ ersetzt alle Topics ab der Stelle, an der sie steht. Der Abonnent (Subscriber) liest alle Nachrichten ab diesem Punkt in allen Unterordnern. Wird nur der Kanal „#“ abonniert, liest der Abonnent (Subscriber) alle Nachrichten auf dem Server.

MQTT-Restriktionen

• Führendes „$“ vermeiden. Topics, welche mit „$“ beginnen, dienen Systemstatistiken. Verwende diese nicht bei der Erschaffung der eigenen Struktur.
• Führenden „/“ vermeiden. /myHome/… erschafft eine Struktur mit einer unnötigen leeren Topic-Ebene
• Leerzeichen und Sonderzeichen vermeiden. Solche Zeichen sind überwiegend erlaubt, können aber zu Irritationen oder Verwechselungen führen. Bleib Alphanumerisch (0-9, a-z und A-Z) und verwendet PascalCase (Jedes neue Wort mit Großem Buchstaben anfangen) oder camelCase (wie PascalCase, außer beim ersten Wort). Ich verwende camelCase.

Empfehlungen

• Die Topics kurz und präzise halten. So lang wie nötig, so kurz wie möglich. Verwende keine Abkürzungen. Du wirst sie nach einiger Zeit nicht mehr sofort verstehen. Die Topics sollen sprechend sein!
• Bleib Alphanumerisch (0-9, a-z und A-Z), das verhindert Verwechselungen und Irritationen.
• Jedes Gerät soll durch eine einzigartige ID zu finden sein. So kann jedes Gerät auch individuell angesprochen werden, statt nur als ganze Gruppe
• Nicht „#“ abonnieren. Es sei denn zum Debugging oder Test.
• Sei detailliert. Tiefere Hierarchiestrukturen gewähren mehr Möglichkeiten. Dank den Wildcards lassen sich Ebenen auch ignorieren.

Umsetzungsvorschlag

Meine Topic-Struktur entspricht einer mehr oder weniger festen Länge, sodass jede Ebene für eine bestimmte Eigenschaft steht. Ist jede Ebene anhand desselben Kriteriums klassifiziert, lassen sich „+“-Wildcards bestmöglich einsetzen. Dabei müssen die Ebenen nicht zwingend logisch hierarchisch zueinander sein, sondern können auch voneinander unabhängige Eigenschaften abbilden.

Mein Praxisvorschlag: [site]/[floor]/[room]/[area]/[deviceClass]/[devID]/[more device specific stuff]

Beispiele

• home/undef/cellar/undef/octoprint/anetA6_01
• home/under/undef/undef/arduino/FA3845
• home/1OG/livingRoom/couch/light/Hue01