Non Essentials draining batteries when the PV drops off

I had a Victron grid tied system installed last month and now that its settled I have noticed something odd.
The system consists of:
16 x 455W panels,
SmartSolar MPPT RS 450/100 handling the DC charging from the two PV strings,
Quattro 48/8000/140-100/100 230V VE.Bus Inverter
4 x US3000C Pylontech batteries
Victron cerbo
ET112 energy meter

Initially the installer had everything running as essential loads (I have solar geysers) on AC 1out, but this just pulls down the batteries too quickly. I had them split the oven off and it was connected to the out side of the energy meter. Basically removed from essential loads and would drop off when the grid fails due to loadshedding.

What I noticed is that around 5pm with the PV gone, the oven would consume battery power before grid and draw the batteries down to the set 40% SOC then pass grid through. I want the oven to not use battery at all but still get the benefit of PV if its used in the daytime and the batteries are fully charged. Would I need to move it to AC2 out to achieve this? Would obviously require its own earth leakage etc.

Sadly, this can not be done on a Victron system currently… I am hoping that some day it will be possible.

Not natively, but with Home Assistant and ModBus it is really easy. Pretty much what my system does. I dynamically limit the inverter’s power to my PV being generated plus an offset (which I set to 0 during rainy days).

But all in all, the system is doing what it needs to be doing - It is saving the maximum amount of money. So not really sure why the OP want to do differently. The reason I’m doing what I’m doing isn’t to save more money, it is just to manage the batteries more carefully.

Well it can, but not without extra stuff.

The philosophy in an ESS system is that we always want to keep your grid import as low as possible. It will use the battery to do it, if necessary. So that is what it is doing. It sees a load, and it feeds in energy to compensate. Up to 40%. That 40% is your backup margin.

But quite often – and I am one of those people – people want to reserve power, but still (once they know they are okay for the night), use the batteries to offset some of the loads. And that means an additional level of control that is not implemented. But… you can do it yourself, and not only that, Venus 2.90 (the next upcoming release) has a large image option that includes Node-Red. Soon, it will be possible for installers to load “flows” and customise installations to do this sort of thing.

The particular automation required here is really very simple. After a certain point in the day, you no longer want to use the external meter for ESS. It would be a really simple flow indeed.


No it cant out of the box, and you know it.

Indeed, not out of the box. And since ESS is but 15% of the market, and South Africa is a sub-percentage of that… really really hard to justify putting into the main firmware.

But… is this market based on number of units or on capital expenditure on a system? I’d think that most ESS setups are a little bit larger and more expensive than the normal off-grid setup? This might be showing my naivety…

OK, before I step on more toes. These little blue boxes are infinitely configurable, and there are requests from all over about nice to haves. Because it is so difficult to keep everyone happy, we spend a lot of time integrating opensource components so people can do it themselves. That’s why there is MQTT and modbus-tcp support to start with, but also why there is now Node-Red support, and soon (if I can find the time) HomeAssistant integration too.

Here is my challenge to anyone. Find a way to integrate your feature in a straight forward manner that doesn’t break the current design philosophy. In the current ESS design, there is no “idle” mode, and there is a reason for that: An inordinate amount of people emailing support asking “why isn’t it discharging the battery!? Why isn’t it feeding in energy!?”. You’d be surprised to learn that by far the majority of people want to discharge their batteries… :slight_smile:

And I am allergic to support.

1 Like

I think once you buy into the ESS philosophy, it does exactly what it needs to, and very elegantly at that. SA is a unique (relatively) situation where we also want security of power. So once you decide what the minimum battery level is that you are comfortable with - set your ESS min SoC and be done with it.


I do apologise for my tone though. I am in a sh*tty mood today.

1 Like

You know my blood is blue, blue and then another shade of blue, but the Big “S@#&#&k” has this as a standard setting/function. . If Victron want to stay on top, they would have to consider this.

Its so easy yo implement.

Not every customer that wants blue, tinker like us, we can not expect and pensioner to all of a sudden learn coding to have a function some other cheaper brand offers as a standard.

Here is an idea, one I have been at for years if I may add that.

Option under ESS, that at X-time, lower the inverter watts to Ywatts to a min SOC of ZZ%.
At X time tomorrow morning, set inverter watts back to nomal.

I currently do that with a Cronjob, to bypass the heavy loads early evening, and have spare throughout the night for LS.

No support involved either, RTFM. :smile:

1 Like

Implement, yes. The trouble is to make it really really obvious in the user interface, and also, the project leader has to sign off on it. I would love to do something like that, and I can use help. Options I have considered, all of which I hate, are 1) another ESS mode, 2) some kind of a switch with a really difficult label explaining what it does…

What I like about Node-Red, is that it is a standard of sorts. It was made by IBM. Lots of people know it. It is visual, you can see exactly what it does. Hobbyists love it. At the very least, I agree that effort should go in this direction first, which is what is happening.

