A software emulator of a Z-Wave controller chip. It presents the Z-Wave Serial API (Host API) over a PTY (the interface a real controller exposes to a host over a UART), backs it with a fake network of virtual nodes, and can inject failure modes — checksum errors, dropped/late frames, refused inclusion, NAK/CAN storms — that real hardware cannot be made to produce on demand. It is the Z-Wave sibling of a virtual cellular modem: same idea (a PTY speaking a real device protocol, plus a controllable fake network behind it), different radio.
It is built public-first, from public sources only (see
docs/research/zwave-virtual-radio-survey.md), so it can live in the open and be
reused unchanged behind a private host daemon that already speaks the Serial API.
The load-bearing idea, carried over from the cellular project: don't trust a test
you can't anchor to something external. The external, non-LLM oracle here is
zwave-js (MIT) — the production
Z-Wave host driver behind Home Assistant. If real zwave-js drives this virtual
radio correctly, the radio is correct in the way that matters. That conformance
harness is BATCH-1, not an afterthought. See docs/oracle.md.
rust/
vzwave-serial/ Serial API frame codec (SOF/ACK/NAK/CAN, length, type,
command ID, params, XOR checksum). Pure, tested. DONE.
(vzwave-radio) virtual controller state machine + fake mesh + command
classes. NEXT.
(vzwave-bridge) PTY/TCP transport (reuse the non-blocking poll pump proven
in the cellular project's pty-bridge). NEXT.
oracle/ the zwave-js conformance harness (Node). BATCH-1.
docs/ research survey, oracle plan, ADRs.
cd rust && cargo test # unit tests
cargo clippy --all-targets -- -D warnings
cargo fmt --checkJust scaffolded — the Serial API codec is implemented and green (incl. a golden
frame vector). Everything else is next; see PROJECT-STATE.md.
MIT (planned). Reuses MIT zwave-js building blocks with attribution; implements
a publicly-specified protocol. Not affiliated with or certified by the Z-Wave
Alliance / Silicon Labs.