Closed markusdd closed 2 months ago
probably the right approach would be to send persistent lowest limit to inverter, then issue restart, and the re-adjust to whatever it was before to avoid that spike.
how often can you write to the persistent memory? It this discharge worth the hassle and risk? Like 2.000W for 1min is worth 33.33Wh. That 0.7% of a 4.8kWh battery. How long is the restart and the discharge spike?
Anyway, wouldn’t it be better to just set a persistent low limit once, and only work with non-persistent higher loads? Imagine your inverter resets for whatever reason and your DTU is broken / not responsive to stop it from discharging.
probably the right approach would be to send persistent lowest limit to inverter, then issue restart, and the re-adjust to whatever it was before to avoid that spike.
how often can you write to the persistent memory? It this discharge worth the hassle and risk? Like 2.000W for 1min is worth 33.33Wh. That 0.7% of a 4.8kWh battery. How long is the restart and the discharge spike?
Anyway, wouldn’t it be better to just set a persistent low limit once, and only work with non-persistent higher loads? Imagine your inverter resets for whatever reason and your DTU is broken / not responsive to stop it from discharging.
valid points tbh.
it would equal to 2 writes per day, not sure what type of Flash they use and if they have a littleFS or something to balance wear.
Maybe the better idea would be to offer this as an option next to the inverter reset, something as 'keep inverter limit at minimum to avoid discharge at reset'. Enabling this would then write the lowest limit as persitent once upon save and use it going forward, not daily.
I'm not particulary concerned in my setup about this as it is a large US5000 pack with plenty of margin til empty, but people with smaller Batteries or deeper DoD might be more concerned with this.
So this is more about thinking how we can make handling of this more user friendly.
EDIT: I assume this spike is about the length of the restart and adjustment Interval of the inverter, probably around 30s or a minute max. What I am more concerned is people with smaller packs where the maximum current being drawn might trip the BMS cutoff at low SoC. For my setup it isn't really an issue, so isn't the total energy amount.
how often can you write to the persistent memory?
very, very good point... no risks please 😨
3,55A x 48V = 170W for a few seconds until the OpenDTUonBattery sends the new limit.
I am actually even happier to see that the Hoymiles did not reach "Full Power" during the startup sequence 👍
how often can you write to the persistent memory?
very, very good point... no risks please 😨
3,55A x 48V = 170W for a few seconds until the OpenDTUonBattery sends the new limit.
I am actually even happier to see that the Hoymiles did not reach "Full Power" during the startup sequence 👍
I don't think we can say that for sure. I observed this varies a bit by day so I have seen deeper spikes as well. I assume it goes to full 800W for a certain span. But as 5s is usually the reporting interval this might not get captured.
Edit: when checking my raw data I actually can see it maxes out the current briefly:
@markusdd Do I see the graph correctly, the peak happened within a 10 second timeframe?
I would not add any changes for something that occured only for a few seconds.
Ne neither.
And, you can always set a lower permanent limit. So that after DC reconnect (or software restart) the inverter starts with allowed limit. If it should start to produce energy, the DPL will give it a higher, non persistent limit as needed.
As said, I just wanted to bring this to attention. For my setup it is not an issue, but people with smaller batteries or very deep DoD settings might look at that differently.
The most realistic problem that could occur is tripping the BMS of the connected battery. Then it does not matter is this only occurs for a couple of seconds.
I'm fine with not changing the code but that behavior should at least be documented somehow so that people e.g. can set lower persistent limits
but that behavior should at least be documented somehow
Yes, I agree. Adding something to the documentation was also in my head. I thought about putting it next to the explanation of the auto-restart function. It would be great if it was part of the "setup checklist", but there is nothing like it, AFAIK.
@markusdd It was not meant a critic Markus. I am happy that somebody spent the time and gathered some data.
I always knew it, this is the normal way the Hoymiles starts (goes to full power). What I also know was that it does not jump to full power immediately, rather it gradually increases power. I am curious to see how long it takes the Dynamic Power Limiter to start regulating the Hoymiles.
I also have the restart of the Hoymiles at 08:00 which means my battery is actually going to be empty after a night's work. I do not let my battery below 15% but still, it good to keep this in mind.
So your mention is well taken, I will see where I can put a note about this in the Wiki.
not taken as criticism, I think the NVM wear-out argument is very valid and we should not do that. afaik the regulating loop of th HM series is somewhere between 20-30 seconds, so it's not long on a total scale, still significant though for a discharged battery.
maybe a comment in the UI next to the restart enable which enables the restart would be good?
But I agree a general 'items to be considered' list would help here.
@spcqike
Anyway, wouldn’t it be better to just set a persistent low limit once, and only work with non-persistent higher loads? Imagine your inverter resets for whatever reason and your DTU is broken / not responsive to stop it from discharging.
Wird es funktionieren?
Das waere Super! 🤩
Das waere Super! 🤩
Naja, das ist genau worüber wir reden, das funktioniert so. Jedenfalls nehme ich das fest an.
maybe a comment in the UI next to the restart enable which enables the restart would be good?
If the hint bubble would not be so large already, then yes.
I am thinking about replacing some of these hints to be links to the respective part of the documentation. What do you think about that idea?
Wird es funktionieren?
Ich gehe davon aus.
Theoretisch macht es aus Gründen der (Batterie)Sicherheit (tiefenentladeschutz) halt auch Sinn das lower limit des DPL als persistentes Limit zu übertragen. Oder sogar noch kleinere werte.
Warum sollte der inverter im worstcase nach einem Neustart einfach 100% fahren und die Batterie krampfhaft entleeren?
Bei meinen rein PV Systemen ist mir das quasi egal (: aber mit ner Batterie? Da hätte ich längst 50W persistent hinterlegt :)
Da hätte ich längst 50W persistent hinterlegt :)
Und ich wünschte, wir könnten das wissen und im Code verarbeiten. Dann könnten wir im DPL pauschal ein persistentes Limit setzen, wenn festgestellt wird, dass der Inverter kein persistentes Limit kennt bzw. dass es hoch ist (höher als unteres Limit dachte ich). Ich hab noch nicht genau geschaut, aber ich vermute diese Info haben wir nicht (auf der Grundlage, dass sie irgendwo angezeigt würde im Web Interface).
I consider this completed by this commit in the docs repo, deployed to opendtu-onbattery.net:
Please do complain if you think that is insufficient.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.
What happened?
Currently there is a significant discharge event when the inverter restarts at night to reset the daily values:
This should not be happening if the discharge SoC limit (in my case 20%) is already reached.
To Reproduce Bug
schedule inverter reset while Battery is already sitting at discharge limit
Expected Behavior
probably the right approach would be to send persistent lowest limit to inverter, then issue restart, and the re-adjust to whatever it was before to avoid that spike.
Install Method
Pre-Compiled binary from GitHub
What git-hash/version of OpenDTU?
https://github.com/helgeerbe/OpenDTU-OnBattery/releases/tag/2024.03.07
Relevant log/trace output
No response
Anything else?
No response