Mqtt problem mit neuer firmware weil unoetig viele daten

Other languages Deutschsprachiger Bereich
1

hallo,
heute habe ich mich einmal auf die suche nach der ursache gemacht, warum mein system die anzeige zu langsam aktualisiert.

da ich die daten vom mqtt-server abrufe und in eine datenbank uebertrage, musste das problem ja irgendwo auf diesem weg zu finden sein und dort habe ich es auch gefunden:
der mqtt-server schickt mir ca. alle 30 sekunden einmal die komplette history der solarcharger. das sind ca. 4000 zeilen obwohl sich diese daten nicht geaendert haben und die meisten davon sich auch nur einmal am tag aendern.

die alte firmware wiederholt zwar auch daten ca. alle 30 sekunden, aber nicht die history der solarcharger! kann man das irgendwo abstellen oder muss ich versuchen, wieder eine aeltere firmware zu installieren, wo keine mehr als backup vorhanden ist?

also man kann es mit dem aktualisierungsintervall der daten auch uebertreiben!

wenn man das nicht abstellen kann, muss ich mir einen anderen weg einfallen lassen, um dieses problem zu loesen. obwohl ich mein programm schon abgeaendert habe, dass es diese datenmenge problemlos verarbeiten sollte, kommt es trotzdem noch zu verzoegerungen und ich weiss nicht warum!

manche neue futures machen aber auch wirklich nur aerger!

tschuess

2

Nein, der mqtt-Broker “schickt” keine Daten…er gibt dem Client die Daten, die dieser subscribed.
Wenn Du alsp den kompletten Baum “bestellst” bekommst Du ihn auch.
Auch die 30sec sind keine Einstellung des mqtt-broker…ich habe hier topics, zB vom grid-meter, die alle 100ms ein update bekommen (publish vom GX modbus interface des grid-meter auf den broker/dbus)…wenn ich das topics dauerhaft subscribe, bekomme ich auch die updates in diesem intervall/dieser granularität.

Frag einfach nur einmal am Tag dieses relevante Topic ab…oder andersherum, höre auf einfach immer alle Topics zu subscriben, sondern subscribe spezifische Topics, dann wann/in der Frequenz die Du brauchst.

3

hallo,
ich subscribe nur ein einziges mal alle topics und das hat bisher auch immer prima funktioniert.

aber mit einem der letzen firmware-updates gab es eine aenderung, durch die der mqtt-server mir regelmaessig, eben ca. alle 30 sekunden, alle topics erneut schickt, obwohl sich die meisten davon nicht veraendert haben. das entspricht nicht der spezifikation fuer den abruf von mqtt-daten.

da bekommt man beim anfordern einmal alle und dann nur noch die geaenderten daten, also die daten, die erneut geschrieben wurden, egal ob sie sich geaendert haben oder nicht. massgebend fuer den erneuten versand ist die tatsache, dass sie neu geschrieben wurden.

bei werten, die nur maximal einmal am tag oder nie geaendert werden, macht es absolut keinen sinn, die alle 30 sekunden zu wiederholen.

das sind bei meinem ersten cerbo ca. 4800 topics, bei den anderen teilweise mehr, meistens aber weniger. damit muss mein system dann in maximal 1s bestimmt mindestens 15000 topics verarbeiten und das schafft es definitiv nicht. selbst wenn mein programm das koennte, die datenbank koennte unmoeglich ca. 30000 sql-abfragen in einer sekunde verarbeiten.

ich habe es jetzt geschafft, unnoetige daten schon beim abruf auszufiltern, so dass das system nur noch 6s haengen bleibt und nicht mehr 25s!

ich werde morgen wohl einmal pruefen muessen, was ich sonst noch weglassen kann und die filterliste dann entsprechend erweitern. heute habe ich dazu keine lust mehr.

tschuess

4

…das war meine Vermutung, ja.

seit der Umstellung auf flash-mq, das ist aber schon länger her, gibt es das retain flag für topics nicht mehr. Das hat aber nicht notwendigerweise etwas mit dem Poblem u tun, was Du schilderst.

das gilt nur dann, wenn der client sich nicht ständig mit neuer ID neu verbindet.
Schliesst Du die Verbindung zum Broker wieder, nachdem Du einmal das/alle Topics abgeholt hast und baust Du danach die Verbindung mit anderer Client-ID wieder auf?
Dann hat der Broker keine Wahl und muss Dir alles nochmal senden, da er nicht erkennt, dass Deinem client diese Daten schonmal ĂĽbermittelt wurden.

Behälst Du alleerdings die Verbindung bei bzw. nutzt eine eindeutige, stabile client-id, dann sollte das nicht passieren, es sei denn auf der “anderen Seite” hat ein Prozess im GX das Topic neu ge-published - egal ob ssich die Daten im Topic geändert haben oder nicht - und auch dann muss der Broker das topic neu an den client übermitteln.
Dann würde ich hier im Forum einen Bug aufmachen…das Problem ist aber eben vermutlich nicht auf Seiten des Brokers, sonders beim Prozess, der das topic erneut, unnötig, zum Broker publiziert.

5

es könnte auch mit dem senden des keep-alive zusammenhängen das du vermutlich alle 30 sekunden sendest. dort gibt es eine option suppress-republish die ein senden aller nicht geänderten daten verhindert.

6

hallo,
die verbindung wird nur dann neu aufgebaut, wenn sie aus irgendeinem grund beendet wurde. ansonsten bleibt sie ueber wochen und monate aktiv und auch die client-id aendert sich nicht!

tschuess

7

hallo,
was den zugriff fuer den keep-alive angeht, der leider immer noch noetig ist, weil der keep-alive ping des clients nicht ausreicht, so findet der zwar alle 30s statt, aber eine aenderung auf 5s hatte hier auch keine auswirkung. ich bekam weiterhin alle topics alle 30s erneut uebertragen.

es gibt zwar die option, dass gespeicherte nachrichten nicht gesendet werden sollen, aber das funktioniert auch nicht. die einzige gespeicherte nachricht ist naemlich die serien-nr.

aktuell bleibt mir nur die moeglichkeit, den filter zu benutzen, mit dem ich verhindern kann, dass alle topics ausgegeben werden. nur wird die liste immer laenger.

ich werde auch versuchen, die datenbankzugriffe zu reduzieren, so dass ich mehr nachrichten verarbeiten kann. obwohl es sich um eine memory-tabelle handelt, schafft die datenbank eben keine 5000 sql-abfragen pro sekunde und gx. es sind ja schliesslich auch 5 gx-devices, die abgefragt werden.

tschuess

8

…dann ist es evtl. wirklich ein Bug, aber auf Seiten des Prozesses, der die Daten ständig (neu, mit unverändertem Inhalt) publiziert.
Weisst Du welcher Prozess diese Daten publiziert? Dann kann man da ein Ticket bei victron hier im Forum aufmachen…

9

hallo,
ich vermute, dass es der mqtt-server selbst ist, denn die komplette historie der mppts wird sonst nirgends gespeichert. sie muesste hoechstens vom vedirekt-programm erneut abgerufen werden.

allerdings sind, soweit ich das bisher feststellen konnte, alle daten betroffen, die der mqtt-server vorhaellt. wie z.B. die seriennummern aller geraete.

es ist ja ok, dass man beim verbindungsaufbau einmalig alle daten bekommt, aber doch nicht alle 30s. bei dem getesteten cerbo kamen auf diesem weg, ca. 4000 datensaetze zwischen den beiden zum test ausgewaehlten topics an.
selbst der mqtt-explorer unter windows bleibt zu dem zeitpunkt fuer 5-10s haengen.

es duerfte auch absolut unmoeglich sein, dass so viele daten in so kurzer zeit an den mqtt-server geschickt werden. beim abruf sieht das anders aus, da muss ja nicht erst der alte datensatz gesucht und ueberschrieben werden! es wird einfach nur die ganze liste vom mqtt-server gesendet werden und das geht sehr schnell.

ich glaube auch nicht, dass es einen client gibt, der in der lage ist, diese datenmenge so schnell zu verarbeiten, wie er sie bekommt!

und ein selectiver abruf der daten, die man braucht, ist leider auch keine option, da muesste ich wohl ueber 500 topics einzeln abonieren. da ist der filter im mosquitto client wesentlich einfacher zu nutzen.

und de datenbank brauche ich fuer die steuerung und auswertung, weil es viel zu aufwendig ist, sich die daten einzeln und aktuell vom mqtt-server zu holen. fuer die daten, die ich mit einer einzigen datenbankabfrage bekomme, muesste ich in node red wohl ueber 50 nodes benutzen und die daten muessen dann auch noch verknuepft werden!

