A DJ controller is the best home-automation remote

A fader is a positional control: the current brightness is where the fader physically sits. A touch slider is a velocity control: it starts at zero and you drag until the screen shows the target. Positional controls have a massive advantage for "set to a known level" because the position is the state. You do not look at the fader; you grab it and the room is already roughly right.

Pads are momentary scene triggers. The tactile click confirms the scene fired without looking. Encoders are relative adjustments that do not need absolute position. The combination of positional, momentary, and relative controls maps naturally to lighting (brightness, scenes, color temperature) and media (volume, play/pause, source).

A one-directional bridge fires MIDI to the system and ignores the return path. That means if a scene is triggered from a phone, the controller fader still shows the old position. The bridge must also subscribe to device state and write the current value back to the controller. This closes the loop: the physical surface always reflects the actual device state.

The sync loop is the hard part. MIDI writes to a controller can fight the human hand: if the bridge writes a fader position while the operator is holding the fader, the motor fights the hand (if motorized) or the position jumps when released (if not). The practical rule is to write feedback only when the source of the state change was not the controller itself, and to debounce rapid state transitions.

When a light is offline, the controller should not pretend it is in scene. The feedback LED for that control should reflect the outage: dimmed, amber, or off. The operator can still trigger the scene; the bridge queues the target and applies it on recovery, but the physical surface communicates "this did not fully take."

This is the same availability contract as the lighting engine. The controller is a view of the system state; if the view lies, the operator loses trust in the surface. A controller that shows green when the light is offline is worse than no controller at all.

A USB controller can disconnect, sleep, or be power-cycled. The bridge must detect MIDI port disappearance, attempt reconnection, and re-sync the full controller state on reconnect. This is the same pattern as reconnecting to a WebSocket: the connection is a resource that can drop, and the bridge treats reconnection as a normal event.

The re-sync on reconnect is important: the controller may have been moved while disconnected. The bridge reads no state from the controller on reconnect; it writes the current device state to the controller. This prevents a stale fader position from firing a brightness change the moment the cable is plugged back in.

1def on_midi_port_lost():2    log.warning('controller disconnected')3    schedule_reconnect(interval=2)4 5def on_midi_port_recovered():6    # do NOT read controller state; write current state7    for control, entity in mapping.items():8        state = ha.get_state(entity)9        write_feedback(control, state)10    log.info('controller re-synced')