Combination of 2 grid meters

Q&A and troubleshooting
, , , , , ,
1

Hi community,

I am currently operating the following system:
3-phase MultiPlus II 5000 + 48 kWh battery made of EVE MB31 cells with a Cerbo. A Huawei inverter with PV modules and a total capacity of 20 kWp is AC-coupled. An ET340 measures the power from the PV system, and a VM-3P75CT monitors the three grid phases.
Great system – everything is working smoothly so far.

Now to the interesting part: in front of the house connection point (in the garden) there is also a Tesla Wallbox that is connected directly to the utility meter. The VM-3P75CT is installed inside the house at the main distribution board together with the rest of the ESS system, so it does not see the Wallbox consumption (upstream) and therefore cannot compensate it via the battery.

I have already integrated the Tesla Wallbox using a dbus script and can now display it in the VRM, but of course the grid meter – and therefore the battery control – remains unaffected. As a next step, I created another dbus script to output the combined load of the VM-3P75 and the Wallbox. Unfortunately, I was not able to define this virtual sensor as a grid meter, so this attempt also failed.

Of course, the best solution would be to install the VM-3P75 directly behind the utility meter and thus upstream of both the Wallbox and the house, but there are about 60 m of garden between the driveway and the house.
Is there an alternative way to include the Wallbox in the control loop?

My idea would be a second Wi-Fi-enabled meter, such as a Shelly 3EM Pro, which only measures the Wallbox. Then a virtual grid meter that outputs the sum of the two parallel meters (Wallbox + house), and based on that the battery power would be regulated. This way, I would have a very fast, directly connected VM-3P75 for the house loads and a slower, Wi-Fi-connected Shelly 3EM for the additional Wallbox load.

Would it even be possible to define such a virtual sum sensor as an official grid meter?
Is there another alternative? I am also open to using a different Wallbox.

Thank you very much for your support.

2

Good Morning Helmut,

welcome to the community :slightly_smiling_face:

if you consider to connect an additional meter via WiFi to bridge the 60m between the Wallbox and the house … why not establishing a quality WiFi bridge between one main Victron gridmeter connected to your utility meter and the GX (home network). This would avoid all the effort with two meters and a virtual device.

You would just extend your home network to the driveway/garden for that specific purpose. Of course, WiFi is - in general - not as relieable as a wired network connection. But in your case, it does not sound like too much other WiFi traffic nearby.

Just make sure, you are not just using two simple repeaters, slowing down and destabilizing your home WiFi. Could be a dedicated clean connection on a separate unused channel.

1 Like
3

Yes, you could to that - but there are two flaws with doing that:

  • the local system will “auto-detect” the grid meter with Role “grid”. Any restart and eventual race-conditions may cause the “wrong” grid meter beeing picked up, if there are two with role “Grid”.
  • VRM will sum up Meters of type acload for the total consumption calculation. So, if you try to avoid Issue 1 by setting only your virtual meter to “grid” and the actual meter to “acload”, you’ll have wrong total consumption figures, as both meters are counted.

The only way to have a virtual grid meter working as expected, is beeing the only meter with Role “grid” and directly querying your actual two meters and building the respective sums without exposing their values as seperate meters on dbus.

I’ve just been doing that for a system (4 Buildings) with 4 individual Meters and “no access” to set up a meter at the congestion point, where the actual grid-metering should happen.

So, I added the 4 meters as service “partialmeter” (which is no existing service type, so no interference with any system mechanics) and have only 1 service evaluating these 4 meters representing the “official” meter at the congestion point of the buildings.

image
image1114×125 5.01 KB

But this ofc. Is done with native python code, not sure if it could be done otherwise.

1 Like
4

Thank you guys for the possible solutions!

I actually already have a Wi-Fi mesh access point mounted directly at the gate, and it has good connection to the main router. The only obstacle for running a cable toward the utility meter is the paved driveway. That would definitely be an alternative, but it would also involve some effort—probably the cleanest solution overall.

Dognose, your idea can most likely be implemented much faster in this case. In principle, I have already created a Python script for a virtual grid meter (voltages, frequency, and connection status are taken from the VM, while power and current are read directly from the Tesla Wall Connector on L1, L2, and L3 and then added to the VM values).

