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. |
|
Hallo @AndreasBoehm , |
|
Endlich hab ich dran gedacht. Innenwiderstand ist mittlerweile auf 24,9 mOhm gesunken. Vor dem Test (WR aus) Während dem Test (WR an, 1000 W) Spannung ist nach dem die Last weg war auf ~52,1 V gesprungen, anschließend ist sie weiter gestiegen bis auf 52,48V.
|
|
Cool, das passt. 👍 Du müsstest jetzt auch schon feststellen, das für den Vergleich mit den Schwellenwerten, die Leerlaufspannung verwendet wird. Jetzt stellt sich der Frage ob und wie wir weitermachen? |
Ich würde gerne die Werte in der Batterie Live-View sehen, wie ursprünglich von dir implementiert. MQTT und HA auto-discovery wären traumhaft 🙈 Und dann brauchen wir noch "Battery Guard Settings" um das Feature-Set zu aktivieren, Sonst fällt mir gerade noch ein das wir noch schauen müssen was aktuell passiert wenn man MQTT als Provider konfiguriert hat, kommt es zu sinnlosen versuchen was zu kalkulieren das wir nie kalkulieren werden? Das löst sich dann eventuell über Default-Werte, die in dem Fall dann zwingend erforderlich sind oder über das hinzufügen eines Strom Topics?
Ich finde es besser wenn wir jedes feature in einem einzelnen PR haben, das macht das code review und auch das testing einfacher. Zusätzlich musst du nicht alles permanent rebasen und die einzelnen Features kommen dann schneller nach development und somit auch in ein release :) |
Ich hab einen Issue angelegt um das nicht zu vergessen, dann wird dieser PR auch nicht zu groß. Nur wenn du einverstanden bist das wir das nicht direkt implementieren @schlimmchen ? |
|
Ja, passt. Wenn das Feature fliegt, soll es rein. Es ist natürlich echt ein Problem, wissentlich Baustellen übrig zu lassen, aber dieses Thema (open circuit voltage, das entsorgen des load correction factors) ist total gut und wichtig, dann müssen wir das halt schrittweise angehen. |
|
Ok, Das Feature sollte nun mit allen Battery-Providern laufen, die folgende Bedingungen erfüllen:
|
Berechnet den "Internen Batteriewiderstand" und daraus die "Batterie Leerlaufspannung"
Einschränkungen:
Was noch fehlt ist ein Anfangs/Defaultwert der über die Web-UI konfiguriert werden kann.
An dieser Stelle benötige ich Unterstützung.