I would really like to be able to exclude specific acload from beeing counted as consumtion (or even be counted as acload).
The reason is that I have an additional charger in parallell with MPII and when charging it is counted as acload and consumption. When the charged energy is used from the battery, it is counted as consumption again.
I have a power meter for the addidional charger so in Node Red I know the power. I would like to subtract this from the actual acload/consumption.
In Node Red it does not seem to have any effect when trying to edit the consumption.
No from what I understand this is coded into the firmware of the Victron devices, and requires to be fixed in firmware. I made an Feature Request for this but I guess this has low priority.
I have exactly the same issue and have trying to find a workaround to this with node-red but with little success. See also some of my other posts. The best I have managed to do is as follows:
Measure the charge current with a bmv-712 set to ādc-systemā
Setup a virtual device as āpv-inverterā on ac-out
Use custom controls and functions to populate frequency, ac voltage, power (corrected for 96% efficiency) and a calculated ac current into the pv-inverter
The results is that the gauges in VRM and gui-v2 show ac charge power (as negative pv-inverter power) separate from ac loads.
But in the history the charge energy is still added to the ac consumption.
Quite frustrating to be honest. All the ingredients are there, as well as many ways to use internal as well as external power/current meters and node-red to link them up but I could not find any way to make the system aware that the ac energy used was actually fed right back into the battery.
Also I use the BMV relay to switch the charger on/off based on ac-in setpoint, that takes some special precautions to have all the DESS settings correct but then that works quite well.
If @lxonline is interested I can provide the node-red flows, Iām a bit hesitant to share publicly as it is still āin workā and cluttered.
My understanding now is that it will require either a new virtual device type in node-red and/or a new device type in the BMV firmware or both.
Even though that might seem a big ask to the Victron dev team, all the software functions required are already there in the BMV ( solar / ac-charger / dc-system) and node-red virtual devices (pv-inverter or other ac loads). It would only take recombining those to reflect an actual ac-dc charger. The use case has obvious very practical value so I hope they will consider to give it some attention and priority.
This is still under development, as you say the potential is there now.
Part of the issue is balancing making it not too complicated (or without great possibilities for mix up) for most end users and still having the toys for others.
Well, those willing to dig into node-red hacking virtual devices together to build high capacity energy trade systems already have plenty opportunity to make the system do a ārapid unplanned disassemblyā, if so inclined.
The most āelegantā solution in my opinion would be for the devs to add a āvirtual (dumb) multiplusā to the node-red library. It only takes two inputs: delta AC-current and delta DC-current (or power equivalent), that does precisely that (and only that): add or subtract current (power) from the energy flow from AC to DC and back of the actual multiplus. Then it doesnāt matter anymore which devices are used to feed those inputs with actual or derived values from any available ac and DC meters and/or (known) efficiency curves and a single meter.
But maybe that hits a bit ātoo close to homeā as one could imagine Victron rather just be selling additional multiplusses for that use case.
I was on Venus 3.67 and upgraded to latest beta now (3.70 beta 61). I can see there are updates on the virtual devices in Node Red but unfortunately no āvirtual chargerā.
I have been using the ānegative power virtual pv inverterā to subtract ac loads reliably on v3.7 and v3.8 beta. See post above. This corrects both AC out as well as the historical loads records. Only drawback as far as I am aware of (if you find it a drawback at all) is that the subtracted ac load still gets displayed as grid to consumption, even though it isnāt recorded as such. The loads prediction in VRM/ DESS will correctly disregard this negative AC pv production and not count it as AC load.
The actual AC charge power / energy in the last picture is 7.97kWh (via HF chargebank) plus 0.53kWh (MP-II topping up to set AC current limit ~ 37.5A actual when set to 40A limit, donāt know why but not bothered by it either) gives 8.5kW charge power.
And (in this single phase setup at least) the MP-II correctly protects the mains fuse when other real loads are switched on by delivering (inverting) the required power for them, no need for an additional (fast) control loop to reduce the HF charge power, unless you wish to prevent the temporarily double conversion AC DC AC efficiency loss.
The only caveat / issue I ran into in over a year is that under special circumstances, when manually setting MinimumSoc above the current battery SoC to force a full power charge run, I have seen the MP-II go into passthrough mode when the HF bank already fully draws the set AC current limit. This then disables the above mentioned mains fuse protection should another load switch on at the exact same moment. I believe that had to do with a bug in one of the v3.7 beta version that has since been fixed. It can easily be avoided by lowering the HF current a bit to let the MP-II carry more of the total charge power. Or not drawing large AC loads during full power charge runs. We actually run most (light/ house) AC loads from a secondary 3kW HF DC to AC inverter anyway, primarily to allow maximum feed-in power during sell runs, and wait with heavy (3kW+) loads until prices are too low to sell.
For all practical purposes, this works like a charm, did not blow the mains fuse, yet, hahaha.
