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

[Deepflash]

bin gerade am Aufsetzen von dem Ganzen und habe nun eine kleine Frage:
Wenn ich es richtig verstanden habe, nimmt loxmqttrelay alle VIs vom Miniserver und schaut am MQTT-Broker nach passenden Werten.
Wozu müssen dann eigentlich noch Topics oder Filter definiert werden? Um den Pool zu verkleinern, in dem gesucht wird?

[Acidcliff]

Wenn du die Miniserver-Sync-Funktion benutzt dann ist das richtig - dann brauchst du theoretisch gar keine Filter/Topics mehr setzen.
Theoretisch könntest du mit "#" auf alle topics subscriben und loxmqttrelay übernimmt den Rest.

Da das filtern aber erst im letzten Schritt stattfinden kann, erreichst du typischerweise eine bessere Performance, wenn du zumindest die Subscriptions klug aussuchst. Den größten Effekt wird es immer haben, wenn du über die Subscriptions so wählst, dass Topics, die JSON-Payload enthalten, aber ohnehin verworfen werden würden, ausgeschlossen werden. Die sind am rechenintensivsten.

Wenn du es simpel halten willst, kannst du es aber quasi auch komplett generisch lassen. Das Relay ist wirklich sehr performant.

[Deepflash]

aber welchen Vorteil bringt es mit Topic Subscriptions oder Whitelists zu arbeiten, wenn es doch das MiniServer-Sync-Feature gibt:
Automatic Configuration Sync

Enable automatic synchronization with your Miniserver's configuration:

[miniserver]
sync_with_miniserver = true

When enabled, the relay will:

Automatically load Miniserver configuration on startup
Update the topic whitelist based on Miniserver inputs
Resync when Miniserver configuration changes

Caution: This function will assume that every Virtual Input is a possible target for forwarding mqtt messaages.

[Acidcliff]

Einerseits um das letzte bisschen Performance rauszuholen.
Andererseits (und das war meine hauptsächliche Motivation beides anzubieten) ist die Interaktion mit der Miniserver-Config eigentlich kein von Loxone offiziell vorgesehener Weg. Ich dachte mir, dass sich nicht jeder wohl fühlen wird ein fremdes Programm auf die eigene Konfiguration loszulassen.

[Deepflash]

noch etwas: offenbar ist der UDP-Port bereits durch das MQTT Gateway vom Loxberry besetzt. Gibt es einen eleganten Weg, das frei zu bekommen?

[Deepflash]

- Antwort: einfach im MQTT Gateway einen anderen Port eintragen

[<Andreas>]

Entweder in den Gateway Settings des loxberrys den "Gateway UDP in-port" ändern oder in Docker einen anderen setzen, dann müsstest du aber auch die Adresse in der Config ändern (zu spät 🙈)

[Deepflash]

also was soll ich sagen, bin nun auch ein- bzw. umgestiegen ohne separaten Broker.
Das Ergebnis lässt sich sehen (ganz am Ende). Sieht an und für sich nicht so drastisch aus, entscheidend ist aber, dass die ständigen Spikes in der CPU-Nutzung in HTOP komplett weg sind und auch meine IKEA MQTT Lampe mit Display nun flüssig funktioniert. Davor war das furchtbar.. die Zeilen nie synchron, mal gar nicht, mal alles auf einmal... Manchmal haben die schaltbaren Steckdosen einfach nicht reagiert - funktioniert nun prima :-) Vielen Dank an der Stelle auch für die Unterstützung beim einrichten.

[challo]

Ich hab auch einfach den loxberry Broker weiter am laufen. Die topics mit vielen Daten bzw. Json laufen über das relay und Dinge mit Transformation oder Umwandlung laufen weiter über loxberry. Funktioniert super bei mir.

[Acidcliff]

Also wenn es nur um die eingebauten Mapper und Transformatoren geht ist es ziemlich überbordend den Loxberry noch laufen zu lassen, oder?
Da wäre node-red vermutlich die deutlich schlankere/schnellere und durch die Plugins auch erweiterbarere Lösung.

