Opportunity loads and load shedding in an inverter overload scenareo

Node-RED
, , , , ,
1

I have a customer with an off grid system that has been installed for some years with a MP2 5000VA inverter. Histotrically they powered mainly lights, heating pumps and had an immersion set up as a rudimentary opportunity load (OL) switched via inverter settings and the relay on the MP2.

They have recently added a large home extension with a variety of new appliances including an induction hob, oven, more lighting, washing machine (hot fill) and dishwasher, max. individual load of 2.9kW on a 13A plug top or fused spur. They are well aware of the limitation on multiple devices not being used together but my conundrum is how to automate the immersion (3kW) now that with any two devices running there is a chance of long term overload.

I am more familiar with Nodered since I configured the original system and have set up a few systems with smallish immersions of c.1kW switched via shelly relays with nodered control. Still not quite able to conceive how to manage the overload and load shedding issues with that route.

Now the Shelly integration is here it looks like that has been dealt with, but I’m still after some clarification.

At 20.6.1 in the documentation ( 20. GX Opportunity Loads ) it does describe that if a large load switches on then the algorithm will switch off the load based on the timer function set and other parameters but how long can the MP2 deliver say 6kW if the immersion is on as an OL and the induction hob is then switched on?

The data sheet for the MP2 5000 that 9000W is possible for short periods, how comfortable is this headroom in order to allow controlled behaviour? When setting the reserve, does Venus know that you have a MP2 5000 or do you need to tell it the capacity of the system. I couldn’t find a reference to that in the documentation.

NB, for this example the really big loads VA=kW.

Anyone who has been considering some of the real world applications of this with limited or evolving systems please chime in! One option is obviously to upgrade the MP2 to the 8000VA version but I’d like to explore the solutions with the current setup as I expect their budget has been decimated by the recent build.

2

Hi,

Opportunity Loads will read the nominal inverter power from the bus as the inverters report them. So, for a MP 5000, that will be 4500.

In the Settings, you can already define a “safety margin”, how close you want Opportunity Loads to drive the inverter there (Nominal Inverter utilization Limit²). If you would specify this as 100%, Opportunity Loads will target to utilize the inverter at 4800W (including base consumption) at maximum.

When the Inverter raises an overload alert (because for example some unscheduled consumption kicks in at that time), Opportunity Loads will immediately try to drop all controlled loads to 0, ignoring their configured minimum run times as well and gently resume regular operation after 60 seconds.

This should be a question of Milliseconds, in our tests we never had the system break down, even when dropping assisting AC-PV inverters on a MP 5000 while Opportunity Loads was charging an EV at 8kW (plus ~ 1kW base consumption).

² When AC-Coupled PV is present, I would not recomend to run the battery inverters at 100% with Opportunity Loads. The Nominal inverter utilization limit (for example 50%) can be used to keep the battery inverters cooler and ready to provide overload power longer for when ac-coupled pv suddenly drops out and the battery inverters have to catch their load temporary.

3

Hi dognose,

That was such a comprehensive answer, thank you!

It allows me to think about the next issue I can anticipate. Maybe I should start a new thread but I’ll ask it here and then maybe move it later.

If we imagine the scenario where we have a battery at 80%, 1kW of solar available (from any source, DC or AC) and a 3kW OL in the form of an immersion or resistive heater.

If this load is switched on, the PV will supply 1kW and the battery will make up the other 2kW. In the OL algorithm, this load may never get switched on as there is never 3kW available direct from the PV.

Is there a way for the algorithm to predict, for example, that allowing the heater to be on for 5 minutes in every 15 minutes will allow the excess PV to be consumed and allow the battery to stay at roughly 80% though some of the energy will go via the battery to the OL?

I have managed this with a nodered flow to heat the battery when there is forecasted PV (via VRM) and the battery is too low a temperature to accept the full charge current. It allows the system to ‘invest’ some energy in the heating while knowing it will get at least that much back in the next hour.

I could do this in Nodered again for the OL but I am keen to have the function of load rapid shedding that comes for free with the OL package as discussed above.

Again, many thanks in advance!

Jona

4

In the current version, there is no feature that would allow this during regular soc levels.

Opportunity Loads would strictly conclude that there isn’t enough solar and keep the heater off.

Until the battery reaches 99% soc, then the “Solar-Keep-Alive” feature would kick in: To avoid Solar beeing throttled Opportunity Loads will enable additional loads above solar budget, until the smallest possible battery discharge has been achieved. It would then keep that down to 97% soc (so, technically for 1%, assuming a threshold based BMS). Then it would resume to operate based on solar only, eventually allowing the battery to reach 99% again. Rinse and repeat throughout the day, until that 99% can no longer be reached.

