Vorstellung loxMqttRelay: Docker-fähiges MQTT-Gateway "light"

[Acidcliff]

Hallo zusammen,

ich möchte euch ein weiteres Projekt von mir vorstellen, welches ich nun seit ca. 6 Monaten mit einem User hier aus dem Forum getestet habe.

LoxMqttRelay
GitHub: https://github.com/Jakob-Gliwa/loxMqttRelay
Docker: https://hub.docker.com/r/acidcliff/loxmqttrelay

Kurz gesagt:
Das loxMqttRelay leitet als docker-fähige standalone Lösung MQTT Nachrichten eines Brokers an den Loxone Miniserver weiter.
Es liest (wenn gewünscht) automatisch die im Miniserver konfigurierten Topics aus und leitet entsprechend Nachrichten an diese weiter.

Details:
Im Prinzip tut das loxMqttRelay das Gleiche wie das Loxberry MQTT Gateway nur mit einem verringerten, auf das Nachrichtenweiterleiten fokussierten Featureset:

• Kommunikation von Miniserver an loxMqttRelay rein über UDP
• Keine UDP-Features (bspw. UDP Transformer)
• Kommunikation von loxMqttRelay and Miniserver nur über HTTP/Websocket
• Keine Topic/Payload Conversion (text-to-value, etc.) außer Boolean Mapping und JSON-Flattening
• Keine Zusatztools wie MQTT-Finder, Übersicht der eingehenden Nachrichten oder einen eingebauten MQTT Broker

Dafür besitzt das loxMqttRelay die Möglichkeit sich selbstständig mit dem Miniserver zu synchronisieren, um aus dem Miniserver auszulesen, welche Topics bedient werden sollen. So ist sichergestellt, dass nur Nachrichten an den Miniserver geleitet werden, die dieser auch erwartet.

Warum brauche ich das (insb. in einer Welt in der das MQTT Gateway schon existiert)?
Das MQTT Gateway ist super, über Jahre erprobt und die Loxberry Community hat über Jahre hinweg eine unglaubliche Zuverlässigkeit an den Tag gelegt. Wer Loxberry nutzt oder es gerne maximal komfortabel hat sollte auch weiterhin das Gateway nutzen.
Das loxMqttRelay ist gerichtet an...

• ..."Power User", Werkler oder/und IT-Puristen, die Lösungen lieber getrennt laufen haben oder harmonisiert
• ...Leute die strickt auf einen Docker-Stack setzen wollen
• ...Personen, die rein eine MQTT-Weiterleitung brauchen und dafür keine ganze Loxberry Installation laufen lassen wollen
• ...Low Power Anwendungsfälle

Der Grundgedanke ist weniger alle denkbaren Funktionen an einem Platz zu haben, sondern eher spezialisierte Tools dediziert zu betreiben (und diese vll dann auch für weitere Zwecke mitzubenutzen). Beispiele:

• MQTT Finder -> MQTT Explorer
• Integrierter MQTT Broker -> Eigener, dedizierter MQTT Broker
• Topic / Payload Transformation -> Node-Red oder/und Telegraf
• ...

Migration von einem MQTT-Gateway Setup geht schnell. Es sollte größtenteils vorher so funktionieren wie nachher. Falls etwas nicht funktioniert liegt es meistens an exotischen Topics etwa mit Leer- oder Sonderzeichen (lest dazu am besten das entsprechende Kapitel in der Doku).

Ich hoffe das loxMqttRelay ist hier für den einen oder anderen nützlich!
Freue mich über Feedback und eure Erfahrungen damit!

[Noschvie]

Wäre es nicht einfacher gewesen, einen Docker Container zur erstellen, der das LB Plugin „as it is“ laufen lassen kann?

[Acidcliff]

Wäre es nicht einfacher gewesen, einen Docker Container zur erstellen, der das LB Plugin „as it is“ laufen lassen kann?

Hatte ich anfangs auch überlegt, aber am Ende nicht wirklich:

1. Gibt es das Plugin per se nicht mehr, weil es nun in den LB integriert ist
2. LB Plugins haben eine Installationsroutine, die nicht ohne Weiteres in einem Docker abbildbar ist
3. Die LB Plugins nutzen das LB Konfigurationsökosystem, das von der Plattform bereitgestellt wird. Das hätte nachgebaut werden müssen
4. 1-3 würden neben der höheren Implementierungsaufwände auch die Wiederverwendbarkeit der LB Fortentwicklungen einschränken
5. Perl ist nicht meine Stärke
6. Kann man heute ein paar Sachen schlicht besser machen (bspw. Miniserver Sync, Anbindung via Websocket statt UDP)
7. Wollte ich es wie oben beschrieben schlanker halten
8. Wegen Low Power Anforderungen. LB und die derzeitige Perlimplementierung sorgen u.a. dafür, dass moderne Prozessoren tiefere C-States nicht erreichen können, was auf non-arm Plattformen für höheren Stromverbrauch sorgt

Glaube bevor man ein Docker-gekapseltes MQTT Gateway Plugin macht, kann man gleich eine Plattform bauen, die theoretisch jedes LB-Plugin hosten könnte. Das wäre aber quasi eine Reimplementierung von LB (wurde hier im Forum ja schon öfter diskutiert). Das wäre ein ganz anderes Kaliber an Aufwänden.

[<Andreas>]

Ein Zufall das du scheibst, ich habe das gestern bei mir produktiv aufgesetzt

- Mir persönlich ist wenn es im Docker läuft wesentlich lieber als in einer VM (clean, einfach zu warten, performant)
- als MQTT broker habe ich nonomq verwendet (klein, schnell und leicht zu konfigurieren)
- Die CPUlast meiner Diskstation hat sich verringert
- man kann den Loxberry mit einen externen Broker weiter betreiben, es werden sogar die Verbindungen umgeleitet die noch auf den Loxberry zeigen

Ich bin jedenfalls sehr dankbar für diese Implementierung

[hismastersvoice]

Acidcliff
Tolles Plugin...

Habe wie <Andreas> einen nanomq, zigbee2mqtt und dein Plugin am laufen.
Zum testen habe ich mal eine hohe Traffic-Last simuliert, indem ich diverse Sensoren auf sehr kurze Intervale gestellt habe, und die Z2M Bridge-Info Daten mit Json-Expand bearbeiten lassen habe.
So gut wie keine CPU Last, und sehr schnell.
Bei den Z2M-Bridge-Info Daten gibt es beim Loxberry extrem hohe CPU-Lasten durch das MQTT Plugin.

Das einizige was mir nicht gefällt, ist das ich die VI Namen nicht wie im Loxberry per Copy&Paste nutzen kann, sondern sie von Hand zusammen bauen muss.
Bei vielen Daten doch mühsam, und Fehler werden nicht immer sofort erkannt.

[<Andreas>]

Die Performance ist wirklich sagenhaft, Datenströme die zuvor das ganze System ausbremsten sind jetzt quasi nicht mehr relevant

Das mit den Input Nahmen sehe ich genau so, hier wäre irgend ein Tool eine echte Erleichterung, muss ja nicht im gleichen Container Laufen

[Noschvie]

Datenströme die zuvor das ganze System ausbremsten sind jetzt quasi nicht mehr relevant

Das erscheint mir etwas übertrieben...

[<Andreas>]

Ich hab hier Moonraker (3D-Drucker) wenn ich da die falschen Topics abonniere geht beim Loxberry MQTT nichts mehr, aber das neue Setup steckt es mit einstelliger CPU Belastung weg

Natürlich ist das kein Benchmark und der Loxberry ist bei mir auch noch benachteiligt weil er in einer VM läuft

Soll auch den Loxberry nicht negativ darstellen für 99% ausreichend, tolle Software nach wie vor

[hismastersvoice]

Leider ist es nicht übertreiben.
Wenn ich zu meinem Werten die zum Teil alle 3 Sekunden kommen (Energiemanagement) noch pauschal Zigbee2MQTT subscribe ca. 1600 Werte bei Json expand dann geht das System sehr in die Knie und die Bedienung ist zum Teil spürbar verzögert.

Ich habe es ACL Filterung behoben, ist aber händisch und man muss wissen was man tut.

Zugegeben in 95% der Fälle dürfte es kein Problem gegen, aber es wird hier immer wieder diskutiert.

[challo]

Sehr interessantes Projekt! Eventuell ist es ja auch möglich "Vorteile" dieser Implementierung in Loxberry MQTT zu übernehmen?
Ich habe hier auch aktuell etwas Probleme mit sporadischen Verzögerungen.

[<Andreas>]

Hab mir hier jetzt was einfaches gebaut, aber muss noch testen

[hismastersvoice]

Kannst mir gerne zukommen lassen, dann test ich mit

[<Andreas>]

Ein paar Dinge muss ich aber vorerst noch ändern 🥲

[<Andreas>]

https://github.com/Andreas-strg/loxMqttRelay-Viewer.git

Hier wäre was zum testen:
- einfach die requirements installieren und die main.py (vorher MQTT Daten eintragen) ausführen oder Docker verwenden
- das Frontend habe ich größtenteils mit KI erstellt, da ich hier relativ wenig Ahnung habe, es sollte eher als Hobbyprojekt eines nicht Entwicklers betrachtet werden
- wenn jemand sich beteiligen will oder was eigenes geplant hat lasst euch nicht aufhalten
- um die Datenlastet zu verringern oben ein Topic eingeben, sonst kann man recht gut mit der Suche arbeiten
- ich möchte noch den Wechsel zwischen den Loxone und den original Topic einbauen

Viel Spaß

[Acidcliff]

Danke für das positive Feedback. Freut mich insbesondere, dass der Performanceaspekt tatsächlich auch auffällt - ich hab da relativ viel Zeit investiert!

Sehr interessantes Projekt! Eventuell ist es ja auch möglich "Vorteile" dieser Implementierung in Loxberry MQTT zu übernehmen?
Ich habe hier auch aktuell etwas Probleme mit sporadischen Verzögerungen.

Die zusätzliche Performance kommt aus verschiedenen Ecken - manches könnte denke ich im LB ggf. nachimplementiert werden, anderes wäre eher nicht praktikabel:

1. Caching von Booleantransformationen, topic-conversions, tlw. JSON expands -> wäre durchaus im LB drin denke ich
2. Asynchrone Verarbeitung (erhöht insb. die Reaktionsgeschwindigkeit) -> schwieriger im LB abzubilden
3. Miniserver-Sync mit "Fail-Fast-Whitelist" (da das MQTT Relay durch den Miniserver-Sync genau weiß welche topics der MS erwartet, kann es sich viele Rechenoperationen für irrelevante topics sparen) -> ist auch im LB denkbar
4. Umsetzung der rechenintensiven Operationen in maschinennahen Programmiersprachen (im Relay in C/Rust) -> Eher nicht praktikabel im LB
5. Nutzung der Websocketschnittstelle statt HTTP -> Auch möglich
6. Mikrooptimierungen auf Codeebene -> Eher nicht praktikabel. Der LB sollte immer Wartbarkeit vor Mikrooptimierungen setzen

In Summe wären das aber keine kleinen Änderungen mehr - man müsste quasi den Kern vom MQTT Gateway neu schreiben.

[Acidcliff]

Acidcliff
Tolles Plugin...

Habe wie einen nanomq, zigbee2mqtt und dein Plugin am laufen.
Zum testen habe ich mal eine hohe Traffic-Last simuliert, indem ich diverse Sensoren auf sehr kurze Intervale gestellt habe, und die Z2M Bridge-Info Daten mit Json-Expand bearbeiten lassen habe.
So gut wie keine CPU Last, und sehr schnell.
Bei den Z2M-Bridge-Info Daten gibt es beim Loxberry extrem hohe CPU-Lasten durch das MQTT Plugin.

Das einizige was mir nicht gefällt, ist das ich die VI Namen nicht wie im Loxberry per Copy&Paste nutzen kann, sondern sie von Hand zusammen bauen muss.
Bei vielen Daten doch mühsam, und Fehler werden nicht immer sofort erkannt.

Ich hab da etwas drüber nachgedacht - ich glaube es gäbe auch eine Möglichkeit eine Implementierung herzustellen, bei der man den Topic gar nicht mehr umwandeln müsste, sondern einen normalen MQTT Topic in den VI schreibt.

Aktuell ist das Problem ja, dass mqtt topics slashes verwenden, die im Kontext von Webserviceaufrufen nicht gehen.
Ich glaube man kann aber statt dem Control-Namen auch die uuid des VI nutzen.
DIe müsste man aus der Config rauslesen und dann vom Relay auf den topic live-mappen lassen.

Das würde aber nur in Kombination mit dem Miniserver-Sync feature gehen.

Wenn es Interesse an dem Feature gibt, kann ich das mal ausprobieren.

[<Andreas>]

Hört sich ziemlich cool an, es wäre evtl. in den Zusammenhang auch interessant die Syntax für die JSON trasvormation anders zu gestalten um in der Config mehr Übersicht zu haben, bzw. erkennbar wird ob es ein echtes topic ist, oder von einer JSON stammt

Beispielsweise keller/waschmaschine[status] oder keller/waschmaschine_status statt keller/waschmaschine/status

Mit dieser Herangehensweise könnte man auch die Korrekturwerte aus der Config funktional machen

Die Frage ist ob das dann nicht alles zu überladen wird, bzw. wie weit die Wartbarkeit darunter leidet

[hismastersvoice]

Acidcliff

Ich habe das Relay jetzt intensiv getestet, und für alle meine Anwendungen läuft es wirklich sehr gut.
Das einzige was mir fehlt, ist das ich nur einen MiniServer abfragen bzw. beschreiben kann.

Ist die einzige Möglichkeit ein zweites Relay aufzusetzen?

[Acidcliff]

Ich glaube MQTT senden könnten sogar jetzt schon mehrere Miniserver gleichzeitig über eine einzige Relayinstanz.

MQTT Nachrichten vom Relay erhalten wäre aber ein größeres Ding und so wie ich das derzeit implementiert habe auf jeden Fall eine sehr große Änderung.

Denke ein Muiltirelay-Handling hätte auch einen Rattenschwanz in Bezug auf ein paar andere Features (bspw. Miniserver-Sync oder das Handling von Whitelists, Filtern etc.), die auch aus Nutzersicht die Konfiguration komplex machen könnten. Daher könnte es gut sein, dass mehrere Dockerinstanzen auch vom "Komfort" her nah an einer Multirelay-Lösung liegen würde.

Performance-technisch würde ich annehmen, dass sich mehrere Dockerinstanzen nichts nehmen außer ein paar wenigen MB mehr RAM-Verbrauch.

[fs79]

Acidcliff
Nutze das Relay und es läuft sehr gut, hatte ein Problem mit valetudo und non UTF8 Daten.
Hab einen Workaround und es funktioniert, hab dir aber mal auf GitHub ein Issue eröffnet.
Ignore non‑UTF8 MQTT payloads to prevent crashes · Issue #6 · Jakob-Gliwa/loxMqttRelay

Vielen Dank für deine Arbeit.
Edit: Vielen Dank für die schnelle Erledigung des GitHub Issues

[fs79]

Kurzer Erfahrungsbericht: Warum ich (ungeplant) auf loxmqttrelay gewechselt bin