Ich glaube auch rein architekturell ist es sinnvoll allzuviel "Magie" auf den Transportwegen zu vermeiden

[challo]

Hab noch mehr auf dem loxberry laufen. Ansonsten würde ich auch nodered nehmen....

[<Andreas>]

Hey,

Das Realy läuft nach wie vor top, ohne einen einzigen ausfall

Ich wollte fragen ob du es möglich machen könntest MQTT 5 User Properties beim Loxone Ausgang zu übertragen?
Ich gebe da gern unter anderen die Einheit mit um später mehr Übersicht zu haben

Danke & Gruß
Andreas

[Acidcliff]

Moin!
Habe gerade eine neue Version gepusht.
Neben ein Paar Performancesachen, habe ich auch die MQTT 5 Fähigkeit eingebaut.

Standardmäßig läuft das Relay weiter auf MQTT3.1
Du musst einmalig in der config.toml den Wert mqtt_version = "5" in der [broker] Sektion einfügen/setzen.
Dann das Relay neu starten.

Wie die Properties zu übergeben sind kannst du hier nachlesen:

https://github.com/Jakob-Gliwa/loxMqttRelay#mqtt5-user-properties

[<Andreas>]

Danke erst einmal für die schnelle Umsetzung wirklich super was du da leistest

Hab hier aber noch ein kleines Problem, der Container startet in der aktuellen Version nicht mehr Logs bekomme ich auch keine


Ein wenig habe ich schon geforscht, vermutungen angestellt
rustc_flags=["-C", "target-cpu=x86-64-v3"]
AVX2 unterstützt meine CPU noch nicht, ich hab gesehen du hast einen fallback eingebaut, evtl. greift der nicht vollständig?

[<Andreas>]

Bei der neusten Version leider das gleiche Bild, bekomme auch keine weiteren logs

Kann ich etwas machen um dir weitere Informationen zukommen zu lassen?

[Acidcliff]

Leider kannst du vermutlich gerade nicht mehr tun um Logs zu generieren. Liegt daran, wann genau das XML Modul geladen wird.

Versuch mal die neuste Version. Am besten direkt gegen den neusten Tag gehen statt auf lastest, damit nicht zufällig was aus dem Cache geholt wird: acidcliff/loxmqttrelay:49709b6aa820868f91cab9c275a917d29165d 73c (Achtung, das Forumsystem fügt hier gerne mal ein Leerzeichen beim Tag hinzu - sollte eigentlich ohne sein)

Ich hoffe ich hab zumindest das Logging jetzt vorziehen können um mehr zu erfahren (und env variable LOG_LEVEL=DEBUG sollte zumindest für den Test gesetzt sein).

[<Andreas>]

2026-06-06 13:15:38,512 INFO [loxmqttrelay.utils] platform=Linux 4.4.302+ arch=x86_64 (x86=True, avx2=False)

Also läuft vielen Dank!

Mein Nas ist mittlerweile in die Jahre gekommen wollte mal Influxdb3 hosten das machte auch schon Probleme, möchte den Neukauf aber noch ein paar Jahre hinauszögern

[schildkroete]

Ich wollte nur kurz ein Danke und Feedback da lassen - bin gestern von Loxberry auf das Relay umgestiegen. War sehr schnell erledigt und tut genau das, was es soll - Top! Danke für die Zeit, die Du da reingesteckt hast.

[schildkroete]

Eine Frage kam mir gerade: Ich habe ein paar Sonoff-Buttons, die beim Klick ein solches "Event" feuern. Per Zigbee2MQTT landet das dann auf einem Topic.

{
   "action":"double",
   "battery":100,
   "last_seen":"2026-06-26T11:19:01+02:00",
   "linkquality":102,
   "update":{
      "installed_version":8704,
      "latest_release_notes":null,
      "latest_source":null,
      "latest_version":8704,
      "state":"idle"
   },
   "voltage":3000
}

