MQTT Gateway sehr langsam bei hoher CPU Last

[Mex]

Hallo zusammen

Ich habe bei meinem Loxberry das Problem dass das MQTT Gateway sehr träge ist.
LB Version ist 3.0.1.2
Da ich das Problem schon länger habe, wurde er gestern neu installiert.
Aber leider auch hier das gleiche Problem.
Verwendet wird der LB auf ESXi. VM Tools wurden installiert.
Als virtuelle HW stehen ihm zwei Cores (Xeon E5-2680 v4) und 16GB RAM zur Verfügung.
Das sollte doch reichen nehme ich an.

Das Problem ist dass Befehle sehr langsam bis teilweise gar nicht umgesetzt werden.
Was bei Bewegungsmelder natürlich nicht von Vorteil ist.
Das Merkwürdige hier ist das im MQTT Finder LOG die Befehle sofort kommen wenn diese statt finden.
Allerdings in der Incoming Overview erst viel später (von ein paar Sekunden bis zu Minuten) angezeigt werden.
Und gleich lang dauert es auch bis der Befehl dann verarbeitet und an Loxone gesendet wird.
So kann ich das einfach nicht mehr nutzen.
Data Transfer Performance ist auf Fast (Default).

Die CPU Auslastung von mqttgateway.pl ist hier bei über 40%.
Und das permanent.

Die gesamte Systemauslastung ist natürlich nicht so hoch.
CPU overall liegt bei ca. 24%.

Ich hoffe ihr könnt mir hier weiterhelfen.

Vielen Dank

bg

Mex

edit: Ich habe nun noch einen Loxberry installiert. Auf diesem habe ich nur das nötigste und eben MQTT konfiguriert. Um auszuschließen dass etwas anderes die Probleme verursacht. Aber auch hier habe ich genau die gleichen Probleme. Sobald etwas an das MQTT Gateway schickt geht die Auslastung des Prozesses auf ca. 40%. Danach habe ich nochmal die IP auf eine andere geändert sodass nichts mehr auf den Test LB geschickt werden kann. Hier geht dann nach ein paar Minuten die Last runter. Aber wenn ich zB. nur Z2M (ca. 12 Geräte) auf den Test LB mit MQTT stelle ist die Last schon wieder auf ca. 40%. Und hier kommt kaum etwas daher.
Ebenfalls ist es hier so dass im MQTT Finder alles was von Z2M daher kommt sofort ersichtlich ist. Aber in der Incoming Overview nicht. Bzw. extrem verzögert

[Christian Fenzl]

Was steht denn im Log?
Wieviele Einträge hast du in der Incoming Overview?

Wenn du in der Incoming Overview nach mqttgateway filterst, kommen ein paar Statistikwerte. Mach da mal einen Screenshot.

lg Christian

[Mex]

Hallo

Danke schon mal für deine Antwort.
Es wird immer merkwürdiger...
Also ich nun nach Hause gekommen bin war MQTT Server state disconnected und dass Ports/Host etc. geprüft werden sollten.
Danach habe ich den Loxberry einmal neu gestartet.
Danach war alles wieder grün.
Dann habe ich ein paar Minuten gewartet und danach kam eine Meldung dass keepaliveepoch länger dauert.
Und noch ein paar Minuten später ist alles wieder grün...

In der Incoming Overview habe ich ca. 8200 Einträge.
Wenn er länger läuft sind es maximal 9500.

Welche Logs brauchst du?
Es gibt ja doch ein paar

Hier noch der Screenshot:

Hier steht bei Status Disconnected. Solld as so sein??
Beim Selbsttest aber ist alles grün.




Ich habe zum Testen auch noch 2 Cores hinzugefügt.
Auslastung ist sehr Einseitig wegen dem MQTT Prozess.

[svethi]

Also bei der Menge brauchst Du Dich auch über die Last nicht wundern. Du solltest mal Deine Subscriptions überprüfen und nur das eintragen, was Du auch benötigst.

[Mex]

Das meiste hier ist vom Zigbee2MQTT. Da ich den haken bei "Topic bei MQTT PlugIn registrieren" aktiv hatte. Das habe ich nun geändert. Und ich bin bei etwas über 1500. Ich habe keine Ahnung was hier ein "normaler" Wert ist. Aber die Auslastung ist trotzdem oben. Jetzt ist das meiste von den Shellys. Ca. 45 Stk. Habt ihr hier bei jedem Shelly nur in den Subscriptions stehen was ihr auch braucht? Und das für jeden einzelnen? Oder "shellies/#" eingetragen?

[hismastersvoice]

Die Anzahl der Werte heißt erst mal nichts.
Last kommt von Werten die extrem oft/schnell im System verarbeitet werden.

Beispiel: PV-Zähler sekündlich oder ähnliches.

Such mal ob du viele Werte hast die oft erneuert werden.

Ich habe auch >1200 Werte im Loxberry, aber keine hohe Last.

[Mex]

Nachdem ich Z2M und Homeassistant hier einmal extrem eingeschränkt habe ist es aktuell bei der Auslastung besser. Jetzt gerade 12%. Ich werde das übers We. einmal beobachten.
Außerdem werde ich mal schauen ob ich eine Möglichkeit finde den Prozess mqttgateway in der Last zu überwachen.

[hismastersvoice]

Ich habe seit gestern auch das selbe Problem...

Nachdem ich Zigbee2MQTT installiert habe werden mehrere tausend Werte (>6000) von der Bridge angelegt (Expand JSON Data).
Das kann man nur über ACL deny verhindern, diese kann ich natürlich nur händisch im System anlegen und würde nach jedem Update vermutlich nicht mehr gehen.
Das mqttgateway.pl geht auf 99% und das ganze System ist kaum noch zu bedienen.

Abhilfe konnte ich nur schaffen indem ich die Subscription nur direkt auf das Gerät angelegt habe und nicht auf das kpl. Zigbee2MQTT.
Dieser Workaround ist aber beim hinzufügen eines neuen Gerät eher fehlerbehaftet.

Christian Fenzl
Ich habe mir das noch nicht angeschaut, aber was macht das Skript das es derart viel Leistung bei vielen Werte braucht.
Die Werte der Bridge von Zigbee2MQTT werden nur sehr sporadisch erneuert, das Skript braucht aber dauerhaft viele Leistung.
Läuft das Skript immer nur auf einem Kern? Es wird immer ein Kern voll ausgelastet und die anderen 5 haben wenig zu tun.

Ein Thema ist auch...
Wenn ich zB von einem MQTT Gerät einen Wert an Loxone senden will, dann dauert es oft Sekunden bis es auslöst.
Beispiel ein HASP-Display senden einen Tastendruck per MQTT, dieses wird sofort im MQTT Explorer angezeigt, einmal kommt er sofort bei Loxone an, das nächste mal dauert es 1-2 Sekunden. Das ist willkürlich und ich kann keine Situation nachstellen um die Ursache zu erkennen.


PS: Auch die Incoming Overview im UI ist kaum noch zu bedienen, jedes Eingabe dauert 1,2,3 Sekunden.

[svethi]

Ist doch ganz klar. Wenn Du expand JSON an hast wird jedes JSON ausgepackt und wenn in einem JSON 30 Werte drin sind und sich nur einer davon ändert, muss das komplette JSON wieder ausgepackt werden. Und ausgepackt und überprüft werden muss es ja auch ohne Änderung.

[hismastersvoice]

Ein JSON auspacken kann doch keine 99% CPU Last auf einem Kern verursachen.
Es ändert sich kein Wert, und die CPU wird trotzdem extrem belastet.

Kenn mich mit Perl nicht aus, aber in Python und PHP würde das keine solche CPU Last ergeben.

[svethi]

Zu Perl Zeiten gab es noch gar kein JSON. Da muss sicher mindestens ein Modul geladen werden. Und wenn Du dann mal angenommen 10 Werte im JSON hast und wie Du selbst sagst, dass es dann gleich > 6000 Werte sind, dann bekommst Du über MQTT zusätzlich zu normalen Werten auch noch über 600 JSON‘s innerhalb von paar Sekunden. Für jedes muss dann ein Modul geladen werden. Und wie schon gesagt. Es ist doch völlig uninteressant ob sich da ein Wert geändert hat. Das JSON muss doch erstmal interpretiert werden. Und dann wird ja nicht nur geprüft ob geändert sondern Du kannst ja auch noch für jeden Wert einstellen ob er gecached werden kann oder nicht und andere Optionen.
Nimm es mir nicht übel aber wenn Du Dich hier jetzt über die Abarbeitung von über 6000 Werten beschwerst, dann möchte ich von Dir sehen, dass Du diese ganzen Werte im MS benötigst. Ich will also sehen, dass Du für jeden Wert einen Gegenpart in der Config hast. Dann schaltest Du den Cache für alle Werte ab und zeigst mir dann wie die Reaktionszeiten des MS sind.

[hismastersvoice]

Danke für die Aufklärung.

Wer beschwert sich?
Ich habe meinen Workaround gefunden, und mein System läuft ohne hohe Last, was ich oben erwähnt habe.

Es geht hier im Thema um hohe CPU Last und wo sie her kommen kann, und das wird damit bestätigt.

Ich lasse mir keine 6000 Werte an den MS schicken, man könnte das ja auch per RegEx filtern, aber auch dann braucht das mqttgateway.pl hohe Rechenleistungen. Meine Lösung also war die Subscription zu ändern, was nicht sehr elegant ist aber geht.

Wenn man für jedes JSON ein Modul laden muss ist die Abarbeitung in Perl sehr ineffektiv, und es ist klar woher die CPU Last kommt.


Aber wie du siehst kann alleine ein Loxberry-Plugin wie Zigbee2MQTT das ganze verursachen, und da dieses Plugin auch gleich die Subscription anlegen kann, wird es schwer das auf anhieb zu verstehen warum ein Loxberry plötzlich langsam oder im worst case instabil wird.

[Mex]

Also leider ist mein Problem nicht behoben.
Ich bin jetzt bei nur 2238 Werten in der Incoming Overview.
Wobei diese natürlich nicht pro Sekunde so ankommen.
Aber ich bin bei der Last schon wieder so hoch oben.

Was mir noch aufgefallen ist
Der "mqttgateway_status" geht bei mir anscheinend öfter auf Disconnected.
Wenn man Zeitgleich einen Selbsttest durchführt ist allerdings alles grün.
Kann es sein dass die Verbindung irgendwie unterbrochen wird und die ganzen Meldungen gecached werden wodurch die CPU nach oben geht?
Das ist die Meldung im Log:

OK: MQTT IN: loxberry-vm/mqttgateway/status: Disconnected
12:50:59.497 loxberry-vm/mqttgateway/status is cached
12:50:59.498 loxberry-vm/mqttgateway/# matches loxberry-vm/mqttgateway/status, send to MS 1
12:50:59.498 HTTP: Preparing input loxberry-vm_mqttgateway_status (using cache): 0

12:50:59.617 OK: MQTT IN: loxberry-vm/mqttgateway/keepaliveepoch: 1728816506
12:50:59.618 loxberry-vm/mqttgateway/keepaliveepoch is cached
12:50:59.618 loxberry-vm/mqttgateway/# matches loxberry-vm/mqttgateway/keepaliveepoch, send to MS 1
12:50:59.618 HTTP: Preparing input loxberry-vm_mqttgateway_keepaliveepoch (using cache): 1728816506

Es ist dann aber nicht so dass nichts mehr geht. Nur eben extrem verzögert.
@hismastervoice: Könntest du mal schauen ob du diese Meldung auch im Log hast? Bzw. in der Incoming Overview unter "mqttgateway_status". Wäre interessant ob das bei dir auch disconnected war/ist.
Und ich kann mir nicht vorstellen dass es an der Anzahl der Befehle hier liegt. Zumindest jetzt bei unter 3.000. Denn so ein Prozessor den ich hier einsetze ist für weit höhere Lasten und Berechnungen ausgelegt. Auf diesem liefen zuvor 20-30 virtuelle Server mit über 1.000 Benutzern die darauf zugriffen gleichzeitig. Als Disk wird ein SSD Raid Verbund verwendet. Also würde ich die Zugriffszeiten auch ausschließen.

[hismastersvoice]

Habe ich nicht, aber ich habe auch die hohe Last im Augenblick nicht.
Da müsste ich erst wieder auf umkonfigurieren um die hohe Last zu bekommen.

Schau ich mir mal an.

[Mex]

Was hast du genau gemacht damit die Last nicht mehr vorhanden war?
Nur die Subscription auf das Gerät direkt? Das habe ich auch gemacht. Aber richtig geholfen hat das nicht.

[Mex]

Hier ein Auszug von einem Log nach einem Neustart des MQTT Gateways:


13:27:35.938 OK: MQTT IN: loxberry-vm/mqttgateway/status: Joining
13:27:35.938 loxberry-vm/mqttgateway/status is cached
13:27:35.938 loxberry-vm/mqttgateway/# matches loxberry-vm/mqttgateway/status, send to MS 1
13:27:35.938 HTTP: Preparing input loxberry-vm_mqttgateway_status (using cache): 2

