Unwanted Inverter Settings Changes in Solar Prediction Algorithm

[DarkFiguringitout]

I've noticed that the algorithm switches the battery to idle a little early as soon as it predicts that any sun will be coming out. I've attached a couple of screenshots of what I mean, please ignore 3am that is when my network updated. However, it correctly predicts (in my opinion) that it should use the batteries (showing the light blue on the energy graph) for the entire day, but when it comes to the time the sun starts generating electricity (6 am) switches the battery to idle. It still displays the blue until the hour is over, but already put the battery to an idle state. This is not an isolated incident, I've had it for the past three days, and it did the same each day.

The issue persists into the evening. As long as there is still some solar present, it keeps the batteries in an idle state, despite the electricity prices being at their high.

I unfortunately had to modify the node red flow a little to make it work with my system, I could see the issues coming from there. The "victron-idle-battery", integration does not appear to be working for me, therefore I used a flow to limit the inverter output from 0 to 3000 depending on idle or active battery state.

I also had to change the TG max and grid-set-point flow. For some reason when the battery is idle, it would set the grid-set-point to TG max. Therefore, when I wanted to interfere, there were a lot of settings for me to change. I was not exporting anyways through the inverter, therefore I changed the flow to only only have TG max 0 and a block filter unless values change. This way I could intervene without the system changing everything back straight away.

My apologies if this is its intended purpose, or if I broke the algorithm with my modifications to the node-red flow. It could be plausible that the algorithm was not meant for grid-tie micro inverters and my issues stem from that. I find this project really great and would love it to work. In the last screenshot, I already intervened to turn on the inverter. However, the system still wanted and still displays to keep the battery at idle.

[DarkFiguringitout]

Reiterating on the issue, after solar production picked up enough, the battery went out of idle on the dashboard. However, now at around 17:30, I noticed it turning the battery to idle again. Charge percentage is at 77%, with tomorrows solar forecast in mind, unless I keep the battery on all day. I'll charge past fully charged tomorrow afternoon, therefore I don't see why the automation would turn the batteries into idle mode.

I just can't figure out why the system would decide to not assist in the mornings, and early evenings.

Please refer to the screenshots bellow, if they help with diagnosing the issue.

I've also attached home assistant logging of when the automation decided to put the battery into idle and out of idle bellow.

[PoolsideKelbi]

Hey there @DarkFiguringitout, thank you for the extensive case description, I think I understand what's happening here.

From the looks of it, there are two points that are of interest to you it seems:

1. Why the controls (grid setpoint and battery idleness) do what they do;
2. Why the battery is idle as much as it is during the morning/early evenings.

The directing control output for Dynamic ESS is really the battery-idleness:

• if battery is set to be idle, it does not charge or discharge;
• If battery is not idle, it can charge or discharge depending on the other forces at play (consumption, solar yield and if possible grid import/export).

Grid setpoint is there to to enforce charging or discharging (not in your case since export to grid is not desired) over the battery when it is not idle. For instance, charge will definitely happen when battery is idle and the grid setpoint is the grid import max.

Moreover, since there are some quirks for each site, it proved to be the best the set the grid setpoint to the minimum value if the battery is idle, to disallow the battery to be charged by the excess solar (outside of the planning).

This ties into the seemingly odd behaviour displayed by the battery where it becomes idle when it seems that it shouldn't. In general, the battery is only set to be non-idle if the usage of the battery is significant (not below 10% of FBmax, or TBmax). This is done to limit the unintended battery usage that happens when the battery is set to be non-idle and the consumption/solar yield estimates are wildly off (way more excess or need for energy than predicted). Since the battery costs are one of the significant costs, the batteries are used somewhat conservatively.

This appears the most in mornings and early evenings, because those are the times where the solar yield and consumption estimates are most close to one another (because of the solar yield numbers passing the consumption numbers when it increases in the morning and decreases in the evening). This makes it so that the excess or needed energy in the system in those hours are low in amount, hence not significant enough for battery to participate.

I think this is more of a visualisation issue than a feature issue, because the limitation here is that we cannot estimate the future perfectly and those imperfections are too costly if battery usage is the way of coping with inaccuracies. We are thinking of tackling it visually so it causes the least amount of confusion :)

I hope my response clears it up for you

[DarkFiguringitout]

Ah, I see. Thank you for clearing up the confusion I had. I got the feeling that the algorithm was being a little too conservative. Perfect when its raining and probably winter, I noticed it handling the rainy week I had nicely. However, right now in I have to offload the excess load because it decides to switch the batteries off and I get no credit for feed-in. I'll have to stick to my old flow that changes the inverter states based on the battery charge and prices of each hour. The higher the charge, the longer it stays on. The lower the charge, the fewer hours it stays on and only targets the most expensive hours then. Maybe there will be a possibility of tuning the goal of the system at some point. The algorithm also seems to forget about my idle loads, and deletes them from my evening predictions when afternoon consumption peaks and then slowly decreases.

Really liking the project so far and looking forward to see it in the official vrm at some point!