MQTT Gateway sehr langsam bei hoher CPU Last

[Christian-Kopf]

Hallo!

Ich hab selbiges Problem...

MQTT braucht "undefiniert" lange, mal reagiert ein angesprochener Client innerhalb einer Sek. mal nicht unterhalb 1min...

Ich lese hier schon einige Zeit mit, sorry daher für den direkten Einstieg hier in das Forum!
Jedenfalls herzliche Grüße vorab mal an alle, mein Name ist Christian und ich "spiele" mich hier bei mir auch seit geraumer Zeit mit diversen Loxone und Loxberry - "Verstrickungen" herum...;-)

Loxberry läuft bei mir übriges auch auf RPi4...

Gruß
Christian

[davidoff019]

Hallo liebe Freunde.
Ich würde mich gerne hier einklinken und ebenfalls mein Leid klagen. Wie bei einigen anderen Forumsnutzern ist auch bei mir das MQTT Plugin seit einigen Tagen unberechenbar und teilweise sehr verzögert. Bei mir im Rahmen von 2 - 200 Sekunden. Auch bei gleichzeitig abgesetzten Aktionen vom Miniserver ist dies spürbar, da die Aktionen z.B. schalten von RGBW Streifen, keiner Logik folgen und somit "Interessante" Zwischenstimmungen erzeugen.

Aber jetzt komme ich zum eigentlichen Problem: Ich als Bastler sehe ja immer eine Chance mich wieder mit meinem System zu beschäftigen und es zu verbessern...

ALLERDINGS hat meine Frau hier auch etwas Mitspracherecht und würde am liebsten gerade alle Spielereien (Shellys, Zigbee HW, Loxberry.... ) am liebsten wieder aus dem Fenster, zur Tür oder sonst wo raus schmeißen, und danach vermutlich mich auch gleich mit...

Deswegen hier mein überspitzter Hilferuf. Wenn hier irgendwelche Lösungen gefunden werde würde ich mich freuen und wenn ich irgendwie unterstützen kann helfe ich sehr gerne mit Daten aus.

LG
David

[Chrism3112]

Gibt es an dieser Front schon etwas neues? Weil ich dasselbe problem habe das die Shellys sehr träge reagieren?

Grüße

[Sunny]

Ich kämpfe auch gerade mit extremen Verzögerungen bis hin zu nicht durchgestellten Werten. In Summe habe ich ca. 1900 Werte, wobei die meisten vom Weather4Lox-Plugin kommen.

Das Problem tritt aber erst seit der Instattaltion einer MQTT-Bridge zum Solar-Assistant (/etc/mosquitto/conf.d/...) auf. Der liefert so ca. 90 Werte, teilweise im Sekundentakt. Wenn der Solar-Assistant abgeschaltet wird, läuft der MQTT Gateway wieder normal.

Auch scheint erstmal ein Clear-Database und Delte-Cache zu helfen.

LG Dirk

[<Andreas>]

Schaut erst mal in terminal was CPU Leistung saugt, um es näher eingrenzen zu können, deaktiviert die Json Umwandlung zum testen
Man macht meistens irgend einen Blödsinn, ging mit auch so

Ich hab letztendlich einen externen Broker in Docker gehostet und https://www.loxforum.com/forum/faqs-...-gateway-light verwendet was wesentlich effizienter arbeitet

[Sunny]

Danke für die erste Unterstützung.

Aber leider hat das nix gebracht, auch mit deaktiviertem JSON Expand hängt es.
Die CPU Last des RPi3 ist aktuell sogar nioch höher als zuvor. jetzt 50/20/80/80, hatte aber auch schon 20/70/00/30 mit den Hängern. Update: jetzt 90/05/20/35, also ein Kern hatt immer gut zu tun.


Eigentlich wollte ich nicht noch ein System installieren, deswegen hab ich ja die Bridge genommen, damit alles auf kurzem Wege über den Loxberry läuft.
Ich werde dann mal testweise den Weg einschlagen, das die Solar-Assistant Werte erst über dem Home Assistant laufen und u.U. nur die benötigten Werte an den Loxberry weiter gereicht werden.

[Firebiker]

Mich trafs jetzt auch. MQTT braucht 2-60 sec zum Verarbeiten, meist im Schnitt 20-30 sec. Das ist für Haushaltsangehörige 😀 leider nicht zu tolerieren.