13:27:35.940 OK: MQTT IN: loxberry-vm/mqttgateway/keepaliveepoch: 1728818844
13:27:35.941 loxberry-vm/mqttgateway/keepaliveepoch is cached
13:27:35.941 loxberry-vm/mqttgateway/# matches loxberry-vm/mqttgateway/keepaliveepoch, send to MS 1
13:27:35.941 HTTP: Preparing input loxberry-vm_mqttgateway_keepaliveepoch (using cache): 1728818844

13:27:35.943 OK: MQTT IN: loxberry-vm/mqttgateway/status: Joining
13:27:35.943 loxberry-vm/mqttgateway/status is cached
13:27:35.944 loxberry-vm/mqttgateway/# matches loxberry-vm/mqttgateway/status, send to MS 1
13:27:35.944 HTTP: Preparing input loxberry-vm_mqttgateway_status (using cache): 2

13:27:35.946 OK: MQTT IN: loxberry-vm/mqttgateway/keepaliveepoch: 1728818844
13:27:35.946 loxberry-vm/mqttgateway/keepaliveepoch is cached
13:27:35.947 loxberry-vm/mqttgateway/# matches loxberry-vm/mqttgateway/keepaliveepoch, send to MS 1
13:27:35.947 HTTP: Preparing input loxberry-vm_mqttgateway_keepaliveepoch (using cache): 1728818844

13:27:36.855 OK: MQTT IN: loxberry-vm/mqttgateway/status: Joining
13:27:36.855 loxberry-vm/mqttgateway/status is cached
13:27:36.855 loxberry-vm/mqttgateway/# matches loxberry-vm/mqttgateway/status, send to MS 1
13:27:36.855 HTTP: Preparing input loxberry-vm_mqttgateway_status (using cache): 2

13:27:37.865 OK: MQTT IN: loxberry-vm/mqttgateway/status: Connected
13:27:37.865 loxberry-vm/mqttgateway/status is cached
13:27:37.865 loxberry-vm/mqttgateway/# matches loxberry-vm/mqttgateway/status, send to MS 1
13:27:37.865 HTTP: Preparing input loxberry-vm_mqttgateway_status (using cache): 1


13:29:23.074 WARNING: No connection to MQTT Server localhost - Check host/port/user/pass and your connection.

13:29:23.102 OK: MQTT IN: loxberry-vm/mqttgateway/status: Disconnected
13:29:23.102 loxberry-vm/mqttgateway/status is cached
13:29:23.102 loxberry-vm/mqttgateway/# matches loxberry-vm/mqttgateway/status, send to MS 1
13:29:23.102 HTTP: Preparing input loxberry-vm_mqttgateway_status (using cache): 0

13:29:23.222 OK: MQTT IN: loxberry-vm/mqttgateway/keepaliveepoch: 1728818940
13:29:23.222 loxberry-vm/mqttgateway/keepaliveepoch is cached
13:29:23.222 loxberry-vm/mqttgateway/# matches loxberry-vm/mqttgateway/keepaliveepoch, send to MS 1
13:29:23.222 HTTP: Preparing input loxberry-vm_mqttgateway_keepaliveepoch (using cache): 1728818940



Also irgendwas passt hier nicht würde ich sagen...

Testweise werde ich Expand Json Data einmal deaktivieren. Mal schauen ob es da gleich ist.

[raphiki]

Sieht bei mir im Log genauso aus 😒

[Mex]

Also ohne Expand Json Data dürfte es "connected" bleiben. Zumindest ist es die letzte Stunde so gewesen. Aber sobald ich den Haken wieder setze bekomme ich nach ein paar Minuten wieder die Meldung "Disconnected".
Wenn ich das nun umstellen will, wie bekomme ich die Werte dann vom MQTT Gateway in Loxone? Da hier ja nur die Json Datei im MQTT Gateway ist und nicht wie sonst in der Regel eine Zahl. Gibts dazu evtl. wo eine Beschreibung? Die die ich gefunden habe sind alle mit expanded Json Data...
Falls also wer einen Link für mich hat wäre das super.
Oder sollte dann von HTTP auf UDP umgestellt werden?
Aber wird dann mit der normalen text to value conversion noch umgewandelt? Denn ein false oder true wird nicht zu 1 oder 0. Das habe ich getestet.

[Jan W.]

Ich habe zwar kein Problem mit zu hoher CPU Last, aber nutze immer stärker MQTT und stelle Teile meiner Config von UDP Input und Parsen um. Bei der Nutzung von MQTT für meine easee Wallbox und Tesla Command Plugins fiel mir auf, dass die Abfragen der Geräte sehr viele Elemente liefern, die ich gar nicht benötige:


