Bestes "Format" Nachrichten über MQTT zu empfangen hinsichtlich Performance

[fudi6489]

Grüß euch

Ich nutze mittlerweile für die meisten Anbindungen zentral NodeRed, Edomi übernimmt größtenteils nur noch die Visualisierung. Ein paar Logiken laufen aber natürlich auch noch darauf, die seit Jahren sehr zufriedenstellend funktionieren.

Da Edomi wie gesagt größtenteils nur visualisiert/steuert, werden extrem viele Nachrichten via "MQTT Subscribe Client 0.6 1901054" von NodeRed an Edomi gesendet.
Hierbei kann ich beobachten dass Topics oftmals nicht aktualisiert werden, in der Zwischenzeit aber schon 10-15 Nachrichten gesendet wurden. Dies kann ich auch mit mqtt.fx sehen. Die Nachrichten werden also von NodeRed gesendet, Edomi "verschluckt" sie aber.

Ankommen tun sie in folgenden Format, und werden dann wie unten weiterverarbeitet:
pv/deye||{"deyewirk":97.9}||1||1||2


image.png
Ich schicke quasi alle Nachrichten einzeln, und gehe davon aus dass das die Probleme verursacht, und bei einer niedrigeren Nachrichtenanzahl die Performance deutlich besser wäre.
Bevor ich jetzt alles ändere, was wäre die resourcenschonenste Variante (welches Format) um quasi eine Live-Anzeige in Edomi zu erhalten?
Oder sollte ich die Frequenz (aktuell 100ms) niedriger stellen, denn 100ms bedeutet für mich maximal 10 Nachrichten pro Sekunde?

Zusätzlich steuere ich manche Dinge über Edomi und sende dann via MQTT, dies funktioniert zuverlässig innerhalb 1-3 Sekunden.
Bis die Rückmeldung über den verstellten Wert kommen, dauerts aber auch mal über eine Minute.

LG

[mycroft2k]

Mehr CPU-Kerne helfen deutlich

Ich setze mehrere Instanzen des MQTT Subscribe Client V0.10 ein, mit Abfragefrequenzen zwischen 500 ms und 3000 ms – je nach Anwendungsfall.

Zum Vergleich:
Eine Frequenz von 100 ms bedeutet 10 Abfragen pro Sekunde.
Beim Victron ESS liefert der SmartMeter alleine alle 100 ms rund 20 neue Werte – das sind etwa 200 Werte pro Sekunde, die EDOMI ausschließlich für den SmartMeter verarbeiten muss.

Auch Geräte wie der Shelly mit Tasmota als EnergyMeter erzeugen eine ähnlich hohe Datenrate und fordern das System entsprechend stark.

SmartMeter und Energy Meter wie der Shelly mit Tasmota werden bei mir nur einmal pro Sekunde abgefragt.

lg

[fudi6489]

Mehr CPU-Kerne helfen deutlich

Ich setze mehrere Instanzen des MQTT Subscribe Client V0.10 ein, mit Abfragefrequenzen zwischen 500 ms und 3000 ms – je nach Anwendungsfall.

Zum Vergleich:
Eine Frequenz von 100 ms bedeutet 10 Abfragen pro Sekunde.
Beim Victron ESS liefert der SmartMeter alleine alle 100 ms rund 20 neue Werte – das sind etwa 200 Werte pro Sekunde, die EDOMI ausschließlich für den SmartMeter verarbeiten muss.

Auch Geräte wie der Shelly mit Tasmota als EnergyMeter erzeugen eine ähnlich hohe Datenrate und fordern das System entsprechend stark.

SmartMeter und Energy Meter wie der Shelly mit Tasmota werden bei mir nur einmal pro Sekunde abgefragt.

lg

Danke für deine Antwort
Die Rechenleistung wäre denke ich ganz gut, bei mir ist das ganze aber nicht ganz durchdacht und ich schicke immer nur eine einzelne Nachricht. Ich denke ich sollte das umstellen...

Meine Visualisierungswerte werden etwa im 5-10sek Rhythmus gesendet was mir zur Visualisierung ausreicht. Sekundengenaue Berechnungen benötige ich nicht, also komme ich mit diesem Intervall ganz gut zurecht.

Ich möchte jetzt die Einzelnachrichten auf eine Nachrichtenkette umstellen. Wie gehe ich hier auf der Edomi Seite performancetechnisch am besten vor?

Hier ein Beispiel: (Topic bleibt pv/prognose)

Alt:
image.png

Neu:
image.png
So werte ich das ganze aktuell (Version Alt) aus:

image.png
Soll ich jetzt das Topic gleich unter E9 in den Subscripe Client schreiben und dann mehrere davon machen?
Aktuell hört er auf alle Topics (deswegen habe ich auch die 100ms gewählt) und mit dem Topic Parser separiere ich dann. Ich denke aber dass das eine eher suboptimale Lösung ist. In Summe sinds in etwa 190 Nachrichten die ich so abfrage mit den leider erwähnten Zeitversatz. Pro Minute sehe ich 1400 Nachrichten wenn ich auf "#" höre.

LG

[fudi6489]

Durch das "Bündeln" der einzelnen Nachrichten habe ich es jetzt geschafft die Gesamtanzahl der Nachrichten von 1400 auf 170 zu verringern.
Mein Subscribe Client hört auf E9 das Topic und mit JSON Extractor werte ich dann die einzelnen JSON Teile aus. So weit so gut, nur werden auf der Edomi Seite die meisten Nachrichten nicht wahrgenommen. Oftmals 2 Minuten keine Aktualisierung obwohl die Nachrichten im 10 Sekunden Takt weggeschickt und wie ich mit MQTT.fx sehen kann auch unterwegs sind.
Der Subscribe Client wurde schon von v0.6 auf v0.10 upgedatet, aber auch ohne irgendeine Verbesserung.

image.png

Nach diesem Muster werte ich aus. Den Client gibt es insgesamt 11x. Ich habe zum Test auch schon alle bis auf einen deaktiviert, aber es werden immer noch Nachrichten nicht wahrgenommen.

Wie kann das sein?
LG

[mycroft2k]

Wie sieht deine Logic Queued aus?
image.png

Weiteres Basis-Konfiguration Queue welchen wert hast du da?

image.png
und auf welcher Hardware läuft es Bare-Metal oder Virtualisiert ?

[fudi6489]

image.png

43 war jetzt das höchste was ich in rund 10min gesehen habe, springt sonst immer zwischen 0 und 10 umher.

image.png
hier deutlich niediger als bei dir, könnte mich aber nicht erinnern hier was umgestellt zu haben.
Soll ich erhöhen?


Edomi läuft auf einem Intel NUC BXNUC10I3FNHN2 i3-10110U worauf Proxmox installiert ist.

Schöne Grüße und danke für deine Hilfe

[mycroft2k]

Die Queue steht standardmäßig auf 10 – ich würde sie testweise mal auf 40 erhöhen und das Verhalten beobachten.

Hast du Edomi 2 CPU-Kerne zugewiesen?

Läuft der MQTT-Broker direkt innerhalb von edomi?

Was läuft sonst noch alles auf deinem Proxmox-Host?
Ein i3-10110U ist jetzt nicht gerade eine Rakete.

Bei mir läuft edomi auf einem ESXi-Server mit einem Intel Xeon Gold 5416S und 512 GB RAM.( Es laufen 22 Systeme )
edomi selbst hat 4 vCPUs und 4 GB RAM zugewiesen bekommen.

[fudi6489]

Ich habe jetzt auf 40 erhöht, heutige Tests lassen aber nicht darauf schließen dass sich was verbessert hat. Die Zeiten sind noch immer im selben Bereich wie vorher.

4 CPUS, und 8GB RAM

Der MQTT Broker läuft auch auf Proxmox in einem eigenen Container, und wie gesagt mit MQTT.fx sehe ich die Daten sekundengenau, bin mir also ziemlich sicher dass es an Edomi liegt.

Installiert ist noch Homeassistant, Grafana mit Influx, und wie geschrieben MQTT, außer MQTT ist aber alles deaktiviert. Es läuft noch ein automatisches Backup welches mir täglich ein Backup von Edomi auf eine NAS erstellt. Das war`s.

LG und Danke

[mycroft2k]

Der i3 ist eine Dual-Core-CPU mit Hyper-Threading. Ich würde empfehlen, testweise Hyper-Threading zu deaktivieren.
Auf meinen ESXi-Servern habe ich festgestellt, dass bei aktivem Hyper-Threading die Leistung teilweise um bis zu 25 % schlechter war.
Wie gut oder schlecht Proxmox mit Hyper-Threading umgeht, kann ich allerdings schwer beurteilen, da ich Proxmox bisher noch nicht im Einsatz hatte.

Für EDOMI würde ich daher maximal 2 vCPUs zuweisen.

Bei mir läuft der MQTT-Broker direkt im EDOMI-System. Es kann auch hilfreich sein, bei den einzelnen gesendeten Topics das 'Retain-Flag' zu aktivieren.

Ich würde empfehlen, EDOMI zunächst auf echter (Bare-Metal) Hardware zu installieren.
Wenn alles stabil läuft, kannst du dann mit Virtualisierung testen bzw. einsetzen.