After the bench works Productization path

From one working prop.
To a room standard.

The prototype proves that signals move and outputs react. Productization proves that every node is protected, replaceable, observable and documented—and that failure cannot defeat emergency escape.

Game logicCentral only

Room nodesGeneric thin I/O

Field wiringProtected 24 V

SafetyIndependent system

01Bench prototype

Prove each electrical function.

02Engineering node

Protect and standardize the electronics.

03Pilot room

Install, observe and break deliberately.

04Room standard

Repeat from drawings and stocked spares.

BENCH PROVESPRODUCTION MUST ALSO PROVE

A button changes a GPIO.

A protected field input survives long wires, noise and wiring mistakes.

A relay opens the test lock.

A bounded command operates it, a separate sensor confirms it and failure is visible.

Two modules exchange CAN frames.

A labelled, terminated room bus remains diagnosable and one node can be replaced quickly.

The code works once.

Versioned generic firmware recovers from reboot, duplication, disconnection and power loss.

Frozen decision

One brain. Thin room hardware.

The central on-prem platform owns every game decision. Room hardware translates, protects and reports.

CENTRAL RACK Game server · event log · GM interface

One isolated runtime per room · database · monitoring · backup · UPS · cold spare

Wired EthernetMQTT events, commands, acknowledgements and heartbeats

EACH ROOM Ethernet-to-CAN gateway

Protocol translation and link health only—no puzzle state machine

CAN trunk120 Ω at both physical ends · short node stubs

FIELD LAYER Replaceable thin I/O nodes

Protected inputs · device drivers · bounded outputs · actual-state feedback

SERVER

“UID A419 is correct at this point in session 472. Open the drawer.”

NODE

“Pulse output 1 for at most 500 ms. Report the reed sensor’s actual state.”

SAFETY

“Emergency opening remains available regardless of either result.”

Architecture boundary approvedNo puzzle rules or session state are stored on room nodes. Room, gateway and node addressing frozenEvery installed device has a unique, documented service identity.

Hardware transition

Replace modules with a serviceable node.

Keep the prototype until its behavior is proven. Then consolidate only the repeated, understood circuitry.

Bench implementation	Production target	Why it changes
ESP32 development board	Standard MCU carrier or custom PCB with programming/service access	Repeatable assembly, mounting and replacement
Raw 3.3 V GPIO inputs	Protected 12/24 V field inputs; opto-isolation where appropriate	Long-wire noise, ESD and wiring-fault tolerance
SN65HVD230 breakout	Isolated CAN transceiver, isolated power and bus protection	Prevent ground and transient faults spreading between nodes
Loose buck module	Protected 24 V input and documented DC/DC stage	Reverse polarity, surge, thermal and service behavior
Relay and MOSFET modules	Protected drivers sized for each load class	Flyback, current, temperature and fault reporting
Breadboard and jumper leads	Pluggable terminals, ferrules, strain relief and permanent enclosure	Traceable wiring and fast field replacement

Standard node core

One replaceable base

24 V protected input and local regulated rails
MCU, watchdog and non-volatile identity
Isolated CAN with termination selectable but off by default
Service LEDs, test points and programming connector
Pluggable, labelled terminals and keyed power connection

Configurable I/O

Reuse before specializing

Protected digital inputs for switches and feedback
Protected low-side outputs for lamps and small DC loads
Dry-contact relays for low-voltage interfaces
Dedicated variants only for RFID, motors or dense LEDs
Same message protocol and service procedure on every variant

Field-input circuit testedNominal, open, shorted and noisy wiring states are characterized. Isolated CAN design testedCorrect power, ground, termination and bus-fault behavior confirmed. Every load class characterizedStartup, steady current, heating, flyback and failure state recorded.

Room installation

Separate power, data and show control.

A maintainable room is a set of documented trunks and short local branches, not an accumulation of improvised cables.

24 V power

Industrial room supply, fused distribution and separately protected load branches. Keep noisy motors and effects away from logic branches where practical.

CAN

Shielded 120 Ω twisted pair in a line, with short stubs and exactly two end terminators. Reserve RJ45 for actual Ethernet.

Ethernet

Star from the managed rack switch to the room gateway and networked AV endpoints. Do not extend Ethernet wiring as a proprietary prop connector.

DMX + audio

Separate show-control runs: DMX daisy chain with correct termination and balanced audio where cable length or interference warrants it.

Egress + life safety

Physically and functionally independent routes designed and commissioned by the appropriate specialists.

Required before walls close

