Feature: "Open circuit voltage" and "Battery internal resistance" #1466
Conversation
|
Noch eine Anmerkung zum "Internal Resistance". Man kann natürlich auch den Begriff "Load compensation factor" verwenden. Beides lässt sich in den jeweils anderen Wert einfach umrechnen. |
Dabei kann ich dir gerne helfen. |
Warum? IMHO sollte das nicht konfigurierbar sein. Insbesondere weil dieser Wert ja dann "automatisch" obsolet wird. Und selbst Andreas weiß nicht, was er da eintragen soll... Was macht dann der Standard-Benutzer? Meinst du vielleicht, dass diese Werte persistiert werden sollten, sodass der Algorithmus nicht bei jedem Neustart der OpenDTU-OnBattery von vorne beginnen muss? Das fänd ich nachvollziehbar. Wenn man das gleich richtig macht, ist das aber ein handfestes Feature. Denn in der Konfig verstecken möchte ich solche Sachen nur ungerne, die gehören da eigentlich nicht rein. Das sind "Kalibrierwerte" und die würde ich gerne in eine separate JSON im LittleFS ablegen. Macht das Sinn? Ich hab für den Battery Watchdog beispielsweise auch schon Werte im Kopf, die persistiert werden sollten (Zeitpunkt der letzten vollständigen Aufladung der Batterie). Und auch der charge cycle des DPL sollte da persistiert werden, das wäre sehr sinnvoll. |
Gut...das muss ich noch etwas genauer erklären. Ich benötige keinen Anfangswert aber er wäre nützlich.
Klar, das geht im Prinzip genau so um das Start Problem zu umgehen. Aber es gibt noch einen spezial Fall: Und aus all diesen Überlegungen bin ich dann auf die Idee gekommen:
Bei meiner Batterie steht im Datenblatt Ri < 12mOhm und diesen Wert nehme ich auch als Startwert. Aber die Lösung mit einer Kalibrier-JSON finde ich auch gut.
Das wäre ein super Feature. Könnte ich auch an der einen oder anderen Stelle brauchen. Ich habe ja schon eine einfache Routine die dafür sorgt das alle 14 Tage die Batterie auf 100% SoC aufgeladen wird. Aber diese Info geht leider bei jedem Neustart verloren. Wichtig wäre das das ganze mal auf einen anderen System getestet wird. Momentan geht es ja nur in Verbindung mit einem Smart Shunt. Ich kann aber auch gerne die fehlenden Codezeilen für andere Batterieprovider einfügen. |
Ich würde das Feature gerne testen, nutze allerdings eine Pytes Batterie. |
|
Ok, ich schau mir die Pytes von den technischen Daten mal an und mache die notwendigen Änderungen. |
|
Auflösung: 10 mV und 100 mA Genial wäre es wenn wir das so integriert bekommen das es direkt für alle Provider funktioniert. |
Es gibt nur 2 Limitierungen:
Beides lässt sich automatisch ermitteln. Und wenn die Werte zu schlecht sind dann gibt es keine automatische Berechnung des "internen Batteriewiderstands" und man muss mit dem Startwert leben. |
SW-Niko
force-pushed
the
batteryguard
branch
from
f2c67a3 to
98d801f
Compare
|
Hallo @AndreasBoehm, Einfach eine Zeit lang laufen lassen und dann im Log nachschauen wie es funktioniert. 16:39:37.963 > [BatteryGuard] |
AndreasBoehm
force-pushed
the
batteryguard
branch
from
98d801f to
b592d9c
Compare
|
Ich war so frei und hab den PR rebased. |
|
Natürlich war mein Akku beim installieren deiner Version schon leer und der WR aus. Was mich irritiert ist diese Zeile, denn es wurde ja eigentlich noch gar nichts berechnet? Das sagt uns zumindest auch die Zeile darüber. |
|
Ich sehe gerade das du die Werte nicht mehr für die LiveView ausspielst. Das sollte eigentlich ganz einfach für alle Battery Provider machbar sein. in |
Das irritiert mich auch. Allerdings wird der Widerstand aus jeder ausreichenden Stromänderung berechnet. Egal in welche Richtung. Gibt es bei deinem System außer dem Inverter und dem Solar Charger noch weitere Geräte die den Strom um mindestens 3.5A ändern? Und ich sehe noch einen weiteren Punkt der mir nicht gefällt.
Die Resolution passt zu deinen Angaben. 👍 Ursache 1: Ursache 2: Für Ursache 1 muss ich auf jeden Fall noch was in die Berechnung einbauen. PS: Ich hätte bei deiner Batterie grob über den Daumen so mit 20mOhm gerechnet. Nachtrag: Ich denke ich habe das Problem gefunden. Sollte einfach zu fixen sein. |
|
Sorry, mir ist gerade eingefallen das der WR nach dem installieren deiner Version kurz losgelegt hat, das erklärt warum wir einen Messwert haben. Lass uns das also erstmal ignorieren. Zur Timing problematik: Aktuell gehst du auf OpenDTU-OnBattery/include/BatteryStats.h Line 96 in af66a8e und OpenDTU-OnBattery/include/BatteryStats.h Line 102 in af66a8e Bei CAN Batterien wird |
|
Hier noch ein Log mit dem du ein gefühl dafür bekommst wie oft wir neue Werte der Pytes Batterie bekommen (falls das interessant ist für dich) Log |
Ja, ist bei mir genauso. Das passt. 👍
Das habe ich gefixt. Der Report ist gar nicht so schlecht. 2 Probleme identifiziert und gefixt. Ich kann den Fix leider nicht testen. Bitte Fix installieren und nochmal den Report posten. Danke Andreas. |
|
Hier der erste Report nach der Installation der neuen Version. Ich schau später nochmal drauf. Hier nochmal nach einer Stunde, leider liegt Schnee auf den Modulen. |
Das schaut schon mal sehr gut aus. 👍 Jetzt brauchen wir nur noch genügend Lastwechsel und dann sollte es klappen. Allerdings muss ich noch einen Schutz einbauen. Ich muss noch sicherstellen das der Spannungs- und der Stromwerte zeitlich zusammengehören. Beim Smart Shunt und bei Pytes ist das automatisch gegeben. Beide Werte haben den gleichen Zeitstempel und es ist nicht möglich das eine Berechnung mit den beiden Werten erfolgt wenn erst einer der beiden Werte angekommen ist. Das trifft uns bei anderen Berechnungen genauso P = U(t1) * I(t1) und nicht P = U(t2) * I(t1). |
Grundsätzlich sieht es so aus, ich würde aber nicht meine Hand dafür ins Feuer legen. Im Falle des OpenDTU-OnBattery/src/BatteryStats.cpp Lines 725 to 737 in af66a8e Wir müssen uns noch was für den MQTT Provider überlegen, der unterstützt Stromwerte nicht, also brauchen wir hier eine ausnahme, das wir nicht versuchen was zu berechnen wenns nie klappen wird. |
|
Beim JK und JBD BMS werden DataPoints verarbeitet. Diesen Ansatz würde ich langfristig gerne auch bei anderen Softwarekomponenten sehen. Dort hat jeder Skalar einen eigenen Zeitstempel, der auch mal ein paar wenige Millisekunden von anderen abweichen kann, weil es eben auch Millisekunden dauern kann, einen Satz Daten von der Peripherie zu verarbeiten. Darüber hinaus ist es nicht vorgesehen garantieren zu müssen, dass alle Datenpunkte, wenn man den Container anschaut, immer aus dem gleichen Datensatz der Peripherie kommen. |
Die Millisekunden stören nicht. Was stört ... ist das an vielen Stellen wo die Daten verarbeitet werden erst mal überprüft werden muss ob der neue Spannungswert zu dem bereits vorhandenen Stromwert zeitlich passt oder ob der passende Stromwert erst in einigen Millisekunden eintreffen wird. Aber das ist mit etwas Zusatzaufwand lösbar. Ich bin dran ... |
|
Leider liegt immer noch Schnee auf meinen Modulen, der Widerstand konnte aber mittlerweile berechnet werden. Der Amount bei 17.02. 18.02. Hier noch der Verlauf des Stroms |
Kein Grund zur Sorge. Es wird weiter gemittelt. Ich lass den Zähler nur nicht über 10000. Vielleicht sollte ich "Amount: > 10000" ausgeben?
Der Unterschied zwischen Min und Max ist etwas zu groß für meinen Geschmack, Da kann ich aber noch was machen.
Der jetzt wirklich wichtige Punkt ist herauszufinden, ob der Wert von 40mOhm für deine Batterie ausreichend genau ist. |
|
Hallo @schlimmchen ,
Ich habe eine Lösung gefunden, die mit allen Varianten, wie die Daten daherkommen können, zurechtkommt. |
Hab zwischenzeitlich andere builds auf meiner DTU ausprobiert. |
|
Verstehe ... Auch das kann man Lösen wenn man zusätzlich noch Spannungsgrenzwerte einbaut. Ich bin mir nur nicht sicher wie viel Aufwand wir noch investieren sollen. Einfach melden wenn ich noch was ändern soll. 👍 |
…s, ensure that voltage is valid
…ive view after the battery guard is deactivated
Build ArtifactsFirmware built from this pull request's code:
Notice
|
3 participants
Berechnet die "Batterie Leerlaufspannung" und verwendet sie als Vergleichswert für den „Start-Schwellwert“ und den „Stop-Schwellwert“.
Einschränkungen für die automatische Berechnung des Internen DC-Pulse-Widerstandes:
Beispiel: Kompensation beim Laden der Batterie ("Start-Schwellwert“)
Die Batterie wird mit 4.7A geladen. Deshalb ist die Batteriespannung höher als die Leerlaufspannung.
Update 07.06.25
Es gibt für die Dokumentation gibt es ein Update:
Whitepater-BatteryGuard.pdf