MODBUS RS485 reader

[jnahorniak]

We have a need for a MODBUS RS485 reader to support an existing met mast data feed.

I am planning to copy the existing MODBUS TCP reader and modify it for RS485 use. If this seems like something that would be useful to have in the main repo, let me know and I'd be happy to send you whatever I come up with!

[davidpablocohn]

Thanks, Jasmine! Back in January, we added some changes to PolledSerialReader to handle an RS485 loop (#411). I'd love to have an equivalent using MODBUS. I don't actually *understand* MODBUS TCP (there's *so* much I don't understand!), but I'd be grateful if we could keep the calling conventions compatible, or even leverage existing code.

…

On Mon, Dec 8, 2025 at 9:05 AM Jasmine ***@***.***> wrote: *jnahorniak* created an issue (OceanDataTools/openrvdas#481) <#481> We have a need for a MODBUS RS485 reader to support an existing met mast data feed. I am planning to copy the existing MODBUS TCP reader and modify it for RS485 use. If this seems like something that would be useful to have in the main repo, let me know and I'd be happy to send you whatever I come up with! — Reply to this email directly, view it on GitHub <#481>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFO7V3SPQXC36YJHAUDV3OL4AWVXHAVCNFSM6AAAAACOMYBDUWVHI2DSMVQWIX3LMV43ASLTON2WKOZTG4YDOMRWGA4DIMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[webbpinner]

Had some time so wrote an initial Serial ModBus Reader along with a unittest. Available from branch issue_481
33d067a

Should give you a good start.

[webbpinner]

I'm working through a polled version which is required for issuing commands. Almost done. Just trying to get the unittests working.

[jnahorniak]

Thanks Webb and Pablo! I also wrote a Serial Modbus Reader but was trying to keep the serial port open (like the regular serial reader does). I was trying to avoid the overhead of opening and closing the port multiple times a second. Am I overthinking it?If that's not an issue, it makes the code much cleaner and easier to use - your version looks great Webb!

In my particular use case, I have a single serial port (/dev/ttySI2) that is used to communicate with several devices/units/slaves, each with different registers that need to be read from. So for my version of the serial modbus reader (that opens the /dev/ttySI2 port in the init), I allowed the input arguments to be lists (device list, list of register lists). I also added a "function_code" argument (3, 4, etc) to select which register types to read from (holding, input, etc). The code loops over the device list and reads the relevant registers, creating a long string (I prepended each register string set with the device identifier like "D2" to make it easier to parse). The current version only has one interval value (e.g. 1 second) so all devices are read at the same interval.

I'll be running more tests next week.

[webbpinner]

nope... that makes sense. Refactored to keep port open between reads. Also added some thread-safe logic. Still working on the polled version.

[webbpinner]

Just posted a small update. There was an error in how i was using the pyModbus client args caused by a recent API change. Also added some exception refinements by incorporating the ModbusException class vs just using a general Exception.

[jnahorniak]

Thanks Webb! I'll try it out!

[jnahorniak]

The new reader works great for a single logger talking to a single slave. Is there a way to have multiple loggers talk to the same serial port (to read from different slaves)? I'm getting a "cannot connect to serial port" when I try adding a second logger to talk to a different slave. So my yaml file has two loggers, both using the new modbus serial reader, both pointing to the same port (/dev/ttySI2), and one is trying to read data from slave ID 1 and the other is trying to pull data from slave ID 2.

[jnahorniak]

modbus_rs485_reader.py

I've uploaded my version that takes a list of devices (slaves) as input. This was my workaround.

[webbpinner]

Refactored the interface to support multiple slaves and function codes. This is a much cleaner/safer way to interact with multiple devices through one kwargs vs enumerating multiple kwargs.

Configuration is handle via a yaml-formatted scan file.

---
polls:
- slave: 1
  function: holding_registers
  registers: "0:9,20:21"
- slave: 2
  function: input_registers
  registers:
  - [0, 4]
  - [10, 3]

supports 2 styles:

• "0:9,20:21" --> 0,1,2,3,4,5,6,7,8,9,20,21
• [10, 3] --> 10,11,12

Allowed function types:

• "holding_registers"
• "input_registers"
• "coils"
• "discrete_inputs"

output looks like:

slave 1: 100 101 102...
slave 2: 55 56 57...

As for the UDP output... the more OpenRVDAS way to handle this is via the standard readers, transforms, writers model. Readers that are also writers isn't inline with the core ethos of OpenRVDAS and should be avoided.

Here's the better way to handle the redirect:

---
readers:
  - class: ModBusSerialReader
    module: logger.readers.modbus_serial_reader
    kwargs:
      port: /dev/ttyUSB0
      baudrate: 9600
      scan_file: ./local/sio-rr/metacq/sample.yaml
      interval: 2
writers:
  - class: ComposedWriter
    kwargs:
      transforms:
        - class: RegexFilterTransform
          module: logger.transform.regex_filter_transform
          kwargs:
            pattern: "^slave 1"
      writers:
        - class: UDPWriter
          kwargs:
            port: 16001
  - class: ComposedWriter
    kwargs:
      transforms:
        - class: RegexFilterTransform
          module: logger.transform.regex_filter_transform
          kwargs:
            pattern: "^slave 2"
      writers:
        - class: UDPWriter
          kwargs:
            port: 16002

[jnahorniak]

Fabulous - thank you!!! I'll try it out! And thanks for the tip on how to send the output to different UDP ports - that makes a lot of sense.