MQTT Gateway V2.0 ist das größte Feature- und Performance-Release, seit es das MQTT Gateway gibt. Viele Punkte, die sich als Fragen oder Unklarheiten im Forum wiederfinden, sind im UI nun klarer dargestellt, bzw. als neue Features enthalten.

Hier eine Übersicht der Neuerungen:

Auf der Settings-Seite gibt es unten jetzt eine zusätzliche Lasche zum Aufklappen, wo es "Still more settings" (Noch mehr Einstellungen) gibt.

Dort kann derzeit (nur) die Verarbeitungsgeschwindigkeit des MQTT Gateways eingestellt werden.

Die Einstellung regelt, wie viel CPU-Zeit das Gateway zur Abarbeitung der Nachrichten (in beide Richtungen) beanspruchen darf. Bislang gab es pro Abarbeitung eine feste "Zwangspause", die aber dazu geführt hat, dass beispielsweise eingehende Tastendrücke doch spürbar verzögert sein konnten.

Ab dieser Version wird mittels eines integrierten Reglers auf die gewünschte CPU-Belastung ausgeregelt. Diese Logik passt sich nun automatisch an die Systemgeschwindigkeit, und an die Anzahl und den Durchsatz der zu übertragenden Daten an. Die Regelung läuft kontinuierlich, etwaige Lastspitzen werden ausgeglichen. Weil die CPU-Belastung nicht linear, sondern eine exponentielle Kurve ist, ist die Regelgeschwindigkeit relativ langsam eingestellt. Eine Änderung der Performance-Einstellung dauert einige Minuten, bis sie spürbar wird. 

Standardwert ist "Fast (Default)", was im Vergleich zu den Version 1.x in etwa einer zehnfachen Beschleunigung entspricht (auf einem Raspberry Pi 1 / Zero ca. dreifach).
Die Einstellung "Moderate" ist etwa dreimal so schnell wie früher, "Energy Saver" wird (je nach Hardware) vermutlich langsamer sein als früher, und ist für Taster-Übertragungen eher nicht geeignet.
Mit der Einstellung "Very fast" ist praktisch keine Verzögerung mehr spürbar ("lippensynchron "), wohingegen mit "NO LIMITS!" je nach Hardware der LoxBerry fast voll ausgelastet ist und alles andere träge wird. 

Wenn du willst, kannst du die Wirkung der Regelung beobachten, indem du an der Shell mit top die CPU-Auslastung des mqttgateway.pl Prozesses verfolgst. Die Regelanpassung passiert im Minutentakt.

Der Mosquitto WebSocket-Port (bisher fest Port 9001) ist nun konfigurierbar. Standardmäßig wird weiterhin 9001 verwendet.

Achtung beim Update: Wenn Use the local Mosquitto MQTT broker aktiviert ist, wird der Port 9001 beim Update neu in die Mosquitto-Konfiguration geschrieben. 

In den Subscriptions findest du jetzt zusätzlich die Subscription Filter Expressions (RegEx), mit denen per RegEx Daten aus den Subscriptions weggefiltert werden können. Diese Filterung passiert nach der JSON-Expandierung, d.h. es ist per RegEx möglich, auch aus einem JSON-Datensatz vom Gerät übertragene Informationen wegzufiltern, die du am Miniserver nie brauchst. Damit entlastest du (zusätzlich zum eingebauten Cache) den Miniserver.

Jede Zeile entspricht einem RegEx-Filter. Trifft eine Zeile zu, wird der Datensatz nicht an den Miniserver übertragen.

Die Filterung passiert gleichermaßen bei HTTP- und UDP-Übertragung. Bitte beachte, dass sowohl für HTTP als auch UDP im Filter der Unterstrich _ als Topic-Trenner zu verwenden ist.

Gefilterte Topics/Werte werden nach kurzer Zeit direkt in der Incoming Overview dargestellt (ausgegraut und durchgestrichen). Wenn du "Show details and advanced settings" in der Incoming Overview aktivierst, kannst du sogar nachsehen, welche Zeile im Filter für das Ausfiltern verantwortlich ist.  

Die Incoming Overview hat ein überarbeitetes Erscheinungsbild. Die Symbole ganz links zeigen, ob

•  die letzte Übertragung erfolgreich war, oder 
•  der VI am Miniserver nicht existiert,
•  der Datensatz seit dem letzten Start noch nicht übertragen wurde,
•  der Datensatz gefiltert wurde, oder ob vielleicht
•  das Gateway keine Berechtigungen auf den VI am Miniserver hat. 

