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