VOLTTRON Modbus Driver Interface

This interface lets the VOLTTRON Platform Driver poll and command Modbus devices over TCP, UDP, TLS, or serial. All Modbus communication happens in the Modbus Protocol Proxy, a separate process shared by every Modbus device on the platform. The interface declares each device's registers and their data types to the proxy once, then reads and writes decoded values by address. Grouping registers into requests, padding, and value encoding are handled by the proxy.

Pre-requisite

VOLTTRON (>=11.0.0rc0) should be installed and running. Its virtual environment should be active. Information on how to install of the VOLTTRON platform can be found here

Automatically installed dependencies

• volttron-lib-base-driver >= 2.0.0rc5
• protocol-proxy-modbus >= 2.0.0rc3 (which brings pymodbus)

Documentation

More detailed documentation can be found on ReadTheDocs. The RST source of the documentation for this component is located in the "docs" directory of this repository.

Installation

1. If it is not already, install the VOLTTRON Platform Driver Agent:

   vctl install volttron-platform-driver --vip-identity platform.driver
   

2. Install the VOLTTRON Modbus Driver Library:

   poetry add --directory $VOLTTRON_HOME volttron-lib-modbus-driver
   

3. Store device and registry files for the Modbus device to the Platform Driver configuration store:

   • Create a config directory and navigate to it:

     mkdir config
     cd config
     

   • Create a file called device_name.config; it should contain a JSON object that specifies the configuration of your Modbus driver. An example of such a file is provided at the root of this project; the example file is named 'modbus_example.config'. The following JSON is an example of a modbus.config:

     {
         "driver_type": "modbus",
         "remote_config": {
             "device_address": "10.0.0.4",
             "port": 502,
             "unit_id": 1
         },
         "registry_config": "config://modbus.csv",
         "interval": 15,
         "timezone": "US/Pacific"
     }
     

     The legacy key driver_config is accepted in place of remote_config.

   • Create another file called device_name.csv; it should contain all the points on the device that you want published to VOLTTRON. An example of such a CSV file is provided at the root of this project; the example CSV file is named 'modbus_example_registry.csv'. The following CSV file is an example:

     Volttron Point Name,Units,Writable,Point Address,Modbus Register,Table,Default Value,Notes
     ReturnAirCO2,PPM,FALSE,1001,>f,input,,CO2 reading
     CO2Stpt,PPM,TRUE,1003,>f,holding,1000,Setpoint
     UnitName,,TRUE,1005,string[6],holding,,Unit name
     reserved,,FALSE,1008,pad[2],holding,,Read through but never published
     Mode,,TRUE,1010,uint16,holding,,Operating mode
     FanStatus,,FALSE,3,bool,discrete_input,,Fan proof
     FanCmd,,TRUE,5,bool,coil,,Fan command
     

   • Add the Modbus driver config and CSV file to the Platform Driver configuration store:

     vctl config store platform.driver modbus.csv modbus.csv --csv
     vctl config store platform.driver devices/campus/building/modbus modbus.config
     

4. Observe Data

   To see data being published to the bus, install a Listener Agent:

   vctl install volttron-listener --start
   

   Once installed, you should see the data being published by viewing the Volttron logs file that was created in step 2. To watch the logs, open a separate terminal and run the following command:

   tail -f <path to folder containing volttron.log>/volttron.log
   

Configuration reference

Device configuration (remote_config)

Registry columns

modbus_tk configurations

The modbus_tk driver split a device between a registry (Volttron Point Name, Register Name) and a register map named by register_map in the device configuration (Register Name, Address, Type, Units, Writable, and optionally Default Value, Table, Mixed Endian, Description). Such configurations work unchanged. Rows that already carry an address and a data type are used as they are, so the map is only consulted for rows that need it. Where a registry row and its map row both supply a field, the registry row wins; blank registry cells do not override the map. A row that lacks an address or type and has no matching Register Name in the map is dropped with a warning and the rest of the device is configured. A map file may also be used directly as the registry: each row is then published under its Register Name.

Pad registers

A row whose data type is pad (or pad[n]) declares registers to read but never publish. Use pads to bridge gaps between points so that they are fetched in one request. Pad rows must name their Table. They are not points: the platform will not poll or publish them, and they do not appear in the device's topics.

Requests per poll

When the device registers with the proxy, the driver logs, per table, how many points and pads were configured and how many requests each poll will take. Adjust pads and max_gap to reduce that number.

Testing

pytest tests

The unit tests run against a fake proxy manager. tests/test_end_to_end.py additionally launches a real Modbus proxy process and a pymodbus TCP simulator on a free local port; it needs no hardware.

tests/test_driver_local.py goes one level further: it starts a real VOLTTRON platform in a temporary home, installs the Platform Driver, configures this driver against a local modbus_tk server, and reads and writes every struct data type in both byte orders through vdrv. It takes a few minutes, mostly platform start-up. Set MODBUS_SKIP_PLATFORM_TESTS=1 to skip it. tests/test_driver_demo_board.py runs the same flow against real hardware when MODBUS_TEST_IP is set.

Development

Please see the following for contributing guidelines contributing.

Please see the following helpful guide about developing modular VOLTTRON agents

Disclaimer Notice

This material was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the United States Department of Energy, nor Battelle, nor any of their employees, nor any jurisdiction or organization that has cooperated in the development of these materials, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness or any information, apparatus, product, software, or process disclosed, or represents that its use would not infringe privately owned rights.

Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government or any agency thereof, or Battelle Memorial Institute. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof.