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

**Deepflash** · 03.09.2025, 08:57

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?

**Deepflash** · 03.09.2025, 09:48

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** · 04.09.2025, 14:55

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.

**<Andreas>** · 05.06.2026, 16:30

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

**<Andreas>** · 06.06.2026, 05:56

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?

**schildkroete** · In den letzten 3 Wochen

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** · In den letzten 3 Wochen

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.

Code:

{
   "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?

**Prof.Mobilux** · In den letzten 3 Wochen

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

**schildkroete** · In den letzten 3 Wochen

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.

Code:

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?

**Deepflash** · In den letzten 2 Wochen

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?

**Prof.Mobilux** · In den letzten 2 Wochen

Zum Vergleich mit dem LoxBerry Gateway V2: Deepflash:

Ich denke die Zielgruppe ist eine andere, wie Acidcliff ja schon geschrieben hat. Das LoxBerry Gateway legt Wert auf eine einfache Bedienung und maximale Kompatibilität, das MQTT-Gateway "light" setzt auf eine minimalistische Umsetzung mit maximaler Performance ohne "Overhead".

Ein paar Kommentare von mir zum Gateway V2:

"CPU Last vom neuen Gateway ist besser aber immer noch hoch" - keine Ahnung wo <Andreas> diese Aussage aufgeschnappt hat - sie ist falsch. Richtig ist, dass die CPU Last mit parallelen Übertragungen steigt (was logisch ist....), da das Gateway 100% asynchron arbeitet. Ansonsten liegt die CPU Last im minimalen Grundrauschen. Das Gleiche dürfte auch für das MQTT-Gateway "light" gelten.

Das LoxBerry Gateway V2 ist in Python mit asyncio geschrieben. Alle Aufgaben (wie z. B. JSON expand) laufen in eigenen Threads. Das stellt eine ordentliche Skalierbarkeit sicher, ist aber sicherlich durch Python nicht mit C/Rust vergleichbar.

Das LoxBerry Gateway V2 arbeitet asynchron und wurde bzgl. Verarbeitungsgeschwindigkeit optimiert - die Übertragung eines Wertes vom Eingang zum Ausgang im Gateway dauert im Schnitt < 5 ms (150 abonnierte Werte, Übertragung HTTP). Die Übertragungsart kann auch auf UDP umgestellt werden, was weiteren Performancegewinn bringen dürfte. Bei < 5 ms habe ich da bei meiner Installation aber keinen Bedarf gesehen, zumal dann der Miniserver durch die notwenbdige Befehlserkennung etwas mehr belastet wird. Wie sich im Vergleich Websocket schlägt weiß ich nicht. Das kann das LoxBerry Gateway in der Tat nicht.

Das LoxBerry Gateway V2 (wie auch schon das Gateway V1) verzögert die Übertragung von zu vielen parallelen Übertragungen an den Miniserver, da ansonsten der Miniserver überlastet und neu startet. Ob das bei Websocket ein Problem ist weiß ich nicht, bei HTTP und UDP ist es so. Daher halte ich Testszenarien, wo 20.000 Werte parallel an den Miniserver übertragen werden, auch für völlig belanglos.

Läuft irgendein Dienst (oder Plugin) auf dem LoxBerry amok, zieht das nicht nur das Gateway sondern das gesamte System inklusive Mosquitto mit sich. Das ist systembedingt. Lässt sich aber lösen, wenn man einen dedizierten LoxBerry nur für das Gateway und den Mosquitto laufen lässt (z. B. in einer VM). Docker ist da aber natürlich schlanker.

**Acidcliff** · In den letzten 2 Wochen

Zitat von Prof.Mobilux

"CPU Last vom neuen Gateway ist besser aber immer noch hoch" - keine Ahnung wo diese Aussage aufgeschnappt hat - sie ist falsch. Richtig ist, dass die CPU Last mit parallelen Übertragungen steigt (was logisch ist....), da das Gateway 100% asynchron arbeitet. Ansonsten liegt die CPU Last im minimalen Grundrauschen. Das Gleiche dürfte auch für das MQTT-Gateway "light" gelten.

...

Das LoxBerry Gateway V2 arbeitet asynchron und wurde bzgl. Verarbeitungsgeschwindigkeit optimiert - die Übertragung eines Wertes vom Eingang zum Ausgang im Gateway dauert im Schnitt < 5 ms (150 abonnierte Werte, Übertragung HTTP). Die Übertragungsart kann auch auf UDP umgestellt werden, was weiteren Performancegewinn bringen dürfte. Bei < 5 ms habe ich da bei meiner Installation aber keinen Bedarf gesehen, zumal dann der Miniserver durch die notwenbdige Befehlserkennung etwas mehr belastet wird. Wie sich im Vergleich Websocket schlägt weiß ich nicht. Das kann das LoxBerry Gateway in der Tat nicht.

Die Verbrauche und Verarbeitungsgeschwindigkeit sollten beide (sehr) niedrig sein - das Relay ist aber von der Architektur her so, dass es deutlich geringere CPU Last bei schnellerem Durchsatz haben sollte:
- Es macht schlichtweg weniger (bspw. kein Dedup)*
- Aggressiveres Caching
- Schnellere (dafür zugegebenermaßen tlw. exotische) Algorithmen bspw. für die JSON-Expansion
- Hotpath maßgeblich in C/Rust
- Weniger Stellen mit I/O Overhead
- Tlw. schnellere Bibliotheken auch in Python
Sollte aber nicht überbewertet werden - wir sprechen hier vll von einer Optimierung von 5 auf 1-2 ms und, dass das Gateway irgendwo bei 1-3% auf einem normalen Rechner und das Relay bei 0,x% liegt.
Ich hatte das Relay auch dahingehend optimiert, dass es öfter niedrigere C-States freigibt. Das war in der alten Gateway-Version relativ suboptimal und jetzt vll besser.

*der Subprocess-Transformer Pfad bei den UDP Eingängen dürfte bspw. ziemlich teuer sein so wie er aktuell umgesetzt ist. Wenn Andreas das nutzt und viele ausgehende Nachrichten hat, könnte das eine Erklärung sein.

Btw. einige der Performancevorteile wären auch im MQTT-Gateway mit wenigen Anpassungen umsetzbar (es sei denn man will RPI<=2 weiterhin unterstützen):
- uvloop statt der standard-asyncio-Eventloop
- orjson statt der Standard-json-lib
- gmqtt statt aiomqtt

Zitat von Prof.Mobilux

Das LoxBerry Gateway V2 ist in Python mit asyncio geschrieben. Alle Aufgaben (wie z. B. JSON expand) laufen in eigenen Threads. Das stellt eine ordentliche Skalierbarkeit sicher, ist aber sicherlich durch Python nicht mit C/Rust vergleichbar.

Asyncio macht die Sache concurrent, aber nicht multithreaded. Das heißt, dass an anderen Tasks gearbeitet wird, wenn ein anderer Task gerade auf I/O-Operationen warten muss (bspw. das Versenden über HTTP). Sowohl das Relay als auch das Gateway sind "nur" concurrent. Das ist auch gut so - Multithreading wäre vom Overhead höher als jeder Nutzen, den man dadurch hätte. Ehrlich gesagt muss man auch sagen, dass die Concurrency in diesem Anwendungsfall wahrscheinlichst mehr Overhead als nutzen bringt, da die interne Arbeitsweise der meisten (Python) MQTT, UDP und Websocket-Clients intern so geartet ist, dass Nachrichten defacto sequentiell kommen und das, was Relay/Gateway machen so trivial/schnell ist, dass eine Parallelisierung nicht wirklich was bringt. Aber ich tue mir auch schwer es im Relay fallen zu lassen.

Zitat von Prof.Mobilux

Das LoxBerry Gateway V2 (wie auch schon das Gateway V1) verzögert die Übertragung von zu vielen parallelen Übertragungen an den Miniserver, da ansonsten der Miniserver überlastet und neu startet. Ob das bei Websocket ein Problem ist weiß ich nicht, bei HTTP und UDP ist es so.

Wäre mal interessant zu testen

Per se braucht der Websocketkanal ja keine nachgelagerte Befehlserkennung wie UDP, hat deutlich weniger Overhead als der HTTP Pfad und Belegt nur einen Kanal/Portslot auf dem Miniserver. So weit ich das beurteilen kann Loxone kein Multiplexing, daher kommen alle Nachrichten beim Miniserver auch immer sequenziell an, sodass aufgrund von Parallelität über Websocket eigentlich keine Überlastung da sein sollte. Wenn, dann könnte es sein, dass der MS intern einen Schutz gegen zu viele Befehle je Zeiteinheit hat. Müsste man mal testen - vll jemand der eine stabilere Verbindung hat als Schildkröte

Nebenbei:
Zwei Kernunterschied haben wir hier noch nicht angesprochen:
- Das Relay ist standalone - heißt, wer kein Loxberry benutzt/benutzen will, weil er/sie bspw. keine Plugins braucht, kann das so relativ schlank via Docker machen.
- Der Miniserver-Sync macht den Konfigurationsaufwand etwas geringer

Falls ihr irgendwann überlegen solltet Websocket im Loxberry anzubieten - ich hab die Kommunikation mit dem Miniserver als separate Lib ausgelagert. Sollte sich theoretisch gut in das Gateway einfügen: https://github.com/Jakob-Gliwa/loxwebsocket

**Prof.Mobilux** · In den letzten 2 Wochen

Zitat von Acidcliff

Btw. einige der Performancevorteile wären auch im MQTT-Gateway mit wenigen Anpassungen umsetzbar (es sei denn man will RPI<=2 weiterhin unterstützen):
- uvloop statt der standard-asyncio-Eventloop
- orjson statt der Standard-json-lib
- gmqtt statt aiomqtt

Das schaue ich mir nochmal an - Danke!

Falls ihr irgendwann überlegen solltet Websocket im Loxberry anzubieten - ich hab die Kommunikation mit dem Miniserver als separate Lib ausgelagert. Sollte sich theoretisch gut in das Gateway einfügen: https://github.com/Jakob-Gliwa/loxwebsocket

Das wäre tatsächlich interessant, haben wir als Issue schon "jahrelang" offen, uns aber nie daran versucht.