[Hilfe] Logic: Queued schaukelt sich hoch

[hartwigm]

Ich kam Gestern aus dem Urlaub zurück, mein Smarthome war offensichtlich noch im Urlaub, da alles nur extrem verzögert reagierte.
Das über Edomi gesteuerte Licht ging erst nach ca. 4min an. Die Visu reagierte aber flott.

Ich fand einen Logic:queued von ca 38.000

Nach dem Stop des Edomi und anschließenden Start, war wieder alles OK. Nun stelle ich Heute Morgen fest dass die Queue nun schon wieder bei 4002 angekommen ist.

Einmal Stop einmal Start und alles ist wieder gut, die queue geht wieder auf einen kleinen Wert zurück und so bleibt das auch weitgehend über den Tag hinweg.

Es scheint so zu sein, dass in der Nacht oder durch irgendeinen Parameter die Queue vollläuft.

Was gibt es für eine Strategie die den Verursacher zu finden.

Das Abschalten von Logiken ist dabei unsinnig, da der Fehler sich erst über lange Zeit aufbaut.

[gulp2k]

Liegt meistens an einer Logikschleife, du wirst wohl nicht drum rum kommen Logiken zur Eingrenzung zu deaktivieren.

Eventuell kannst du ja zuerst mal im Monitor beobachten ob irgendwelche iKO´s besonder oft beschrieben werden.

[hartwigm]

das wird nicht funktionieren
zu eine ist das Projekt zu gross und zum anderen ist die Queue aktuell 0
wenn ich jeden Tag eine Logik deaktiviere bin ich bei der Edomi Version 3 fertig.

Ich brauche ein Verfahren mirt dem ich die Ursache finden kann, wenn das Problem ansteht.

Vielleicht hat ja jemand eine Insidertipp

Hartwig

[hartwigm]

Gibt es den eine Möglichkeit auf die Logic:Queued zuzugreifen.

So dass ich den Verlauf in einem Datenarchiv mitschreiben könnten um zu erkennen, wann die Queue beginnt hochzulaufen.
Heute Vormittag bis 12 Uhr bei ca 50 , eben wieder kontrolliert bei 9000

[givemeone]

Hast du eine Lösung damals gefunden? In der DB man man die Queue nicht einsehen?
zumindest, welche LBS oder welche Seiten beteiligt sind?

Auf sehr schneller Hardware (70Cores) geht meine Logik problemlos ;-)

aktuell versuch ich das jedoch auf etwas stromsparendere Hardware umzustellen.

Da ich über 600 Logikseiten habe und die Queue nur manchmal "hoch" geht, komme ich mit deaktivieren leider auch nicht weiter.
Eine direkte Schleife dürfte es nicht sein.
Mqtt dürfte irgendwie daran beteiligt sein in meinem Fall!

[hartwigm]

Hallo,

bei mir ist das selbe Problem wieder mal hochgepoppt.
Heute Morgen war die Queue mit 40000 Einträgen voll, damit ging überhaupt nichts mehr.

Ein Stopp der Logic und anschliessendem Start hat eigentlich immer geholfen, nicht Heute.

Abhilfe und hier lagst Du mit deiner Vermutung richtig, ist die MQTT-Verbindung.

Ich habe mir mal in der mysql die Tabelle RAMknxRead angeschaut. Diese entspricht bei mir der Anzahl der Queue Einträge.

Schnelle Lösung: den Mqtt Broker Client, welcher die meisten Daten sendet (bei mir der IOBroker) deaktiviert und schon ging die Queue runter. Nachdem diese auf ca. 0 war wieder gestartet und das System läuft stabil

Ich werde als erste Maßnahmen nun den Mqtt Subscriber erst 5min nach Systemstart hochfahren, damit wäre mal eine flottes Starten wieder möglich.

[tunneltruppe]

Hallo,

bei mir ist das selbe Problem wieder mal hochgepoppt.
Heute Morgen war die Queue mit 40000 Einträgen voll, damit ging überhaupt nichts mehr.

Ein Stopp der Logic und anschliessendem Start hat eigentlich immer geholfen, nicht Heute.

Abhilfe und hier lagst Du mit deiner Vermutung richtig, ist die MQTT-Verbindung.

