Metainformationen zur Seite
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. MQTT ist eine offene Verbindung zwischen Gerät und Broker. Das Gerät sendet bei einer Änderung sofort diese Daten an den Broker. * Damit gibt es faktisch keine Wartezeit, bis die Daten übertragen werden. * Wenn hingegen keine Daten zu melden sind, passiert einfach nichts (kein sinnloses Pollen) * Die Strommessdaten der Shellys werden beispielsweise immer aktualisiert (auch mehrmals pro Sekunde, wenn erforderlich) - bleibt der Verbrauch dann aber konstant, müssen keine neuen Daten übertragen werden. * Beispielsweise wird der Tastendruck oder Doppelklick auf einen Taster "on-the-fly" übertragen und kann verwendet werden. | |
| - 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 Übertragung vom Gerät zum MQTT Gateway erfolgt standardisiert, es gibt hier keine unterschiedlichen Methoden. |
| - 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 "pure" Wert → wird direkt übermittelt * Ein JSON-Datensatz (auch verschachtelt) → Das MQTT Gateway zerlegt diese Daten, sodass am Miniserver die eindeutigen Werte einzeln übernommen werden können. |
| - 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.) * Diese Texte müssen mit komplizierten Befehlserkennungen (\1 um einen ASCII-Code eines Buchstabens zu erhalten, dann wieder zusammensetzen mittels Statusbaustein) erfolgen. | Für textuelle Stati gibt es im MQTT Gateway zwei Verfahren:\\ \\ * Booleans (z.B. "on", "off", "true", "false",...) werden vom MQTT Gateway vollkommen automatisch in die numerischen Entsprechungen 1 oder 0 übersetzt.\\ * Spezielle Texte, wie den Status von Fenstern ("offen", "gekippt", "geschlossen") können per Conversion in selbst definierbare Werte (z.B. 1, 2, 3) übersetzt werden, und damit kann im Miniserver direkt weitergearbeitet werden.\\ * Per Conversion können auch Texte in andere Texte konvertiert werden: z.B. "undefined" nach "Keine Information verfügbar", um dies in einem Virtuellen Texteingang anzuzeigen.\\ * Fertige Conversions können von LoxBerry Plugins mitgeliefert werden, die MQTT unterstützen. 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). * Das MQTT Gateway erkennt gleiche Daten, und übermittelt nur Änderungen an den Miniserver. * Dies entlastet den Miniserver wesentlich, da die Übertragung vieler gleicher Werte einfach wegfällt. * Daten, die man nie am Miniserver benötigt, kann man explizit wegschalten |
| - 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: * Die Wertvalidierung setzt einen Standardwert, der zu Fehlverhalten in der Logik führen kann, und daher selbst wieder extra behandelt werden muss. * Liefert der HTTP-Abruf ein unerwartetes Ergebnis (z.B. eine Fehlermeldung), sodass die Befehlserkennung den Wert nicht mehr findet, geht der "Fehlerausgang" nicht auf 1 und der letzte Wert bleibt erhalten. 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. * Dieser Status kann genauso wie andere Virtuelle Eingänge benutzt und für eigene Validierungszwecke weiterverarbeitet werden. * MQTT-Geräte gehen automatisch auf "offline", ohne dass dies extra abgefragt werden müsste. * Die Aktivität des MQTT Gateways selbst kann mit dem "keepaliveepoch"-Topic überwacht werden. |
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.