Ich bin schon längere Zeit am brüten, wie ich meine verschiedenen Datenquellen im ganzen Haus
mit deren verschiedenen Datenformaten, neutral übers Netz zusammenbinden, überallhin transportieren kann
und diese mehreren Anwendungen unabhängig, gleichzeitig zur Verfügung stellen kann
und trotzdem beliebig erweiterbar für die Zukunft sein kann.
Im ersten Schritt wird Heizraum mit Büro übers lokale Netz oder Wlan zur Messdatenübertragung mit MQTT verbunden.
Message Queue Telemetry Transport (MQTT) ist ein offenes Nachrichten-Protokoll für Machine-to-Machine-Kommunikation (M2M).
Das offene, lizenzfreie MQTT-Protokoll wurde bereits 1999 von IBM für die Satellitenkommunikation entwickelt
und später in vielen industriellen Anwendungen eingesetzt. Inzwischen ist es standardisiert und MQTT gilt als ein Protokoll des Internet der Dinge.
Es ist äußerst einfach zu implementieren, kennt drei unterschiedliche Dienstgüten (QoS) für Service-Optionen.
Das MQTT-Protokoll ist heute schon in den meisten SmartHome-Sytemen wie FHEM, openHAB, ioBroker, Node-RED usw. integriert.
Die Struktur in der das MQTT-Protokoll arbeitet, besteht aus der Datenquelle, die als Publisher bezeichnet wird,
der Datensenke, dem Subscriber, und dem zwischengeschalteten Message-Broker, der für die Kommunikationssteuerung sorgt.
Das Protokoll hat einen ereignisgesteuerten Ansatz. MQTT benutzt das Publish-Subscribe-Pattern.
Das bedeutet, dass die Clients sich untereinander nicht kennen und einen zentralen Verteiler,
einen sog. Broker, zur Kommunikation nutzen. Der Broker ist dafür zuständig,
dass eine gesendete Nachricht alle interessierten Clients erreicht.
Wenn ein Client sich zu einem Broker verbindet, teilt dieser dem Broker mit,
für welche so genannten Topics er benachrichtigt werden möchte, also welche Topics er abonnieren möchte.
Diesen Vorgang nennt man Subscribe.
Wenn ein Client eine Nachricht sendet, muss dieser die Information mitsenden,
an welches Topic diese Nachricht gesendet werden soll.
Diesen Vorgang nennt man Publish.
Diese Architektur ermöglicht es hochskalierbare Lösungen mit vielen Clients zu entwickeln,
ohne dass Abhängigkeiten zwischen den teilnehmenden Clients entstehen.
Topics: Jeder Client kann frei wählen, zu welchem Topic er publishen oder subscriben möchte.
Topics sind frei wählbare Strings und können mittels „/“ hierarchisch aufgebaut werden.
Topics-Beispiele wären „SolarEngel/A25“ und „SolarEngel/LC“.
Das Root-Topic wäre hier „SolarEngel“, die untergeordneten Topics wären „A25“ und „LC“.
Ein Client könnte entweder ein konkretes Kind-Topic abonnieren oder mittels einer Wildcard („#“)
alle Kind-Topics eines Eltern-Topics abonnieren.
Beispielsweise könnte er „SolarEngel/#“ abonnieren,
was zur Folge hätte, dass er alle Nachrichten für „SolarEngel/A25“ und „SolarEngel/LC“ zugestellt bekommen würde.
Bei den Topic-Namen wird zwischen Groß- und Kleinschreibung unterschieden.
Warum MQTT? Ich habe mich für MQTT aus mehreren Gründen begeistern können.
Einer davon ist, dass das Protokoll sehr leichtgewichtig ist und es ermöglicht, bandbreitenschonend Daten zu übertragen.
Durch das Publish-Subscribe-Pattern von MQTT ist es ein Leichtes, diese Informationen an mehrere Datenkonsumenten zu verteilen,
welche sich alle zu einem MQ MQTT Broker verbinden. Außerdem werden die Nachrichten durch die offene TCP-Verbindung,
die jeder MQTT-Client zum Broker hält, direkt per Push an alle abonnierenden Clients versendet.
Ein anderer interessanter Aspekt sind die verschiedenen Servicequalitäten (QoS) von MQTT. Obwohl MQTT auf TCP basiert,
kann es bei Mobilfunknetzen zu Übertragungsproblemen kommen, welche durch Protokollmechanismen ausgeglichen werden.
Die Zusicherung der Übertragung kann für jede Nachricht individuell angegeben werden.
Level 0 bietet keinerlei Garantie, dass die Nachricht ankommt,
bei Verwendung von Level 1 wird sichergestellt, dass diese mindestens einmal ankommt
und bei Level 2, dass die Nachricht genau einmal ankommt.
Durch die Verwendung von Level 2 bei der Übertragung zwischen SmartHome und dem Broker ist sichergestellt,
dass alle Nachrichten auch wirklich ankommen.
Der konkrete Aufbau und die Kommunikation in meinem Projekt zur Messdatenübertragung mit MQTT und Mosquitto
wird mit mehreren python-scripts als Clients(python-script-A25, python-script-LC, python-script-UVR1611, python-script-KAMO-FWS usw.),
dem freien SmartHome-System FHEM und mit dem Open Source Broker Mosquitto auf RASPI2(im Heizraum) und Cubitruck(im Büro)
mit Raspian-Betriebssystem aufgebaut.
Im lokalen Netz werde ich mit Level 0 arbeiten, d.h. ohne Garantie, dass die Nachricht ankommt.
Mit einem zusätzlichen Client(python-script-DB) abonniere ich Nachrichten aller Topics und speichere sie in eine SQL-Datenbank(SQLite)
und mache somit die Nachrichten nicht über das Protokoll persistent. Es gibt Clients für Android, Java, Perl, Python und Arduino usw.
MQTT-Nachrichten an Topics senden und MQTT-Nachrichten abonnieren(empfangen) habe ich mit Android-App, perl-client,
python-client und java-client getestet.
Die ersten Tests sind vielversprechend. Auf den nachfolgenden Screenshots sieht man wie die Clients über das
Versenden und Abonnieren von MQTT-Nachrichten miteinander kommunizieren.
Dabei ist es ganz einfach möglich, andere Geräte(publisher) oder Abnehmer(subscriber) für die bereits vorhandenen Topics hinzuzufügen
oder neue Daten mit neuen Topics über den Broker zu versenden, um auch andere Systeme,
wie beispielsweise zum Testen eines zusätzlichen SmartHome-Systems oder zusätzliche Clients anzubinden und parallel mit Nachrichten zu versorgen.
Desktop vom Raspi2 im Heizraum: 2 python-scripts als Client zum Empfang und senden von Nachrichten vom A25-Brenner
Desktop vom Cubitruck im Büro: python-script als Client zum Empfang von Nachrichten
Android Tablet: mit freier MQTT App zum Empfangen und senden von Nachrichten.