question

pedaaa avatar image
pedaaa asked

external (non-Victron) Wallbox - VRM integration ?

Hello,

is there any simple or ready solution available, to implement external (non-Victron) Wallbox EV Chargers into the VRM layout?!

I assume most of these support e.g. Modbus TCP. But i have not seen any of such integration yet.


All i know of, is this GO-E integration, but this is using REST-API

https://community.victronenergy.com/questions/128552/go-echarger-integration-in-venus-os.html


Isnt there more demand for that?

i would love to use the original Victron EV-Charger, but it is not compatible for company cars using RFID cards.

So i am forced to use an external Wallbox.


wallbox#vrm
2 |3000

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

3 Answers
matt1309 avatar image
matt1309 answered ·

Hi @Pedaaa

I'm surprised there's not a go to community made one.

However victron's EVCS is controlled via modbus server running on EVCS. So in theory you could maybe just edit the scripts used for the actual victron ev charger. To align with the modbus addresses of your evcs....


So just change the relevant modbus addresses. (You can see the script on your gx device saved in /opt/victornenergy/dbus-modbus-client/ev_charger.py

II would say maybe copy it and rename the new one to custom_ev_charger.py
Rename the classes in the file also as well as updating modbus addresses and model names/handlers and then #include the new custom_ev_charger.py file in the dbus-modbus-client.py. (Note this wont persist if you update gx device. You'll need to make a script saved in /data that makes these changes for you if you want this to keep working after updating gx without needing to repeat the process)


However I think if you get the models setup right the scripts are written in a way that they seem to do all the heavy lifting from there/once you've got the addresses/status codes updated etc.

The github page is here if you'd rather use that than copy the ev_charger.py from your gx device:

https://github.com/victronenergy/dbus-modbus-client/tree/master


I'm happy to try help where i can, I'm not a python dev though. However hopefully it's just a case of changing the register addresses/status codes and models map at the bottom.



2 |3000

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

pedaaa avatar image
pedaaa answered ·

Hi Matt,


thank you, that is super useful. I will read your Github-Links in Detail, and hope its possible.

The EV-Charger parameters does not look that much, maybe the different status-stages could be a challange... but lets see. I try my best.

Still, i am really surprised, nobody did or tried this before?


2 |3000

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

matt1309 avatar image
matt1309 answered ·

Hi @Pedaaa

I did think about it a fair bit so happy to help with any bits but you're right it does look surprisingly doable.

Dont think it would be a massive task to even get RTU implemented as well as TCP. Could use the abb.py as an example for that.


The hardest issue i could think of would be if the registers are of different types ie floats rather than uints. Might just need to defined a new function like in register.py.

Other than that it should be all in one file and then just then

import custom_ev_charger.py in the dbus-modbus-client.py


I suppose you could spoof the status-stages functionality if there's no way around it for you.

ie rather than writing something from modbus you just write a value to that dbus path manually once and then leave it. Assuming you dont need that functionality.

2 |3000

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

Related Resources

Additional resources still need to be added for this topic