131ae200ee32c67732b667e1ceac700b522b279a
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Oliver WalterandClaude Opus 5
|
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> |
||
|
Oliver WalterandClaude Opus 5
|
5b9c09df3b |
Speak Modbus RTU instead of a custom command protocol
ESPHome only has built-in support for Modbus RTU over RS485, so the application layer moves to it. The transport already conformed: the CRC was CRC-16/MODBUS, the line rate 19200 8N1, the delimiter a 3.5-character idle gap pinned at 1750 us above 19200, and the address space 1..247 with broadcast never answered. Only the bytes between the address and the CRC change, and no external crate is needed for a read-only server. frame.rs drops the explicit LEN byte, which RTU does not have — a request's length is implied by its function code. The parser gets simpler and MAX_FRAME grows to the RTU limit of 256. The CRC is now the only integrity check there is, so a truncated frame fails it rather than a length comparison; a test asserts every single-bit corruption is still caught, and another pins our encoding against the published example 01 03 00 6B 00 03 74 17. proto.rs becomes a Modbus server: function codes 0x03 and 0x04 over one 19-register table, 0x08 sub-function 0x0000 as the link test that replaces PING, and the four standard exception codes. Registers are big-endian with 32-bit values high word first, which is what masters and ESPHome's S_DWORD assume. Snapshot::registers renders the whole map and reads slice it, so a range read cannot disagree with a single-register read of the same address — the alternative, assembling only the requested registers per read, has no such guarantee. Both read function codes serve the same table. That is not only for masters that implement just 0x03: a read overlapping the measurement block is refused with SERVER_DEVICE_FAILURE when the sensor has never produced a reading, and ESPHome coalesces adjacent registers of one type into a single command, so diagnostic entities merged into that command would go unavailable along with the measurement they were meant to explain. Requesting them under the other function code puts them in their own command. The generated ESPHome config does this. The firmware barely changes, because dispatch's signature does not: flags widen to u16, buffers follow MAX_FRAME, and comments name registers rather than commands. Now ~35 KiB flash and ~2.6 KiB RAM. tools/wiredsensor.py is rewritten and grows from 15 checks to 21, adding agreement between the two function codes, sub-range consistency, and a per-code assertion for every exception. It stays a hand-written Modbus implementation rather than moving to pymodbus: half these checks inject deliberately malformed frames, and a conforming client library exists precisely to make those unconstructable. It also keeps the wire format independent of wiredsensor-core, so a shared bug cannot cancel itself out. Not yet exercised on hardware — the host tests and register-map cross-checks pass, but the timing-dependent behaviour needs `wiredsensor.py test` against a real bus. This replaces the old protocol rather than joining it; command codes 0x01..0x04 are all valid Modbus function codes, so the two cannot share a segment. PROTOCOL_VERSION is 2. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Oliver WalterandClaude Opus 5
|
ddfda14085 |
Add USB-RS485 bridge and PC-side test suite
Makes end-to-end verification of the bus possible with a spare RP2040 and no dedicated RS485 dongle. bridge/ turns a second Pico into a transparent USB-to-RS485 bridge. It is deliberately protocol-agnostic: bytes from USB go out on the pair, bytes from the pair go back up USB, and it knows nothing about frames, addresses or CRCs. A protocol-aware bridge could have a bug that happens to agree with the node's own, which would defeat the point of using it as a test instrument. It also needs no register-level code — it never has to delimit a frame, and the one thing it does need, knowing that the final stop bit has cleared the shifter before releasing DE, rp2040-hal exposes as uart_is_busy(). tools/wiredsensor.py is an independent implementation of the wire format, written from the specification in README.md rather than sharing code with wiredsensor-core. Shared code would let a framing or CRC bug cancel out and every test pass regardless. Cross-checked: it reproduces the CRC-16/MODBUS catalogue vector and builds byte-identical frames to the Rust side for all five documented examples. Its `test` subcommand covers what host tests structurally cannot, all of it timing-dependent: that malformed and mis-addressed frames leave the node silent rather than colliding with whoever was actually addressed, that the driver-enable turnaround leaves replies intact, and that no state leaks between back-to-back frames. Uses one wiring diagram for both boards, since the bridge mirrors the node's GPIO0/1/2 assignment. Frames must fit one 64-byte USB packet, as each host write becomes exactly one DE-bracketed transmission; every real command is at most 21 bytes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |