Wann und warum soll das MQTT-Protokoll verwendet werden?

Ich entwickle ein Gerät, das Temperatur, Luftfeuchtigkeit und Masse misst. Derzeit wird HTTPS zum Hochladen von Daten auf einen Remote-Server verwendet. Jetzt weiß ich, dass es ein Protokoll namens MQTT gibt, das angeblich das "Protokoll des Internets der Dinge" ist.

In welchem ​​Fall und warum sollte ich von HTTPS zu MQTT wechseln?

MQTT ist ein "Messenger" zwischen Geräten:

• Ihr Gerät misst zum Zeitpunkt T eine Temperatur von X Grad
• Es verbindet sich (selbst oder über den zwave Hub) mit dem MQTT-Broker
• Es wird eine Nachricht mit dem Thema erstellt /domotics/myplace/mydevice/temperature
• innerhalb der Nachricht setzt es nur X(als "Nutzlast")

An anderer Stelle in Ihrem Haus:

• Ihr Raspberry Pi ist mit dem MQTT-Broker verbunden (es kann die MQTT-Instanz selbst sein)
• Es abonniert das Thema /domotics/+/+/temperature, um ALLE Temperaturinformationen von allen Geräten zu erhalten, die dieses Themenformat verwenden. Weitere Informationen zu MQTT-Themenplatzhaltern ( und ) finden Sie in der MQTT-Spezifikation .+#
• Es wird eine Nachricht mit der Nutzlast erhalten Xund tun, was es will!

An anderer Stelle in Ihrem Haus:

• Ihr Computer ist mit dem MQTT-Broker verbunden und abonniert das Thema /domotics/myplace/mydevice/#, um ALLE Informationen von Ihrem Gerät abzurufen und zu protokollieren
• Es wird eine Nachricht mit der Nutzlast erhalten Xund tun, was es will!

MQTT ist sehr nützlich, um zu vermeiden, dass Ihre Server von Webdiensten und Sockets umgeben werden. Node-RED verwendet MQTT und Domoticz kann so konfiguriert werden, dass Signale empfangen inund gesetzt outwerden.

Ich persönlich benutze MQTT bei mir zu Hause, um Computer auszuschalten: /house/computers/mycomputerNutzlast:0

MQ Telemetry Transport Protocol bekannt als MQTT ist für Geräte entwickelt , die auf niedriger Leistung und niedriger Bandbreite laufen. Es handelt sich um ein einfaches Publish / Subscribe-Nachrichtenprotokoll, das bedeutet, dass jedes andere Gerät ein bestimmtes Thema abonnieren kann.

HTTP / HTTPS ist als Anforderungs-Antwort-Protokoll für Client-Server-Computing konzipiert, das sich nie um den Stromverbrauch kümmert und einen hohen Datenaufwand hat.

Verwenden Sie MQTT, wenn:

• Das von Ihnen verwendete Gerät wird mit einer Batteriezelle betrieben und Sie möchten diese nicht alle x Tage ersetzen (MQTT ist für die Batterieverwendung optimiert, HTTP / S hingegen nicht).
• Brauche schnellere Antwort
• Pub / Sub-Mechanismus erforderlich (Wenn Sie Nachrichten an viele Clients senden möchten)
• Daten müssen zuverlässig mit unterschiedlichen QoS-Stufen gesendet werden

Bietet MQTT so viel Sicherheit wie HTTPS?

MQTT basiert auf TCP als Transportprotokoll, was bedeutet, dass die Verbindung standardmäßig keine verschlüsselte Kommunikation verwendet. Um die gesamte MQTT-Kommunikation zu verschlüsseln, erlauben die meisten MQTT-Broker - wie HiveMQ - die Verwendung von TLS anstelle von einfachem TCP.

Ref: HiveMQ

MQTT (Message Queue Telemetry Transport) scheint für die vorgeschlagene Anwendung gut geeignet zu sein.

Es ist sowohl in Bezug auf die Bandbreite (kleinste Paketgröße mit einem Header von nur 2 Bytes) als auch in Bezug auf den Client-Code-Footprint (damit es auf Thin Clients wie dem ESP8266, einem typischen IoT-Client, ausgeführt werden kann) leicht. Reduzierte übertragene Daten verlängern die Batterielebensdauer für netzunabhängige batteriebetriebene Clients wie Sensoren.

MQTT bietet auch einfache Methoden ( Verben ), die sich gut für IoT-Aufgaben eignen, z. B. dauerhafte Abonnements, mit denen Verbindungen nach unerwarteten Clienttrennungen wiederhergestellt werden. Im Vergleich zu HTTP / HTTPS ist es auch einfacher, Daten aus dem Paket zu extrahieren (kein Parser erforderlich).

Hier habe ich einen Artikel geschrieben, der die Entwicklung des Kommunikationssystems in unserem Projekt zeigt. Es geht um Mikrodienste, aber Sie können jeden Sensor als Mikrodienst betrachten, der für das Sammeln und Veröffentlichen von Telemetriedaten jeglicher Art zuständig ist.

Die wichtigste Schlussfolgerung ist also, dass es besser ist, MQTT zu verwenden, wenn Sie nur ein Ereignis an einen anderen Ort senden müssen und nichts über den Empfänger wissen. Und es ist viel besser, HTTP (normalerweise REST) ​​zu verwenden, wenn Sie etwas über den Empfänger wissen und eine Antwort benötigen - z. B. bei Befehlen jeglicher Art.

Aus Sicht des Datenverkehrs, der CPU, des Speichers und des Energieverbrauchs sind MQTT und HTTP im Wesentlichen gleich.

In Bezug auf Ihr Zitat ist MQTT das "Protokoll des Internets der Dinge":

Ja, es gibt eine große Anzahl von Entwicklern, die dieses Protokoll verwenden (siehe IoT Developer Survey 2018), aber CoAP (es ist HTTP-angepasst für IoT, basierend auf UDP) bietet eine Alternative für HTTP, falls Sie eine einfache Anforderungs- / Antwortfunktion verwenden möchten Ihre Bewerbung.

MQTT hingegen bietet eine integrierte Publish / Subscribe-Logik, die sich hervorragend für die Skalierung eignet (Sie können mehr Gateways für eine größere Anzahl von Geräten verwenden). Es gibt auch eine UDP-Alternative (wie CoAP zu HTTP), die MQTT-SN (MQTT for Sensor Networks) heißt. Dies bietet einen noch geringeren Overhead als CoAP, macht jedoch keinen Gebrauch von R / R.