Oxy- avatar image

Bug report: VRM consumption calculations are incorrect when using non-victron charge sources


I noticed that consumption in VRM "System overview" dashboard graphs and widgets are always way smaller than they should be. I think I got to the cause of it, hence this report and ask for a fix.

Below in red rectangle you can see how it has been for months - consumption always shown lower than it was. Then I started playing with the settings and got it to show up more or less right - in green rectangle you can see how the consumption is in reality.

As you can see in "Jun 18", discrepancy is about two times! So what's the reason?

There are various DC chargers in this system, of which mainly two of them generate the bulk of energy:

  1. Non-Victron solar charger 80A
  2. Victron solar charger 85A

In order to see all the chargers conveniently in the "Remote Console", I have had "Has DC System" enabled. Then I see all chargers summed up in "DC Power" box. If the value is negative there, it means "DC System" is charging and all is great! At least you would think so.

However, what you can see in the picture above, is that VRM on the left shows very tiny consumption (224 W) compared to the real one (1395 W AC). There is some time lag between these two screens, but I noticed that essentially VRM takes AC consumption and adds DC Power. So, if you have any external chargers (like non-Victron solar, wind or even a generator with DC charger), "DC Power" shows as negative and VRM just blindly deducts that charging power from the consumption.

As soon as I turn off "Has DC System", the consumption shows up more or less correctly:

This is very inconvenient, because if you have any non-Victron charger and disable "Has DC System" in favour of correct VRM consumption, you can't see it in Remote Console view.

What's the possible real fix? VRM should only add "DC Power" to the consumption if it is positive, but ignore the value if it is negative (in other words, when DC system is charging as opposed to consuming).

