Extreme Verzögerungen - wie gezielt auf die Suche gehen? (Loxone, MQTT, NodeRed,...)

[Clubsport]

Hallo Mitleidende,

ich kämpfe aktuell seit dem Wechsel auf Loxone 13.1 (und diversen anderen kleinen Änderungen) mit extremen Verzögerungen in der Automation.
Aufbau der Struktur ist ca. folgende:

- Loxone als Steuerungslogik
- diverse Sensoren und Aktoren per MQTT und/oder den Umweg über NodeRed eingebunden

Hardware:

- Loxone MS Go Gen.1 auf Version 13.1
- MQTT Gateway Plugin (V 2.1.0) auf einem Loxberry V2.2.2.2 (Raspi 3B+), neben anderen Plugins
- NodeRed zusammen mit PiHole und CUPS auf einem Raspi Zero W

Wie kann ich gezielt auf die Suche nach der Ursache gehen? Über den MQTT-Explorer sehe ich zumindest schon mal, dass tatsächlich eine Verzögerung beim Absetzen der Befehle (z.B. eine Lampe) vorhanden ist - daher würde ich die Ursache im MQTT-Gateway oder davor vermuten.

Im MQTT-Gateway Plugin ist mir noch aufgefallen, dass die "Incoming Overview" extrem laggy zu bedienen ist - hab ich vielleicht einfach zuviele Topics die verarbeitet werden müssen?!
Könnt ihr mir hier mal so eine grobe "Hausnummer" geben, was man dem Raspi zumuten darf?
Der Loxberry selbst ist über den Healthcheck aber komplett unauffällig.

Ich hatte schon mal solche Probleme, da lag es allerdings an einem (fehlkonfigurierten) Sensor, der mir das MQTT-Gateway zugespammt hat.

Bitte helft mir, ich rede hier wirklich von Verzögerungen im Minuten-Bereich.
Ich habe schon das Statistics4Lox-Plugin über die GUI alles disabled, weil ich das als Ursache in Verdacht hatte, aber das hat es nur gefühlt minimal besser gemacht.

[svethi]

Du brauchst doch „nur“ den Weg der Daten logisch verfolgen. Ein Sensor, der seine Daten selbst über MQTT einliefert, kannst Du ja allein schonmal km MQTT Incomming überprüfen. Normalerweise gibts da kein delay. Und wenn ja, dann musst Du die Kette abgehen. Du musst beim Sensor anfangen und dann bei jeder Stelle prüfen was los ist.
Kann ja gut sein, dass Du viel zu viele Daten schickst und der MS das ausbremst und die Warteschlange immer größer wird

[Clubsport]

Hi svethi, danke dir - ich seh aktuell den Wald vor lauter Bäumen nicht, hab aber auch den Kopf momentan richtig voll (Arbeit)....
Ich werde damit mal beginnen - ich werd mal die Zeiten versuchen (wenigstens sekundengenau) über ihren Pfad zu beobachten!

Erste Erkenntnis: Die Absetzung einer Meldung vom Sensor (ich teste das aktuell mit einem Bewegungsmelder) erscheint im MQTT-Explorer quasi zeitgleich, im "Incoming Overview" habe ich schon mal die ersten 1-2 Sekunden Delay... Das variiert. Wie verlässlich / aktuell ist die Anzeige dort?

[Christian Fenzl]

Du musst ins MQTT Gateway Log schauen. Die Incoming Overview hat ein dynamisches Delay von mindestens 1 Sekunde. Das ist aber nur die Anzeige im Browser. Im Log siehst du die Zeiten in Millisekunden genau.

[Clubsport]

Hallo Christian,

ich hatte auf dich auch gehofft!
Das passt auch soweit!!! Nur wenige Millisekunden. Ich vermute mal, jetzt muss ich in Loxone mir den http-Monitor vornehmen, oder?

[svethi]

Du hast gesagt, dass Du sehr viele Daten hast. Wenn Du die alle an den ms schickst, dann kann das schon eng werden, da der ms nicht so viele Connections verwalten kann.

[Clubsport]

Okay, das heisst wirklich hinsetzen und die Arbeit machen, und ALLE nicht benötigten Sachen per "Do not forward" raus schmeißen, korrekt? Na dann hab ich ja ne Abendbeschäftigung....

[svethi]

Oder mit entsprechend Wildcards nur die Daten subscriben, die Du auch brauchst

[Prof.Mobilux]

Naja, was hast Du denn geändert? Wenn es "früher" mit den vielen Daten ging, dann würde ich auf Loxoneseite schauen, ob es nicht die V13 selbst ist. Würde mich nicht wundern... Eventuell noch einmal auf die V12 downgraden und schauen, ob dann alles wieder in Ordnung ist. Dann schmeisst Du die V13 da hin, wo sie hingehört und wartest auf die nächsten Bugfixes, bis Loxone die Kinderkrankheiten der V13 gelöst hat.

[Christian Fenzl]

Clubsport Es geht um das Senden per UDP vom Miniserver an das MQTT Gateway, richtig?

Hast du das denn jetzt immer, oder nur sporadisch?

Zum Zeit messen kannst du eigentlich nur:
- Schauen, wann der Befehl getriggert wurde (über die App oder Logik,...)
- Schauen, wann der Befehl im Loxone Monitor per UDP versandt wurde, und
- Schauen, wann der Befehl am MQTT Gateway angekommen ist.

Damit du die Timestamps vergleichen kannst, muss die Uhrzeit zwischen Miniserver und LoxBerry synchron laufen. (aber wenn es um Minuten geht, kannst du auch mitzählen ;-) )

Ich weiß nicht, von welchen Datenmengen du in die andere Richtigung MQTT -> Loxone sprichst (100 Werte? 1000 Werte? 3000 Werte?), aber es gibt immer noch den Cache am LoxBerry, der identische Daten abfängt - die kommen sowieso nur bei Änderung zum Miniserver. Im Gateway Log sieht man nicht, wenn Daten vom Cache abgefangen wurden. Das siehst du nur auf der Miniserver-Seite im Netzwerk-Log, was dort wirklich los ist. Ich würde aber Daumen Mal Pi sagen, dass 90% der Daten vom Cache abgefangen werden, weil sie identisch sind. Nur beim Gateway-Neustart und auch beim Miniserver-Neustart wird alles beim ersten Eintreffen einmal neu übertragen. Dann ist das Gateway und der MS mal für eine Minute beschäftigt. In der Zeit werden eingehende UDP-Daten auch langsamer verarbeitet.

Wenn das aber alles erst seit Loxone 13.1 passiert, dann hast du ein "schlechtes Update" erwischt

lg, Christian

[Clubsport]

Ich hab jetzt mal erstmal meine Hausaufgaben gemacht - und wirklich sauber durchsortiert... Mal gucken wie es damit wird.

Ich nutze die virtuellen http-Eingänge, falls das eine Rolle spielt....?!?

Aktuell waren es ca. 1500 Werte, die da rein gespült wurden.... von denen ich vielleicht 30 verwendet habe.

Ich möchte erst auf meiner Seite aufräumen, bevor ich die 13.1 noch mehr verfluche.....

[simon_hh]

Mal als Gefühl... bei mir werden durch shellies ca 2500 Werte eingespült ubd es scheint keine große Verzögerung zu geben

[Clubsport]

Danke, dann weiß ich das ungefähr einzuordnen

[Christian Fenzl]

Vieles kannst du per Subscription Filter abfangen, ohne jeden einzelnen Wert angreifen zu müssen.