Ältere Miniserver-Firmware

Ältere Miniserver-Firmwarestände (ich glaube, vor V10?) zeigen immer  Access denied an, egal ob der Eingang nicht existiert oder tatsächlich der Zugriff verweigert wurde.

Das neue Lösch-Symbol  ist jetzt immer sichtbar und näher heran gerückt.

Mit dem Filter oben können die VIs jetzt nach diesen Stati gefiltert werden, um schnell z.B. jene VIs zu finden, die nicht funktionieren, oder nicht am Miniserver angelegt sind.

Die Checkbox "Show Advanced Table Information" heißt jetzt "Show details and advanced settings", weil das klarer macht, was sich dahinter verbirgt.

Die Darstellung bei aktiver "Details and advanced settings" haben sich ebenfalls verändert:  Um mehr Platz zu schaffen, sind die Checkboxen für Disable cache, Reset after send und Do not forward nun nebeneinander unter das Topic gerutscht. Rechts beim Zeitstempel gibt es jetzt zusätzlich die Information, wann tatsächlich der letzte Zustellversuch zum Miniserver war und wie dieser ausgegangen ist. Wenn du Subscriptions an mehrere Miniserver sendest, steht dort der Status für jeden Miniserver.

Als kleine Unterstützung wird das „Show Details“ Häckchen und der Textfilter jetzt während einer Browsersitzung gespeichert.

Der markierte Knopf ist umbenannt auf "Delete cache (for testing)", weil "Retransmit all data" irreführend war. Wenn man diesen Knopf drückt, wird der Cache des Gateways zurückgesetzt, gleichzeitig werden alle Übertragungsstati (die bunten Icons) zurückgesetzt, sodass man kontrollieren kann, ob die nächste Übermittlung klappt. Nach dem Anlegen der VIs am Miniserver sollte man einmal diesen Knopf drücken, damit die Daten bei der nächsten Einlieferung neu übertragen werden. 

• Die Übersicht wird nun etwa 3-4x so schnell dargestellt, der Webbrowser kommt bei großen Datenmengen nicht mehr so leicht ins Wanken.
• Werden die Filter oben benutzt, beschleunigt sich die Darstellung nochmals deutlich. 
• Der Abruf der Datenpakete und das Ändern von Einstellungen am LoxBery geht etwa 10x so schnell.
• Die Änderungen der Einstellungen "Disable cache", "Reset after send" und "Do not forward" werden unmittelbar übernommen (kein "Flackern" des Häckchens mehr). 

Transformers sind Scripts, die du erstellen kannst (bzw. auch mitgeliefert werden), um vom Miniserver eingehende Daten zu transformieren, also an das Zielsystem anzupassen. Der Aufruf eines UDP Transformers erfolgt direkt im Virtuellen Ausgangsbefehl. Wird der Transformer aufgerufen, wird das hinterlegte Transformer-Script ausgeführt, darin nach deinen Wünschen die Daten geändert, und dann an MQTT weitergesendet. 

Ein Anwendungsbeispiel, das auch mitgeliefert wird, ist der shelly_rgb&w Transformer, der den von Loxone eingehenden RGB-Wert zerlegt, in 0-255 umrechnet, und das Ergebnis als JSON an den Shelly RGBW2 weitergibt. 

Alle Infos dazu findest du hier: MQTT Gateway - UDP Transformers. Die Erklärung des mitgelieferten shelly_rgb&w Transformers findest du hier: UDP Transformer - shelly_rgb&w.

Wenn ihr testweise etwas an den MQTT Broker publishen wollt, egal ob mit Transformer oder nicht, verwendet den MQTT Gateway Quick Publisher (Link bei den Transformers). Der Quick Publisher ist bereits seit mehr als einem Jahr in der Hilfe (rechts beim Info-Symbol) zu finden, aber ich glaube, keiner weiß das 

Der Quick Publisher erlaubt nun auch die Verwendung von UDP Transformers. Im Formular eingegebene Daten werden im Browser gespeichert, wenn man das Fenster mal unabsichtlich schließt. 

Es ist nun möglich, den Loglevel des MQTT Gateways selbst einzustellen. LoxBerry setzt bei der Installation den Loglevel auf "Error". Ich empfehle, den Loglevel auf "Warnung" zu setzen (das MQTT Gateway gibt Warnungen im Logfile aus, wenn es Probleme bei den Einstellungen erkennt, die zwar die Verarbeitung nicht behindern, aber dich darauf hinweisen, dass etwas möglicherweise nicht passt).

Jegliche Fragen im Forum bitte immer mit Logfiles im Debug-Modus untermauern. Eine Anpassung des Loglevels wird - ohne Neustart des Gateways - nach ca. einer Minute übernommen. Ohne Debug-Modus sieht man im Log über den Ablauf des Processing praktisch garnichts. 
Wenn die zehnte Anfrage im Forum mit einem Log im Error-Standard-Modus kommt, setze ich den Loglevel wieder fix auf DEBUG!

Das MQTT Gateway ist jetzt standardmäßig ein Empfänger für Loxone Logger-Nachrichten. Dieses Nachrichten werden geparst und an den MQTT Broker weitergeleitet.

Diese Funktion muss am MQTT Gateway nicht aktiviert werden, sondern ist immer aktiv. Wie du in Loxone einen Logger einrichtest, damit er mit dem MQTT Gateway spricht, findest du hier:   

MQTT Gateway - Loxone Logger Receiver

• Das UDP JSON Interface und das HTTP Interface erlauben ebenfalls die Angabe eines UDP Transformers (MQTT Gateway - HTTP- und UDP-Interface) 

• DNS Lookup-Cache: LoxBerry benötigt für ein paar Funktionen den Hostnamen oder die IP einer eingehenden UDP-Verbindung und macht dafür einen DNS Reverse Lookup. Es gab zwei oder drei Fälle von Benutzern, die ihren DNS schlecht, falsch oder gar nicht konfiguriert hatten, und deswegen dieser DNS-Request ewig gedauert und die Weiterleitung verzögert hat. Das Gateway hält nun einen eigenen Reverse Lookup Cache für Hostnamen/IP-Adressen, der alle 4 Stunden aktualisiert wird.
  

Dauert ein Reverse Lookup länger als 50 Millisekunden, wird ins Log eine Warnung geschrieben. In diesem Fall schau dir bitte deine IP-Konfiguration in deinem Netzwerk an. Ein derartiger Lookup einer lokalen Adresse dauert normalerweise 3 bis 5 Millisekunden. Da (auch der langsame) Lookup dann für 4 Stunden gecached wird, verzögert das die Übertragung nicht mehr und entlastet den DNS-Server.

• pawel-urban hat der BETA4 performancemäßig noch mal auf den Zahn gefühlt (Issue), und daraus habe ich auch noch ein paar Millisekunden beim Processing optimiert  Thanks Pawel for findings and testing!
• Eine Korrektur bei der JSON Expansion ermöglicht nun auch die Einlieferung von JSON-Daten, wo der übergeordnete Datensatz ein Array ist - d.h. ein JSON, das nicht so beginnt { .... } sondern so [ { .... } ] .
• Für Entwickler: Im bin/plugins/mqttgateway/lib-Verzeichnis findet ihr den Perl PID-Regler, den ich für die Steuerung der Gateway-Performance geschrieben habe. Wenn ihr sowas mal brauchen solltet…
• Wenn du in der Incoming Overview nach "poll" filterst, erhältst du Informationen über die Performance-Steuerung des MQTT-Gateways:
  • pollcpucurpct: Die durchschnittliche CPU-Last des MQTT Gateways in der letzten Minute in Prozent
  • pollcpumaxpct: Die maximal erlaubte CPU-Last in Prozent (das ist der Wert, der in den Settings eingestellt wird)
  • pollms: Die aktuell verwendete, vom Regler eingestellte Verzögerung eines Processing-Durchlaufs in Millisekunden
  • pollpidvalpct: Die vom Regler berechnete Änderung aufgrund der CPU-Last der letzten Minute
  • pollproccnt: Die durchschnittliche Anzahl der Processing-Durchläufe pro Sekunde der letzten Minute (wenn du vergleichst: Früher war dieser Wert fix bei etwa 18)
• Die Incoming Overview passt sich nun besser der Displaygröße an. Man kann sich das jetzt auch auf einem Tablet ansehen.
• Fix: Wenn die Subscriptions-Liste leer ist (was durchaus ein mögliches Szenario ist), wird keine Warnung mehr ausgegeben.
• Fix: Das Credentials-File cred.json mit dem Broker-Zugangsdaten ist nur noch für loxberry (und root) lesbar.
• Wie das immer so ist, habe ich auch noch einige weitere Bugs so nebenbei mitgefixt bzw. auch historisch gewachsene Unschönheiten ausgebessert. 

Viel Spaß mit dem neuen, schnelleren MQTT Gateway!