Es ist ja nicht ungewöhnlich, dass eine einzelne API Abfrage ein JSON mit vielen Werten liefert. Es ist mir auch klar, dass diese vom Loxberry zunächst verarbeitet werden müssen und die Liste der Elemente in der MQTT Incoming Overview Ansicht dadurch nicht kleiner wird.

Die Elemente, die eine "HTTP 200 OK" Antwort vom MS bekamen, also in der Loxone Config enthalten sind, werden nur bei Änderung gesendet, was die Last gering hält (in meinem kurzen Test wurden die allerdings auch ab und zu gesendet - habe mir den Code und Cachezeiten noch nicht angesehen). Allerdings werden alle Elemente mit der Antwort "HTTP 404 Input not Available" (yet) regelmäßig bzw. viel öfter gesendet. Dies verursacht unnötige Last zwischen Loxberry und MS, insbesondere wenn diese Antwort für 95% der Elemente erfolgt:

EDIT: Ich habe es gerade noch einmal näher überprüft: die Elemente, die nicht in der Loxone Config sind (und daher mit 404 vom MS beantwortet werden) werden ebenfalls nur bei Änderungen vom Loxberry gesendet. Solange diese sich nicht ändern, ist der Overhead daher gering.



Man kann zwar händisch den Haken bei "Do not forward" setzen, aber das erfordert viel manuellen Aufwand. Wäre es nicht sinnvoll, die Antwort des MS auszuwerten und eine Kategorie "Suppressed" zu ergänzen, in der alle Elemente mit einer HTTP 404 Antwort aufgenommen werden? Dann würden diese Elemente deutlich weniger Last verursachen und eine Optimierung würde automatisch erfolgen.

Man hätte allerdings das Problem, dass alle Elemente, die man nachträglich in der Loxone Config ergänzt, natürlich wieder Daten senden sollen. Dies könnte man z.B. über ein Löschen des Caches oder manuellem Ändern eines Hakens bei "Suppressed" lösen, aber ein Neustart des MS beim Installieren einer neuen Config hat ja ein ähnliches Problem, dass die Elemente, die bereits mit HTTP 200 OK an den MS gesendet wurden, nur bei Änderungen gesendet werden und es daher sehr lange dauert, bis wieder passende Werte beim MS angekommen sind. Das ist mir vor kurzem aufgefallen und eine Suche hat die erforderliche Lösung schnell gefunden: Beispiel: Nach einem Miniserver-Neustart das Übermitteln der aktuellen Daten forcieren (Danke an Prof.Mobilux für diese Info). Ich denke, dass es am besten wäre, wenn dieser Reconnect Aufruf alle unterdrückten Elemente einfach wieder aktiviert.

EDIT: bei sehr vielen Elementen in der MQTT DB könnte es die Last im Netz und auch auf dem MS etwas reduzieren, aber bei einer moderaten Anzahl von Elementen (ich habe einige 100) und nur wenigen Elementen, die sich schnell ändern, bringt es wahrscheinlich nicht viel.

[Christian Fenzl]

Mex Ich würd gern mal ein ganzes oder zumindest größeres Log sehen.

Die JSON Library wird natürlich nicht jedesmal neu geladen, die bleibt im RAM. Man sieht an den Timestamps, wie lange was dauert.

Disconnects mitten drin sind ungewöhnlich. Ich brauche ein vollständiges Log.

lg Christian

[Mex]

Ich kann hier leider kein Log mehr bereit stellen da ich alle Shellys auf UDP umgestellt habe. Somit ist die Last weg. Ich habe alles soweit reduziert dass ich nur mehr ca. 150 Meldungen per MQTT bekomme. Und was ich nachstellen konnte war das Problem weg als ich Expand Json Data deaktiviert habe. Wenn ich jetzt in die Logs sehe, sehe ich nur mehr aktuelle Daten. Und derzeit funktioniert alles ohne Probleme. Ich habe auch keine Disconnects mehr. Das protokolliere ich jetzt in Loxone.

[Christian Fenzl]

Das Unterdrücken bei 404 habe ich mal überlegt, aber die meisten kommen schon nicht damit zurecht, dass das Gateway die Daten cached (obwohl das 100x überall steht).
Da aber die 404er auch gecached sind, sollte das OK sein.

Die hohe Last bei dem geringen Durchsatz bei euch kann ich mir aktuell auch nicht erklären.