I am also painfully aware that competitors have a feature like that. The best angle there, is tell your sales person… so that at the next distributor meeting, it comes up :slight_smile:

My understanding of the issue is the following two scenarios:

  1. Someone is sitting with full batteries at sundown, and then a bunch of heavy hitter loads come on. The inverter draws the batteries down quickly and at midnight they’ve hit min SoC and the discharge stops.
  2. The day is a little overcast, batteries are at min SoC, PV doesn’t generate enough to power the entire house (including non-backup) and charge batteries. Might get the batteries up a little, but then pulls them down quickly, ends the day at min SoC.

To make it clear, in both those scenarios, the maximum amount of energy was saved. However, the user wants the batteries to be full, if possible, by the evening, and during the evening don’t want to use them excessively.

To solve the: Don’t want to use the batteries excessively: An input called “maximum battery discharge”. Setting this to say 1000W limits the draw down of the batteries to 1000W. So the inverter is happy to invert PV generated + 1000W.
To solve the: Want to get the batteries as full as possible by evening: Well this is the awkward one. You don’t want to use the grid to do it. Maybe a toggle: PV first to batteries. Then you set the inverter’s capacity to 0 until the batteries are full (or say 80%, maybe that can be another input), and thereafter inverter’s limit is set to PV generated (obviously if the battery is full, you won’t know what that is, but allow for a 3% discharge on the batteries to see what the MPPTs can come up with). When PV drops to 0, limit inverter power to the aforementioned 1000W (or unlimited if that setting isn’t in use).

This isn’t very elegant… I hate it.

Otherwise just a simple, and expensive option: Min SoC per time of day. Then the grid would just jump in when the PV isn’t enough. I hate it more.

To do that, I run NodeRED. Yes @plonkster it is not THAT easy for a non-developer to implement.

@jykenmynie we run the max inverter power at just below max panel wattage, measured at what goes into/out of the batteries, every 30sec. That way you can a) stop draining from the bank and b) if there is ample panel wattage, increase the SOC.

In the 3rd “move”, during the day, I use NodRED to increase the SOC. If the SOC is 3.1% above the current SOC level, up it i.e. 33.1%, make it 30%, 38.1%, make it 35%, and so forth.

So, in these last two posts, I have shared the stuff I have done over the last few years, to spread the load over 24h, instead of hammering the batteries over a short period of time, or keeping it at a low SOC.

Recently, with the bad weather in Cpt, I stop NodeRED and set the inverter to like 200w, all the spare power goes towards the batteries. That is still a work in progress.

Yeah I know.

Let me perhaps explain. Jaco has been telling me that this is somewhat of a stumbling block (for customers) for some time. He is right. They end up buying something from a competitor.

But in the short term, there is no quick fix. Sorry, but it needs a good think, and personally I suck at UX design. Getting the algorithm right is no problem, in fact I designed it in the shower last night.

I suspect that even in the long term, something like Node-Red is going to be used more often than not, since there are other scenarios too. But I don’t expect that Mr. Pensioner himself is going to implement a Node-Red flow. I am actually not that stupid. No, I expect that Mr. very-good-installer will have his own add-ons that he will load on the day it is installed… maybe. I don’t know if that is good enough.

So yeah, I will write some more about this, but suffice it to say: In the original design, there wasn’t really a distinction between loads on the input and on the output. We want to keep your grid consumption low for the entire thing. Installing a grid meter (which was actually supported FIRST, before using the inverter input as zero-point!) merely moves the zero-point.

Therefore this request essentially comes down to …

Which we’ve already got… except it is a manual thing.

So that is where my thinking is right now.

Edit: And something else that occurred to me last night. If you AC-couple your PV, it gets even easier to do this. One hard part in the present setup is that the PV goes to the DC-bus… so you have to do all sorts of calculations to make sure you only take so much DC so as to not discharge the battery for the big loads, but still use the PV.

1 Like

Yes I realise the DC coupling is an issue, I had to deal with it myself, especially when the battery gets full and you don’t know how much is actually available on the MPPTs. I just reset inverter power to maximum when batteries reach X%, below X% limit again to MPPTs + offset.

Completely aside: @plonkster, you added so much value to my life with your putu recipe (krummelpap), you are excused from developing something for me for a while. We’ve been making it in the microwave ever since! Even my grandmother adopted it!

Non-essentails don’t use battery flag?

1 Like

Why don’t we brainstorm it here, even the UX?

Start off with what “missing” feature makes users opt for another brand?

Once NodeRED OS can be upgraded without any additional steps, afterward, I would move NodeRED to the Venus.

That opens the door that we could consider, here, on this forum, to have a NodeRED image created that we can fine-tune here together, that can become a defacto option, shared to all via Victron’s Community.

We have the skills to do that here, as well as the ideas.