Detect and drive the display-only ble_uart_vibe_indicator sample alongside
the interactive MiaoBan companion device, and let multiple OpenCode instances
each bind their own indicator channel.
- plugin: after connect, probe the device over the daemon's generic /request
path and classify it as vibe_indicator / generic / unknown — a vibe_indicator
answers the indicator_count capability query, a 502 marks a generic device,
and a transport failure stays unknown for retry on a later refresh. The daemon
stays a generic transport and is unchanged; detection is a demo concern.
- plugin: route by device_type. The vibe_indicator mirrors OpenCode activity
as four lamp states on its bound channel — executing (green blink),
success (green solid), waiting-for-user (yellow solid, on permission
prompts, decision left to the TUI), and error (red solid, on session.error
and the following idle). Other devices keep the existing session.status /
permission round-trip.
- plugin: add indicator_bind_channel / indicator_unbind_channel /
indicator_show_binding tools. Each channel has at most one live owner:
binding a channel owned by another running instance fails (force to take
over), and stale claims are reclaimed via process-liveness checks. The
per-directory binding is persisted and re-claimed across restarts
(OPENCODE_BLE_BINDING_FILE).
- docs: document device detection, lamp effects, and channel binding.
- Add type assertion for event.type to bypass strict TS compilation errors
- Accept both 'permission.asked' and 'permission.updated' event types
- Add normalizePermissionEvent() to handle internal vs SDK event property
format differences (pattern vs patterns, type vs permission fields)
- Add RawPermissionEvent type for loose event property parsing
- Add troubleshooting section and subdirectory auto-loading note to README
Move the OpenCode companion guide into the ble_uart_service example.
Add English and Chinese Markdown guides with image assets.
Keep ESP-BLE-UART naming consistent across the example and bridge tooling.