Der erste Kern vom CPU ist auch bei mir voll überlastet (wie oben beschrieben). Mqtt-Errormeldungen: "keepaliveepoch is older than 5 min" und auch Mosquitto. Anzahl Mqtt-Zeilen: <800, Miniserver gemonitort: schickt auch nur 10 Sachen pro min.
Gegeben ist Loxberry 3.0.1 auf Raspb Pi 3b+, bereits 3x völlig neu aufgesetzt, gänzlich ohne plugins, Netzteil+SD+USB neu gegeben. Keine Änderung...

Was kann sein?
Wie habt ihr anderen es erfolgteich gelöst?

Wo finde ich und wie kann ich Loxberry 2.x installieren, scheinbar funkt das gut ✌️
THX!

[Deepflash]

same here.. kommt immer wieder vor. 50% CPU Last bei einem PI5, der vor nicht allzu langer Zeit eingerichtet wurde:


Bin über jede Hilfe das zu beheben dankbar. Dadurch hängen Befehle endlos lang in irgendeinem Puffer fest.

[hismastersvoice]

Ist bei mir auch immer wieder vorgekommen, und ich habe es nicht weg bekommen.
Ich nutze inzwischen das hier und bin mehr als zufrieden.
Keine echte CPU-Last mehr und alles läuft ohne jegliche Verzögerung.
Vorstellung loxMqttRelay: Docker-fähiges MQTT-Gateway "light" - loxforum.com

[<Andreas>]

JSON splittet das Loxmqttrealy auch um, würde ich nicht ausschalten wollen, soweit ich das beurteilen kann liegt der Performancevorteil wirklich in der cleveren Programmierung (rust gegen perl sagt eigentlich auch schon viel)

Klar wenn ich mir Gedanken mache was ich wirklich brauche, bekomme ich die Überlast von Loxberry schon weg
Bei großen Installationen ist das aber irgendwann nur noch nervig

[hismastersvoice]

Ich gebe svethi recht, man kann Filtern udn nur Teile in die Subscription nehmen.
Aber selbst dann ist das Skript bei größeren Installationen mit viel MQTT einfach an der Grenze.

Ich will das Gateway des Loxberry in keiner weise schelcht reden, für 99% der User wird es wohl auch reichen, in Sonderfällen leider nicht.
Deswegen ist es gut das es die Alternative gibt.

[svethi]

@<Andreas> Du hast schon richtig beschrieben, dass es das JSON ändert (macht alles in eine Ebene, aber noch immer wird das JSON komplett übergeben. Hast Du 10 Geräte, die ein JSON mit 100 Elementen publishen, muss dass loxMQTTRelay nur 100 Werte senden. Das MQTTGateway 1000!

[dasrockt]

habe auch alles schon sicher ein paar jahre am laufen aber seit zwei drei wochen funkt es nicht mehr die esp senden brav aber mqtt gateway verweigert ☹️

[Prof.Mobilux]

Ist das so, dass das LoxMQTTRelay das JSON nicht zerpflückt wie svethi oben schreibt? Wie kriege ich dann die einzelnen Werte zum MS?

Egal: Fakt ist, dass Perl hier an der Grenze ist. Es ist sowieso eine eher antike Scriptsprache... Mit Rust kennt sich kein LB Entwickler aus. Python dürfte schon reichen, um ein performantes MQTT-Gateway nachzubauen - idealerweise mit asyncio. Problem: Zeit :-) Am Ende kann das nur Christian sagen - und auch der hat aktuell wenig bis keine Zeit.

Wenn sich jemand findet das LoxBerry Gateway gegen etwas mehr performantes (abwärtskompatibles!!) zu ersetzen - macht sehr gerne einen PullRequest!

Ich persönlich hab immer Bedenken, dass der Miniserver unter den REST-API-Anfragen zusammenbricht...

Die reine Anzahl an Topics ist es übrigens nicht - ich hab 1500 Werte in der Incoming, der LB langweilt sich vor sich hin. Ich denke es ist eine Kombination aus vielen Werten, JSON-Extraktionen und schnellen Wertänderungen. Eventuell ist es auch Christians Routine zum Performancebalancing, dass macht nämlich sein Script automatisch. Aber auch das hat sich vermutlich nie einer wirklich angeschaut. Wir wissen nur, dass es unter bestimmten Situationen unerträglich langsam wird. Warum ist denke ich bis jetzt reine Spekulation. Wenn man das vorhandene Script nicht gegen etwas ganz neues ersetzen möchte, wäre das vermutlich das Erste, was man herausfinden müsste.

