Skip to content

feat: Modbus and RS-485 support #61

Description

@Vaishnav-Sabari-Girish

Is there an existing issue for this?

  • I have searched the existing issues

Problem Statement (The Pain)

When interfacing with industrial Operational Technology (OT) like PLCs, motor controllers, or HVAC sensors over RS-485, the communication relies on the Modbus RTU protocol. Because Modbus is a strict binary protocol, standard serial monitors just print unreadable garbage characters. Currently, developers have to capture the raw hex, manually separate the frame boundaries, look up the Function Codes, and manually calculate the CRC-16 checksums just to see what a sensor is reporting.

Suggested Solution

Add a --modbus flag to the CLI. When active, ComChan should buffer incoming serial bytes and automatically decode them as Modbus RTU frames on the fly.

The output should:

  • Automatically validate the CRC-16 checksum (silently dropping corrupted noise frames).
  • Decode the frame into human-readable English, showing the Slave Address, Function Code (e.g., "Read Holding Registers"), and the parsed Data payload.
  • Output clean, formatted terminal lines (e.g., [Modbus] Device: 01 | Func: 03 (Read) | Bytes: 02 | Value: 245).

Useful Resources

We can use a lightweight crate like rmodbus or tokio-modbus (or write a simple custom frame parser) to intercept the rx_buf in monitor.rs. Ideally, parsed numeric register values could even be piped directly into ComChan's existing TUI plotter!

Additional Information

No response

Self Grab

  • I'm ready to work on this issue!

Metadata

Metadata

Labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions