ESS runtime parameters to work with other consumers of excess PV power

Node-RED
1

Hello all,

I recently installed a MP-II GX I’m currently reworking some automation I had (part python services, part home assistant), to node-red and integrate it properly around the ESS.
First of all, the rerouting of excess PV power to my water heater.

My goal is for excess power to be consumed in priority by the water heater, since it’s basically a battery that doesn’t wear I cycle everyday anyway for my hot water needs.
Then, when it’s charged, I allow ESS to charge the battery.

I can’t use the grid meter in my water heater control loop because it is already in the ESS control, so using it for another load without feeding anything back to ESS would basically create a nice randomly oscillating system.
Looking at node-red victron nodes I’m quite sure there is currently no way to insert a consumer in the ESS control loop. There seems to be third party mods for Venus to have a power broker system that would allow this (a good concept indeed, hope Victron will consider this for future features), but I’d rather stick to stock firmware.

I have settled for setting the water heater power at PV production, minus MP-II output and a fixed power setting reserved for loads between grid and the MP-II (I lack another metering device to report this, and since my PV is AC-tied there, this is an unsolvable equation).

This works, but while the water heater charges, ESS also tries to hit its grid setpoint, as it’s way more reactive than my flow it ends up charging at little power that I’d rather see into the heater, and that I suspect will reset batterylife and prevent raising active soc during low PV yield times.

So, I also need a way to tell ESS “stop charging” that
1/ Is not a setting that may be written into a flash or eeprom of a microcontroller and cause wearout
2/ Does not mess with ESS native features, like batterylife

For now, I use the ESS Control Node to prevent battery charge while the water heater is preempting excess PV power :
image
It is satisfying, but I don’t know if it answers the criteria I mentioned just before.

I set it based on a function that prevents excessive flapping

var disable_charge = (
    allowed_time &&.  // static 08:00 - 18:00 time range
    heater_needs_power &&. // flag set when the heater thermostat is closed
    pv_power_sufficient. // threshold when I consider I start/stop producing (100W for 2700Wp)
) ? 1 : 0;

To give an overview of the flow

image
image2256×1974 509 KB

There are other flows it depends upon, that collect PV data from OpenDTU via MQTT, among others.

I’ll happily share any details, I’d just rather not dump the whole thing right away without discussion context.

Read you later

2

I might have misunderstood something – but what you’re trying is basically what my EV charging setup with evcc does: suck up all available solar energy dynamically, optimally leaving the battery and grid at 0 watts, right?
What evcc does is simply look at the battery charge power plus the grid meter value, and then “steal” that amount of power for the car – without needing to set anything on the victron side, as the ESS simply reacts to the additional load.
You might even be able to use evcc to run your water heater, I think it has support for that.

3

Yes it seems the same : to have an external load preempt PV excess power that ESS will otherwise use to maintain its grid setpoint until the battery reaches 100% SoC.
With added bonus that if that power being “stolen” under ESS’s nose makes it eventually trigger its batterylife algorithm the same way it would if PV production was merely lacking, it’s all the better.

The thing I can’t figure out is, how can you do that using a grid meter, while ESS is also watching that measurement and reacting quite fast to keep it at setpoint.

If I use the grid meter to control the heater in a feedback loop, like it did before the MP-II, then each system (ESS and my own) will be influencing grid power without each other’s loop being aware of the other, it can’t be stable.

It is why I rather take the solar power reported by the inverters, substract the known/estimated loads and use that value for the heater.

4

Thinking about how you describe the EVCC mode of operation, I’ve quickly thrown together a flow that implements something like that :

image
image2926×1478 329 KB

On the top, the sum of grid meter and sign-reversed battery power represents what would be drawn from grid (negative meaning exporting) if the battery wasn’t charging.

It is fed into a PID controller node (node-red-contrib-pid (node) - Node-RED) with a setpoint at 50 (same as ESS grid setpoint, if this is stable I may let the flow fetch that setting directly from the Multiplus settings rather than leave it hardcoded).
Right now I’ve not tweaked the PID parameters. Could be either oscillating wildly or slow to react.

The Postprocess function merely turns the PID 0-1 output to 0-100 (not sure the range node works on a float input) and sets the topic.

The remainder handles the heater control modes (my HASS setup has a control to force mode between automatic, on and off) and wether it is actually ready to use power, to enable/disable PID and/or send a fixed power directive when relevant.

Of course the minute I switch from the former flow to this one, my water heater is charged :smiley:

1 Like
5

This is inconclusive, but the fault is in the PID settings.

I am trying to follow the tuning guide given in the node-red-contrib-pid node doc but I probably don’t get it right, I either have it oscillating wildly, or being roughly stable 500 watts above setpoint.

I could cheat and move the setpoint, but that’s a bit crass.

Edit : I gave up on the “start with proportional gain at 0 to measure overshoot” PID tuning methods; I gather the nodered dashboard charts I’m using to observe are not accurate/reactive enough. Instead I focused on what the node-red-contrib-pid doc says about Proportional band : the value (in the units of input and setpoint, here watts) that a corresponds to the output full power, so the power of my heater’s resistance at 100%.
With that, and integral/derivative out of the play, for some time it stayed some 300W above setpoint but I left it alone and it slowly homed on it. The sky is clear, so the PV yield is pretty stable. It would be different with passing clouds.
The sign I must now adjust with integral and derivative settings, I think.

For now I think I’ll leave it run a few days and look at when the ESS battery starts charging, should be when the heater is done, and there should be little or no transient charging before that.

If I can get it working it’s a good way to avoid the question of interacting with ESS parameters altogether.