MQTT

Viele IoT Geräte bauen heute auf Cloud-Dienste auf, von denen Sie weder wissen, wer sie betreibt, wer die Daten noch bekommt und wie lange sie Bestand haben. Das gilt insbesondere wenn der Absatz der Geräte abnimmt und die Kosten unverändert bleiben. Sehr bald muss ein Anbieter sich dann umschauen und neue Geldquellen anbohren oder den Betrieb einstellen. Da ist mir eine "eigene Cloud" lieber und um das Rad nicht neu zu erfinden, gibt es mit MQTT eine Definition, wie Geräte miteinander kommunizieren können. Dann muss ich das Rad nicht neu erfinden.

MQTT ist übrigens keine Abkürzung für "Message Queue Telemetry Transport" und kann maximal auf "MQ Telemetry Transport" zurückgeführt werden, wobei MQ ein Produkt von IBM ( https://www-03.ibm.com/software/products/de/ibm-mq). Die Anfänge von MQTT sind im Jahr 1999 zu suchen, wo IBM-Techniker zur Überwachung von Öl-Pipelines über Satelliten ein bandbreitenoptimiertes Protokoll mit grundlegenden QoS-Strategien entworfen haben.

Grundprinzip

MQTT ist erst mal nur ein Protokoll ohne über die Transportwege und die Inhalte etwas zu sagen.

MQTT  ist ein offenes Nachrichtenprotokoll für Machine-to-Machine-Kommunikation (M2M), das die Übertragung von Telemetrie-Daten in Form von Nachrichten zwischen Geräten ermöglicht, trotz hoher Verzögerungen oder beschränkten Netzwerken.[1] Entsprechende Geräte reichen von Sensoren und Aktoren, Mobiltelefonen, Eingebetteten Systemen in Fahrzeugen oder Laptops bis zu voll entwickelten Rechnern. Das Protokoll wurde von Andy Stanford-Clark von IBM und Arlen Nipper von Cirrus Link Solutions entwickelt.
Quelle: https://de.wikipedia.org/wiki/MQTT

In der Regel wird aber schon TCP/IP als Transport genutzt und damit stehen alle physikalischen Schichten (Ethernet, WiFi, LTE etc.) offen. Es sind aber auch ZigBee und andere Übertragungswege möglich. Das System besteht dabei aus drei Komponenten:

  • Sensoren (Publisher)
    Sensoren sind jede Art von Geräten, die Daten erfassen und irgendwo hin melden. Sensoren sind in der Regel nicht 24h aktiv und erreichbar. Sie sind entweder batteriegestützt eh die meiste Zeit im Schlafmode und wachen nur kurz auf um Daten zu senden oder Sie "verstecken" sich hinter NAT-Routern und können die Verbindung nur von ihrer Seite her aufbauen. Daher ist ein "Clearingpoint" erforderlich, an den Sie ihre Daten senden können und von dem andere Dienste die Daten auch wieder abrufen
  • Broker
    Der Broker ist ein Service, der für alle möglichen Sensoren 24h erreichbar ist und deren Meldungen annimmt. Zudem antwortet er auch auf Anfragen von anderen Diensten, die die Werte wieder auslesen wollen
  • Konsument (Subscriber)
    Die von Sensoren an den Broker gemeldeten Daten können von anderen Diensten wieder abgerufen werden

Die Übertragung erfolgt als TCP-Stream über die Standardports 1883/TCP oder 8883/TLS

Kaum jemand schreibt das aber komplett selbst, sondern es gibt verschiedene Libraries, auf die man aufsetzen kann:

MQTT Broker

Die Spinne im Netz, an die sich alle Publisher wenden ist ein Dienst, der per TCP auf den Port 1883 (oder 8883/TLS) erreichbar sind. Wenn alle Nutzer mit DNS umgehen können, kann die IP-Adresse auch dynamisch sein. für den internen Gebrauch ist aber wohl eine statische direkt erreichbare IP-Adressen einfacher. Als Broker gibt es gleich wieder mehrere Lösungen und Betriebsarten.

MQTT im Eigenbetrieb

Sie können einen Broker natürlich einfach selbst lokal oder ihrer eigenen Cloud-Instanz installieren und betreiben. Es gibt eine ganze menge an Open Source-Lösungen

Einige der Systeme können Sie sogar auf dem ein oder anderen NAS-Devices oder RaspberryPi und Co installieren

Installing Mosquitto (MQTT) broker on Synology NAS
https://www.youtube.com/watch?v=b3A1RJdDf-w

MQTT in de Cloud

Natürlich gibt es auch jede menge Anbieter, die basierend auf der ein oder anderen OpenSource oder Eigenentwicklungen einen Cloud-Services bereit stellen. Fast alles haben auch eine "Free-Version" für geringe Datenmenge, die für erste Gehversuche sicher ausreicht. Aber letztlich müssen auch Cloud-Anbieter irgendwie ihre Kosten wieder verdienen und wenn dies nicht klappt, dann können Sie nur die Daten verkaufen, die Leistung weiter einschränken oder wieder verschwinden. Siehe auch Cloud - Abruptes Ende. Man muss als schon genau überlegen, bei welchem Cloud-Service Sie ihre IoT-Daten als Relay hinterlegen.

MQTT Test-Systeme

Die Firma Hive betreibt einen öffentlichen MQTT-Server, zu dem jeder seine Daten senden und beliebige andere Daten empfangen kann. Das ganze erfolgt natürlich ohne eine Betriebsbereitschaft und auch die Gültigkeit der Daten ist natürlich nicht gesichert. Zumal man per Subscribe "*" quasi alle Kanäle bekommt und damit die Daten auch absichtlich "stören" kann. Das ist wirklich nur ein "Test-System". Aber was sollte jemanden hindern eine Information per MQTT durchaus "anonym" lesbar zu machen. Diese Vorsichtsmaßnahmen gelten für alle "Test-Broker" aber so können Sie ohne Kosten und Mühen erste Gehversuche mit MQTT Publisher oder Subscrier machen:

Broker Server TCP Ports TLS Ports Websocket

Mosquitto

iot.eclipse.org

1883

8883

n/a

HiveMQ

broker.hivemq.com
broker.mqttdashboard.com

1883

1883

8000

Mosquitto

test.mosquitto.org

1883

8883 / 8884

8080 / 8081

mosca

test.mosca.io

1883

1883

80

Es gibt sicher noch mehr Server aber für den Anfang ist das schon mal ausreichend.

MQTT Clients

Es gibt eigentlich keinen "Client" sondern nur Subscriber, die Werte von einem Broker abfragen und ggfls. darauf reagieren oder diese grafisch aufbereiten

MQTT mit PowerShell

Als Windows Admin und Consultant stellt sich mir natürlich immer die Frage, wie ich MQTT auch aus der PowerShell nutzen kann. Ich kann es mir schon interessant vorstellen gewisse Kennzahlen, die z.B. als Windows Performance Counter vorliegen, per MQTT-Publish an einen Broker weiter zu geben. Umgekehrt könnte es auch interessante Anwendungsfälle geben, MQTT-Werte per Subscribe abzufragen und z.B. in PRTG weiter zu verarbeiten.

Es ist in PowerShell selbst aber schon knifflig das MQTT-Protokoll auf Basis der System.net.sockets.tcpclient-Klasse selbst zu programmieren. MQTT ist zwar "Lightweight" aber durch die Verwendung von Bits und Bytes anstatt SOAP-URL und REST-APIs und JSON doch etwas schwerer zu lesen.

Da aber z.B. der Subscriber die Verbindung aufrecht erhalten muss, damit er weitere Updates bekommt, hätte ich intensiver mit PS und Callback-Funktion arbeiten müssen. Daher habe ich mich doch lieber nach Libraries umgeschaut, die z.B. auf :NET basieren und per PowerShell anzusprechen sind. Ich bin fündig geworden und die Ergebnisse finden Sie auf einer eigenen Seite

MQTT mit ESP8266, Arduino, RasPi und Co

Natürlich ist das schlanke MQTT-Protokoll ideal für das Internet der Dinge (IoT) nutzbar und so verwundert es nicht, dass viele Seiten die Integration von MQTT in die gängigen Plattformen integrieren. Dazu zählen insbesondere die Arduino Plattform und natürlich der ESP8266.

Es gibt aber durchaus auch kommerzielle Firmen, die fertige Sensoren verkaufen oder Sensoren, die mit einer passenden Firmware auch zu einem MQTT-Sensor umgebaut werden können

Öffentlichen MQTT-Server und Daten

Vielleicht muss man auch nicht alle Werte immer selbst ermitteln. Ich kann es mir durchaus vorstellen, dass diverse MQTT-Broker im Internet bestehen, die kostenfrei oder per Subscription bestimmte Daten bereit stellen. Da gibt es schon ganz viele Informationen, die z.B. Banken, Wetterdienste, Verkehrsbetrieb u.a. per MQTT bereitstellen könnten

  • Wetterdaten
  • Aktienkurse
  • Zugabfahren, Ankunft, Verspätungen
  • Verkehrsdichte
  • Preise von Waren (z.B. Treibstoff)
  • Strompreis zur Steuerung von Wärmepumpen

Es muss ja nicht immer eine REST-API sein, die per HTTP-Polling abgerufen wird. MQTT überzeugt durch das Subscriber-Modell, dass neue Daten sehr schnell an die Subscriber aktiv ausgeliefert werden können.

  • Wie können Flugdaten von MQTT Servern empfangen und in openHAB angezeigt werden?
    http://blog.wenzlaff.de/?p=7289
    tcp://test.mosquitto.org:1883/Anzahl/Flugzeuge/Hannover:state:default]"}

Weitere Links