ESPHome has had no way to react in YAML to the traffic going through a Modbus hub. A new modbus_monitor block fills that gap. Pull request #20256 by Bascht74 was merged into the development branch on 27 October 2026 at 02:28 Polish time. The branch is numbered 2026.11.0-dev, so the block should first appear in ESPHome 2026.11.

Two triggers

modbus_monitor attaches to an existing Modbus hub with modbus_id and offers two automations:

  • on_request runs for every frame a server hub reads as a request, and for every request a client hub sends, including broadcasts and retries. It gets the variables address and request.
  • on_response runs for every response a client hub receives to its request, and for every reply a server hub sends or sees from another device on the bus. It gets address, request and response.

The variable names match the existing on_custom_response trigger in modbus_client. The example in the pull request logs the target address and function code of each request:

modbus_monitor:
  - on_request:
      - lambda: |-
          ESP_LOGD("modbus_monitor", "Request to %u, function 0x%02X", address, request[0]);

What it is for

The author lists logging bus traffic, counting requests and reacting to a client's writes, for example in a gateway. An ESP32 set up as a Modbus server, for instance, can use on_request to notice when the device on the other end writes a register, without a separate sniffer on the line.

Limits worth knowing

Actions that wait, such as delay or wait_until, are rejected in these handlers. The request and response data is only valid while the handler runs, so the automation has to finish at once. Several monitor blocks can watch the same hub. When nothing is configured, nothing is compiled in.

On a server hub that uses on_response, ESPHome keeps the last request so it can report it together with the reply. That costs 254 bytes of RAM per server hub. The server hub now also copies the whole request so the automation can see it.

The documentation has already been merged in esphome.io pull request #7535. A separate proposal for a passive Modbus RTU sniffer, #19450, used the same way of attaching to a hub but is now closed without being merged.