question

Hi @joolster

Take a look at this: GitHub - victronenergy/dynamic-ess

Lots of posts/chat about it in modifications section of the forum.

It's essentially some prebult node red nodes that help achieve what you're describing. ofc you can write from scratch if it's not exactly what you want.

You essentially want a node red function that reads solar and loads/what's going into battery and setting grid setpoint equals to that. but i imagine DESS has some similar solutions to this.
I've never used it but believe it's aim is similar to what you're looking to achieve.

You can also do similar if you have node-red enabled on your GX device. It's a bit basic but it will keep your grid setpoint to the same level of your solar input:

Note. I have 2 solar sources so the join allows me to add them together but the join node also allows you to add more inputs (SoC etc) if you wanted. Just remember to set the 'after number of message parts' to the number of inputs you have like this:

Then in the function is where you have your logic. It can be as simple as:

You can add more logic in this if you wish, such as only exporting if SoC is > 25% etc. Here you can see it roughly exports the solar and the battery is still running the AC loads, there is a few seconds lag which is expected.

I'm sure there are other ways to achieve a similar result but this works well on my system. Have fun.

So, thanks for your comments ... i've been playing today as have had good solar for most of the day

Spring / Summar Scenario:

[This summer scenario my goal as (obviously) in winter, fully charge batteries overnight and all energy goes to house and electric heating]

Battery starts the day, well charged to 80% or greater - this will be plenty for the evening peak etc

I want to export as much solar as possible, not charge the battery above its SOC, but only while there is plenty of solar - effectively this is well post sun rise and well pre-sunset

When the solar is either side of daily peak, then revert to normal case - which is minimising import using stored energy in battery and any residual solar

Victron Cerbo Working Setup:

I've found that a combined use of a NEGATIVE Grid Set Point and a Scheduled Charge provides a working combination.

There are two options, depending on preferences.

Option 1 (values are obviously examples that work for my system size)

- Grid Set Point -4000

- Schedule - SOC 80%

Self Consumption above limit = PV

Start time - depends on time of year / sun rise

Duration - say sunset minus 2 hours, depending on time of year

In this scenario, what I have observed is:

[Export amount] = [PV generated] - [House Loads], and the Battery is IDLE

i.e. the battery is not discharged

Option 2 (values are obviously examples that work for my system size)

- Grid Set Point -4000

- Schedule - SOC 80%

Self Consumption above limit = PV + Battery

Start time - depends on time of year / sun rise

Duration - say sunset minus 2 hours, depending on time of year

In this scenario, what I have observed is:

[Export amount] = -4000 = [PV generated] + [Battery discharge] - [House Loads]

i.e. the battery is discharged to make the export 4000W until SOC limit reached

I've not checked what happens when the house load is very high, ie elec heating operating / dishwasher and washing machine and oven/hob etc are on ... will check at some point

Next step: node red / programmatic automation etc

Any thoughts?

If i understand correctly this looks like this will force export from your batteries if you dont have 4kw+ of Solar coming in. This may be what you want :)

Node Red would give you more control over this. I have been running the following for a week now and it works as expected. All house loads will come from the battery while the SoC > 50%. If the loads exceed the inverter max then Solar and/or Grid will be used.

This is the content of the function. I added the SoC value. as I have 2 inverters I add them together. This will force the solar export until the battery drops to 50% as this mean I always have enough charge once the sun has set to get me to the next cheap rate window.

var soc=msg.payload["Venus system - Battery State of Charge (%)"];
var pv_house=msg.payload["Solar - House Roof - L1 Power (W)"];
var pv_garden=msg.payload["Solar - Garden - L1 Power (W)"];

// Sum the Solar PVs
pv = pv_garden + pv_house;

// Adjust ESS based on Solar and SOC
if (pv > 100) {
    if (soc > 50){
        if (pv > 4600){
            // Solar greater than 4.6kW so limit
            msg.payload = -4600   
        } else {
            // Export all solar
            msg.payload = Math.floor(-pv)
        }
    } else {
        // Batt low. Allow charge from solar
        msg.payload = 0
    }
} else {
    // Not enough solar so leave setpoint at 0
    msg.payload = 0
}
return msg

Guys I asked @Guy Stewart (Victron Community Manager) For something like this but said it was niche. So I’ve been looking at this with help from @matt1309 I was thinking that I could change DVCC charge current for the battery basically lower it for day and return at nigh, but I’m a noob with nodered and I’ve not seen any DVCC settings. If it can be done this way you won’t get over shoot which the battery will have to cover in cloud cover and if you start using the solar ie kettle microwave that can eat the solar and save the battery from having to cover the full load. Any thoughts

I've not confirmed this but I imagine if you're using MPPT if you lower DVCC it stops the charging rather than exporting more? AC coupled PV I imagine it just exports?

I think @marv2097 suggestion looks like it would work well. And it's got the 100w buffer built in. For others maybe deducting other loads from generated PV would be needed rather than just exporting all solar. ie same code but replacing PV with PV - loads.

@daza I think the overshoot issue is always going to be an issue. Only way to minimise it is to have the above code checked more frequently. so the grid setpoint is corrected faster to avoid drawing from battery. My only suggestion for this is something written in a faster languages that reads data directly from dbus. Maybe something written in c++ doing the exact same node red is just reading directly from dbus would be needed but I imagine node red is fast enough for most cases. I suspect the overshoot will be relatively small unless you have large loads turning on/off frequently during the export window.

