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>

README.md

@@ -25,6 +25,7 @@ Written in Rust on **RTIC 2** + `rp2040-hal`.
 | `firmware/`| `wiredsensor-fw` — the RTIC application, drivers and register access.     |
 | `bridge/`  | `wiredsensor-bridge` — a spare RP2040 as a USB-to-RS485 bridge, for testing. |
 | `tools/`   | `wiredsensor.py` — PC-side Modbus master and end-to-end test suite.       |
+| `examples/`| ESPHome configurations, one node and a whole segment.                     |
 
 The `core`/`firmware` split exists so the entire protocol can be exercised by
 ordinary host unit tests (`cargo test`) with no hardware and no emulator. `core`
@@ -238,8 +239,17 @@ register map at all.
 ## ESPHome
 
 `modbus_controller` reads this node with no custom component and no external
-library. `tools/wiredsensor.py esphome` prints a complete config for a given unit
-address; the essentials are:
+library. Complete, flashable configs live in `examples/esphome/`:
+
+| File | What it is |
+|------|------------|
+| `wiredsensor.yaml`      | one node, with every measurement and diagnostic exposed. Start here. |
+| `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. `tools/wiredsensor.py esphome` prints
+the same thing for an arbitrary unit address if you would rather generate it. The
+essentials are:
 
 ```yaml
 uart:
@@ -309,8 +319,13 @@ binary_sensor:
 ```
 
 This is what serving both function codes from one table buys, beyond mere
-compatibility. `tools/wiredsensor.py esphome` generates a config already set up
-this way.
+compatibility. Both `examples/esphome/wiredsensor.yaml` and the generated config
+are already set up this way.
+
+One more wiring detail the YAML has to get right: **`flow_control_pin` on the
+`modbus:` component**, unless your transceiver switches direction itself. Without
+it the ESP32 never asserts DE and nothing you send reaches the segment, which
+looks exactly like a dead node.
 
 ## Configuration