und dann kommt noch hinzu, wenn ein weiteres geraet ueber usb angeschlossen wird, koennen sich im unguenstigsten fall, beim naechsten neustart mehr als 10 ids aendern und die nodes vieleicht nicht mehr funktionieren.

ich koennte natuerlich die ganzen mppts, zumindest die mit vedirect, an einen pi haengen, anstatt an einen cerbo.

tschuess

10

Ich habe ein kleines Framework fĂĽr ESS-Systeme, und ein service davon ist der Mqtt-Exporter.

Statt mit Keep-Alive permanent ALLE Daten zu aktualisieren und einen client auf dem cerbo-mqtt zu haben, kannst du hier einen externen Mqtt Server festlegen - und nur die 10,15 Werte “exportieren”, die dich auch interessieren.

Das spart es komplett den lokalen Mqtt per keep-alive zu fĂĽllen und bringt die notwendigen Daten direkt in den eigenen Mqtt.

https://github.com/realdognose/es-ESS/blob/main/README.md#mqttexporter

(Enthält ein paar Services, sind aber alle selektiv aktivierbar - oder nicht)

1 Like
11

hallo,
das problem ist, dass ich von den ueber 4000 werten mindestens 50-100 werte speichere und einige mehr fuer die steuerung auswerte.

und eines der hauptprobleme besteht ja auch darin, dass ich auch die historie der mppts speichere oder wenigstens geplant hatte, die zu speichern und alleine diese datensaetze, sind 473 topics pro laderegler, der mit vedirect verbunden ist.

dazu kommt, dass vorher beim verbinden, zuerst einmal alle topics geschickt wurden. das ist jetzt auch nicht mehr der fall. geaenderte topics bekommt man sofort, alle anderen nur im 30s zyklus!

wenn victron wenigstens den versand der zyklisch verschickten daten auf 60s verteilt haette, waere das auch kein problem. aber ueber 4000 datensaetze in weniger als 1s ist eben fuer jede software ein problem!

und wenn ich jeden einzelnen wert, den ich haben moechte, erst einmal abonieren muesste, waere die liste noch laenger, als die filterliste fuer den mqtt-client mit den daten, die ich nicht haben will!

dast ist mein aktueller aufruf fuer den client:
mosquitto_sub -k 30 -v -I myclient_ -t “#” -h $IP -T “N/+/solarcharger/+/History/#”
-T “N/+/platform/#”
-T “N/+/settings/#” -T “N/+/vebus/+/AcSensor/#” -T “N/+/vebus/+/Devices/#”
-T “N/+/system/0/Ac/Genset/#” -T “N/+/system/0/Ac/PvOnGenset/#”
-T “N/+/system/0/Ac/PvOnGrid/#”
-T “N/+/system/0/Ac/PvOnOutput/#” -T “N/+/system/0/Timers/#”
-T “N/+/system/0/Control/#”
-T “N/+/system/0/SystemState/#” -T “N/+/vebus/+/Interfaces/#”
-T “N/+/vebus/+/FirmwareFeatures/#”
-T “N/+/inverter/+/Alarms/#” -T “N/+/inverter/+/Devices/#” -T “N/+/+/+/Diagnostics/#”
-T “N/+/+/+/VEDirect/#” -T “N/+/vecan/#” -T “N/+/adc/#” -T “N/+/+/+/Alarms/#”
-T “N/+/+/+/Info/#” -T “N/+/digitalinputs/#” -T “N/+/logger/#”
-T “N/+/system/0/LoadShedding/#” -T “N/+/vebus/+/Settings/#” -T “R/#”
-T “N/+/+/+/Mgmt/#” -T “N/+/fronius/#” -T “N/+/modbusclient/#”
-T “N/+/system/0/DynamicEss/#”

und da der client lediglich daten entfernen und nicht sortieren muss, geht das auch sehr schnell. im gegensatz zu jedem anderen programm, das die daten irgendwo speichern muss und sie dafuer natuerlich auch zwingend sortieren muss oder jedesmal alle datensaetze durchsuchen muss, ob ein datensatz bereits vorhanden ist!

ich bin jedenfalls der meinung, dass es eine sehr schlechte idee war, den versand der mqtt-daten auf diese weise zu erledigen. dafuer gibt es extra ein flag, mit dem man dem client mitteilen kann, dass es sich nicht um eine aktuelle sondern um eine gespeicherte nachricht handelt. es waere also kein problem, beim verbinden alle datensatze ohne dieses flag zu senden und alle wiederholungen mit dem flag. aber der einzige datensatz, bei dem das flag gesetzt ist, ist die seriennummer!

