++ 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.

• Eine Überwachung des Zustands kann direkt als virtueller Eingang eingerichtet werden (keepaliveepoch) 

- 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.

• Wird mit IP-Adressen gearbeitet, müssen an den Geräten feste IP-Adressen, oder feste DHCP-Leases vergeben werden.
• Je nach Infrastruktur und Netzwerk-Erfahrung könnte ein Wechsel des Internet Routers schon erhebliche Sorgen verursachen.

+ Ausschließlich der MQTT Broker (also der LoxBerry) muss IMMER erreichbar sein (egal ob mit Hostname oder fester IP)

• Alle Geräte (der Miniserver und alle MQTT-Geräte) verbinden immer zum MQTT Broker.
• Da der Broker selbst nie eine Verbindung zu den Geräten aufbaut, sondern die Geräte zum Broker, benötigt der Broker weder Hostname noch IP-Adresse der Geräte. 

+ 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.

-- 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.

• Dies multipliziert sich weiter, wenn ein Gerät mehrere URLs benötigt, um alle Daten einzusammeln.
• Dies multipliziert sich nochmals für jedes weitere Gerät.
• Loxone erlaubt keine Abfrage von Daten "on demand" (z.B. nur bei Anwesenheit, nur wenn eine Logik eine Abfrage auslöst,...)
• Beispielsweise die Abfrage eines Tastendrucks oder Doppelklicks kann damit überhaupt nicht realisiert werden. 

++ 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.

- 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).

• 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.