Files
wiredsensor/examples/esphome/bus-of-nodes.yaml
T
Oliver Walter c49fff9faf Add ESPHome example configurations
The README carried a fragment, which is enough to show the shape but not
enough to flash. These are complete configs:

  wiredsensor.yaml      one node, every measurement and diagnostic register
  wiredsensor-node.yaml one node as a reusable package, parameterised by address
  bus-of-nodes.yaml     three nodes on one segment, via that package

All three validate against ESPHome 2026.7, and the expanded config was
checked register by register rather than only for schema validity — a
wrong address or value_type validates perfectly and then reports a
plausible but wrong temperature, which is the failure mode worth
guarding against.

Two things the fragment in the README was missing and a real config
cannot be:

flow_control_pin on the modbus component. Without it the ESP32 never
asserts DE, so nothing reaches the segment and the node looks dead. The
generated fragment now carries it too.

The read/holding split for diagnostics. ESPHome merges adjacent registers
of one register_type into a single command, and a read overlapping
0x0000..0x0004 is refused when the sensor has never produced a reading —
so diagnostics merged into the measurement command go unavailable exactly
when they are needed. Asking for them as `holding` puts them in their own
command.

Serials are text_sensors with raw_encode: HEXBYTES rather than numeric
sensors, because Home Assistant stores states as float32 and 24 bits of
mantissa cannot hold a 32-bit serial. Uptime has the same limit and is
left numeric with a note; quantising past 194 days does not matter for
spotting a reboot.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-29 17:28:08 +02:00

95 lines
2.2 KiB
YAML

# Several wiredsensor nodes on one RS485 segment, read by a single ESP32.
#
# The point of a bus: one gateway, one pair of wires, N sensors. Each node needs
# a distinct UNIT_ADDRESS, which means one firmware image per node — see the
# Configuration section of the top-level README.
#
# esphome run bus-of-nodes.yaml
#
# The per-node entities live in wiredsensor-node.yaml and are instantiated once
# per address below, so adding a node is three lines rather than a copied block.
substitutions:
name: rs485-gateway
friendly_name: "RS485 gateway"
baud_rate: "19200"
tx_pin: GPIO17
rx_pin: GPIO16
de_pin: GPIO4
esphome:
name: ${name}
friendly_name: ${friendly_name}
esp32:
board: esp32dev
framework:
type: esp-idf
logger:
level: INFO
api:
encryption:
key: !secret api_encryption_key
ota:
- platform: esphome
password: !secret ota_password
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap: {}
captive_portal:
# ---------------------------------------------------------------- the bus ---
uart:
id: rs485
tx_pin: ${tx_pin}
rx_pin: ${rx_pin}
baud_rate: ${baud_rate}
data_bits: 8
parity: NONE
stop_bits: 1
modbus:
id: rs485_bus
uart_id: rs485
flow_control_pin: ${de_pin}
# ----------------------------------------------------------------- nodes ---
#
# One entry per node. `node_id` must be unique; `node_addr` must match that
# node's UNIT_ADDRESS.
#
# Requests are serialised across the whole bus — ESPHome waits for each response
# before sending the next — so poll cost scales with node count. A node answers
# roughly 2 ms after the request ends, so a dozen nodes at 30 s is nowhere near
# saturating the segment. If you do see timeouts, `command_throttle` on the
# controllers is the knob, not `update_interval`.
packages:
hallway: !include
file: wiredsensor-node.yaml
vars:
node_id: node_hallway
node_addr: "0x01"
node_name: "Hallway"
cellar: !include
file: wiredsensor-node.yaml
vars:
node_id: node_cellar
node_addr: "0x02"
node_name: "Cellar"
greenhouse: !include
file: wiredsensor-node.yaml
vars:
node_id: node_greenhouse
node_addr: "0x03"
node_name: "Greenhouse"