dazu kommt noch, dass ich die daten von 4 cerbos und einem venus-gx verarbeiten muss!

tschuess

12

Es handelt sich immer um ungespeicherte Nachrichten, die den Ist-Zustand abbilden. Retain wäre absolut nicht zielführend, würde nur zu alten Daten führen, die bei einem client-reconnect erneut versendet werden.

Mqtt funktioniert anders herum. Beim Verbinden wĂĽrden die Nachrichten MIT flag versendet werden, sofern sie eben als retain markiert werden, bei jeder weiteren Ăśbertragung dann ohne.

13

hallo,
ich glaube, du stehst immer noch auf der leitung:
mein venus-gx, mit einer aelteren firmware, schickt mir beim verbinden sofort alle datensaetze und dann nur noch die aenderungen.
meine cerbos mit der aktuellen firmware schicken mir nur die aenderungen und alle 30s alle datensaetze!

was ist deiner meinung nach besser? zuerst alle datensaetze und dann nur noch die geaenderten/neu geschriebenen oder nur die aenderungen und alle 30s alle, was bedeutet, dass du auf werte, die nicht neu geschrieben werden bis zu 30s warten musst, bevor sie zur verfuegung stehen! ob das auch gilt, wenn ich nur einen werte aboniere oder nur wenn ich alle aboniere, habe ich jetzt nicht getestet. aber ich finde das definitiv katastrophal!

gluecklicherweise ist es zwar so, dass sich die messwerte staendig aendern, man also normalerweise nie 30s auf einen messwert warten muss, aber trotzdem, so sollte es nicht sein!

ich habe es gerade einmal bei einem can-bus mppt getestet, an dem noch keine pv haengt. der wert kommt, auch bei einzel-abo, nicht sofort, sondern mit mehreren sekunden verzoegerung! bei meinem test 2-22 s verzoegerung!

tschuess

14

Für mich klingt die Beschreibung eher nach einem Fehler in deinem Script, der wie folgt aussehen könnte:

  • Du veröffentlichst die erste KeepAliveMessage
  • Erst dann subscribst du, hast den ersten “Full Publish” aller Werte also verpasst.
  • Dein Script ist - wie du es schreibst - Laufzeittechnisch mit der Datenmenge und/oder externen EinflĂĽssen ĂĽberfordert und kann die darauf folgenden KeepAlive-Messages nicht innerhalb des timeouts (glaub 30s) an den Broker senden.
  • Der Broker geht in SleepModus.
  • Jede KeepAlive Message weckt also den Broker wieder aus dem Sleep, woraufhin er einen erneuten Full Publish durchfĂĽhrt, der dein Script wieder ins Laufzeitproblem drĂĽckt.

Mach mal nebenher das VRM Portal am PC auf, das Dashboard schickt regelmäßige Keep Alives an den Broker, sofern die RealTime Verbindung aktiv ist - dann wirst du bestimmt plötzlich nur noch inkrementele Daten mit deinem Script bekommen.

15

hallo,
ich habe es mit verschiedenen clients probiert, einmal mosquitto unter linux und einmal mit dem mqtt-eplorer unter windows und das verhalten ist absolut immer das gleiche:
zuerst kommt immer die seriennummer, dann die geaenderten daten und dann zyklisch einmal aller daten alle 30s! es spielt auch keine rolle, von welchem system aus ich die daten abrufe und welche client-id ich benutze!

auch der mqtt-explorer bekommt zuerst nur geaenderte daten und dann, wenn der naechste zyklus an der reihe ist, alle daten.

ausser ich rufe daten von meinem venus-gx ab, auf dem noch eine alte firmware ist, dann sieht das so aus:
zuerst bekomme ich alle daten und danach nur noch geaenderte daten und damit hat mein system keine probleme.

selbst der mqtt-explorer bleibt kurz haengen, wenn er auf einen schlag ueber 4000 datensaetze bekommt. um sowas in der zeit, in der die daten ankommen, verarbeiten zu koennen, muesste die anwendung schon parallel auf mindestens 8 kernen laufen und du solltest wissen, dass es immer probleme gibt, wenn mehrere processe gleichzeitig den gleichen speicherbereich nutzen, um dort daten abzulegen.

und da ich eine mariadb-datenbank mit einer memory-tabelle benutze, also das schnellste speichermedium, das moeglich ist, habe ich keine moeglichkeit, das ganze zu beschleunigen. selbst wenn ich anstatt einem process, 5 starte, gibt es das gleiche problem, weil die datenbank die anzahl der datensaetze, die ich pro sekunden aktualisieren/einfuegen kann, begrenzt!

aber ich kann ja mal den datenverkehr zum vrm protokollieren, bzw. die datenrate messen.

ob das vrm die daten vom mqtt-broker oder von einem anderen process bekommt, weiss ich allerdings nicht.

tschuess

16

hallo,
ich habe einmal den netzwerkverkehr protokolliert und das ist das ergebnis:
vrm portal spitze 441049 B/s
local spitze 434958 B/s
und das alles alle 30s!

normal waeren auf jeden fall weniger als 5 kB/s oder weniger!

da das vrm in der amazon-cloud laeuft und jetzt ja auch deutlich mehr daten verarbeiten muss, als vorher, duerfte sich das sehr schnell auf der rechnung wiederspiegeln, sobald alle die neueste firmware installiert haben! vom erhoehen leistungsbedarf, damit alles weiterhin schoen rund laeuft, mal abgesehen!

mit manchen aenderungen an der firmware schiesst man sich eben selbst ins bein!

tschuess

17

Kannst du mal die Venus-Version sagen, seit der du das bemerkst?

18

hallo,
ich schaetze mal, dass dieses problem seit version 3.5x auftritt. aktuell habe ich die 3.54 installiert. ob es erst mit dieser version auftritt oder bereits mit einer anderen 3.5x kann ich nicht sagen. ich hatte vor nur bis maximal 3.3x installiert oder aelter.

tschuess

19

Also ich habe aktuell auch die 3.54 und kann das von dir beschriebene Verhalten nicht feststellen.

Was schickst du denn an das Seriennummern-Topic um den Mqtt am Leben zu erhalten? Bestimmt noch “old-fashioned” eine leere Nachricht?

ändere das doch mal wie folgt:

  • Erste Message nach Verbindung: leerer Payload. (dann bekommst du alle Werte)
  • Jede weitere Message dann: { "keepalive-options" : ["suppress-republish"] }

Also dass es dann so aussieht:

image
image815Ă—205 3.12 KB

Seit “wann” das geht kann ich dir nicht sagen, aber schon ziemlich lange - VRM selbst nutzt das (lt. changelogs) seit 2023-12-18 VRM Portal Changelog [Victron Energy]

1 Like
20

hallo,
ob das funktioniert, kann ich erst heute abend pruefen. aber was das vrm angeht, kann ich dir garantieren, dass das auch alle 30s alle datensaetze bekommt. das sind von einem meiner cerbos ca. 4,5 MB an daten. bei den anderen wohl weniger, da dort nicht so viele mppts angeschlossen sind.

ich habe extra die packete, die ueber 120s an das vrm geschickt worden sind, protokolliert und dann die laenge fuer 1s zusammengezaehlt. das ist zwar prutto, also mit den steuerdaten fuer das netzwerk und nicht nur die nutzdaten, aber auch die muessen ja uebertragen und verarbeitet werden.

und es sieht auch nicht so aus, als wuerde hier ein republish der daten erfolgen, es erfolgt lediglich ein erneuter versand durch den mqtt-server. denn bei einem republish durch das programm, das die daten an den mqtt-server sendet, wuerde auch der cerbo ins stolpern kommen und waere mindestens fuer 5-15s nur mit dem mqtt-server beschaeftigt!

und mit der firmware, die aelter ist, gibt es ja auch keine probleme, da bekommt man zuerst alles und dann nur noch aenderungen. die umstellung ist auf jeden fall nach version 3.29 (oder auch 3.3x) erfolgt. dann das duerfte die neueste version gewesen sein, bevor ich auf die aktuelle aktualisiert haben.

auf jeden fall wird bei victron die monatliche rechnung fuer das vrm steigen, je mehr user die neue firmware installieren, auch abhaegig davon, wieviele mppts ueber vedirect angeschlossen sind. bei einem anschluss ueber den can-bus fallen naemlich nicht so viele daten an!
der dicke brocken sind naemlich die daten der history und das sind 30 oder 31 tage, beim can-bus aber nur 2!

tschuess