Unexplainable Grid to Consumption at night - not comnsumed from Battery

Hi!

I have observed this strange behavior that my Victron Multi Plus 5000 setup was during the night all of a sudden consuming Power from the grid twice.

Here the screenshot from VRM:

where you can see that between 1 and 2 am there was about 0.32kWh of consumption that is not really explainable - no real peaks or anything.

I also looked at home assistant graphs and found this between 0:00 and 3:00:

where you can see that there are to windows of consumption from the grid:
01:04 - 01:22
and
01:37 to 02:01

You also see that while there was this spike the load of the battery was reduced from -11.5A to -2.4A.

Any ideas why this could have happened?
How can I avoid something like this in the future?

Thanks

Has something like this been seen before?

From the screenshots i presume you run DESS? Looks like DESS calculated it needed to use the grid to get to the desired SOC. Why that was the desired SOC? Depends on your prices and settings in DESS.

Yes - I have enabled DESS but as I am at this moment self efficient this should not happen - and the buy price was definitely not the cheapest (2-3am was slightly cheaper - not to mention around noon)

Also what is suspicious to me is the fact that it was twic for 20 minutes - if it had been for 15 minutes or 1 hour I could probably under stand it!

As for Soc: it was at that time between 74 and 78%.

So I wonder why DESS would come up with the idea of not charging the battery (but just taking less from the battery for those intervals.

Are there any logs on the GX device that could help understand this? If so which ones?

Dess does not know that and apparently calculated differently.

DESS adjusts to get back on track for the running hour, this takes however long it takes, not 15 or 60 minutes.

So probably target SOC was 78%

I’ve observed this behaviour frequently, hopefully it will get better with time. For the moment it’s annoying but not a dealbreaker for me.

Well - I am still getting my feet wet with DESS but I find this behaviour annoing (and an unnecessary waste of money).

It actually happened this morning again - at the highest local price to buy from the grid!

With the battery at 61-62% (as per VRM for that time)

The effective Power cost (including Gird and taxes): 0.10Eu.

Which is minimal but it would sum up in the long run!

Right now I start to think how to do DESS without using DESS as an alternative.

Some hints on which logs on my GX/VenusOS device would explain the behaviour of DESS would also be appreciated!

I agree, but i fail to find a better system that works out of the box.

Seeing you use home assistant maybe this thread can be of help. That way you can log what the DESS strategy is in home assistant.

1 Like

Thanks for that link!

I already got an MQTT server in my setup (for other sensors) and adding an additional one is not supported - only possibility would be replicating from the Venus MQTT server…

MQTT Servers can be bridged.

I have done this with mosquitto on my Homeassistant server.

Thanks - yes I have tried that and now I am using the ha plug-in victron_mqtt that I am now helping to improve to get all the DESS values into HomeAssistant! - and yes: also soon hopefully all the schedule values of DESS!

Unfortunately the behavior still persists on a general principle:

  • battery has sufficient SOc left (> 35%)
  • But DESS decides to use Grid over Battery
  • On the other hand: in the same hour it does deliver power to the grid from the battery

Net consequence is that I have to pay more than necessary - and battery costs are negligible (0.04Eu) compared to Grid cost (0.25Eu)

This did not happen with DESS disabled!

Here what it looks like zoomed in into HomeAssistant:

Blue (without text) is: self consume increased discharge!

My interpretation is that DESS has in its plan a (lower?) SOC target and when it reaches that because of some energy getting used, then it falls back to grid (to maintain Target SOC) even if there is no need…

Here some more details:

The trigger was the boiler heating up water…

But see now also SOC currents for each phase on AC out, power of boiler as well as power drawn from battery

Also visible the SOC limits that are not the ones specific to the DESS schedule.

Why DESS would switch to idle- maintain SOC is the big question!

So here now with DESS target SOC and minimum SOC:


So the target Soc makes huge jumps and it is not obvious why DESS is setting this up as is.

It is not a lot of money, but it is 0.20 Eu that I have lost today so far - mostly due to the high consumption peaks.

Can maybe someone from Victron give an explanation why something like this is happening?

Here the same again a bit later (now with power for out and battery)


Based on latest venusOS 3.64.

Graphing/presentation via HomeAssistant with the victron_mqtt integration.

Would you like to share your VRM DESS settings?
Which device provides the Cerbo the SOC?

What i find helpful sometimes is to also read Venus OS beta posts.
Sometimes there are insights to system behavior or other hints or tips.
It seems since the latest beta update two users stated that with DESS Trading the self consumption was managed better.

Setup:

  • Ekrano GX with 3.64
  • 3 Multi Plus 48/5000
  • 2 MPPT RS 450/100 (but as at Night: not relevant)
  • Victron Grid meter (3P75)
  • 4 Pytes e-box v5 - total 20kWh - providing SOC value as part of BMS
  • Reading Power directly from Grid provider grid meter via m-bus - 7s intervals (that is only integrated with home assistant)

You are right the DC to DC converter is Not relevant in the night time.

DESS has trouble with peak usage as you have noticed when there are heavier loads switched on at different time intervals it cant know about up front.

Here the heat pump boiler every day runs on the same time. But if the airconditioners are running more than expected at night, DESS has some small grid usages, to keep up with the trading plan for that moment. It should be a bit more flexibel in these cases I think.

Sometimes when there is more capacity left in storage for the morning hours export, than there is no grid usage at night, at least I did not notice. But DESS is really good and the overall Victron experience with VRM is outstanding. So I don’t know if sometimes a 40cents is that big of an issue to make a fuss over it.

Just using it without DESS and do some node red and try your own systematic, you wil notice how hard it is the more you try to dive into the matter. I tried and it cost a lot of time, I gave up because DESS is doing a great job, at least for my system it is.

Just curious about your DESS Settings?
perhaps you can also take a peek at the SOC data graph under advanced in VRM?

Often the SOC from the BMS is not that accurate, having percentage jumps. But I don’t know about the Pytess BMS.

I use a Victron Shunt for my system and also noticed these grid usages sometimes though very small, it does not irritate me with trading.

The Victron Shunt is very precise managing 90kWh (next month 150kWh) storage. I use 3 multiplus 8000 and at the beginning playing with DESS was not that satisfying at all. It irritated me also that it had used grid at night and every 60cents. Playing with the price settings and observe can give some insights too.

I use the latest Venus OS beta and at the moment I am very happy with DESS trading. With the VRM database issues last week it missed some peak price for selling but it is what it is. An outage can occur also on the internet Connection and so on.

@Ersus : what I find unexplainable is that at night DESS is running without any SOC target (=0)
but when something unexpected is kicking in for a short period (hot water boiler running 10min) of time then it changes its idea and starts to increase the Target SOC all of a sudden!

Timeline:

  • 6:00: battery discarging to grid and handling all the energy needs of the house
    • SOC: 70%
    • target SOC: 61%
    • reactive Strategy: “scheduled minimum discarge”
  • 6:02:43: Quooker water heater kicks in for about 30 seconds (making some tea)
  • 6:04:30: Boiler kicks in and runs until 6:11:40 (showering)
  • 6:06:17: DESS switches to:
    • Target SOC: 68%
    • reactive strategy: Self Consume increased discarge
    • SOC is: 69.5
  • 6:10:58: DESS switches to:
    • Target SOC: 68
    • reactive strategy: Idle maintain Target SOC
    • SOC is 69
  • 06:11:04: Power is coming from GRID at 2200W
    • Battery is still discharging at 2391W
  • 06:11:27 SOC Reaches 68%
  • 06:11:39 Battery draining drops to close to 0 Grid consumption drops to 400W (a ramp down)
    • from then on battery is sligthly charging and GRID consumption at arround 400W
  • 06:15:03 DESS changes to:
    • reactive strategy: Schedule minimum discharge
    • Target SOC: 66%
    • SOC: 68%
    • Battery consumption increases
    • Grid consumption 0W

I understand that the DESS is complex.
But this scenario is simple enough and in the end this switch of reactive state and increase in Target SOC needs to get investigated - something is going wrong there!

For what it is worth - why would it decide to increase Target SOC? Maybe Solar Power was just starting to kick in a little - but definitely not at above 200W…

and if you look instead at yesterday evening (earlier post):
There the Target SOC was 0 and all of a sudden changes to a high value close to existing SOC.
And then again it drops to Target SOC of 0.

Something is not right there and victron should have an explanation why this is happening.

unfortunately there are no logs (taht I know of) that one could look at locally to find some motivation why DESS would be deciding on such a plan change.

maybe logging those would at least give an indication why…

1 Like

here the behaviour since yesterday evening

also including Batttery Power and (total) Solar Power

those jumps at target SOC ans strategy changes are what is strange.

And why there would not be a target SOC for most of the night, but then starting at 4am?

I dont use Homeassistant for Victron readouts.

You see that the DESS SOC Schedule is zero when ‘Self consume’ is Prioritized. Perhaps this is wanted so the system wont interact with the ‘Self consume’?

Hi,

Which version of venus OS you are running?

From your screenshots, I can see, that the gx went into Idle_maintain_target_soc during pro grid. This happens, when your system reaches the calculated target soc too early. (That can have many reasons)

However, the cut there is “too hard”, so in the current betas, this has been fixed. If this situation appears, the reactive strategy would be “Selfconsume_accept_bellow_tsoc” and just continue to drive loads rather than idling - accepting that soc goes bellow target soc and let the scheduler make the best out of it :wink:

So, you can either try the beta, or wait for the next official release.

1 Like