Hi, ich habe in letzter Zeit immer wieder sehr hohe unrealistische peaks beim Verbrauch (ca.2500kWh) für sehr kurze Zeit.
Hat einer eine Idee, woher das kommen könnte?
Setting: 3x MP2 5000/70, 2x MPPT 450/200, Cerbo, EM 24 Netz, EM 540 für PV mit 2x Hoymiles HMS1600W am am MP Out 1
Liebe Grüße Matthias
schau mal die neuen beta-Versionen an - genau das soll wohl in Zukunft unterbunden werden
Stand nicht sogar irgendwo was die letzten Tage das es in der neuesten VRM-Version bereits unterbunden wird?
Hm, der letzte Peak war am 25.05.2026. Ja, schaue ich mir mal an. Ich hatte vor zwei Wochen einen Screenshot über Beta Feedback abgeschickt. Gibt es dazu Rückmeldungen? Ich glaube wohl nicht.
Danke.
Aber um dem ganzen mal auf den Grund zu gehen… Das kommt ja öfters vor, ist es so dass die Verbrauchsdaten die aus irgendwelchen Gründen nicht Zeitgemäß übertragen wurden dann einfach „nachgeholt" werden? Also, der Verbrauch hat so stattgefunden, nur eben verteilt und früher was aber nicht so übertragen wurde. Um wieder auf Stand zu kommen gibt es dieses „Offset". Ich hoffe das ist verständlich. Ist das so?
Zumindest scheinen die Summen zu passen. Irgendwie lese ich hier öfters davon, aber warum das so zustande kommt ist mir nie klar geworden auch nicht ob das in Summe dann passt. Ich denke hier werden Werte nachgeholt.
Ich habe das bisher nur in Verbindung mit Zählern von Shelly oder anderen, nicht offiziell unterstützen, Zählern gelesen.
Da wird wohl irgendwie durch einen Reset o.ä. der Zähler neu eingelesen und dabei der, in dessen Speicher vorhandene, Gesamtverbrauch übermittelt.
Andersherum wäre besser.
Also den neuen schnelleren EM540 als Netzsensor und den EM24 für PV.
Ich dächte auch da etwas gelesen zu haben, das das auf VRM Ebene behoben wurde, kann es aber gerade nicht finden.
Ja stimmt, das macht kein Sinn. Aber die Auswertung Allgemein scheint ja zu passen… Immerhin, das wäre sonst Sau ärgerlich.
Solche Spikes treten auf, wenn der Energie-Zähler, der normal für-immer-inkrementel ist kurz eine “0” liefert: 5001, 5002, 0, 5002 → Zack, 5002 kWh in einer Stunde.
(Natürlich passiert das auch bei jedem anderen Wert, der aus der Reihe tanzt - die 0 ist aber 99% Fall hierfür 
)
Wie hast du das EM angebunden? Falls via nodered, darfst du das notered meter NICHT mit defaults initialisieren, sonst gibt es bei jedem Neustart von Nodered “eine 0” im System.
Sinnvoll ist auch ein Filter zu verwenden, der eine 0 die vom shelly oder mqtt kommt nicht durchlässt.
Danke, das erklärt einiges. Ein Zählerwechsel würde demnach bedeuten dass es zwar einen Spike gibt, die VRM Daten aber korrekt weiterlaufen. Ich habe mich schon immer gefragt was passiert wenn man den Zähler tauscht. Danke nochmals.
Wobei meine Erklärung nicht ganz hinhaut, der Spike bleibt aus da der neue ja bei 1 weitermacht.
ja, korrekt, aber so was sollte serverseiitig abgefangen werden
Die Frage ist auch - warum liefert er eine Null? weil die Übertragung keine Prüfsumme hat?
Genau. Ein niedrigerer Zähler ist stets ohne Auswirkung - es gibt Geräte, die starten beim “Booten” bei 0, für die ist das dann nötig.
Nur nach einer 0 wieder auf einen vorherigen Wert springen ergibt dann ein “false-positive-spike”.
eben nicht, s.o. - Gibt Geräte da ist es wichtig das Delta-Tracking herunterzusetzen, wenn ein kleinerer Wert ankommt. Es gibt sogar noch Zähler, die haben nur ein Zählwerk und gehen “rauf und runter” je nachdem ob Einspeisung oder Bezug statt fand - da muss man das dann in beide richtungen praktizieren, wenn man die Werte getrennt haben will.
Das deckt die Auswertung alles ab - dass ein forever-forward-incremental Zähler keinen falschen Wert einbringt, ist Aufgabe des Zählers, nicht des Lesers.
Übertragungsfehler sind via TCP eigentlich ausgeschlossen. Entweder ein Bug im Sender, oder im empfangenden Skript. Bei Mqtt-Übertragung können auch retained values lange für graue Haare sorgen, denn die können immer mal wieder bei einem reconnect des Empfängers einstreuen, auch wenn der Sender schon lange nicht mehr retained published aber der broker 3 Monate alte retained values für ein topic vorhält.
Ja, das ist richtig. Wenn mal alles läuft, wird getauscht.
Die Victron EM sind jeweils mit USB angeschlossen. Sonst gibt es keine weiteren Sachen wie Nodered o. ä.
Hast du ein raspberry als GX, oder ein Victron-GX?
Oh, und welche venus version? (Nicht, dass das eine known Issue genau deiner Version ist)
Cerbo GXC00A HQ2215ZJYVG v3.73v3.73 Auf dem neusten Stand
SmartSolar MPPT RS 450/200A111 0252868 HQ2222G3QU2 v1.29v1.29 Auf dem neusten Stand
SmartSolar MPPT RS 450/200A111 0261060 HQ222644WEP v1.29v1.29 Auf dem neusten Stand
EVCS-Wellnes Oase EV Charging Station 32AC025 HQ2231VQXFW v2.07v2.07 Auf dem neusten Stand
MultiPlus-II 48/5000/70-502623 HQ2219T7HKT v505v560 Gerät aktualisieren -mache ich im Winter-
aus Interesse - benutze VRM wenig, logge selber - was wird da überhaupt übertragen?
Zählerstände oder Leistungswerte?
Ich habe viel Erfahrung mit Volkszähler - da passieren solche Dinge nicht
Beachtet vielleicht auch diesen Thread hier, wo ich mein Problem damit gepostet habe.
Hier geht es allerdings nur um Virtual-Devices (AC-Load) in NodeRed.
https://community.victronenergy.com/t/ac-load-spikes-in-vrm/58738/6
Sowohl Links mit Infos drin, als auch Erklärungen/Lösungen.
Sollte man jedenfalls beachten, auch wenn in der letzten Beta ~27 jetzt zum 2. Mal OS-seitig ein “Filtern” für diese Events nachgerüstet wurde.
Für die Nicht-NodeRed Sachen hoffe ich für euch dass die Änderungen in ~21 und ~27 für euch ausreichen, denn da habt ihr ja selber leider gar keinen Einfluss.
Ich habe einen Modus Zähler und einen Smartmeter mit Lesekopf die gerne mal Fantasiewerte melden.
Inzwischen Filter ich die aus. Aber wenn irgendwo Zählerwerte gespeichert werden und die dann nicht taggleich zurückgesetzt/verworfen werden kann ich mir vorstellen, dass die zu solchen Peaks führen.