I'm very much a c++ noob but i have seen some drivers from victron written (for fronius and other inverter integration) it's not really relevant but might be able to steel them as a guide for interacting with dbus from c++ the same way victron does.

HI All,

I've thought about how you could natively add this feature into victron rather than automating it via node red (slow day at work....)

I'm far from a pro (especially when it comes to understanding the victron system) so please correct me if any of this is wrong.

My thinking was you'd ideally want this calculation that @marv2097 has done in node red to be done at the same time your load figures are calculated. That way you'd minimise the time you'd be in "overshoot" as @Daza mentioned. I assumed this would be done in C++ for speed but digging around on github i stumbled upon dbus-systemcal-py. Which seems to be the script that does it?

Can someone confirm if this is where the consumption calculations are done?

If so I would say this is the script that needs to be edited to add this functionality natively.

My plan would be add a settings option in gx device for the "Export all solar"

or "Export all solar less loads". You'd also need to defined a min SoC for the logic to be active. And then maybe also implement a schedule of sorts.

I think the lines we'd need to edit would be from around 888 onwards. So whenever consumption is updated we'd have to check ESS is enabled then if it is edit gridsetpoint via dbus at the same time.

WIth

gridsetpoint = c - consumption[phase]

where c is defined in the python script. as pvpower.

This probably gets more complex on multiphase but I think that's the basic logic.

Anyone (preferably someone that knows what they're on about unlike me) confirm I'm understanding how the system works/the above high level proposal would work or if I'm miles off please?

I'd love to help on a project like this but I'm not a software dev and would be afraid my edits would impact an aspect of the system that I'm not aware of, so probably need someone more in the know to do what i describe above in a safe and reliable manner.

Would be interested to know if im miles off or not though.

Tldr: use node red solution

I've thought about this more.

More than I should have. I've concluded node red is just the best solution

That python script assuming that's the right one. Runs once per second, even if we upped that to ever 100ms to match the fastest energy meters available. Assuming no other latency you'd update the gridsetpoint every 100ms

Node reds refresh rate is in theory whenever dbus is updated. So odds are it's not much different. But even if we assume it's 1second vs 100ms.

Say you turned on a big load of say 4kw.

The time difference between python and node red would be 1 watt hour of usage. (4000/(60*60*.9))

The losses are probably more in the Ess algorithm ie how fast the inverter covers loads that are turned on. I have seen threads on that in the past but definitley above my pay grade.

@matt1309

Some interesting points, i had a similar journey and went down the route of putting ESS in external control mode and then using an external golang app to read/write setpoints via modbus. It's not really any slower/quicker than standard ESS and the limitation appears to be how fast the inverter is allowed to respond based on grid-code.

Using node red may be a little slower but its hardly noticeable and as you say ESS already has to deal with reacting to large loads turning off/on so there is not much of a way around that unless you decouple your AC system fully from the Grid (sure i saw a thread about it) but thats not really what im going for.

All depends on your use case but im hoping to export most of my solar at 15p/kwh and run my loads mostly of off-peak electricity at 7.5p. Im sure with charging/inverting/wear losses its not much in it but I also like to tinker with these things :)

Hi @Daza

I've just worked it out the value to disable dvcc current limit (ie set it to max is -1).

So you do the exact same as what you've done on the others. Where cron node send a number like this:

Except you use -1. Rather than 50. this should disable any dvcc current limit when passed into the DVCC system max charge current.

(I worked this out by seeing what using ESS node to see what DVCC max charge current was set to when manually disabled in gx device. it showed -1.)

@matt1309 or anyone else that knows nodeRed well so with the help of @matt1309 i have made a flow but something that sprung to mind is what happens in the event of a grid down situation, i want to make a fail safe, ie my flow won't trigger in a grid down situation so it will just charge the battery as normal, so i thought i could use the AC input with a cron on to say grid available take it to a joining node and then to another cron and then to the DVCC output? Im not sure if AC input is what i can use to say if grid is available lower DVCC? and then a failsafe to return to Max charge if the grid goes down in the day? I'm wired to AC 1 output on the multiplus for PV. I have no idea if the multiplus reverts by itself in this type of situation any victron staff members know if the victron system operates this way in this scenario?

@Guy Stewart (Victron Community Manager) @Matthias Lange - DE @mvader (Victron Energy)

Brilliant mate thanks a lot I’ll set it up and try and put it in the flow so it doesn’t trigger at all, this is awesome @matt1309 thanks a lot much appreciated mate.

@matt1309 so i've followed it and had a good hack at it but for the life of me i can't get the grid to trigger i did manage to stop the message on the cron but now appears i can't even do that again :(

@matt1309 so I got the grid down to work which is great thanks a lot but my flow doesn’t look like yours but work, I would love the switch node that breaks the crown up to work so it just stops them from running but end of the day the grid down will always return it to max so this is great. Thank you very much mate.

@matt1309 i couldn’t leave it alone lol done it now. So it will only allow the amps to go down if the grid is available and will go back to max if the grid is down thanks again mate

Ive added it to GitHub so people can just jump in and mess about with it maybe adding SOC before limiting DVCC https://github.com/dazza120/Victron-Solar-Export-NodeRED.git @matt1309 much appreciated for your help buddy.

I basically did this using Node-RED, modulating the grid setpoint. House loads are covered by the battery. Then added a few other controls relevant to my tarrif.