[DESS HACK] Unexpected Bat2Grid and Solar-Feedin. (Green Mode)

[Fellside]

I was in no way criticizing the hack version by dognose. I think he has done a great job. If fact the hack version is the only reason I have been testing DESS again. It was posted here as feedback because I am using the hack version. Which I assume is unsupported by Victron at the moment.

[Gaspa (Andrea Gasparini)]

Today it also happened to me that it scheduled a charge to reach target soc, charge was scheduled for 700watt, but solar was over 4kw for a couple of hours.
Given the fact that my highest price difference is less than the round trip efficiency of charging/discharging, and so it never makes sense to charge the battery from the grid, I deleted the charge logic from Dognoses dynamicess.py for now.

[dognose]

@dognose

Just encountered a NEW, wild situation:

• Battery charge was scheduled to reach target soc
• during that time, pv spiked.
• so the scheduled charge rate was lower than the pv surplus, leading to solar beeing feedin

Will think about, if that can be addressed somehow.

So, finally I was able to verify the changes I made regarding this issue:

• TargetSoc was Set to 78%
• With a Soc of 76%, this resulted in a calculated charge-rate of 2943 Watts, while currently solar spiked upto 6000 Watts.

Regular behaviour here would be, that the battery charges with 2943 Watts and the system will feedin about 3000 Watts to the grid.

Therefore, “my” system switched into “SCHEDULED_CHARGE_SUPPRESS_FEEDIN”, pretending that there is a “0-Feedin-Restriction” enabled - and this causes the system to ignore the precalculated charge-rate and use what is available.

So, this seems to work as expected - I will update the repository during the day, so this mode will be available for everyone as well:

A tiny simplification here is, that this mode will only kick in upto 90% SoC. When the battery is not able to take the excess solar anymore, pretending a “0-Feedin” would most likely result in throttling of the mppts / ac-pv, which is most likely undesired as well.

So, the simplest approach is to say “Once we got 90% soc, it is not that important anymore to suppress some extra from beeing feedin.”

[dognose]

Updated the repository, installation remains the same, just follow this post:

[DESS HACK] Unexpected Bat2Grid and Solar-Feedin. (Green Mode)

I’ve now thought about this, and how to solve it - and I think the only way to address this, is a user-preference setting. I’ve therefore now modified the UI of the Dynamic ESS Page in cerbo, where a user can set the “Max Target SOC for idle”. (And in the same turn added the Final Strategy Output there): [image] So, what does this exactly mean? When there is a roadmap based on target-soc, VRM has a plan, that it should reach a certain soc-level per hour. The Hack will slightly adjust this “…

Additionally addded a “Hack-Version” Field in the cerbo-UI, so you can easily verify (in the future) on which version of the hack you are running in case you skip some posts :

[grua]

Can the new version simply be installed over the existing one, or does the current version have to be uninstalled first?

[dognose]

Just run the scripts again, it will overwrite.

[OveStj (Ove)]

hopefully the DESS-logic will not drain the batteries after this “powerful” loading the next hours to the newly computed (lower) TargetSOC…
As encountered yesterday: Bei wem läuft DESS? - #165 by OveStj

[dognose]

My hack suppresses that as well. Discharge (to grid) is completly removed from the possible actions.

When the actual soc exceeds the target soc desired by DESS, my hack is switching to either SELFONSUME_ACCEPT_CHARGE (if solar+ > consumption) or SELFCONSUME_ACCEPT_DISCHARGE (if consumption > solar+, until the soc falls down to target soc worstcase)

Means: Getting ahead of (soc-)plan is always allowed - getting behind not, when falling behind the system will charge or idle based on the original vrm schedule.

All the states starting with “SelfConsume” are basically just regular ESS Mode without any magic. I just gave them different names to be able to identify WHY the system is deciding to override any possible schedule.

[OveStj (Ove)]

@dognose

90% SoC

why do you stop charging with max. avail solar in your script at 90% SOC ?
I understand, that max. charging-ability of batteries is getting lower the nearer 100% SOC comes. But if some batteries charge with max. power up to 95 or 98% what would be the problem to charge at max. avail solar power and if batteries are unable to charge that fast the rest of solar is fed in…

