openWB Forum

Vielleicht hilft euch die Info:
Ich hab ein neues RCT System und ein Kostal Piko Bestandssystem.

Hallo zusammen,
ich hatte solch ein Problem im Zusammenhang mit meinem Kostal Schwarm. Die Ursache war die Sychronität der Messwerte von den einzelnen Geräten.
Erst als ich beide WR in möglichst kurzem Abstand abgefragt hatte habe ich eine schöne gleichmäßige PV-Kurve bekommen.
Die openWB scheint das innerhalb des Kostal Moduls gut hin zu bekommen, ob das jedoch mit zwei WR über verschiedene Module passt müsste man mal analysieren.

VG
Christian

Hallo,
ich beobachte auch einen Spike / Peak im Logging jeden Tag am Morgen. Ich vermute es passiert in dem Moment, in dem der Fronius Wechsel Richter einschaltet.
Ich denke, dass es sich bei dem Wert um die Verbrauchssumme der Nacht handelt, in der der Wechselrichter "schläft" und keine Messwerte liefert

Logging: Anzeige Wechselrichter: Hat jemand einen Rat wie, man das verbessern kann?

Schürharker hat geschrieben: Fr Sep 23, 2022 11:10 am Hallo,
ich beobachte auch einen Spike / Peak im Logging jeden Tag am Morgen. Ich vermute es passiert in dem Moment, in dem der Fronius Wechsel Richter einschaltet.
Ich denke, dass es sich bei dem Wert um die Verbrauchssumme der Nacht handelt, in der der Wechselrichter "schläft" und keine Messwerte liefert

Logging:
LoggingFr.png

Anzeige Wechselrichter:
FroniusFr.png

Hat jemand einen Rat wie, man das verbessern kann?

Hallo,

welche SW version läuft bei dir?
Ist der Fronius bei dir über Nacht komplett aus oder meinst du den Zeitpunkt, wenn er mit der Erzeugung beginnt?

Der Graph wird aus den Logs unter http://<fronius-ip>/openWB/web/logging/data/daily berechnet.
Vielleicht erkennt man in den Dateien, woher der Peak kommt.

Ansonsten wäre noch die Frage, ob zur entsprechenden Zeit etwas im Debug Log steht?

VG

Hi, ich habe "das" Problem auch. Im Tageslog immer wieder Spikes und ich habe mein Problem im CSV gefunden:



Ich habe einen 600W Microwechselrichter und der liefert im Webinterface immer nur 182,4 kWh -> 182,5 kWh Sprünge, die ich per MQTT schicke und das CSV hat die Werte so und der Graph zeigt sie genau so.
Für mein Problem müsste der Graph die Zwischenwerte schätzen: +0,1kWh nach 30 Minuten? Also statistisch pro 5 Minuten +0,01666 kWh darstellen.
Nicht ganz trivial, nicht 100% korrekt, aber machbar und schöner als das aktuell.
Ob das aber mit dem Problem hier zusammenhängt und nur bei mir einfacher zu erkennen war?

Bei wir war es die Rundung auf nur 1 Nachkommastelle der Total_in und Total_out kW Werte vom EVU. Nach Änderung auf 4 Nachkommastellen sieht es nun wieder gut aus - siehe letzte Stunde. (2 Stellen hätten wahrscheinlich auch gereicht):

Schürharker hat geschrieben: Fr Sep 23, 2022 11:10 am Hallo,
ich beobachte auch einen Spike / Peak im Logging jeden Tag am Morgen. Ich vermute es passiert in dem Moment, in dem der Fronius Wechsel Richter einschaltet.
Ich denke, dass es sich bei dem Wert um die Verbrauchssumme der Nacht handelt, in der der Wechselrichter "schläft" und keine Messwerte liefert

Logging:
LoggingFr.png

Anzeige Wechselrichter:
FroniusFr.png

Hat jemand einen Rat wie, man das verbessern kann?

Hab selber Problem, seit ca 7.mai
WR ist ein fronius symo 8.2.3 mit datalogger V2
Die openWB inzwischen auf 1.9.301(macht aber keinen Unterschied..
Werde das Datensenden vom fronius auch in der Nacht aktivieren und hoffe, dass das eine Besserung bringt?.. bei mir ist der Spike täglich um ca 0600 und "dauert" 10 Minuten..
Problematisch ist in der Visualisierung die automatische Skalierung, da damit der Tageslog unlesbar wird..

mrinas hat geschrieben: Di Jun 21, 2022 9:10 am Soweit ich das sehe ist das Kern des Problems die Zählerstände. Werden hier nur die vollen kWh übermittelt kommt es an unterschiedlichen Stellen im Logging zu solchen Sprüngen. Einzige Lösung ist hier eine Übermittlung genauerer Zählerstände (oder keine Zählerstände übermitteln, wobei das ggf. aus dem jeweiligen Modul kommen müsste).
Die gute Nachricht ist das dies wirklich nur im Logging ein Thema ist, die Regelung selber nutzt die Momentanwerte.

Ich hol das Thema nochmal hoch, da ich genau dasselbe Problem habe und ich bestätigen kann, dass es genau an Zählerständen liegt, die nur mit der Auflösung von 1 kWh gesendet werden. Man hat dann z.B. beim EVU Zähler genauso viele Peaks am Tag wie man kWh bezogen hat.
Ich frage mich nur, warum openWB aus den Zählerständen die EVU Leistung berechnet, obwohl ich doch die genauen Leistungswerte sekündlich in Watt per MQTT sende. Das macht doch gar keinen Sinn. Es sollten doch die bereitgestellten Werte genutzt werden und nicht künstlich etwas berechnet werden, was schon viel genauer vorliegt. Und wenn man es schon berechnet, dann sollte doch die Leistung über den Zeitraum des letzten empfangenen Zählerstandes gleichmäßig verteilt werden. Aus meiner Sicht ist das ein Bug in den Diagrammen, oder?

Ich vermute, wenn ich die Zählerstände nicht sende, dass es dann korrekt funktioniert? Ist das richtig?

Ich frage mich nur, warum openWB aus den Zählerständen die EVU Leistung berechnet

Weil es im längeren Zeitraum betrachtet genauer ist.

Das Problem ist hier die geringe Auflösung, das ist unüblich.

Mit Software2 kannst du auch nur die Leistungswerte senden und die openWB errechnet auf Basis dessen einen Zählerstand.

Sw1.9 wird nicht mehr weiterentwickelt.

openWB hat geschrieben: Di Feb 10, 2026 6:41 am

Ich frage mich nur, warum openWB aus den Zählerständen die EVU Leistung berechnet

Weil es im längeren Zeitraum betrachtet genauer ist.

Das Problem ist hier die geringe Auflösung, das ist unüblich.

Mit Software2 kannst du auch nur die Leistungswerte senden und die openWB errechnet auf Basis dessen einen Zählerstand.

Okay, verstehe. Ich bin auf SW2 und ich sende Leistungswerte 3x pro Sekunde. Das wäre sicher genauer als die aktuelle Berechnung von openWB.
Habe mir jetzt in Nodered eine Function geschrieben, die meine aktuellen Leistungswerte über die Zeit integriert und somit den Zählerstand dann auf hunderstel Wh an openWB sendet. Damit sind die Peaks dann hoffentlich weg.
Ich würde halt in openWB gerne die richtigen Zählerwerte meines Zählers sehen und keinen neuen Zähler der bei 0 startet, denn openWB verkauft den Wert ja als EVU Zählerstand.
Falls das jemanden interessiert, kann ich den NodeRed Function Code gerne hier zur Verfügung stellen.

Ganze Wh sind mehr als ausreichend.

Bei Deiner Berechnung wirst Du dann aber auch über lange Zeit eine Differenz zwischen dem berechneten und realen EVU-Zählerstand feststellen. Das liegt in der Natur der Dinge, wenn man tausende von kleinen Differenzen summiert. Aus diesem Grund verwendet openWB die realen Zählerstände, wenn sie denn übergeben werden. Dann laufen die nicht auseinander.