Device compatibility / model by model
Compatibility,
without the asterisk.
“Implemented” is not the same as “tested on your exact device.” This matrix separates shipped code, observed hardware behavior, and the checks still open.
DIYcheck your exact model before you build
4physical BLE transport groups at once
24saved device records
01 Read the signal
Four labels.
Four different promises.
The narrowest accurate label wins. A supported protocol family never silently becomes a claim about every model in that family.
- Supported
- An operator-approved working path on the exact named model; stated limitations can still apply.
- Verified bounded
- The named behavior was observed on the exact named hardware, with remaining gates stated.
- Experimental
- Code exists, but model coverage or real-hardware validation is incomplete.
- Research / later
- No generally usable saved-device path is claimed yet.
02 Device matrix
Exact names.
Honest boundaries.
Snapshot: 12 August 2026. The repository documentation remains the source of truth as firmware and hardware evidence evolve.
| Device / path | Evidence | What works | Open boundary |
|---|---|---|---|
| MotioniFootage Shark Nano II | Current | Pair/reconnect, battery, keypoints A–H, manual movement, timing, loop/direction, and run control. | Movement must be physically observed; protocol ACKs alone are not proof. |
| Camera · BR-E1 modeCanon EOS R6 Mark II / III | Current | Bonded pairing, reconnect, and stateless movie-record trigger through Canon Trigger. | No recording-state readback. EOS R6 is not claimed. |
| Camera · smartphone modeCanon EOS R6 Mark II / III | Verified bounded | Explicit movie Start/Stop, camera-reported recording state, automatic wake, and explicit power-down. | Full Wi-Fi/CCAPI handoff remains blocked; extended lifecycle gates remain. |
| CameraInsta360 X3 | Supported | Operator-approved operation through Ble(e)p’s GPS Remote path. | Complete reconnect, power, and coexistence coverage remains open. |
| CameraInsta360 X4 | Supported | Operator-approved operation through Ble(e)p’s GPS Remote path. | Complete reconnect, power, and coexistence coverage remains open. |
| CameraInsta360 X4 Air | Supported | Operator-approved operation through Ble(e)p’s GPS Remote path. | Complete reconnect, power, and coexistence coverage remains open. |
| CameraInsta360 X5 | Supported | Pairing, initial state, Start/Stop, reported recording state, shutdown, and physical wake. | Fresh verification of returning wake-address routing remains open. |
| CameraDJI Osmo Action 5 Pro | Verified bounded | On-panel first-pair code, explicit Start/Stop, and camera-originated recording status. | Reconnect, forget/re-pair, and coexistence cycles remain open. |
| CameraDJI Osmo 360 | Verified bounded | On-panel first-pair code, explicit Start/Stop, and camera-originated recording status. | Reconnect, forget/re-pair, and coexistence cycles remain open. |
| Camera · phone shutterGoogle Pixel 9 | Verified bounded | Bonded reconnect and BLE HID volume-up shutter in a mixed sequence. | Other phone models and multi-phone verification remain open. |
| Camera · phone shutter iPhone · Samsung Galaxy · OnePlus · Xiaomi / Redmi · other Google Pixel models | Experimental | The existing Phone Camera mode sends a Bluetooth volume-up key. Keep the camera app open and set its volume button to take a photo. Camera-setting guides: Apple · Samsung · OnePlus · Redmi. | These families still need Ble(e)p pairing, reconnect, and shutter testing. A working built-in volume key does not confirm Bluetooth shutter compatibility. Recording state is not reported back. |
| Recorder · AK-BT1Tascam Portacapture X8 | Current, bounded | Explicit record Start/Stop, recorder-confirmed state, and state restoration after reconnect. | Battery, media, mixer, and broader recorder control are outside this tranche. |
| Local networkHome Assistant entities | Mixed sequence verified | Four selected lights, switches, input booleans, buttons, scenes, or scripts over local HTTP/WebSocket. | Full entity-domain, lifecycle, failure-recovery, and endurance coverage remain open. |
| Camera · Open GoPro BLEGoPro MAX2 | Supported | Bonded pairing, explicit Start/Stop, confirmed recording state, Sleep, physical wake, reconnect, and post-boot Ready. | Other GoPro models and broader coexistence coverage remain open. |
| Light · amaranRay 60c | Supported | Unified Aputure Light controls and per-node power/look routing. | Recovery, multi-fixture isolation, and soak gates remain open. |
| Light · amaranAce 25c | Supported | First-time setup, exact identity, per-node power/look routing, RGB, and power confirmation. | Full four-fixture isolation, color confirmation, fallback, and soak remain open. |
| Light · AputureMC Pro | Supported | First-time setup, exact identity, per-node power/look routing, RGB, and power confirmation. | Full four-fixture isolation, color confirmation, fallback, and soak remain open. |
| Light · AputureMT Pro | Supported | First-time setup and unified Aputure Light controls are physically verified. | Current firmware labels it MC Pro; exact identity mapping, recovery, and soak remain open. |
| Light candidates · amaranPano 60c / Pano 120c | Candidate | Unified Aputure Light control and routing support is intended. | These exact fixtures have not passed their hardware gates. |
| LightZhiyun MOLUS X100 / X60RGB | Experimental | X100 power and CCT/brightness; X60RGB adds captured RGB hue/saturation through the shared mesh path. | Complete panel-originated optical, reconnect, recovery, and coexistence gates remain open. |
| Camera candidatesInsta360 GO 3 / GO Ultra | Candidate / probe | Separate catalog targets preserve room for model-specific research. | GPS Remote compatibility and shutter behavior are not established. |
| CameraSony RMT-P1BT-compatible | Research | Capture-required onboarding identifies the intended research boundary. | No savable driver or camera test yet. |
| RecorderDeity PR4 | Later | No supported control path is claimed. | Transport and protocol research have not started. |
03 Before you build
Compatibility is a test result,
not a vibe.
Firmware can implement a protocol while a specific model, firmware revision, reconnect path, or mixed-device sequence remains untested. Ble(e)p keeps those boundaries visible so you can decide what belongs in your studio.