openWB Forum

LutzB hat geschrieben: ↑Sa Mär 02, 2024 6:00 pm Nein, die Korrektur hat dafür gesorgt, dass der Zähler nicht auf 0kWh zurückgefallen ist. Der Peak kommt, wenn der neue Zählerstand ausgelesen werden konnte.

Ich denke, das Problem der Anwender wir mir hier ist nicht, dass in den Log-Dateinen 0 eingetragen wurde, sondern dass der Graph einen unsinnigen Peak angezeigt hat. Der ist jetzt immer noch da, wenn auch kleiner.

LutzB hat geschrieben: ↑Sa Mär 02, 2024 6:00 pm Eine irgendwie geartete Veränderung der Werte während des Ausfalls ist automatisiert nicht darstellbar.

Das ist klar.

Dafür könnten die Werte aber nachträglich korrigiert werden, wenn der Modbusfehler wieder weg ist.

Vor dem Fix war es möglich, die Differenz zum letzten Logeintrag, dessen Zählerstand >0 war, auf die Eintrage mit Zählerstand 0 aufzuteilen. Genau das machte ich mit einen eigen Script. (das jetzt nicht mehr geht, aber dass ist mein Problem...)
Wenn man dann noch auf die geloggten SoC der betroffenen Fahrzeuge schaut bekommt man das ziemlich genau nachgestellt.
Da PV-Laden bei ausgefallenem Modbus ehe nicht geht ist ein gleichmäßiges verteilen der Ladeleistung auf Log-Einträge mit Zählerstand 0 und geändertem SOC des Fahrzeugs eine sehr gute Annäherung.
Der aktuelle Fix erhöht leider den Aufwand herauszufinden, welche Einträge von dem Problem betroffen sind, erheblich.

Viel wichtiger, und ich hatte gehofft, dass der Fix das tun würde, wäre, die Ladeenergie während des Modbusfehlers dem letzten Eintrag im Ladelog zuzurechnen und - noch Wichtiger - von Hausverbrauch abzuziehen.

Ich vermute, dass Ladelog wird normalerweise beim "Laden beendet" Event gemacht. Das müsste dann eben nach einem Modbus-Fehler nachträglich gemacht werden. Ich würde das per MQTT subscription machen, die darauf lauscht, ob der Modbusfehler im Ladepunkt ausgegeben wird. Das Manipulieren des Ladelogs traue ich mir noch zu. Ich werde mein Skript anpassen und einen PR stellen.
Leider habe ich bei meinen Versuchen kein Möglichkeit gefunden, den Wert, der im Log als "counter" gespeichert wird, zu berichtigen.

LutzB hat geschrieben: ↑Sa Mär 02, 2024 6:00 pm Zielführend wäre, die Ursache der Ausfälle zu finden und zu beheben.

Durchaus.

bye
TW

Aktueller master (2024-03-01 08:58:18 +0100 [414810a6a])
Ich habe heute wieder Peaks, die auch die Tageswerte beeinflussen.
Allerdings habe ich auch einen Solaredge WR mit der bösen Firmware, die openWB ist das einzige Gerät, welches ihn abfragt.

Heut früh um 5:40 Uhr habe ich wohl etwas viel Strom verbraucht: Zugehöriges Log: Heute Abend habe ich eine Aussetzer um 19:51 Uhr und daraus folgend negativen PV-Ertrag. Im Diagramm taucht der allerdings nicht auf: Zugehöriges Log: Durch die Zählerstände tauchen bei mir die Probleme immer nur in den Tagesdiagrammen auf, die Monats- und Jahreswerte sind zum Glück OK.

Aktueller master (2024-03-01 08:58:18 +0100 [414810a6a]):
Problem mit Einschaltschwelle bei Speichervorrang.
Der Minimale Entlade-SoC ist überschritten (Steht auf 25%), die Ladung wird aber trotz ausreichend hohem Speicherladen nicht gestartet: Zugehöriges Log: Ich habe zwischendurch auch mal kurz von Zielladen auf PV-Laden umgestellt, das hat nicht geholfen.
Umstellen auf Prio Fahrzeug würde die Ladung starten, dann wieder auf Prio Speicher, damit der Speicher entladen wird, würde dann auch funktionieren.
Nur das Einschalten des Ladevorganges, wenn er noch nicht läuft klappt nicht.
Habe ich etwas falsch eingestellt? Ich meine es hat vor kurzer Zeit schonmal erwartungsgemäß funktioniert.

Ich hab' auch Peaks, werde gleich mal auf den aktuellen Master aktualisieren. Beobachtet hab' ich die Peaks bisher bei PV (Wechselrichterzähler bleiben nachts unverändert, aber der PVAll Zähler springt runter & rauf). Gestern dann erstmalig auch mit den openWB Pro Ladepunkt, auch der hatte im Tageschart einen Peak.

Ich aktualisiere und berichte ob sich das wiederholt.

Wenn ich Lutz richtig verstanden habe sieht das OWB-Team die Peaks nicht als (lösbares) Problem an.

Zumindest treten die Peaks jetzt nur noch auf, wenn es in den Zeiten mit Kommunikationsproblem auch tatsächlich Zählerstandänderungen gab. Ist ja auch was...
;o)

bye
TW

Ich hab' verstanden dass neue Peaks mit dem PR verhindert werden sollen, es aber keine rückwirkende Bereinigung der bereits gesammelten Daten gibt. Oder irre ich mich da?

Es gab bei Kommunikationsproblemen den Effekt, dass die Zählerstände auf "0" gesetzt wurden. Bei dem nächsten funktionierenden Abruf gab es dann ein Peak in der Höhe des gesamten Zählerstandes. Die "0" wird jetzt nicht mehr gesetzt, sodass es nur noch zu einem Peak in der Höhe der Differenz zum letzten Zählerstand kommen kann.

Natürlich passt in der Zeit des Ausfalls der "Hausverbrauch" nicht, da Messwerte fehlen. Das nachträglich automatisiert zu bereinigen, halte ich für nicht machbar.

Bei Thomas traten andere Peaks auf, da war die Kommunikation mit dem Zähler länger gestört, der Peak war dann nur die Differenz, die wirklich aufgetreten ist. Das kann nicht automatisiert behoben werden, so habe ich Lutz verstanden.

Die Peaks, die hier immer wieder Thema sind, treten bei kurzen Unterbrechungen auf. Wenn der Zähler nicht erreicht wird, wurde als Zählerstand 0 angenommen, ein paar Sekunden später kam dann der All-Time Zählerstand, was zu dem (falschen) Peak führte.

Dieses Problem sollte eigentlich behoben worden sein.
Ich garantiere Euch aber, dass ich in den 5 Minuten zwischen 5:35 Uhr und 5:40 Uhr nicht ~10.000kWh bezogen und ~5.000kWh eingespeist habe. Es scheint also auch mit dem aktuellen master noch Probleme zu geben, da ich zu diesem Zeitpunkt bereits auf dem aktuellen master war.

Edit: Lutz war schneller.

Dann gibt es anscheinend irgendwo noch einen anderen Bug, den wir noch nicht identifizieren konnten.

LutzB hat geschrieben: ↑So Mär 03, 2024 10:26 am Dann gibt es anscheinend irgendwo noch einen anderen Bug, den wir noch nicht identifizieren konnten.

Ich hoffe die Logfiles helfen, wenn ich mehr Infos liefern kann, einfach Bescheid geben.