If you want to start creating endpoints to control a Victron GX device, here are some useful hints and considerations.
Obtaining the "Modbus-TCP Register List" link on this page:
A copy of this register list valid at the time of writing is also attached to this guide article, but new registers and new functionality do get added all the time.
The items of interest in the BMS context are those flagged as 'Writable' (hence able to be 'endpoints' in the BMS Digital I/O engine).
Picking the right unit unit number
Two of the most useful endpoints on a GX system are the "ESS Grid Setpoint" and the "AC PV Disable" flag.
Different models of Victron GX hardware use different unit numbers to access 'VEBus' endpoints.
The table below - extracted from the Victron MODBUS-TCP spreadsheet - shows you the choices that exist at the time of writing. The highlighted entries are the common ones - i.e. 246 for a CCGX, 242 for a Venus GX, and 227 for a Cerbo GX.
Most of the examples on this web site are based around the CCGX (unit 246). If you have a Cerbo GX or a Venus GX, just change the unit number on your BMS endpoints accordingly.
Note that you can use a unit number of '0' as a short hand for unit number 246 (for a CCGX) but that this shorthand won't work on Cerbo or Venus units, where you need to use the correct unit number for the hardware type concerned.
IP address of the GX device needs to be static
For (hopefully) obvious reasons, the IP address of the GX device needs to be stable across reboots of the GX and/or restarting of the entire site.
This can be done by manually assigning the IP address for the GX in the GX's 'Ethernet' menu, or by configuring the IP router on your site to assign a static (unchanging) IP address based on the ethernet hardware address of the GX. The hardware address can be easily viewed on the GX's 'Ethernet' menu.
The IP address for the BMS doesn't actually need to be static/manual for endpoint use, though it does need to be static if you plan to read values from the BMS into a remote system (as per Querying the Redflow BMS using MODBUS-TCP or JSON) - for the same obvious reason.
Data type must be correct (signed/unsigned)
Take special note of whether the data type is a signed or an unsigned value, and set up the endpoint accordingly.
Note also that the BMS won't let you write a negative value unless you've defined the endpoint to be a signed integer.
Debugging using the BMS
The simplest way to test a writable endpoint to a Victron GX system, once you've defined it, is to use the Tools->DIO Endpoint menu.
This allows you to choose any defined endpoint on the BMS, and attempt to write any value you'd like to try to write into that endpoint.
This either succeeds or fails - and the BMS tells you which of those occurred.
If the write succeeds but the outcome isn't what you expect - read on.
Debugging using the GX modbus output page to see what went wrong
There is a host of very helpful debugging information for this process on the Victron Energy web site, right here.
That includes how to figure out, from the GX's point of view, 'what happened' if a MODBUS-TCP write operation didn't work as expected.
Example Victron Endpoints
Here are some example endpoints that have been useful in various customer sites over time.
For each of these, you need to substitute the correct unit number (see earlier on this page) and you need to use the IP address of your GX device on your network.
Example Victron 'Rules' and 'Periodic' configurations
This Rules set turns a battery room vent fan on (for cooling) whenever the coolest battery electrolyte temperature gets above 22C, and turns the vent fans off again (so the room stays warm) when the coolest electrolyte temperature drops back below 20C:
The reason we want to keep the minimum electrolyte temperature reasonably high is to ensure that batteries that are hibernated in "SPS" mode, for later use, are always warm enough to start up and deliver power at any time.
In the system this example was drawn from, some batteries are in SPS mode and others are running normally - so the 'Run Mode' batteries are able to keep the room warm (with the fans off) as required, without any separate heating devices being needed (or wanted). Instead, the heat from normal battery operation is being put to good use.
For temperature-based Rules, the BMS maintains four distinct temperature values:
These fields render the highest and lowest observed temperatures (across all batteries), for both the ambient air and the internal electrolyte temperature sensors on the battery array the BMS is monitoring.
This Periodic entry implements AC PV automatic disabling (when off-grid) based on whether any batteries are currently capable of accepting charge. It simply pushes the current boolean value of 'Charge_Disabled' out to the endpoint in the GX that engages the AC PV Disable function.
Hence any time charge is Disabled, the AC PV in turn is Disabled: