Escape room hardware compatibility matrix
Compatibility is more than a logo. For every important device, verify discovery, state feedback, control, failure visibility, reset behavior, and what staff can do when the connection is unavailable.
Plan by connection type
- Inventory real devices and protocols before comparing platform claims.
- Prefer the simplest direct connection that preserves the state and controls staff need.
- Test a representative device through normal, failed, and reset states.
- Keep life-safety and code-required controls independent from entertainment software.
On this page
ARC connection and hardware matrix
This matrix describes the role of each connection. Verify exact models and firmware in your own rooms.
| Connection | Best fit | What to verify |
|---|---|---|
| MQTT | Custom props, brokers, ESP devices, and shared messages | Topic design, retained state, availability, and command acknowledgement. |
| Modbus TCP / PLC | Industrial I/O, relay banks, and durable mapped control | Register map, polling, timeouts, reconnect, and safe output state. |
| DMX / QLC+ | Stage lighting and repeatable effects | Universe and channel mapping, scene ownership, and controller recovery. |
| OSC | QLab, media tools, and addressed show-control messages | Address patterns, arguments, target availability, and retry behavior. |
| Z-Wave / Zigbee / Hue / Kasa | Off-the-shelf sensors, relays, and lighting | Supported models, gateway health, battery state, and command latency. |
| Shelly BLU / BLE | Battery sensors and quick retrofits | Gateway placement, signal quality, battery reporting, and event filtering. |
| Arduino / ESP / Raspberry Pi | Custom controllers, displays, and room clients | Library version, network identity, updates, and watchdog behavior. |
| ARC Node-RED nodes | Existing specialized flows and gradual migration | Flow ownership, error handling, documentation, and which logic belongs in ARC. |
Choose the simplest connection that preserves useful control
When discovery and detail matter
Use built-in connections when ARC can expose useful device state, configuration, health, and actions without an extra translation layer.
When you own both ends
MQTT, Modbus, DMX, and OSC make responsibilities explicit and work well for custom props or established controllers.
When a proven flow already exists
ARC's Node-RED nodes can preserve a specialized flow while ARC owns the game state and staff workflow.
Create a room hardware inventory
Record enough information that another builder can understand the room without reverse engineering it during a failure.
- Staff-facing device name and physical location
- Manufacturer, model, firmware, and power source
- Protocol, address, topic, register, universe, or channel
- Available states, commands, and expected acknowledgement
- Safe behavior when disconnected or restarted
- Reset procedure and manual override
- Network, gateway, credential, and replacement dependencies
Run a compatibility test before migrating a room
- 01
Connect the controller or service
Use the actual gateway, broker, PLC, lighting tool, or custom controller from the room.
- 02
Map representative devices
Include an input, an output, a device that reports and remembers its state, and the hardest integration in the room.
- 03
Exercise every state
Test normal actions, repeated actions, disconnect, reconnect, restart, and incorrect state.
- 04
Build staff recovery controls
Give staff a clear status and a tested action that cannot affect the wrong room.
- 05
Observe readiness and history
Confirm device health contributes to room readiness and leaves useful activity for troubleshooting.
Plan the network and physical safety separately
Segmenting devices, documenting addresses, controlling credentials, and using reliable wired links where practical can improve room reliability. Wireless devices need deliberate gateway placement and battery monitoring.
Entertainment software must not replace required life-safety systems. Emergency egress, fire code functions, and other safety controls need independent, code-compliant behavior even if ARC, the network, or a controller is unavailable.
Questions to answer for every important device
- Can ARC read its current state, not only send a command?
- How quickly is a disconnect visible to staff?
- What happens to outputs after power loss or reconnect?
- Can the device be reset without entering the room?
- Is there a safe manual override?
- Are credentials, mappings, and firmware documented?
- Can a replacement be configured without the original builder?
Test your actual room hardware with ARC
Use your first 14 days free to connect the devices from your most representative room and verify normal, failure, and reset behavior.