[BartChampagne]

@dognose

A tiny simplification here is, that this mode will only kick in upto 90% SoC. When the battery is not able to take the excess solar anymore, pretending a “0-Feedin” would most likely result in throttling of the mppts / ac-pv, which is most likely undesired as well.

So, the simplest approach is to say “Once we got 90% soc, it is not that important anymore to suppress some extra from beeing feedin.”

An option to allow charging up to 100% (from solar) would be nice indeed.
Amongst other reasons: to enable the periodical battery charge up to 100%.
Unless this is unaffected by this version of the hack ?
I’m OK if the system charges the last 10% from grid when prices are low.
If my DESS settings are set to never feed in excess solar to the grid, I presume the hack version will still respect this ?

And big thanks for your work !
*sends virtual beer*

[dognose]

@OveStj

why do you stop charging with max. avail solar in your script at 90% SOC ?

It’s not stopping to charge. It is just stopping to “pretend 0 feedin” at that point, so eventually falls back to the lower chargerate calculated by dess, but allows feedin again.

Reason is, that the systems - naturally - would start to feedin, when the battery can only take for example 500 of 3000 watts solar due to high soc.

If the hack would now still pretend a 0 feedin policy, that would lead to throttling down the solar production to 500.

So, i’m stopping that at 90% soc, allowing the system to act “normal” here, charge what’s possible / calculated and feedin when allowed and / or required.

@BartChampagne

If my DESS settings are set to never feed in excess solar to the grid, I presume the hack version will still respect this ?

Yes ofc, fallback is “User-desired-setting”. If you have 0 feedin enabled that problem basically shouldn’t exist for you anyway.

---

I think I should draw a decission tree of what’s happening when and why

[OveStj (Ove)]

@dognose

would lead to throttling down the solar production

I have an AC attached pv - independent from the victron ESS - so there can’t be any throttling from victron.
I think i’'ll change the parameter in the dynamicess.py to 99%.

@dognose

I should draw a decission tree

would help 100%

Ove

[BartChampagne]

@dognose

I think I should draw a decission tree of what’s happening when and why

That would provide some clarity to those of us not familiar with the script inner workings and could even be beneficial to yourself so you don’t get lost in your own logic

[grua]

@dognose

So, i’m stopping that at 90% soc, allowing the system to act “normal” here, charge what’s possible / calculated and feedin when allowed and / or required.

For me, that’s OK, because of MPPT.

[dognose]

So, have drawn a decision tree

Hope that makes it somewhat clearer for those interested in it. In green you’ll find the respective “final strategy” i’m showing in the cerbo-ui.

(This is evaluated every 4 or 5 seconds)

[BartChampagne]

The flowchart is very nice, although there’s a point that had me scratching my head.
“SoC < TargetSoC ?” → No (so SoC ≥ TargetSoC) → “Solar+ > Consumption ?” → No → “TargetSoC < SoC ?” (so SoC > or = TargetSoC)

It all fits and computes, only the usage of < vs > in different steps, SoC and TargetSoc switching places and inversion when taking “No” branches took some extra iterations in my head before it all parsed.
If somebody else is having parsing troubles, maybe my annotated path above helps a bit

[Groove]

Anyone else having such an alert:

[dognose]

Yes have this as well. Means DESS/VRM is currently not generating a schedule.

I also noted, that during the past days, “tomorrow prices” became available quite late.

I assume this may be the cause, for DESS/VRM not beeing able to generate the schedule for the noon “in time”.

(The hack in this case is not doing anything, but let the original stuff happen - which looks like a fallback to ESS / Self Consume Mode)

[Sarowe1990]

What is happening? I have had this phenomenon before but I am not observing it at the moment. Prices and schedules are usually available at 1:30 p.m.

[grua]

It’s a global problem, many have it at the moment:

Gateway - DESS error code: No matching schedule available

Hello, Starting from today there’s an error in VRM: “Gateway - DESS error code: No matching schedule available”. Anybody has the same issue? [image]