Would someone from Victron step up to address this? As it stands right now, the system is not capable to deal with heterogeneous setup :-(

Finally, one more related bug in VRM's "Consumption" dashboard even with the disabled "Has DC System":

Here you can see that half of the energy is said to be used "from battery", which is just wrong. All that blue energy was generated by the mentioned non-Victron charger. What's worrying here, is that this system has a BMV which knows exactly how much went out of the battery (and in this case it was 0.0Ah), but VRM is using some kind of convoluted formula to get these numbers as opposed to using data from BMV.

It would be really great if this use case with not only Victron chargers be addressed, because as it stands right now, the whole VRM Dashboard tab is just disinformation.

Thank you in advance!

BMV Battery MonitorVRMvrm remote console
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

4 Answers
steffend avatar image
steffend answered ·

I'm having a similar problem with the VRM Portal when running a Phoenix Inverter while having the DC System option enabled (as there are DC loads too!). I thought having only Victron products in the system would allow this to work, but as you can see here (Has DC System - Incorrect Consumption in VRM when Phoenix Inverte...) the VRM Portal just adds DC and AC Power, which is wrong in this case.

Could someone from Victron comment on this (@mvader (Victron Energy))? I think there should be an option to mark that the inverter itself is included in the DC load and have VRM not adding these values (the AC measurements of the small Phoenix inverters are very inaccurate anyway).

10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Jeroen avatar image
Jeroen answered ·

It is impossible to make this work properly if we don't have the information from the additional chargers. Just a simple example, suppose you have a MPPT we are not aware of and a DC load which consumes all it generated power, then obviously you are generating energy and self using it. The BMV will see nothing of that since it is not going into the battery.

10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

osaether avatar image
osaether answered ·

I have a Tristar MPPT controller that I have made a Venus module for. The charging current, power and so on is reported correctly in VRM but the Consumption shown on VRM is wrong. In the screenshots below I have an AC load of around 350W (on my Phoenix Inverter) and in addition I have a DC load of around 15W from internet routers, Venus GX and so on. The solar panels are generating around 550W in the screenshot but the Consumption (behind the remote console) is shown as 774W.

I took another screenshot 5mins later to show the block view in the remote console. Here we can see a DC power of 430W that should not be there. I guess this is because VRM takes the PV power and subtracts the difference in power into the batteries: 546W - 116W = 430W without taking the power drawn from the Phoenix Inverter into the equation.

I am using Venus GX with Venus v2.32.

Can you comment on this @mvader (Victron Energy Staff) ?

vrm-consump2.jpg (66.6 KiB)
vrm-consump1.jpg (77.9 KiB)
3 comments Share
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

I checked again after sunset and it is clear that VRM or Venus is calculating the DC power incorrectly. In this case the DC power should be the battery power minus the AC power:
386W - 322W = 64W

vrm-consump3.jpg (68.5 KiB)

Hi @osaether

Would you share how you have made this module? I’m curious if it would be possible to implement such for Outback MPPT. I guess you’re sending data to Venus per VE.Can, but how are you getting that data from the Tristar itself?


Hi @Oxy- I am getting the data from the Tristar MPPT via Modubus TCP. The Tristar MPPT has an ethernet connection and is connected to the same network as the Venus GX.

The source code can be found here:

mvader (Victron Energy) avatar image
mvader (Victron Energy) answered ·

Hi @Oxy-, all calculations for those graphs in VRM depend in reading energy meter data from the solar chargers.

Which the system can’t in this situation.

There are perhaps/probably other solutions, but making those is not a priority on our side. Sorry.

See the VRM FAQ for an accurate description of what works and what does not work wrt those kWh graphs.

10 comments Share
10 |3000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Sorry, but VRM FAQ is not accurate. Here is one very specific example which describes the system in this post as if it would work:

FAQ> The calculated value for 'DC Power' is not used in any way by the GX, beyond just being displayed 'on screen'. In particular it is not logged on the VRM portal and it is not included in system calculation and it does not appear as part of the recorded Solar Yield.

In reality, we see that DC Power and whether “Has DC System” is enabled or not does make an impact to VRM calculations.

Hi, yes; I checked; and enabling or disabling the has dc systems makes a difference. I can't easily see what and why there is a difference; I've added it on the todo list for Venus OS.

But the actual power reported as DC Power is not used in the calculations. That I know for sure.

Thank you for bringing this up.

Thinking about current VRM architecture further, I had one thought.

In my case, the non-Victron charger goes through its own Victron BMV, which then gets displayed nicely in the Device List of the Remote Console in GX. You can see amperage and wattage that it is generating.

At the same time FAQ states:

> When one or more non-Victron solar chargers are used, the system cannot read their Energy yields, and because of that the resulting overviews are incorrect and unreliable.

Hence, would it be possible to make VRM understand non-main BMVs as other chargers? It would make VRM flexible, as it could monitor wind generators, gensets which do not work with Multi/Quattro (my case) and legacy non-Victron solar chargers.

In other words, it would transform VRM from “green field” capable tool only to a truly versatile solution, and by doing there would be bigger demand for BMVs.

Hi Oxy, yes, I agree. This would be a nice solution. Its already on the wish list (for quite some time). Some day!

Oxy- avatar image Oxy- mvader (Victron Energy) ♦♦ ·

Some of your software is open-source, right? I suggest you adapt the usual open-source model with Pull Requests, people like me could contribute with code to implement things that are pressing quickly. Assuming you can assign a few code maintainers to review the PRs, it's a win-win model and allows the community to participate. GitHub works quite well for this.

Hi, have you already seen this, and all information behind it?

Oxy- avatar image Oxy- mvader (Victron Energy) ♦♦ ·

You see, your current approach and process is not open-source till the end:

1. You don’t have a way of accepting contributions (unless I missed it), so even if someone codes an improvement the user will lose it with next firmware upgrade.

2. VRM is not open-source at all, so it’s impossible to fix this particular bug.

You could fix (1) fairly easily - just need to establish a process and assign a maintainer for reviewing Pull Requests.

While (2) may be not do trivial, because you may not want to open-source all of VRM. The way to do it is to modulize it and add ability to code and plugin custom modules. For instance, the way you calculate consumption totals could just be a small changeable open-source module, so people could adapt it for any non-green-field installation.

Hi Oxy,

Indeed, its not open source till the end. We can't (and will not) fully open source Venus OS for a few different reasons. But for the parts that are, there is nothing stopping you from putting in pull requests; or discussing your plans with us on the different fora.

To submit contributions: use the github pull request feature. Or, as advised on the Venus OS wiki, first discuss your plans on the mailing list or Modifications space on Community.

Btw, there is no need to anyone to lose their changes; even if we were not to accept the change, we have made some hooks that you can use to automatically re-install or run your changes at boot.

For parts not open source: you can always explain what you are after and ask for access.

Do be aware that Venus OS is not a simple platform; and has to work for many different systems. So in many cases, when someone fixes an issue for himself; or makes for an improvement for his system; then there is still quite some work to do (which then falls upon us mostly) to make sure it doesn't break something in any other of the many different product configurations and combinations.

Wrt 2, VRM: yes that would be real nice. But, for what I've seen the last years, the investment we will need to make for that, and increased complexity to deal with afterwards, does not weigh up to the amount of people that will be using it. My opinion is that we can better do other things.

But there are still options for you, to make a different VRM while still taking advantage of whats already available: you could use the API and make your own website.

And the other is the grafana docker solution; did you see that?

Have a good day, Matthijs

Show more comments