Hi, I have 3xMultiplus ii 48/10000 off grid powered by 80kWh batteries. Off grid because UK DNO paranoid about connecting “generators” to the grid, even with zero export configured. They would only let me charge the batteries with ex-Telco PSUs I got off eBay (9xMean Well rack mounted to get 18kW charging capacity). Even then the DNO required that I get Mean Well to supply the actual test data for the chargers so they could check the sum of the harmonic distortion for having 9 class A devices in parallel. Crazy.
Anyway, it all works fine, my question is regarding the VRM display for my setup. I have FIT solar on the grid side and I maintan net zero feed in by controlling the chargers power output through node red on the Cerbo talking to node red on a Rasperry Pi with I2C connection to the Mean Well racks. Does the job, but I was not seeing the solar power generation on VRM so I added a virtual PV node, feeding it the power being consumed by the charger. So now I have the PV measured but unfortunately it doubles my consumption figure because VRM sees the power being generated but not going into the batteries and assumes it is AC load rather than battery charging. The obvious solution would be to have a virtual charger as well. Do you have plans to add charger to the list of virtual devices? Alternatively, are there values I can write over MPPT that will get VRM to recognize the solar power is going into the batteries?
I created (modified) an additional service (driver) on my Venus OS which gets its values (state, voltage, current) via nodered. Basically the values are simply written to the dbus by any method of your choice. A startup script recreates the link at every reboot. It survives updates of the Venus OS (provides it is being stored in the data folder).
Thanks for the suggestion Frank. I could take your approach, but I would really prefer not to mess around too much with the Venus Large installation. At the moment everything is vanilla. I realize that adding startup scripts and running python devices from the data folder should not be destabilizing, but I guess this is really what Victron are trying to avoid with the Node Red virtual devices. It will be good if we can persuade them to add the virtual device types needed for common scenarios. There must be a lot of people using third party chargers to get round the prohibitions on direct grid connection of large Multiplus configurations.
Regards
I’d like that too but there seems to be no plan nor interest to add one, not by Victron anyway. As a workaround I use a BMV Smartshunt as DC System to measure the DC side of a sortlike chargerbank, then feed the power thereof (efficiency corrected 1/0.94) to a virtual pvinverter (negatively) which corrects the AC power side (looks a bit strange in VRM but the charge power does not count toward the AC consumption, nor to any solar production (because: negative power). This works correct enough for DESS not to touch the VenusOS filesystem. But yeah, obviously a virtual AC/DC charger device would be great.
The BMV as DC System monitors the charge bank and a secondary inverter (semi-island regular household loads, gotto keep selling to grid at max power) During charging you’d see the solar yield subtract AC energy to keep the AC Grid and AC Load values correct.
Alright, I can help you. It would be great if you had WinSCP to access the file system of Venus OS directly and a decent editor like Nodepad++.
Since I did this quickly, the resulting code probably isn’t very pretty. Feel free to improve it. However, it’s working for me.
Unpack the zip. In order not to have to change paths unpack to /data/drivers/ (resulting in subfolder “venus.charger.custom”) and make the “venus.charger.py” as well as the “run” files both in service and in log subfolders executable.
Open venus.charger.py and modify line 22 (productname and connection) and in line 37 to whatever you want as well as line 82 (desired name on dbus) and, if necessary, device instance at line 83 (to avoid conflicts if the address is already in use by another charger).
Possible official dbus paths (starting at line 85) see venus Wiki (you can also create custom paths but those won’t appear on VRM or Remote Console). The paths can be fed by nodered (MQTT).
In order to start the service you need to create a link to the /service folder:
Thanks, this is great. I’m thinking about combining this with another project: Setting up a secondary rPi/VenusOS_large instance on local lan (save for mirroring D-BUS over unencrypted TCP) to externalize Node-RED flow development away from the operational MP-II GX. No worries about ssh/scp/editors etc but thanks for the concise instructions and offer to help. I’ll report back.
