MQTT, PLC, DMX, OSC, and Node-RED
Reliable automation separates how data moves, what a device means, and why the game reacts. Choose each protocol for the responsibility it handles well, then keep the live logic understandable.
Choose by responsibility
- Use protocols to transport state and commands; keep game meaning in a clear device model.
- Put normal room logic where owners and future builders will expect to find it.
- Define offline, timeout, reconnect, and reset behavior before the happy path.
- Give staff visible status and safe recovery actions.
On this page
- 01Separate transport, device meaning, and game logic
- 02Use MQTT for flexible custom props and messages
- 03Use Modbus TCP and PLCs for mapped, durable I/O
- 04Use DMX and OSC for lighting, media, and show control
- 05Use ARC's Node-RED nodes for existing specialized flows
- 06Design failure behavior before the happy path
- 07A practical automation implementation order
Separate transport, device meaning, and game logic
A clean boundary makes future changes safer and troubleshooting faster.
How data moves
MQTT topics, Modbus registers, DMX channels, OSC addresses, and HTTP requests carry messages without defining the whole game.
What the hardware can do
ARC gives technical signals staff-facing state, actions, readiness, and a recognizable room purpose.
Why and when it happens
Objectives, variables, timers, conditions, scenes, and When / If / Do automations decide the experience.
Use MQTT for flexible custom props and messages
MQTT works well when many devices share a broker or when you control custom firmware. Design topics around stable device identity, separate reported state from commands, publish availability, and decide which values should be retained.
Do not hide the entire game in opaque topic names. ARC should receive enough state to explain readiness and let the game engine decide the next experience action.
Use Modbus TCP and PLCs for mapped, durable I/O
PLCs are a strong fit for relay banks, sensors, and durable room control. Document register type, address, scale, read or write direction, expected value, timeout, and safe state.
Polling and reconnect behavior matter as much as the map. Staff should know when the PLC is unavailable, and automations should not guess that a missing value means solved or safe.
Use DMX and OSC for lighting, media, and show control
DMX is suited to channels and scenes for lighting and effects. Decide whether ARC or a tool such as QLC+ owns fades and scenes, then document universe and channel mapping.
OSC is useful for addressed commands to media and show-control tools such as QLab. Define address patterns, argument types, target availability, and whether a command can be retried safely.
Use ARC's Node-RED nodes for existing specialized flows
ARC offers its own Node-RED nodes so an established flow can react to ARC game state or trigger appropriate controls. This supports specialized integrations and gradual migration.
Keep ordinary game logic in ARC when that is where staff and future builders will look. Splitting one simple puzzle across several tools creates more recovery paths to understand.
Design failure behavior before the happy path
Know what is unavailable
Track device, gateway, broker, PLC, and service health with useful timeouts.
Avoid unsafe automatic guesses
A missing value should not silently become solved, unlocked, or ready.
Give staff a tested action
Provide a room-specific retry, override, or manual procedure with clear scope.
Preserve useful history
Record the state change, automation, command result, and staff action needed to understand the incident.
A practical automation implementation order
- 01
Inventory the room
List every input, output, controller, dependency, manual override, and reset expectation.
- 02
Define device contracts
Choose stable identities, states, commands, acknowledgements, timeouts, and offline behavior.
- 03
Map devices into ARC
Give each connection a staff-recognizable room purpose and verify its health.
- 04
Build When / If / Do logic
Keep normal experience rules together with objectives, variables, timers, and scenes.
- 05
Test failure and reset paths
Disconnect services, restart controllers, repeat events, and confirm the room returns to a known state.
- 06
Document and rehearse
Record mappings and teach normal staff how to identify and recover the common failures.
Build one real automation in ARC
Connect a representative device, build the normal logic, then test disconnect, reconnect, override, and reset during your first 14 days free.