We want to make interfaces with various PV-inverter factories and we prefer to do this with Node-Red, due to its flexibility. Some PV-inverter can connect with modbus (RTU or TCP) others with RS232. So Node-Red is the best way to go.
We found a way to create a Dbus instance via websocket, but some more has to be done to integrate this in the total VRM picture.
We are aware of the various python scripts available, but that is not the direction we to go.
In order to facilitate the connection between Victron with thirdparty equipment for monitoring AND controlling the following protocols may come accross;
REST API
Maintain an JSON connection e.d. Enphase gateway, APSystems Gateway, Tesla Powerwall and gateway, Shelly relays and energy measurement.
Modbus RTU RS485 e.g. Carlo Gavazzi, Growatt, GoodWe, Huawei, Deye (some SunSpec compliant).
Modbus TCP e.g. SolarEdge, SMA, Fronius, ABB, Carlo Gavazzius (some SunSpec compliant)
OCPP an JSON variation to monitor & control EV Chargers
MQTT message queing to equipment.
RRCR relay contract for limiting the power (PV inverters mainly)
Making a Node-red flow with one of the above protocols is not very difficult but connecting that to the Victron environment is an other story.
We realize that it would be undoable for Victron to implement an interface for all PV interters, EV chargers, energymeters and other equipment, therefor our request for an Dbus service entry in Node-red seams the only logical way.
Thanks hominidae,
We are aware of the various python scripts and possibilities. But what happens when there is a new software update or the python versions is upgraded? Do we have to physically visit our 100+ sites to update the cerbo’s with an SSH connection? We urge a sustainable solution from Victron. Making a connection with thirdparty equipment is one of the main issues at the moment. Especially with the rapidly changing energy market where there are demands to limit our PV power or charging your EV on specific times or conditions. If we were looking for an one-off solution the MQTT would be fine.
That script mentioned, will stay / update itself after a VenusOS update.
I agree, hence I already suggested that victron will incorporate the functionality from that device driver into the mainline development / features of VenusOS themselves as I think that driver will offer a lot of flexibility.
I checked my memmoires and the MQTT solution is monitoring only and we want specifically the control. Like an Fronius connection the only PV inverter that is fully integrated. Monitor AND control. Victron can limit the power or even shutdown the PV. That is what you want for PV and EV.
Would be nice if Victron incorporate the MQTT functionallity and hopefully change the controlling bit too.
Hmmm, well yes…You cannot always get what you want, can you?
maybe one thing at a time…Implementing a standard control/cmd pattern via mqtt is not that hard either.
After all, your Node-Red implementation has to convert it into the individual “language” of the remote device in question.
imho it is much more important to support some standards than every individual textfile or mqtt message.
Means: sunspec. even if it is not implementet perfectly, or via a RTU-> TCP bridge.
So simply make ONE small change: If an IP address is added manually (as it can be done now) for sunspec Inverters, just read the registers. Thats all.
[For energy meters: support for the 3Pase Shellys would be nice, but on the other hand the victron meters are not much more expensive. so this is just a nice to have for allready shelly users]