Add write_lambda support for server_registers in modbus_controller Server Mode #3279
Unanswered
PelicanHu
asked this question in
Component enhancements
Replies: 1 comment
-
🏷️ I've automatically added the |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Component name
modbus_controller
Link to component documentation on our website
https://esphome.io/components/modbus_controller.html
Describe the enhancement
The modbus_controller component in server mode (role: server) allows defining server_registers with a read_lambda to return values when a Modbus client reads from the specified registers. However, there is no support for a write_lambda to handle write requests from a Modbus client to these registers. In contrast, the modbus_controller in client mode supports write_lambda for components like switch, number, or output, allowing custom handling of write operations to Modbus devices.This limitation prevents users from implementing custom logic to process incoming write commands to server_registers in server mode, which is critical for scenarios where an ESPHome device acts as a Modbus server and needs to react to register writes (e.g., controlling internal states, switches, or other components based on the written values).
Use cases
Scenario
An ESP32 running ESPHome is connected to multiple Modbus keyboards (e.g., industrial keypads or control panels) over an RS-485 Modbus RTU bus. These keyboards act as Modbus clients, sending commands to the ESP32, which is configured as a Modbus server. Each keyboard can send data (e.g., the ID of a pressed key) to a specific holding register on the ESP32 to trigger actions, such as controlling lights, motors, or other devices integrated into the ESPHome system.
Current Implementation (Client Mode)
In the current setup, the ESP32 must operate in Modbus client mode using the modbus_controller component to poll the keyboards periodically. In this configuration, the ESP32 continuously polls the keyboards' holding registers to check for keypresses. If a key is pressed, the register value changes (e.g., to the key ID), and the lambda processes the value to trigger actions (e.g., turning on a switch).
Drawbacks:
Continuous Polling: Polling multiple keyboards every 100ms creates significant overhead on the Modbus bus and the ESP32, especially if many keyboards are connected.
Latency: The polling interval (e.g., 100ms) introduces latency, as a keypress may not be detected until the next poll cycle.
Resource Usage: Constant polling consumes CPU resources and increases power consumption, which is problematic for battery-powered or resource-constrained devices.
Scalability: As the number of keyboards increases, the polling frequency must be reduced to avoid bus congestion, further increasing latency.
Desired Implementation (Server Mode with write_lambda)
A more efficient approach would be to configure the ESP32 as a Modbus server, allowing the keyboards (acting as Modbus clients) to write directly to a holding register on the ESP32 when a key is pressed. This event-driven model would eliminate the need for polling and reduce latency, as the ESP32 would immediately process the keypress when the keyboard writes to the register.
Benefits:
Event-Driven: The ESP32 only processes data when a keypress occurs, eliminating the need for continuous polling.
Low Latency: Keypresses are handled immediately upon receipt of the Modbus write command.
Reduced Bus Traffic: The Modbus bus is only used when a keyboard sends a write command, improving scalability for multiple keyboards.
Resource Efficiency: The ESP32 CPU and power usage are minimized, as there is no constant polling.
Anything else?
Current Limitation
The modbus_controller in server mode does not support write_lambda for server_registers. This forces users to rely on client mode with polling, which is inefficient for this use case. Without write_lambda, the ESP32 cannot process write requests from Modbus clients (keyboards), making it impossible to implement the event-driven model described above.
Beta Was this translation helpful? Give feedback.
All reactions