MQTT vs. HTTP - Vorteile und Nachteile
Eine häufig gestellte Frage im LoxForum ist: "Was bringt mir die Anbindung per MQTT im Vergleich zu HTTP?"
Diese Frage liest man meist im Zusammenhang mit Shelly-Geräten, aber auch mit anderen sowohl HTTP- als auch MQTT-fähigen Geräten, wenn es darum geht, diese Geräte mittels HTTP anzusteuern, oder mittels MQTT Gateway Plugin.
Hier gehen wir der Sache, am Beispiel eines Shelly 1 PM (Shelly 16A Aktor mit Strommessung) auf den Grund.
Die Wertungen sind ein gewisser Anhaltspunkt. Es kann natürlich jeder für sich entscheiden, wie wichtig ein Thema beim eigenen Betrieb ist.
Daten senden (Miniserver → Gerät)
In Bezug auf Shelly-Geräte könnte das Senden von Daten zum Beispiel das Ein- und Ausschalten eines Relais sein, oder das Einstellen des Dimming-Levels, oder die RGB-Farbe eines LED-Bandes.
HTTP-Verbindung Pro Gerät ein Virtueller HTTP-Ausgang; Virtuelle Ausgangsbefehle | MQTT-Verbindung Einmalig ein Virtueller UDP-Ausgang; Virtuelle Ausgangsbefehle |
---|---|
++ Es handelt sich um eine DIREKTE Verbindung vom Miniserver zum Gerät - kein zusätzliches Gerät (LoxBerry) dazwischen. Damit ist diese Lösung ausfallssicherer. | - Wenn der LoxBerry ausfällt, kann das Gerät nicht mehr gesteuert werden.
|
- Es gibt kein direktes Feedback, ob die Schaltaktion ausgeführt wurde (Loxone kann die Antwort des HTTP-Befehls nicht auswerten). | + Eine Statusänderung des Geräts wird sofort per MQTT zurück übertragen. |
+ Am Gerät muss keine besondere Einrichtung erfolgen (außer evt. Zugangsdaten definieren). Alles wird in der Loxone Config definiert. | - Am Gerät müssen einmalig die Zugangsdaten zum MQTT Broker angegeben werden. |
+ Die Schaltaktion oder Wertänderung wird möglicherweise schneller ausgeführt. | - Durch das Processing am LoxBerry kann - je nach Raspberry-Modell - mit einer Verzögerung von 5 bis 10 ms gerechnet werden, bis der Befehl am Gerät ankommt. |
- Die HTTP-Übertragung vom Miniserver hat größeren Protokoll-Overhead, der vom Miniserver und dem Empfängergerät verarbeitet werden muss. | + Die UDP-Verbindung vom Miniserver zum MQTT Gateway ist sehr schlank. UDP erfordert keine Rückmeldung an den Miniserver. Die MQTT-Verbindung selbst ist eine offene Verbindung und wird binär übertragen, kein eigener Verbindungsaufbau erforderlich. |
O Für mehrere Geräte müssen mehrere Virtuelle Ausgänge und Virtuelle Ausgangs-Befehle eingerichtet werden. | + Es wird nur ein Virtueller Ausgang zum MQTT Gateway eingerichtet. Alle Geräte sind unter diesem virtuellen Ausgang mit verschiedenen Befehlen eingerichtet. |
O Die Netzwerkinfrastruktur (Hostnamen, IP-Adressen) muss korrekt gepflegt werden. Wird mit Hostnamen gearbeitet, muss der DNS-Server für alle Geräte immer korrekt funktionieren.
| + Ausschließlich der MQTT Broker (also der LoxBerry) muss IMMER erreichbar sein (egal ob mit Hostname oder fester IP)
|
+ Shelly verwendet eine klare HTTP API als REST Interface (GET-Requests) - Andere Geräte oder Software verwendet möglicherweise ganz andere Aufruf-Syntaxen, mit Query-Parametern, POST- oder PUT-Requests, Digest Authentication,... Jeder Hersteller hat hier eigene Anforderungen. | + MQTT hat einen standardisierte, klaren Aufbau (Topics), wie Parameter an ein bestimmtes Gerät übertragen werden. Die Parameter jedes Gerätes sind individuell, folgen aber der klaren Struktur von MQTT. + Geräte oder Software anderer Hersteller, die MQTT-fähig sind, haben zwar andere Parameter, aber die gleiche Struktur. |
Daten empfangen (Gerät→ Miniserver)
In Bezug auf Shelly-Geräte könnte das der Relais-Status des Geräts sein, oder eingestellten Farbwerte, bei Geräte mit Senoren die Temperatur oder Luftfeuchte, ein Tastendruck, Fensterkontakte oder bei Geräten mit Strommessung die aktuelle Leistungsaufnahme in Watt.
Hier unterscheidet sich HTTP von MQTT wesentlich: Bei MQTT werden Daten direkt geliefert, während bei HTTP der Miniserver die Daten 24/7 in einem starren Intervall abfragen muss.
HTTP-Verbindung Pro Gerät URL ein Virtueller HTTP-Eingang; Virtuelle Eingangsbefehle mit Befehlserkennungen | MQTT-Verbindung Für jeden Wert ein Virtueller Eingang |
---|---|
-- Das minimale Abfrageintervall von Loxone ist 10 Sekunden. D.h. egal ob eine Änderung passiert ist oder nicht, wird mit dem von Loxone vorgegebenen Minimalintervall 14.400 mal pro Tag eine URL abgerufen.
| ++ MQTT ist eine offene Verbindung zwischen Gerät und Broker. Das Gerät sendet bei einer Änderung sofort diese Daten an den Broker.
|
- Jede einzelne Befehlserkennung innerhalb eines Virtuellen HTTP-Eingangs löst eine Suche innerhalb der HTTP-Antwort aus und belastet damit RAM und CPU des Miniservers | + Jeder einzelne Datensatz wird genau in seinen fest definierten Virtuellen Eingang geschrieben. Am Miniserver ist keine Suche in einem HTML oder dergleichen erforderlich. |
- Loxone unterstützt nur GET-Requests (keinen POST- oder PUT-, keine Request Header usw.) | + Die Übertragung von MQTT ist standardisiert.
|
- Die Erstellung von Befehlserkennungen kann - je nach Art der Antwort - sehr mühsam sein, oder das Finden des Datensatzes ist überhaupt nicht möglich. | + Daten werden bei MQTT in zwei Arten übertragen:
|
- Der Virtuelle HTTP-Eingang unterstützt keine Texte. Texte können nicht dargestellt werden. | + Wird in Loxone statt eines "Virtuellen Eingangs" ein "Virtueller Texteingang" erzeugt, wird der per MQTT übermittelte Text für die Miniserver-Visualisierung übermittelt. |
- Der Virtuelle HTTP-Eingang unterstützt keine textuellen Stati ("ein", "aus", "true", "false", "open", "closed" usw.)
| ++ Für textuelle Stati gibt es im MQTT Gateway zwei Verfahren:
|
- Gleiche Stati werden immer und immer wieder abgefragt. Auch Daten, die man in der HTTP-Antwort nicht benötigt, müssen durchsucht werden. | ++ Auch bei MQTT ist es möglich, dass ein Gerät regelmäßig seinen aktuellen Status übermittelt (beispielsweise Shelly übermittelt per MQTT zusätzlich zu direkten Statusänderungen auch alle 120 Sekunden den aktuellen Status).
|
- Der Ausfall eines Geräts kann frühestens erkannt werden, wenn es das nächste Mal abgefragt wird, und das auch nicht eindeutig. Der "Fehlerausgang" von Loxone ist fehlerhaft und unausgereift:
Damit ist keine sicheres Fehlerhandling möglich. | + Die Technik des "Last Will And Testament" (LWT) von MQTT ermöglicht es, dass ein ausgefallenes Gerät automatisch als "Offline" gemeldet wird, wenn es ausgefallen ist.
|
Allgemein
- Durchaus kann es Sinn machen, den Kompromiss zu wählen, und die Steuerung per HTTP durchzuführen, aber die Statusrückmeldung per MQTT zu empfangen (diesen Ansatz verwendet beispielsweise das NUKI SmartLock Plugin).
- Hast du es mittels MQTT Gateway einmal geschafft, die Vorgehensweise zur Einrichtung in beide Richtungen hinzubekommen, ist die Systematik bei allen weiteren Geräten immer die gleiche.
- Es steht auf der Roadmap von LoxBerry, dass das MQTT Gateway Plugin in den LoxBerry-Core übernommen wird und somit jedem LoxBerry ohne zusätzliche Installation zur Verfügung steht.
- Die Verwendung von MQTT zur Übertragung von Daten von einem Plugin an den Miniserver ist die Empfehlung für neue LoxBerry-Plugins. Für Benutzer bringt das eine einheitliche Einrichtung, für Entwickler den Wegfall der komplexen UIs zur Definition der Übertragungsweise und die Vereinfachung der Datensammlung/Übertragung im Plugin.