Device paths
MQTT and local bridges
ARC already has real integration paths for room devices and local services.
Integrations
Connect the parts of your room without forcing everything into one mold
ARC is meant to sit in the middle of your room operations and connect far more than just puzzle solves. That includes room hardware, sensors, lighting, automation triggers, and the local services that keep live games running.
The current platform architecture and core host already point to integrations for MQTT, Z-Wave, Zigbee, Hue, and local bridge processes. The room story is much broader than a simple puzzle panel.
Room control
Lighting, sensors, scenes
The system is built around live room behavior, not just abstract events.
Operations
One control surface
Manage devices and integrations from the same product you use to run the room.
What ARC is ready to connect around
Room devices
Buttons, sensors, and custom hardware events
ARC is a good fit when your room uses real-world triggers like button presses, door state, motion, or custom controller messages.
Lighting
Scenes and room atmosphere
ARC can sit alongside lighting control so room state and lighting state do not have to live in separate worlds.
Automation
Trigger one action from another
Device events can be used to kick off reactions automatically, which is where ARC starts feeling like room operations software rather than just a dashboard.
Local services
Bridge what already exists on site
ARC is designed to work with local integration services instead of pretending every room starts from a clean slate.
Integration families already reflected in the repo
These are the patterns the current ARC runtime and host architecture already support or explicitly reference.
MQTT
A strong fit for custom room hardware, microcontrollers, event-based triggers, and lightweight communication between devices and ARC.
Z-Wave and scene control
Useful when a room needs dependable local control over devices and scene-style behavior as part of the wider experience.
Zigbee
Part of the current local integration picture for rooms that mix sensors and smart-device style hardware.
Hue
Lighting belongs inside the same control conversation as the rest of the room. ARC already reflects that in the host architecture.
PLC, serial, DMX, and other room-control paths
The host already exposes feature flags around hardware-heavy integrations, which points to a system designed for real control environments instead of one narrow device stack.
Plain-language examples of where ARC fits
- A hint button sends a room event and staff see it in the same system they use to run the game.
- A door sensor changes room state and kicks off a lighting or scene change automatically.
- A custom controller sends an event through MQTT, and ARC uses that event to move the experience forward.
- A room uses a mix of device families, but ARC gives operators one place to watch and control it.
Why this matters for escape rooms
Real rooms are messy. They are built over time, they mix old and new hardware, and they rarely fit a single perfect template. ARC makes more sense when it accepts that reality instead of fighting it.
That is why the product story should not be limited to puzzle logic. The stronger message is that ARC helps operators bring room hardware, room behavior, and live operations back into one system.
Next step
See why local-first matters once devices are involved
The more your room depends on live hardware and timing, the more important it becomes that control stays close to the room itself.