- MQTT hat sich in den 25 Jahren seit der Veröffentlichung der ersten Spezifikation im Oktober 1999 von einem leichtgewichtigen Protokoll für kleine Geräte und instabile Netzwerke auf Industrie, Haushalt und Apps insgesamt ausgeweitet.
- Die einfache Publish/Subscribe-Struktur, die von begrenzter Energie und unterbrochenen Verbindungen ausgeht, bleibt auch dann eine Stärke, nachdem sich Netzwerk- und Edge-Geräte-Umgebungen verändert haben.
- MQTT, das zunächst vor allem im Umfeld von IBM genutzt wurde, gewann 2009–2011 in der Community spürbar an Verbreitung und entwickelte sich über Mosquitto und Eclipse Paho zu einem offenen Protokoll-Ökosystem außerhalb von IBM.
- Heute steckt es auch in Bereichen, die Nutzer oft gar nicht bewusst wahrnehmen: in der Node-RED-basierten Nachrichtenverarbeitung auf dem Raspberry Pi, in Dyson-Luftreinigern und deren Apps, in der 3D-Drucker-Steuerung, in Home-Benachrichtigungen und in Fertigungsumgebungen.
- Zum 25. Jubiläum ist die Community vom alten Projektkonto auf X zu Mastodon unter @mqtt@fosstodon.org gewechselt und hat auch im ActivityPub-basierten Fediverse die erste Nachricht veröffentlicht.
Leichtgewichtiges Messaging aus einer eingeschränkten Umgebung heraus
- Im Oktober 2024 jährt sich die Veröffentlichung des Dokuments, das zur ersten Spezifikation von MQTT führte, zum 25. Mal.
- MQTT ist ein Netzwerkprotokoll, das für die kleinen und eingeschränkten Geräte sowie die leichten oder instabilen Netzwerke der späten 1990er Jahre entworfen wurde.
- Im Fokus stand, Sensordaten aus Szenarien mit unterbrochener Verbindung und begrenzter Stromversorgung – etwa bei weit entfernten Umweltüberwachungsgeräten – an größere Systeme zu senden.
- Solche Geräte müssen sparsam mit Energie, Bandbreite und Netzwerkverfügbarkeit umgehen.
- MQTT eignet sich gut dafür, Daten in einem kleinen, aber nützlichen Format zu veröffentlichen sowie zu sammeln und zu empfangen.
- Auch nachdem Netzwerke schneller und stabiler geworden sind und Edge-, Home-Automation- und mobile Geräte zugenommen haben, bleibt die Einfachheit des Protokolls eine zentrale Stärke von MQTT.
Vom IBM-Umfeld zum offenen Ökosystem
- Nach dem Einstieg bei IBM im Jahr 2001 wurden Kundenprojekte rund um IBM MQ, Business-Integration, Message Queuing, Anwendungsanbindung und Middleware durchgeführt.
- Das IBM Hursley Lab war die Basis von MQ und zugleich das Wirkungsfeld des MQTT-Mitbegründers Andy Stanford-Clark; in diesem Umfeld begannen die MQTT-Experimente.
- MQTT war damals zwar extern als Protokoll veröffentlicht, außerhalb von IBM aber weder besonders bekannt noch weit verbreitet implementiert.
- Um 2009–2011 machten die Aktivitäten Fortschritte, MQTT über den kleinen Implementierungsrahmen von IBM hinaus bekannt zu machen.
- Zu den Broker-Optionen gehörten damals der Unternehmens-Broker IBM WebSphere Message Broker, der teuer war, der Closed-Source-microbroker sowie der ebenfalls Closed Source, aber kostenlos angebotene Really Small Message Broker.
- Das Open-Source-Mosquitto von Roger Light ist bis heute eine der am weitesten verbreiteten freien Implementierungen.
- Roger Light entwickelte Mosquitto, nachdem er auf dem ersten OggCamp 2009 einen Vortrag von Andy Stanford-Clark über das vernetzte Smart Home gehört hatte – zehn Jahre nach der Entstehung der Spezifikation.
Eclipse Paho und die offizielle Standardisierung
- 2011 wurde die MQTT-Implementierung von IBM an die Eclipse-Community gespendet; daraus entstand das Projekt Eclipse Paho.
- Auch nach dem Weggang von IBM im Jahr 2012 blieb die Verbindung zum Paho-Projekt bestehen, und auch während der Zeit bei Cloud Foundry wurden dort Rollen übernommen.
- Nach dem Wechsel zu Twitter im Jahr 2014 zog man sich aus der formellen Beteiligung zurück.
- In dieser Zeit durchlief MQTT den offiziellen Standardisierungsprozess bei OASIS und ISO/IEC.
MQTT heute an unsichtbaren Stellen
- MQTT ist über die Grenzen von IBM hinaus zu einem Erfolgsbeispiel für ein offenes Protokoll geworden und steckt 25 Jahre später in zahlreichen Produkten und Umgebungen, ohne dass Nutzer es überhaupt bemerken.
- Typische Einsatzbereiche sind:
- Projekte von Hobby-Entwicklern und Makern
- Dyson-Luftreiniger und die zugehörigen Apps
- Steuerungssysteme für 3D-Drucker
- Home-Benachrichtigungssysteme
- Industrie- und Fertigungsumgebungen
- Auch im persönlichen Arbeitsbereich wird MQTT auf verschiedene Weise genutzt.
- Der 3D-Drucker Bambu Lab X1C nutzt MQTT für die interne Kommunikation.
- Vernetzte Geräte an der Wand reagieren auf MQTT-Benachrichtigungen, zeigen Daten an oder schalten Licht ein.
- Auf einem Raspberry Pi verarbeitet Node-RED MQTT-Nachrichten.
- Es ist gut möglich, dass mindestens eine App auf dem eigenen Smartphone MQTT irgendwo im Stack verwendet.
25. Jubiläum und Umzug der Community
- Das MQTT-Community-Konto ist vom bisherigen Projektkonto auf X zu Mastodon umgezogen.
- Das neue Konto kann unter @mqtt@fosstodon.org verfolgt werden.
- Zum 25. Jubiläum hat MQTT über ActivityPub seine erste Nachricht im Fediverse veröffentlicht und ist damit dem open social web beigetreten.
- Andy Stanford-Clark führte einen Fireside Chat mit HiveMQ, und auch der HiveMQ-Podcast The Unstructured Message wird als weitere Quelle für MQTT-Inhalte genannt.
1 Kommentare
Meinungen auf Hacker News
Das erste Projekt, das immer noch in Betrieb ist und täglich genutzt wird, bestand darin, eine SVG-Karte des Wasserleitungssystems für Beschneiung und Brandschutz eines großen Skigebiets – mit Rohren, Pumpen und Ventilen – zu einer Status-Website zu machen.
Für jede Pumpe, jedes Ventil und jeden Rohrabschnitt wurden MQTT-Topics angelegt und Statusinformationen wie Fließrichtung des Wassers, Ein/Aus-Zustand von Pumpen/Ventilen und Druck angehängt; mit mqtt.js und jQuery wurden Farben und Füllungen im SVG aktualisiert.
Ein per Container betriebener MQTT-Broker auf statischem Hosting läuft seit fast 10 Jahren praktisch unverändert, und mqtt.js funktioniert über WebSockets, sodass Statusänderungen automatisch bei allen ankommen.
Ich habe MQTT in einem aktuellen Projekt ausprobiert, war aber nicht besonders begeistert.
Das Protokoll hat viele Optionen, und es war nicht sofort ersichtlich, was die einzelnen Optionen tun, warum sie wichtig sind und in welcher Kombination man sie verwenden muss, damit es wie beabsichtigt funktioniert; auch die Dokumentation erklärt das nicht besonders gut.
Ein Teil davon könnte am verwendeten Eclipse-Mosquitto-Python-Client gelegen haben: Auf einem langsamen System traten Race Conditions auf, durch die Topic-Subscriptions stillschweigend ignoriert wurden und Callbacks kaputtgingen; es dauerte Tage, das herauszufinden.
Das geschah, obwohl ich mich zu 100 % an die Dokumentation hielt, und für ein nicht sonderlich altes Protokoll war es eine der chaotischsten Erfahrungen.
Meine Erfahrungen mit den Eclipse-Clients, zum Beispiel Paho in Python und C++, waren ähnlich: übermäßig komplex, fühlten sich zu niedrigstufig an, und wegen der Architektur gab es auch einige Bugs.
Vermutlich ist es im Grunde auf dem Niveau, dass fast eine einzelne Person die Wartung übernimmt, und im Lauf der Zeit ist es so geworden. Auch beim C++-Client gab es in den letzten 6 Monaten nur einen Contributor, und in den letzten 3 Monaten gar keinen.
Ein simpler PR zur Behebung eines offensichtlichen Bugs, im Umfang etwa einer Änderung eines einzelnen Wortes, brauchte 2 Jahre bis Review und Merge. Das ist nicht als Vorwurf gemeint, sondern soll heißen: Es wirkt wie ein Zustand mit vielen Libraries, Bugs und Aufgaben, die von wenigen überarbeiteten Leuten abgearbeitet werden.
Nach dem Wechsel auf andere Clients wurde die Erfahrung in Python, Rust, C# und C++ deutlich besser; meist ist die Kombination aus High-Level- und Low-Level-APIs gut, sodass man sich nicht um Acknowledgements oder Retries kümmern muss, wenn man einfach nur eine Nachricht an ein Topic senden will.
Umgekehrt kann man die Kontrolle übernehmen, wenn man sie braucht. Ich mache mir Sorgen, ob es in der aktuellen Lage nicht eher schadet, paho und Ähnliches am Leben zu halten. Wäre es offiziell tot, würden die Probleme zumindest zwangsläufig sichtbar; so machen Nutzer diese Erfahrung und geben MQTT auf oder glauben, sie selbst würden etwas falsch machen.
Mich störten das API-Design, die schwache Dokumentation und die Art und Weise, die nicht nach Python-Konventionen wirkte.
Der Einstieg wirkt zunächst einfach, aber die Breite des Protokolls und der Implementierung wird einem zunehmend zum Verhängnis. Eine Zeit lang bestand die zuverlässige Methode, zu prüfen, ob eine Verbindung zum Server erfolgreich hergestellt wurde, darin, dasselbe Topic zweimal zu abonnieren und einen bestimmten Fehlercode in der
on_connect-Nachricht abzufangen. In der Dokumentation war dieser Code damals als Erfolgscode angegeben.Mir ist klar, dass das absurd klingt, aber selbst wenn es eine bessere Methode gab, war sie nicht leicht zu finden. Trotzdem ist Meckern einfach, und ich bin den vielen Leuten dankbar, die diese Library gebaut haben. Ohne sie hätte ich das, was ich heute gebaut habe, nicht bauen können, und ich habe Respekt vor Menschen, die solche riesigen Projekte übernehmen.
Wenn möglich, lasse ich das Protokoll lieber von
mosquitto_subundmosquitto_puberledigen und lese bzw. schreibe nur über Standard-Ein-/Ausgabe.Das lag nicht nur an Bugs; es war einfach leichter, die Verwaltung der Broker-Verbindung einem bereits geschriebenen und getesteten Programm zu überlassen.
Bei Last-Will-Messages ließ sich dieser Ansatz allerdings nicht effektiv nutzen, und für Mikrocontroller, auf denen nichts wie Linux läuft, passt er ebenfalls nicht.
Im Grunde baut es ein authentifiziertes Netzwerk-*nix-Pipe-System und zielt darauf ab, die einfachste Möglichkeit zum Senden und Empfangen von Events zu sein.
Für meinen Use Case waren unendliche Warteschlangen wichtig, und MQTT bot das nicht; wenn ich ohnehin wieder Message-IDs verwalten muss, damit MQTT seine eigenen Message-IDs verfolgt und an den Broker sendet, gab es für mich keinen Grund, es zu nutzen.
Wenn man nicht gerade mit Projekten integriert, die bereits auf MQTT ausgelegt sind, ist mir nicht ganz klar, wofür es am besten geeignet ist.
In den letzten Jahren wird MQTT deutlich häufiger genutzt, um innerhalb von Fabriken Daten zwischen Maschinen auszutauschen.
Historisch wurde es im Oil-&-Gas-Bereich für SCADA eingesetzt, um Daten von entfernten Bohrloch-Standorten abzurufen.
Vor mehr als zehn Jahren habe ich MQTT zu Kepware (OPC-Server) hinzugefügt und Tag-Werte in die „Cloud“ gestreamt; nach der Präsentation kam Arlen Nipper, einer der MQTT-Erfinder, zu mir und sagte, das sei „ganz ordentlich gemacht“, was mich ziemlich demütig gemacht hat.
Heute arbeiten wir in einem neuen Unternehmen namens HighByte daran, Fabrikdaten am Edge zu modellieren und sie an MQTT, SparkplugB (ein Protokoll über MQTT), S3, Azure Blob usw. zu senden.
Kurz gesagt: MQTT ist ein großer Treiber von Industry 4.0, und es ist beeindruckend, dass es nach so langer Zeit immer noch so viel genutzt wird.
Das ist etwas grob und hat mehr Verarbeitungsschritte, als uns lieb ist. Da Kepware für das IoT-Plugin jährlich wiederkehrende Lizenzkosten berechnet, bewegen wir uns inzwischen von dieser Lösung weg und lassen telegraf OPC-UA-Daten direkt aus Kepware lesen.
Ich frage mich, ob du bei Kepware gearbeitet hast oder dort arbeitest.
Ich wünschte, sie würden einfach Sparkplug B verwenden und darauf eine Spezifikation für Semantik implementieren.
Außerdem ist die aktuelle Arbeit rund um Asynchronität völlig over-engineered und schlecht. Ich habe eine Weile an den Meetings teilgenommen, und obwohl die MQTT-Spezifikation nicht einmal 50 Seiten lang und leicht zu lesen ist, hatten sie sie nie gelesen und verstanden nicht, wozu Header da sind. Zum Beispiel wollten sie Dinge in Header packen, die eigentlich in die Payload gehören.
Eine Person von Microsoft war sogar beleidigt bei dem Vorschlag, sich zuerst anzusehen, was Wettbewerber mit MQTT machen. Sie wollten lieber etwas neu erfinden als kopieren.
Auf meinen Vorschlag hin wird unser Unternehmen OPC UA nur ganz am Edge behandeln und es so weit wie möglich von unserer eigenen Technik isolieren.
Allerdings sehe ich heutzutage auch, dass Kafka und RabbitMQ stärker in den Marktbereich von MQTT vordringen.
Vor etwa 15 Jahren, als twitternde IoT-Geräte noch nicht alltäglich waren, machte Andy Stanford Clarks Haus Schlagzeilen.
https://www.bbc.co.uk/blogs/technology/2009/06/things_that_t...
Das Kernprotokoll wurde in einer Zeit entworfen, in der die Übertragung eines einzelnen Bytes über eine Satellitenverbindung einen Dollar kostete; es ist daher unglaublich effizient und auch einfach zu implementieren.
Früher gab es einmal bei der Firewall eines Kunden nur einen einzigen nutzbaren Port: MQTT 1883.
Weil darüber Sensordaten empfangen wurden, und egal wie oft wir fragten, sie wollten keinen anderen Port öffnen. Also bauten wir als Workaround einen Echtzeit-TCP-Wrapper über MQTT.
Ein lokaler multithreaded TCP-Daemon lauschte auf ausgehende Requests an einem bestimmten Port, verpackte sie in MQTT und veröffentlichte sie auf einem eindeutigen Topic; der Server-Daemon beobachtete dieses Topic, entpackte die Daten und leitete sie an den Serverprozess weiter.
Aus Sicht der Client-Maschine sah es so aus, als würde sie eine Echtzeit-TCP-Verbindung zu unserem Server aufbauen, aber dazwischen lag ein unsichtbarer, seltsamer MQTT-Wrapper.
Nachdem es funktionierte, war es elegant, aber das Debugging war wirklich qualvoll, und es dauerte Monate mit mehreren Sackgassen, bis das Ganze richtig zusammenspielte.
Heute nennt man Situationen, in denen man nichts tun kann und nur Däumchen dreht, „den Prozess arbeiten lassen“.
Interessanterweise prüft Boost, die bekannteste C++-Bibliothek, gerade zur selben Zeit, ob die
async-mqtt5-Implementierung (https://github.com/mireo/async-mqtt5) als Boost.MQTT aufgenommen werden soll: https://lists.boost.org/Archives/boost/2024/10/index.phpAnekdotisch war die Einführung meist in den 2000ern und sehr frühen 2010ern, also bevor alle C++0x/C++11 voraussetzten; heutzutage sehe ich es nur noch selten.
boost.org wirkt wie eine Zeitreise. Es sieht genauso aus, wie ich es etwa aus 2008 in Erinnerung habe, inklusive des auf den Not-Aus-Knopf montierten „Get Boost“.
MQTT ist wirklich ein gutes kleines Protokoll: nicht nur „klein genug“ für Hobbyprojekte, sondern auch skalierbar genug, um in Dingen wie Facebook Messenger eingesetzt zu werden.
[1]: https://engineering.fb.com/2011/08/12/android/building-faceb...
Dass MQTT als leichtgewichtig und effizient beworben wird, überzeugt mich nicht wirklich
Letztlich nutzt es einfach TCP/IP, und nach damaligen Maßstäben war das vielleicht relativ besonders, aber echte Belege für diese Behauptung habe ich außer wiederholtem Eigenlob nie gesehen
Dass es ein Standard ist und man sich daher mit unterstützten Geräten von der Stange verbinden kann, ist gut. Trotzdem sehe ich für Publish/Subscribe oder Message Queues bessere Optionen, besonders wenn auf Consumer-Seite Failover nötig ist
Das Gute an MQTT – und der Punkt, den fast alle anderen Publish/Subscribe-Implementierungen, die ich gesehen habe, falsch machen – ist, dass die zentrale Datenstruktur von MQTT nicht Queues und Topics sind, sondern abonnierende Clients
Dadurch kann man einen beliebig großen Adressraum auf einen Topic-Baum abbilden. Der Topic-Baum darf Billionen von Endpunkten haben, und wenn man will, kann man sogar auf einem Embedded-Server für jede IPv6-Adresse einen eigenen Endpunkt vorsehen
Weil der Topic-Baum so reichhaltig ist, lassen sich Abonnements so selektiv gestalten wie nötig, und der Server kann auch mit geringem Ressourcenverbrauch schnell arbeiten
Ich habe MQTT über mehrere Jahre in IoT-Kursen eingesetzt, und es hat sich als sehr vielseitiges Werkzeug erwiesen
Praktisch ist auch, dass es über WebSockets unterstützt wird
In einem aktuellen Embedded-Systems-Projekt habe ich MQTT als Messaging-System zwischen Prozessen verwendet, was ziemlich interessant war
Broker und Clients liefen auf derselben Maschine
Wenn man etwas sniffen oder debuggen musste, konnte man das Gerät einfach ins Netzwerk hängen und mit MQTT Explorer Nachrichten aufzeichnen oder injizieren, was sehr einfach war
Man konnte auch einen Port nach außerhalb des LAN öffnen, damit ein remote arbeitender Kollege mit dem System interagieren konnte
Meine größte Sorge beim Einsatz als Systemkomponente sind Garantien zur Dauerhaftigkeit, und ich habe nicht viel Vertrauen, dass eine Broker-Implementierung keine Daten verliert