I am only failing at the attempt to reconfigure the VM-3P75 connected via VE.Can as a partial meter. Or is there some kind of blacklist in systemcalc?

At the moment, both meters are listed under com.victronenergy.grid: the virtual one as well as the physical VM via VE.Can.

5

Yeah, and that is the problem. I also didn’t manage to use the “native” meter connection (producing a com.victronenergy.grid) and avoid all symptoms of automatic usage of that values.

So, the only solution was to surpress that meter appearing naturally as .grid, handle the readout myself and pretend to be a .partialmeter service, of which the system is not aware.

Ofc, you wouldn’t need to take the route through dbus through the .partialmeter-fake-service, you could read both meters from within your single python script and generate the single .grid service, your system is supposed to see and work with.

Key here is to export the two paths from with your pyhon script: /AllowedRoles = ["grid"] and `/Role = “grid” .

In this case, all 4 meters are readable through a json-api, so I didn’t have to deal with reading serial bus-data on my own, just some aiohttp-magic and no need to rely on internal, native meter connection.

A dirty workaround could be the following: Find the piece of code responsible to read the meter naturally. Modify that file to produce values /1000.0 for power and current on dbus. (So, a 18295 W reading of the meter is logged as 18,295 W) - Your virtual meter knows that, could multiply by 1000 again - and for every other system mechanic not aware of this: +/-18W wouldn’t mess with your overall figures all too much :slight_smile:

Then, when configuring the “original meter” to type “acload”, VRM will add that to the consumption - but doesn’t really matter as pretty marginal values seen.

So, you’ll end up with something like

com.victronenergy.grid | Real Meter 1, Role=acload | Meter-Readings divided by 1000
com.victronenergy.grid | Real Meter 2, Role=acload | Meter-Readings divided by 1000
com.victronenergy.grid | Virtual Meter, Role=grid | Actual Values, knowing the other two meter-values on dbus need a *1000 again.

Just would need to be carefull around venus updates, when the original meter file is restored, no longer produces /1000 values, and your virtual grid suddenly reports 18.000 kW or sth. :stuck_out_tongue:

1 Like
6

Maybe I am misunderstanding something, but to me it seems that the VM-3P75, when connected via VE.Can, is immediately defined as a grid meter and I cannot assign it any other role. Is this handled directly at the kernel/driver level?

The ET340 that I use to measure my PV system can be assigned different roles and positions within the system, but this option seems to be missing for the VM.

At the moment, I don’t see any way to change the role of the VM afterward via script so that my virtual grid meter would take priority.

Another half-baked idea I had was, since everything is integrated into Home Assistant, to artificially set the grid setpoint to –11 kW while the vehicle is charging.

Realistically, as far as I understand it right now, I am left with two (real, updateproof) alternatives:

  1. Relatively easy: connect a Shelly 3EM as a grid meter directly at the utility meter in the garden and send the data to the Cerbo via Wi-Fi, accepting a slower control loop due to the 1 Hz data update rate. The VM would then be completely disabled.

  2. Install the VM directly at the utility meter in the garden, dig up the paved driveway again, and run an Ethernet cable to the existing Wi-Fi mesh access point. How fast would the VM be in that case?

When building the ESS, the update rate of the VM via VE.Can was the decisive factor for me. Switching now to a “slower” concept with additional effort is, of course, a weak compromise. In general, I am a complete beginner and also don’t know how fast the MultiPlus units actually regulate. However, when I switch on my sauna with a 7.2 kW load, these additional 7.2 kW are drawn from the battery within roughly 1.5 seconds, which really surprised me.

7

Alternative 3: My garage is also 50 meters away from the house, and I can’t run an Ethernet cable there because there is third-party property in between. However, I do have a three-phase power cable running between the house and the garage - like you. To connect my wallbox to my network, I installed a socket on the same phase at both the beginning and the end of the cable. I plugged a Powerline adapter into each, which provides a sufficiently stable network connection over the 55m power cable.

This way, you could install your VM (Power Meter) directly at the main connection in the garden nearby and including your wallbox. And save yourself all the other effort—provided I understood correctly and your main power connection is located at the front by the wallbox.

2 Likes