Room cabinet locationPower budget by branchCable route and identifier CAN trunk + termination pointsNode and channel scheduleService-access clearance Fire-stopping responsibilitySpare conductor policyAs-built drawing owner

Measured power budget completeBranch fuse and conductor choices derive from the actual loads. Cable and termination schedule issuedEvery route, end, shield, junction and spare is identifiable.

Software boundary

Freeze the contract before the PCB.

Generic node firmware becomes interchangeable only when events, commands and failure behavior are stable.

NODE → SERVER Observed event

{
  "nodeId": "room01-node03",
  "sequence": 184,
  "type": "rfid.detected",
  "channel": 2,
  "value": "A419…",
  "observedAtMs": 482913
}

SERVER → NODE Bounded command

{
  "commandId": "8f2…",
  "nodeId": "room01-node07",
  "type": "output.pulse",
  "channel": 1,
  "durationMs": 500,
  "expiresAtMs": 483500
}

01Identity

Room, gateway, node, channel, firmware and configuration versions.

02Ordering

Sequence numbers and timestamps expose missing, stale and duplicate messages.

03Boundaries

Command ID, expiry and maximum duration make commands idempotent and finite.

04Truth

Acknowledgement reports accepted, executed, rejected and observed resulting state separately.

05Health

Heartbeat, uptime, reset reason, voltage, temperature and communication counters.

06Compatibility

Versioned schemas and capabilities let the server reject incompatible hardware safely.

KEEP LOCAL

Device drivers · debounce · output limits · limit switches · watchdog · configured communication-loss behavior

KEEP CENTRAL

RFID correctness · puzzle state · timers · scoring · prerequisites · cross-prop rules · operator actions

Protocol schemas versioned and testedGolden events, commands, duplicate delivery and incompatible versions covered. One generic firmware image provenNode behavior is configuration-driven; puzzle meaning is absent.

Failure policy

Every failure gets a visible outcome.

Stopping gameplay is acceptable. Silent failure, uncontrolled movement and trapped players are not.

Failure	Expected room behavior	Operator evidence	Recovery
Central server	Game automation stops; each output applies its configured local policy	Venue-wide health alarm	UPS, restart or cold-spare server
Room gateway	One room loses central commands; nodes remain bounded	Gateway and room offline	Swap preconfigured gateway
CAN trunk	Affected segment stops; no actuator runs indefinitely	Error counters and missing heartbeats	Isolate cable or node fault
One node	Only attached prop group stops	Node heartbeat and reset reason	Swap labelled spare, then diagnose offline
Sensor	Input becomes unknown/fault, never silently “solved”	Contradiction, timeout or electrical diagnostic	Inspect wiring and replace sensor
Actuator feedback	Command result remains unconfirmed	Command/actual-state mismatch	GM override only after physical check

100×Complete game reset

No accumulating state or missed reset.

LIVEDisconnect while active

CAN, Ethernet and sensors fail visibly.

BOOTRestart every layer

Known startup outputs and state reconciliation.

SWAPReplace from stock

A technician restores a node from labels and documentation.

Failure matrix verifiedEvery output has a documented hold, off, timeout or bounded-local policy. Soak and interruption tests passedResults retained with firmware, hardware and configuration versions. Cold-spare swap rehearsedA different person restores service without rewriting code.

Release gates

Productized means reproducible.

A room standard is complete only when hardware, software, installation, operations and evidence agree.

GATE 01
Design freeze
Schematics, power budget, message contract, node variants, failure policies and safety boundary reviewed.
GATE 02
Engineering verification
Electrical protection, thermal behavior, communication faults and each real load class tested.
GATE 03
Pilot installation
One representative room runs with production wiring, enclosures, diagnostics and actual operator workflow.
GATE 04
Room acceptance
Reset cycles, power loss, server loss, gateway loss, node swap, sensor faults and GM overrides witnessed.
GATE 05
Specialist commissioning
Mains, fire, emergency lighting and egress work remain within the required professional and authority process.
GATE 06
Operational handoff
As-built drawings, labels, firmware/config versions, spare stock, fault tree and daily checks are usable by staff.

Pilot room acceptedRecorded evidence covers normal play, reset and deliberate failures. Specialist boundaries signed offGame automation cannot defeat the approved life-safety systems. Documentation and spares handed overThe installed room can be serviced from the as-built record.

DEFINITION OF DONE Build a second node from the documents, swap it into the pilot room, recover service, and explain every observed event without changing puzzle code on the node.

From one working prop.To a room standard.