Die modulare Wallbox
https://forum.openwb.de/
Na das ist ja ein Ding. Das... ähm... macht mich ganz schön ratlos o_O.
Nein, habe keinen SSH Zugang (und habe es ehrlich gesagt auch nicht vor).
Dafür hat uwec noch eine separaten Thread: viewtopic.php?f=9&t=4493
Du hast es gefunden! Du bist ein Held!okaegi hat geschrieben: ↑Di Dez 21, 2021 12:01 am Die Pv Zähler! Speicher Import / Export werden unter umständen von OpenWb gerechnet.
Für pv Solaredge (position 4 im Excel , in loadvars.sh circa Zeile 1075)
if [[ $speichermodul == "speicher_solaredge" ]] && [[ $pvwattmodul == "wr_solaredge" ]]; then
usesimpv=1
fi
Bitte nicht. Das ist ungenau und Fehler können sich akkumulieren. Schon wenn alles stabil läuft ist Simcount nur eine Annäherung. Die Annäherung ist umso besser je kleiner die Abtastrate ist. Aktuell ist die Abtastrate meistens bei 10 Sekunden, dass dürfte in den meisten Fällen schon eine sehr gute Annäherung sein, aber trotzdem bleibt es eine Annäherung. Ganz daneben liegt es wenn die Abtastrate runter geht. Zum Beispiel weil ein Netzwerkfehler vorliegt und der Zähler über einen gewissen Zeitraum nicht ausgelesen werden kann. Dann ist alles daneben.okaegi hat geschrieben: ↑Di Dez 21, 2021 8:40 am Ich würde folgendes mal anregen (radikaler Vorschlag):
Warum fahren wir nicht für alle Speicher, Bezugszähler und Wr grundsätzlich mit Simcount für alle Grafiken und csv logs und lesen eventuell vorhanden
Zähler separat aus für den Status und speichern diese als seperate Spalten in csv ohne mit ihnen zu rechnen ?
Das ist bei der Leistung genau so und das Problem geht damit nicht weg. Schlimmer noch: Wenn jemand bei der Leistung was falsch macht, dann akkumuliert sich ein großer Fehler wenn die Energie auf der Basis mit simcount gerechnet wird.
Ja, in dem Fall bleibt einem nichts anderes übrig. Allerdings... Welcher Zähler hat denn heutzutage keinen Ertragszähler? Bei älteren WR mag das ja sein, aber das ist dann ein aussterbendes Phänomen? Der Fronius Gen24 soll wohl erst mit Firmware 1.13.13-1 seinen Zähler in die API bekommen haben. Schon was dämlich von Fronius, fein, aber doch hoffentlich eine seltene Ausnahme?
Wann sowas erhalten bleiben soll, dann braucht es eben ein "offset", in dem der Startwert vom Zähler festgehalten wird. Dann kann man stets den offset Wert auf den neuen Wert dazu addieren. Der offset würde dann nur einmalig gesetzt werden beim Zählertausch und würde dann immer so bleiben.
Das ist ein großer Unterschied ob der Tagesertrag auf Basis von gelesener Energiezähler oder auf Basis mathematisch integrierter Leistung gerechnet wird. Also Tagesertrag aus der Differenz zwischen zwei Zählerständen zu rechnen ist ein nahezu idiotensicheres Verfahren (ich weiß: Der größte Fehler von Leute die versuchen etwas absolut idiotensicheres zu designen ist es den Einfallsreichtum von absoluten Idioten zu unterschätzen
). Ein Integral basierend auf einer Abtastung ist nur eine Annäherung.
Unter der Vorraussetzung, dass die Leistung korrekt implementiert ist. Wenn man das mit der Leistung geschafft hat ist das mit der Energie auch nurnoch ein kleiner Schritt.
Die kann man sich auch so da sparen. Was machen diese Abfragen da?! Wenn man meint man braucht das kann man das doch im Modul selbst aufrufen.
Wo ist der Vorteil davon "dass man es sich sparen kann die HW-Zähler auszulesen", wenn man die HW-Zähler doch ausliest und speichert? Dann hast du nicht anderes gewonnen als einen weiteren Datensatz, der falsch sein kann und über den man sich wundert.
Gerade bei Hybrid Systemen ist das eher die Regel als die Ausnahme.Ja, in dem Fall bleibt einem nichts anderes übrig. Allerdings... Welcher Zähler hat denn heutzutage keinen Ertragszähler? Bei älteren WR mag das ja sein, aber das ist dann ein aussterbendes Phänomen? Der Fronius Gen24 soll wohl erst mit Firmware 1.13.13-1 seinen Zähler in die API bekommen haben. Schon was dämlich von Fronius, fein, aber doch hoffentlich eine seltene Ausnahme?
Die eigene Berechnung erzeugt den Zählerstand. Tagesertrag / Graphen basierend dann auf Deltas davon.Das ist ein großer Unterschied ob der Tagesertrag auf Basis von gelesener Energiezähler oder auf Basis mathematisch integrierter Leistung gerechnet wird. Also Tagesertrag aus der Differenz zwischen zwei Zählerständen zu rechnen ist ein nahezu idiotensicheres Verfahren (ich weiß: Der größte Fehler von Leute die versuchen etwas absolut idiotensicheres zu designen ist es den Einfallsreichtum von absoluten Idioten zu unterschätzen
Sollte man meinen, ist aber oft nicht der Fall.Unter der Vorraussetzung, dass die Leistung korrekt implementiert ist. Wenn man das mit der Leistung geschafft hat ist das mit der Energie auch nurnoch ein kleiner Schritt.
Da bin ich bei dir. Entweder die aaslesbaren Zählerstände sind plausibel und nutzbar oder man kann sie gleich vergessen.Wo ist der Vorteil davon "dass man es sich sparen kann die HW-Zähler auszulesen", wenn man die HW-Zähler doch ausliest und speichert? Dann hast du nicht anderes gewonnen als einen weiteren Datensatz, der falsch sein kann und über den man sich wundert.
In der SolarEdge-Doku steht zumindest ein Register mit dem sich die Zähler seperat auslesen lassen. Noch haben wir es zwar nicht getestet aber aktuell steht zumindest im Raum, dass es den Zähler gibt. Powerwall habe ich vor kurzem überarbeitet weil es kaputt war. Die Auszüge aus der API die mir ein Nutzer geschickt hat zeigen separate Werte für Batteriezähler. Wird halt von der oWB nicht ausgelesen.
Klar, das muss man bei Hybridsystemen auch noch bedenken. Muss man bei der Leistung allerdings auch...
Richtig. Deltas zu nehmen vom Zählerstand finde ich sinnvoll. Das ist einfach, nachvollziehbar und robust. Den Zählerstand durch Berechnung zu erzeugen finde ich nicht sinnvoll, wenn ein "richtiger" Zählerstand zur Verfügung steht.
Wie hast du das festgestellt? Da die Berechnung auf der Leistung basiert die von dem selben Zähler kommt, kann der errechnete Zähler eigentlich nicht besser sein, als der abgerufene.
Im Vergleich bei Anlagen die einen WR haben und zusätzlich einen MID geeichten Zähler vor dem WR und zusätzlich Simcount.Wie hast du das festgestellt? Da die Berechnung auf der Leistung basiert die von dem selben Zähler kommt, kann der errechnete Zähler eigentlich nicht besser sein, als der abgerufene.
Eine openWB ohne Netzwerk ist mit das einzig unschöne, das stimmt.Wie schon erwähnt: Solange die Abtastrate hoch genug ist, wird es in normalen Haushalten mit der Genauigkeit von Simcount gut hinkommen. Es sei denn es kommt was dazwischen. Der erwähnte Ausfall des Netzwerks zum Beispiel. Dann ist alles hinüber. Mit Glück passiert das nie. Wenn doch ist eben schade.
Wenn es "einfach" den Zählerstand gibt bin ich da voll bei dirIch will auch garnicht sagen, dass man Simcount nicht verwenden soll oder das ganze System nichts taugt. Es ist sehr gut, dass das Simcount-Modul da ist um solche Geräte zu unterstützen, die keinen Zähler haben. Es ist auch einfach hinzuzufügen. Man muss nur im Modul welches es braucht Simcount aufrufen und schon hat man den Wert drin. Ich stelle mich nur gegen den Vorschlag den Modulen das Simcount aufzuzwingen und die Möglichkeit die Zähler auszulesen zu nehmen.
Ich konnte die Register noch nicht auslesen, allerdings kann ich bestätigen, dass dein SOC Register 62852 (=0xF584), den du ausliest und ins Debug-Log schriebst, korrekt ist.yankee hat geschrieben: ↑Di Dez 21, 2021 8:08 am
Bisher lesen wir als SoC den Register 62852 (=0xF584) aus. In dem Dokument steht auf Seite 20 genau dieser Register für "Battery 1 State of Energy (SOE)". Ein gutes Zeichen. Wenn das übereinstimmt, dann stimmen vielleicht auch die anderen Register. Demnach müssten wir mit dem Register 0xF576 an den Lifetime-Export und mit dem Register 0xF57A an den Lifetime-Import (beides Wattstunden als Uint64) kommen. Könnte das jemand überprüfen der eine Batterie hat und einmal diese Register manuell auslesen?