Connected does not describe one capability
An official phone app, remote partner control, prerecorded video scripts, generic game vibration, and native scene events are different paths. A useful compatibility report identifies the source, protocol, bridge, adapter, hardware revision, and physically observed result instead of collapsing them into one badge.
Intent instead of packets
Games should emit intensity, position, rhythm, action type, and scene events. The local bridge should translate those intentions into the exact commands a connected device understands, enforce the user's limits, resolve competing sources, and establish a known stopped state when activity ends.
Connection, command, and physical response
A green connection indicator proves only that discovery and authorization succeeded. Testing must then show that commands arrived at the right times and that the device matched the intended actuator, intensity, rhythm, and stop state.
The F1S V4 case study
Our retail LELO F1S V4 advertises as F1SV3 and exposes two independently addressable motors. Direct testing showed that its onboard patterns are stateful and that a zero-speed update did not reliably cancel earlier patterned motion.
The prototype now treats every update as a complete desired state: clear the prior state first, then reapply only the motors that should remain active. That detail separates a device that merely moves from an integration that behaves predictably.
Native events and sound
Native integrations are the most precise source. Audio reaction is the broad fallback for games without an API and needs application selection, threshold, frequency bands, gain, smoothing, attack, release, cooldown, output ceiling, and per-actuator routing.
Audio analysis should remain local. Diagnostics can record normalized control values without recording or uploading what the user heard.
Reconnect and intentional keep-alive
Reconnect should restore a known stopped state and wait for new activity instead of replaying stale output. A physical keep-alive is a separate, opt-in experience for long stretches of story or exploration: an occasional low, bounded pulse chosen by the user, not a hidden transport behavior.
Compatibility is specific
A result should name the game build, acquisition source, integration setting, protocol version, bridge version, operating system, device revision, tested actuators, response timing, idle behavior, reconnect behavior, and anything not tested. “Bluetooth supported” is not a reproducible claim.