Stellt mal bei der Performance im Widget höher. Vielleicht kommen die Disconnects davon, dass die Messages nicht schnell genug abgearbeitet werden können. Ein Disconnect löst vom Broker automatisch das Abholen aller gespeicherten Werte aus, was wiederum zu voller Queue führt, deswegen Disconnect, wieder alles abholen,…
Das wäre eine Erklärung für die Dauerlast.

[Jan W.]

Beim easee Plugin ändern sich bei einem Ladevorgang relativ häufig sehr viele Elemente, z.B. Spannungen und Stromstärken auf den einzelnen Phasen (mit Nachkommastellen), die ich gar nicht im MS abfrage. Daher kam wahrscheinlich meine anfängliche Vermutung, weil diese Elemente sehr häufig im Wireshark Dump auftauchten.

Ich setze mal manuell den Haken bei "do not forward" für alle nicht verwendeten Elemente, was das Problem lösen sollte. Vielleicht wäre ein Button sinnvoll, der diesen Haken bei allen *angezeigten* Elementen setzt (evtl. noch ein 2. Button der den Haken löscht). Dann müsste man nur den Filter auf "Not found" setzen und könnte dann mit einem Button das Weiterleiten für alle nicht verwendeten Elemente blockieren.

Die Anpassungen im Code wären sicherlich einfacher, aber es gibt dann sicherlich einige User, die nachfragen, warum bestimmte Werte nicht an den MS gesendet werden und sich nicht erinnern, dass sie den Button vorher mal gedrückt hatten. ;-) Man kann es wahrscheinlich nicht jedem recht machen.

[hismastersvoice]

Christian Fenzl

Ich habe schon länger vor gehabt meinen Loxberry auf einem CM4 umzuziehen.
Habe ich am WE gemacht und MQTT springt bei vielen Daten immer wieder mal auf 80-90% für eine sehr kurze Zeit, danach sofort wieder auf 3-4% und meist 10-20%.
Also alles normal... Habe auf Fast (Default), aber auch bei Really Fast ist die Last gleich.
Lag eher an meiner alten Installation denke ich.


Wie man sieht hat der Loxberry trotz einigen Plugins incl Zigbee2MQTT und NodeRed im Hintergrund kaum was zu tun.

Übrigens eine Empfehlung für einen Stromsparanden Loxberry... CM4 mit WaveShare Nano Base Board (B)
Im normalen Betrieb <1,8W incl. Netzteil direkt am Board gemessen 1,4W. Für einen Raspi 4 ein sehr sparsamer betrieb.

[raphiki]

Hallo Zusammen,

gibt es mittlerweile einen Lösungsansatz für das Problem? Ich kämpfe seit längerem mit den gleichen Themen.

Status des Gateways ist quasi dauerhaft auf Disconnected und nur kurz nach einem Neustart auf Connected. Die meisten Werte kommen trotzdem wie gewünscht am Miniserver an. Aktuell hab ich ca. 950 Werte, wovon sich viele im Sekunden bzw. 5-Sekundentakt aktualisieren (Zählwerte). Eine Erhöhung des Sendeintervalls hat auch keine Verbesserung gebracht. D.h. Daran kann es eigentlich nicht liegen.

Aktuell hab ich zusätzlich beim Senden von Werten vom Miniserver zum MQTT-Gateway das Problem, dass die UDP-Werte extrem lang brauchen bis sie in MQTT ankommen. Da können schonmal einige Minuten vergehen oder die Werte werden komplett verschluckt. Da macht Dimmen mit einem Shelly RGBW natürlich keinen Spaß.

Loxberry läuft bei mir auf einem RPI 4. Eine Neuinstallation hat keine Besserung gebracht. Gesamtauslastung des Systems liegt bei knapp 20%.

Bis zum damaligen Update auf Version 3 lief alles in der gleichen Konstellation unter Version 2 mit dem MQTT-Plugin problemlos. Ich überlege daher testweise mal wieder auf Version 2 zu gehen.


Update:

Ich hab hab nun einen RPI3 mit der Loxberry-Version 2.2 aufgesetzt. Seitdem läuft alles wieder ohne Probleme. MQTT-Gateway hat mit den gleichen Daten keine Probleme und bleibt connected. Das verteilen der Daten läuft auch deutlich schneller als davor. UDP-Befehle werden fast ohne Verzögerung umgesetzt.
Die Gesamtauslastung des RPI ist zudem deutlich geringer und er bleibt auch deutlich kühler.