Unexpected settings from dynamic-ess

[MichaKersloot]

As a picture tells more than words. One would expect the grid setpoint to be set to 0 and battery idle to false when the proposal is 'from battery' as you can see at 1 o'clock.

[andressade]

I see the same behavior. Even the calculated plan seems reasonable it will not follow it, only setting battery to idle and sitting there

[khostri]

I had similar findings. I made several tests - wrote here in comments https://community.victronenergy.com/questions/216776/dynamic-ess-battery-not-charging.html?childToView=217558#comment-217558 But it seems to me that this is connected somehow to Baterry price. Do you have different price than default 0.04? For me with 0.04 it worked nearly as expected. When I switched to 0.087 or even to 0.07, it starts to act strange it seems. Like with 0.07 discharding works, charging does not, etc. So not sure if there could be some issue when price is further from default value, there is mayube undefined calculated value, overflow/ fixed comparison or something like that.

[PoolsideKelbi]

Hello @MichaKersloot, thank you for raising this matter.

The reason why the controls do not reflect what you see on the graph is because the system is trying to be conservative with allowing the battery to be idle. Since the forecasts for both consumption and solar yield can be inaccurate and the battery costs are a factor to consider, we have seen that it is best to disallow the battery to be non-idle when its planned usage is below 10% of its charge/discharge capabilities.

I can provide a more detailed explanation over what happens here if you could provide me with the following parameters of your installation:

• B_max
• TB_max
• FB_max
• TG_max
• FG_max Additionally, if you could provide me with the updated screenshot of the 'Energy graph', then we could see what really happened as a result of the decisions made by the algorithm for these early hours.

[MichaKersloot]

Hi,

B_max: 9 TB_max: 3 FB_max: 3 TG_max: 4.1 FG_max: 4.1 Battery costs: 0.02

And for your convenience a battery soc graph of the same time:

There are some hiccups in the soc display because I missed: https://www.victronenergy.com/live/ccgx:root_access#partitions_read-only_rootfs_and_available_disk_space

It would helped me if this information was also on this page: https://www.victronenergy.com/live/venus-os:large

[PoolsideKelbi]

Thanks for the timely reply!

It seems what I suspected is true: For the hours 1 and 2, the planned battery discharge was below 0.3 (10% of the FB_max) looking at the screenshot you have provided in the original post. In this case the battery is set to be idle in order to be conservative with its usage. But for the hour 3, the planned discharge was above 0.3 hence the battery was not idle (as you can see from the screenshot you posted the last).

It is important to note that the decision-making with regards to this conservative usage is made based on the forecasts not what happens in reality in that hour: for hour 2 the usage was actually above 0.3 while for hour 3 it was the opposite.

I hope this provided little more context why the strange behaviour exists when there is a small difference between the consumption and solar yield estimates.

[MichaKersloot]

Thanks for your answer, I think I can follow the reasoning ;-) But I assume the settings and the graphics are from the same planning algorithm?

And for the conservative approach... I just see and it shows in the SOC graph that from 9 o'clock the planning is 'delivering to grid' the battery is not set at idle which makes my battery hover between 10% and 12%. Maybe setting the battery in 'idle' should solve this?

[khostri]

It is important to note that the decision-making with regards to this conservative usage is made based on the forecasts not what happens in reality in that hour: for hour 2 the usage was actually above 0.3 while for hour 3 it was the opposite.

Thank for Clarification @MichaKersloot / just curious, would help to use correction factor in recalculation periods? To take in account forecast-current delta. In each period its known if forecast was higher or lower than actual value and decision plan can be adjusted in such way.

[MichaKersloot]

Hi @khostri , I'm not sure how the calculations work and how they should be adjusted. I just wondered why the actions/settings, based on the prediction don't match the graphics that should be based on the same predictions.

[MichaKersloot]

Some strange decisions again. Why charge my batter from the grid at the most expensive hours?

Is there some way to log the actual outcome that is send to the ESS functionality in the inverter?

Is there a (wiki/github) page where we can look into the internals of the decision making a bit? The comment about 10% backoff for example, was very helpful in understanding what happens.

[PoolsideKelbi]

Hello again. I believe this was caused by an issue (overnight) on our end by the API. It has been resolved in the morning. Sorry about the outcome.

The issue was in the domain of overestimating the PV yield. So there is no sensical reason behind what happened overnight :)

[MichaKersloot]

Ha, ehh... great... Thank you for clearing this up. I know this stuff is still beta? So I expect things like this can happen. Thank you for being open on this, so we can keep moving on ;-)

[H8meCZ]

Is there any chance to set minimum SoC to some value - for example 20% (unless grid fails) for Dynamic ESS? It means the Dynamic ESS can change SoC from 20 to 100% not bellow in any chance. Thank you guys!

[MichaKersloot]

Is there any chance to set minimum SoC to some value - for example 20% (unless grid fails) for Dynamic ESS? It means the Dynamic ESS can change SoC from 20 to 100% not bellow in any chance. Thank you guys!

As far as I'm aware, it takes the settings from the ESS settings in the console: Settings -> ESS -> Minimum SOC (unless grid fails).

[dirkjanfaber]

It does use the minimum SOC for its calculations.

We've just published a new release, that is more incorporated into the Venus OS and follows the target SOC instead of setting a setpoint and a less than ideal way of idling the battery.

As this uses a different approach, you will need to:

• update Venus OS (to 3.10 or above)
• update the victron-dynamic-ess node to version 0.1.1
• update the example flow
• reconfigure the Dynamic ESS node (as we switched from the site ID to the VRM portal ID)

More information can be found in the release notes and README.md