Ich habe mir mal in der mysql die Tabelle RAMknxRead angeschaut. Diese entspricht bei mir der Anzahl der Queue Einträge.

Schnelle Lösung: den Mqtt Broker Client, welcher die meisten Daten sendet (bei mir der IOBroker) deaktiviert und schon ging die Queue runter. Nachdem diese auf ca. 0 war wieder gestartet und das System läuft stabil

Ich werde als erste Maßnahmen nun den Mqtt Subscriber erst 5min nach Systemstart hochfahren, damit wäre mal eine flottes Starten wieder möglich.

Jooo,
dass wenn man mehrere MQTT „Datenpunkte“ sich aus anderen Systemen abholt (bei mir ioborker),
sich die Logik „ausschaukelt“ hatte ich auch vor (hmm fast) Jahren festgestellt.
Ich starte einfach nach einem Neustart vom EDOMI nach nun nach die MQTT Logikbausteine.
Zwar komisch, ist aber so… und es geht..
Gruß Marcus
MQTT1.jpg

[jonofe]

Könnte evtl. mit dem Retain-Flag zusammenhängen. Wenn für sehr viele Topics das Retain-Flag gesetzt ist und dann die MQTT Verbindung aufgebaut wird, dann kommt natürlich erstmal ein Sturm von Nachrichten. Trotzdem bleibt die Frage, warum die nicht mehr abgearbeitet werden. Man könnte auch mal ins Broker Log schauen, wie hoch denn da die Message-Rate ist. Es macht natürlich grundsätzlich Sinn auch bei MQTT nicht zu grob zu subscriben/publishen, sondern nur das was man braucht.

[tunneltruppe]

Also bei mit ist:
1) Im iobroker das Retain- Flag nicht gesetzt
2) Joo subscriben mache ich, wenn gleich das echt nicht leicht für mich war zu testen.
Leider hat das beides nix bei mir gebracht, daher fahre ich alle nach und nach hoch..

[hartwigm]

Im Iobroker habe ich selektiv nur das ausgewählt, was ich wirklich brauche.
Aber mit der Lüftungsanlage, Batteriespeicher und PV kommen da doch sehr viel Daten über modbus rein.
Alle Daten mit wenig Wechsel haben das Retain Flag

An 3 Stellen haben ich hier massive Probleme.

a.) Tageswechsel
b.) Datensicherung
c.) Neustart

Den Neustart kann ich mit Verzögerungen in den Griff bekommen und das hängt am MQTT Subscriber

Beim Tageswechsel oder nach/während der Datensicherung habe ich noch keinen Plan, was da zu machen ist., dies hat auch m.E nichts mit dem MQTT zu tun

Jedenfalls habe ich mindestens 2 x im Monat Morgens den Effekt, dass das Wasser kalt ist, das Licht oder andere Features erst nach mehrere Minuten angehen.
Die Garagen für 10min offen bleibt....


bei b,c. ist m.E. das Problem an de EdomLive.RAMknxRead Tabelle bzw. deren Verarbeitung.

Bei der Queue von ca. 40000 Einträgen, schlägt in der Tabelle z.B. der Eintrag Ko5 Systemzeit über 20 Seiten auf .
Ebenso schlagen da Werte der PV Anlage über 20 Seiten auf.

Inwiefern es hier notwendig ist die Queue z.b. hinsichtlich der Systemzeit abzuarbeiten, oder z.b. nur den letzten Wert zu nutzen, kann ich nicht beurteilen.

Da bei mir Edomi auf einem HyperV Server läuft habe ich hier auch schon mal mit der Speicher und den zugewiesenen CPU´s gespielt, allerdings ohne Nennenswertes Ergebnis.

Screenshot 2022-04-28 095134.png

[Langer89]

Hallo zusammen,

bei mir stellt sich das gleiche Problem dar. Habt ihr schon andere Lösungsansätze gefunden? Ein Aufteilen auf mehrere Subscribeclients bringt, zumindest bei mir, auch keine Lösung. Wie habt ihr eurer Subscribe System aufgebaut? Bei mir ist es: LBS Hostcheck --> MQTT Subscribe Client --> MQTT Topioc Parser --> JASON Extractor