← 16. The lab suitcase · Contents · Next → 18. The security agreement
17. The all-in-one reader¶
Exploratory. Nothing in this chapter ships today — it is the roadmap direction 16. The lab suitcase's own wiring argues for, written down before a single carrier board is cut.
Wire two doors and three readers into one suitcase, and the lesson that stares back is the wiring itself: five bridge nodes, an RS-485 home run to each, a relay per node, a power chain feeding all of it, for one controller. A real site multiplies every piece of that by the number of doors and readers it has.
The all-in-one asks what happens if a reader and the door it watches stop being two things joined by a bus, and become one box instead.
What collapses, and into what¶
| Today (§16's bench, and a fielded controller) | The all-in-one | Why the collapse is possible |
|---|---|---|
| A reader, a home run, a Pico+MAX485 bridge node | An NFC/RFID front-end IC (PN7150-class) on the carrier board itself, antenna traced on the front face | The bridge node's whole job in §16 is turning a reader's native signal into something the bus can carry. Solder the reader IC onto the same board as the compute module and there is no bus segment left to bridge |
A separate controller running wardn-edge | A Raspberry Pi CM4 on a custom carrier board, running the same wardn-edge binary | 3. Architecture's case for Rust — unattended, in an enclosure, for years, on modest hardware — describes a door-mounted unit even more than a wiring-closet controller. Nothing about that argument is CPU-specific |
| 12V/5V rails fed from a bench PSU, distributed on Wago rails | Power over Ethernet, split on-board to 5V logic and 12–24V for the strike | One Cat5e/6 cable in, instead of a data run and a power run |
| A relay wired to the controller's GPIO | The same relay contract, on the CM4's GPIO | Unchanged — 3. Architecture's "hardware relay (GPIO)" adapter does not care which board hosts it |
The development roadmap the concept starts from is four phases, each answering a question the previous one leaves open:
| Phase | Proves | Why it comes at that point |
|---|---|---|
| 1. Prototyping | A generic CM4 IO board plus a standalone NFC module can read a card and pulse a GPIO at all | Throwaway scaffolding — the source exploration names Python or Go for this step specifically because it is disposable. It answers "does the reading and actuation work," not "what ships." The firmware that eventually ships is still wardn-edge, unchanged from what a fielded controller already runs |
| 2. Custom PCB | The NFC front-end, PoE extraction and relay switching survive being laid out next to a CPU without the antenna picking up its noise | The step 16's socket-everything bench cannot stand in for: nothing on a breadboard tells you whether an antenna trace six millimetres from a switching regulator still reads a card at range |
| 3. Enclosure & thermal | The board survives outdoors (IP65+) with no fan, on a mullion or a wall | A CM4's Cortex-A72 dissipates more heat in less space than the RP2040 nodes in §16 ever had to |
| 4. Security hardening | Secure boot, mTLS as already specified, and a hardware secure element | See below — this phase already names a candidate for a gap the documentation lists as open |
What does not collapse¶
The unit still dials out the way every controller does today: MQTT over mTLS, outbound only, its certificate's common name confining it to its own topic subtree (14. Deploying to production). PoE solves what happens between the wall and the box. It changes nothing about what happens between the box and the server — same heartbeat, same rights sync, same immutable-rights model, same "the server never decides an opening" principle that 1. The problem opens the whole documentation with.
One thing does change, and the answer is already in the model: 8. The dashboard gives a reader a wiring, and an all-in-one's is onboard — reader and controller are the same device, so there is no wire between them, nothing to address and nothing to lose. The unit is still a controller with a reader under it on the dashboard tree; that reader simply names no address and no pins.
What the firmware does with such a reader is half done: an onboard wiring is carried, stored and displayed everywhere, and the simulated bus presents credentials on one, so the decision path is exercised end to end. What is missing is the hardware adapter — there is no reader IC on a board to read frames from until phase 2 above.
Security hardening is not a generic checkbox here¶
10. Security → What is not there yet lists, in its own words:
⚠️
SQLITE_ENCRYPTION_KEY_SOURCE=secure_elementis not implemented. The controller refuses to start rather than pretending.
A hardware crypto-authentication IC (an ATECC608B-class part, as the source exploration names it) on the all-in-one's carrier board is a plausible way to finally back that setting — not because the all-in-one needs it more urgently in the abstract, but because 3. Architecture's reason for encrypting the local store at all is that "the box is physically reachable: someone can open the enclosure and take the SD card."
A unit mounted on a mullion outside a door is more physically reachable than a controller in a wiring closet, not less. The same part that would finally close that gap is already on the shelf this concept reaches for.
What is traded away¶
- Iteration speed. 16's bench sockets a reader in and out in minutes. A protocol change here waits on a PCB respin.
- Thermal margin. A sealed IP65 enclosure with no fan is a harder budget than a suitcase with its lid open on a desk.
- Fleet bookkeeping. More, smaller units per site instead of fewer controllers each watching several doors — a shift 7. The fleet's heartbeat and alerting machinery was not sized against, one way or the other.
None of that is resolved by this chapter. It is exploratory because the questions above are still open, not because the direction is in doubt.
The lab suitcase is proof today. The all-in-one is the shape that proof is aimed at.