Bei dieser Art von "Events" müsste es aber ja so sein, dass die Nachricht beim Lesen verschwindet. Sonst kann ich nicht erkennen, ob der Button "nochmal" gedrückt wurde. Im Loxberry Gateway gabs dafür eine Option (weiß gerade nicht mehr, wie sie hieß).

Im Moment hab ich das dann als "zigbee2mqtt_device_eg_kueche_button_action" virtueller Texteingang in Loxone drin. Da kommt dann halt "double" an. Aber der Status bleibt dann natürlich bestehen.

Wie würde man das hier lösen?

[schildkroete]

Ich hab das jetzt mit einem Script innerhalb von iobroker gelöst, der dann UDP Signale an Loxone schickt.

[Acidcliff]

Stimmt - das Relay macht das nicht, da ich möglichst keine intransparente Logik ins Relay packen wollte/will.

An deiner Stelle hätte ich das in Loxone selbst abgebildet:

Virtueller Texteingang erhält Nachricht -> Nachgelagerter Flow danach sendet über virtuellen Ausgang deinen gewünschten Resetwert auf den Topic "zigbee2mqtt_device_eg_kueche_button_action"

So hättest du keine Abhängigkeit zu einem Drittsystem wie Biobroker

Wahrscheinlich aber besser (aber ohne es selbst mal probiert zu haben):
Zigbee2Mqtt hat ein Setting, das vermutlich genau das macht, was du hier zu lösen versuchst. Es heißt "legacy_action_sensor" und ist definiert als: "Home Assistant legacy actions sensor, when enabled a action sensor will be discoverd and an empty `action` will be send after every published action. (Default: false)"

[schildkroete]

Danke für den Impuls!

Das Zigbee2MQTT Feature ist nur global und laut Doku deprecated. "Note that this feature is deprecated and will be removed in the future. It's recommended to use the MQTT device trigger instead."

Die Loxone Variante kann man natürlich machen, das stimmt schon. Ich habe iobroker eh im Einsatz, insofern ist mir die Abhängigkeit eher egal.

[Prof.Mobilux]

Im Loxberry Gateway heißt die Option "Reset After send".

[schildkroete]

Irgendwie habe ich immer nach ein paar Tagen das Problem, dass einzelne Topics/VI nicht mehr übertragen werden, während andere aber einwandfrei funktionieren. Ein Neustart von loxmqttrelay löst das Problem dann erstmal.

Im Log tauchen die nicht funktionieren Topics gar nicht auf, die fehlen komplett.

Der einzig auffällige Log-Eintrag ist folgender, der immer mal wieder kommt.

2026-07-02 15:23:16,294 ERROR [loxwebsocket.lox_ws_api] Error using existing token. Error hasing token. Unexpected content in Loxone response.. Trying to acquire new token...
2026-07-02 15:23:18,067 ERROR [loxwebsocket.lox_ws_api] Connection closed unexpectedly with unknown code: 1000
2026-07-02 15:23:18,067 INFO [loxwebsocket.lox_ws_api] Reconnect attempt 2 of 0
2026-07-02 15:23:18,067 INFO [loxwebsocket.lox_ws_api] Waiting for 15 seconds before retrying...

Kann ich irgendwie mit weiteren Infos helfen, um das Problem zu identifizieren?

[Acidcliff]

Code 1000 bedeutet normalerweise, dass der Miniserver die Verbindung planmäßig geschlossen hat. Das wäre eigentlich nur der Fall bei einem Restart, Update oder wenn der Heartbeat aus irgendeinem Grund nicht funktioniert und der MS die Verbindung deshalb planmäßig schließt.

Bin mal gespannt, ob bei dem Lasttest was rauskommt. Klingt nicht nach einer Lastthematik (zumindest was das Relay angeht), weil sowas eher nicht immer die gleichen Topics "fallen" lassen würde. Zudem würde vermutlich eher der MS in die Knie gehen, bevor das Relay zu schwitzen beginnt (famous last words ).

Denke du solltest mal folgende Sachen prüfen
- Prüfe, ob die Werte, die du erwartest, wirklich am Relay ankommen (LOG_LEVEL auf DEBUG setzen) -> Falls nicht: Schau an einem MQTT Broker oder einem MQTT Explorer, ob die Werte tatsächlich an deinem Broker ankommen und versendet werden. Falls die dort ankommen/versendet werden können es eigentlich nur noch Verbindungsprobleme vom Relay zum Broker sein (in einem normalen Netzwerk sehr unwahrscheinlich) oder es sind aus irgendwelchen Gründen die falschen subscriptions gesetzt
- Falls die Werte ankommen, aber nicht weitergeleitet werden müsste es an den Filteroptionen liegen. Neben den offensichtlichen Filter-Holpersteinen könnte es insb. dann unerwartete Verhalten geben, wenn sich die Payload signifikant ändert. Bspw. wenn manchmal ein normaler Wert und manchmal ein JSON Payload gesendet wird und JSON-Expansion aktiviert ist.

[schildkroete]

Ich habe tatsächlich zwei Bugs im Lasttest identifizieren können, die im Testszenario zwischen 5 und 17% Nachrichtenverlust erzeugt haben. Den Fix teste ich lokal mal ein zwei Tage, dann schicke ich Dir einen PR.

[Acidcliff]

Hab mir deine Analyse mal angeschaut. Danke, dass du dir da die Mühe gemacht hast.
30k Nachrichten mit unlimitierter Rate - also auf einen Schlag - über den HTTP-Pfad zu schicken statt über den Websocket-Pfad ist schon sehr abstrakt.

Der Lasttest zeigt, dass der Burst von 10-20k Nachrichten scheinbar fehlerfrei funktionieren (was imo schon an ein Wunder grenzt ) und die Drops erst ab 30k auftreten. Natürlich kann man das mit Connection Pooling und Retries lösen - das hebt Limit dann von 30k auf irgendeinen anderen Wert - maybe sogar mehrere 100k. Aber es fügt Komplexität (bspw. hab ich bewusst keine Retry-Logik) hinzu, die keinen Payoff hat, weil der MS vermutlich schon die 20k nicht ansatzweise verarbeiten könnte.

Jetzt wo wir drüber reden ... langfristig würde ich überlegen, ob ich den HTTP-Pfad ganz zugunsten des WebSockets droppe. Eigentlich ist er eher deshalb drin, weil es damit einfacher ist Mocks/Debugging zu betreiben als das ich glauben würde, dass es eine gute Idee wäre, dass jemand das Relay im HTTP Modus betreibt.

Laut deinen Error-Logs verwendest du bei dir den Websocket-Pfad, oder? Dann dürfte die Anpassung des HTTP-Pfads dein Problem auch nicht beheben.

[Deepflash]

so aus Neugier: in Loxberry 4.0 wurde das MQTT Gateway überarbeitet. Lohnt sich da noch der Weiterbetrieb des loxmqttrelay, hat das schonmal jemand verglichen?

[Acidcliff]

Nach meiner Einschätzung hat sich am Entscheidungspunkt zwischen dem Loxberry MQTT Gateway und dem Relay nichts groß geändert:
- Das MQTT-Gateway hat einen weiterhin einen höheren Funktionsumfang (Deduplikation, Resend, UDP-Send, etc.) und die angenehme Vollintegration in Loxberry
- Das Relay ist weiterhin was Features angeht puristischer und Performance-orientierter (bspw. setzt das MQTT Gateway weiterhin auf HTTP statt Websocket und auf super-schnelle C/Rust-Routinen) - wobei das neue MQTT Gateway durch den Umstieg auf Python & Concurrency vermutlich CPU-optimierter agieren sollte als früher

Also weiterhin ist das Relay eher was für Puristen und Performance-Geeks - der Rest der Welt wird weiterhin mit dem LB-MQTT-Gateway bedient, glücklich und zufrieden sein