Despite that, Node red can always be used in various ways to add own logic on top. Without going too much into detail there, the options range from just putting a standard consumer into manual temporary and turn it on for while upto writing a custom (so called) Ressource-Manager that provides a custom S2 OMBC Control Model instead of a generic on/off model for opportunity loads.

The second approach would be the most promising to achieve your idea: This RM could provide States like Off/On/ForcedOn, where it enters ForcedOn based on your own logic. Then, this model provides a transition from ForcedOn to Off flagged with the “abnormal_condition_only”-bit. That would mean: Opportunity Loads is not allowed to go from ForcedOn to Off, except, there is an Inverter Overload Alert raised.

(There will be a bunch of Node-Red-Tutorials about this coming)

5

dognose,

Again, very comprehensive - thank you.

Could you please tell me what the acronym OMBC is?

I’ll look forward to the nodered tutorials, and in the meantime I’ll have a shot at the inverter overload alarm as a custom load shedding within nodered. Recently it seems I have been writing flows for these problems and then Victron goes and puts it in the main GUI, maybe if I crack it, it will be time for it to come in a venus update!

Thanks

6

Operation Mode Based Control

7

The video gives a good overview of the MultiPlus’s overload capability, especially in off-grid applications.

One installation I built has an MP8000 = 6400 watts.
In the video, it says the unit can handle a 30% overload for 30 minutes (8300 W) and 15 kW!!! for 3 minutes.

To let users see the inverter’s load, several Ulanzi TC001 (€35) displays running AWTRIX firmware were installed and fed data via Node-RED.

The inverter has never shut down, even with loads such as a 3 kW oven, hob(s) = 2 kW, a 1 kW water heater, a kettle, a washing machine, and the woodworking shop’s circular saw in use.

Opportunity loads are still a relatively new concept and haven’t been installed there yet.

8

Hi everyone,

I run a three-phase off-grid system with three MultiPlus 48/8000 units. My flexible loads include a Victron EVCS, controlled natively by Opportunity Loads, and three separate 1 kW heating stages in a heat buffer tank, integrated through Node-RED/S2.

Each heating stage is represented by its own S2 Resource Manager using Operation Mode Based Control (OMBC), with OFF and HEATING modes.

The responsibilities are deliberately separated:

  • Victron OPL decides whether energy is available and issues the ON/OFF instructions.

  • Node-RED determines the heat demand, based on temperatures, setpoint and protection conditions.

  • When heat is no longer required, Node-RED switches the stages off and makes them unavailable for OPL control.

  • When demand returns, the stages become available again but wait for a new ON instruction from Victron.

  • Actual relay feedback is used to confirm the operating mode.

Regarding the SOC discussion, there are some configurable settings worth mentioning. In our priority list, the battery comes before the heating stages. We can configure the SOC threshold for activating lower-priority loads, along with the power reserved for battery charging at that threshold and at 100% SOC.

We also use the “Nominal inverter utilisation limit”, which lets OPL retain inverter headroom rather than allocate the full nominal capacity to household consumption and flexible loads.

In yesterday’s test, our heating stages started at 95% SOC while the battery continued charging. Later, when PV production dropped, the heaters temporarily continued running with battery support before Victron switched them off.

I would therefore distinguish between enabling surplus consumption below 99% SOC—which these settings allow—and deliberately running a load above the available solar budget. We have not established whether the configured activation SOC also represents a firm discharge cut-off. Clarification on that would be useful.

We also had a practical load-shedding test: our espresso machine repeatedly drew around 1,200–1,400 W while reheating. OPL switched a heating stage off and subsequently back on on the same phase. Our logs recorded the incoming Victron instructions and the corresponding relay responses.

When solar availability declined later in the afternoon, Victron switched all three stages off. They remained off despite falling buffer temperatures and continuing heat demand.

Heizung_rams
Heizung_rams605×694 306 KB

My Flowfuse Controlpanel

Having three independently controlled 1 kW stages also allows us to use smaller surpluses than a single, indivisible 3 kW load would.

This demonstrates normal OPL load allocation and shedding in our installation. We have not deliberately triggered an inverter overload or implemented the proposed ForcedOn battery-assisted operating mode.

One thing I missed during debugging was an independent display of the OPL coordinator’s current command. Reported load power alone

9

I have a question about load-shedding control by increasing the frequency.

A separate post will be created for this and linked here, so this post doesn’t get cluttered.