A 15 ms link with max_ce_len=0 sent one DLE PDU per event and capped
badge frames at ~17 KB/s. Request 7.5–15 ms and a long CE, and refill
the single CoC TX slot instead of treating EBUSY as a hard failure.
Enable Tag/AP reboot recovery and image restore, plus OTS DATA_WRITE.
AP start only brings up PAwR; scan is explicit via restart_scan.
Ported onto current master ESL/OTS APIs (ble_esl_state_t,
ble_esl_key_material_t, ble_esl_address_t at the public boundary).
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.
jiminxiang