[svethi]

In der „Doku“ steht JSON Flattening. Was es ja nicht auflöst, sondern auf eine Ebene runterbricht.
Klar, wenn er es über Websocket macht, hat er ne Dauerverbindung und der ganze Overhead fällt weg.
Ich habe es mir nicht installiert, aber er beschreibt, dass man die benötigten Werte im MS angibt und das Tool dann automatisch die Subscriptions anlegt. Klar, das verringert den Traffik gewaltig

[<Andreas>]

Die json Einzelwerte kommen bei mir genauso an wie zuvor beim Loxberry, auf welcher Ebene es das macht ist mir als Endnutzer eigentlich egal, Hauptsache ich bekomm die Werte in die Config

Das Tool das automatisch die Subscriptions anlegt ist optional man kann sie auch so wie im Loxberry eintragen, ich hatte am Anfang noch einfach # eingetragen und es hat es trozdem ohne nennenswerte Last verarbeitet (man muss es glaube ich einfach mal auf einer hohen Last laufen gehabt haben um den Unterschied zu sehen)

Ich könnte mir durchaus vorstellen das Loxmqttrealy als optionales Plugin für die Poweruser laufen zu lassen, man würde auch kein Docker benötigen sondern nur Python, Rust und die entsprechenden Pakete, Gateway Conversions, Incomming Overview und Gateway Transfromers sind halt dann nicht benutzbar...

[Noschvie]

Wäre es nicht möglich, das Perl Script von der AI analysieren zu lassen und dies anschließend als Grundlage für eine Python Implementierung zu verwenden?

[Prof.Mobilux]

Probiere es aus. https://github.com/mschlenstedt/Loxb...mqttgateway.pl

[king-rulez]

Mich trafs jetzt auch. MQTT braucht 2-60 sec zum Verarbeiten, meist im Schnitt 20-30 sec. Das ist für Haushaltsangehörige 😀 leider nicht zu tolerieren.

Der erste Kern vom CPU ist auch bei mir voll überlastet (wie oben beschrieben). Mqtt-Errormeldungen: "keepaliveepoch is older than 5 min" und auch Mosquitto. Anzahl Mqtt-Zeilen: <800, Miniserver gemonitort: schickt auch nur 10 Sachen pro min.
Gegeben ist Loxberry 3.0.1 auf Raspb Pi 3b+, bereits 3x völlig neu aufgesetzt, gänzlich ohne plugins, Netzteil+SD+USB neu gegeben. Keine Änderung...

Was kann sein?
Wie habt ihr anderen es erfolgteich gelöst?

Wo finde ich und wie kann ich Loxberry 2.x installieren, scheinbar funkt das gut ✌️
THX!

Ich hatte das gleiche Problem, MQTT Befehle hatten teilweise über 60 sekunden Verzögerung.
Bei mir hat es geholfen die Subscription Filter Expressions (RegEx) entsprechend zu setzen.

[dasrockt]

Habe bei mir jetzt folgendes gemerkt bei mir kommen drei riesen topics überzigbee2mqtt und zwar sind das zigbee2mqtt_bridge_definitions , zigbee2mqtt_bridge_devices & zigbee2mqtt_bridge_info diese riesen topics habe ich vorher noch nie bemerkt vielleicht kam das mit einen plugin update auf alle fälle hat bis vor 1-2 Wochen alles normal funktioniert... habe jetzt JSON Expand deaktiviert seit dem sieht es wieder stabiler aus.
Interessant wäre das man bei zigbee2mqtt dies brocken abdrehen könnte

[hme0354]

ach du auch. Bei mir ähnlich.

[Noschvie]

Habe nun das Perl Script von der AI analysieren lassen... Ergebnis siehe MQTT-Gateway-Analyse-v1.pdf

In einem weiteren Schritt wurde das Perl Script von der AI in ein Python Script konvertiert, siehe mqtt_gateway.txt und MQTT-Gateway-Python-v1.pdf

Habe derzeit keinen LB 3 zum Testen verfügbar.

[<Andreas>]

Ganz ehrlich, ein ungetestetes von der KI übersetztes Script hilft da niemanden weiter, warum kein Async wenn schon in Python und warum eigentlich Python wenn man es doch eh von der KI schreiben lässt, schreit ja nach den nächsten performance Problemen

[Noschvie]

Du kannst dich gerne einbringen und es auf Async umschreiben