Eigentlich war es gar nicht meine Absicht, den Loxberry oder das Easee-Plugin zu ersetzen. Aber dein loxmqttrelay kam genau zur richtigen Zeit. Die VM auf meinem Intel N100 lief dauerhaft auf 100 % – das war zwar nie ein Problem, aber die hohe Auslastung und Temperatur erschienen mir auf Dauer einfach nicht optimal.

Als Anmerkung: Loxberry lief bei mir zu diesem Zeitpunkt ohnehin nur noch wegen MQTT, ein paar kleiner Testwert-Anpassungen und dem Easee-Plugin. Durch das Auslagern des MQTT-Servers in einen Docker-Container konnte ich die Last und Temperatur bereits merkbar reduzieren. Allerdings hat das MQTT-Gateway im Loxberry trotzdem immer wieder Last verursacht.

Dann bin ich auf dein loxmqttrelay gestoßen, das auf Anhieb sehr gut funktioniert hat. Das war für mich der Punkt, an dem ich die Entscheidung getroffen habe, den Loxberry ganz abzuschalten und den Rest mit Node-RED in Docker umzusetzen. Node-RED übernimmt dabei nicht nur die Umwandlung einiger MQTT-Textwerte, sondern inzwischen auch sämtliche Funktionalitäten des Easee-Plugins.

Ergebnis: deutlich geringere Last, niedrigere Temperaturen und ein insgesamt entspannter laufendes System. Außerdem habe ich mich dabei in die Easee-API eingearbeitet und einiges über MQTT dazugelernt.

[<Andreas>]

kann ich eigentlich den Loxone Startimpuls mit {base_topic}/config/update verknüpfen, um loxmqttrealy nicht manuell neu starten zu müssen oder führt das zu Problemen?

[hismastersvoice]

Ja, kannst du. Ich habe es auch so gemacht, mit 15 Sek. Zeitverzögerung wie ich alles automatische nach dem Neustart verzögere.
So ist man sicher das alles erledigt und Online ist.

[Acidcliff]

kann ich eigentlich den Loxone Startimpuls mit {base_topic}/config/update verknüpfen, um loxmqttrealy nicht manuell neu starten zu müssen oder führt das zu Problemen?

Eigentlich sollte sich der Miniserver automatisch neu verbinden, wenn der Miniserver warum-auch-immer offline war.

Manueller Sync des Miniserver-syncs wird ausgeführt, wenn ihr den Lox Startimpuls auf {base_topic}/miniserverevent/startup verbindet.

[Deepflash]

wie genau sieht der Befehl hierfür in Loxone aus? das mit dem base_topic versteh ich nicht ganz.
Andere Frage: Funktioniert der White-List-Sync eigentlich auch bei entfernten Virtuellen Eingängen, sprich werden die Einträge dann auch in der White List entfernt?

[Acidcliff]

@Andreas: Sorry hatte deinen Kommentar übersehen.

hier wird der base topic definiert - das ist quasi der topic unter dem das relay dann mqtt nachrichten sendet und empfängt

[general]
log_level = "INFO"
base_topic = "myrelay/"
cache_size = 100000

Wenn ihr das so gelassen habt, dann erwartet das Relay unter dem MQTT-Topic "myrelay/miniserverevent/startup" eine Nachricht
Payload kann beliebig sein

Wenn er auf der Adresse was erhält startet das Relay neu und lädt damit auch die whitelist neu (inkl. entfernter/neuer Elemente)

in Loxone müsst ihr das komplett analog wie auch im Loxberry bisher eingeben. Also diese Anleitung folgend https://wiki.loxberry.de/konfigurati...tt_loxone_mqtt - nur statt "publish send/to/this/topic <v>" eben "publish myrelay/miniserverevent/startup 1"

[Deepflash]

ja funktioniert, außer dass in meiner Config "test" als Base-Topic stand und es dann natürlich erstmal nicht funktioniert hat