Provisioning a Shelly over BLE fails at the GATT connect and the cause is
inside the ESP's BLE stack — invisible from shelly-manager's side. To
diagnose and iterate without a USB re-flash per change:
* ota: (esphome platform) so future config changes push over WiFi from the
ESPHome Device Builder. Bootstrapping costs one USB flash; set
shelly_ble_proxy_ota_password in the dashboard secrets first.
* logger DEBUG with esp32_ble_client=VERBOSE / esp32_ble_tracker,
bluetooth_proxy=DEBUG, so a connect attempt logs its progress and the
failure reason.
Takes effect on the (one) USB re-flash; thereafter iterate remotely.
Co-Authored-By: Claude Bot <claude-bot@renner.uno>
ESPHome device configs
Source-of-truth YAML for ESPHome devices in the homelab. These are built and
flashed through the ESPHome Device Builder running in-cluster at
https://esphome.home.renner.uno (see kubernetes/apps/home-assistant/esphome-*
and the esphome-gate Authentik blueprint).
The dashboard reads configs from its own /config on the esphome-data PVC — it
does not sync from git. So the flow is: edit here → paste/copy into the
dashboard → compile + flash. Keep the two in sync manually; git is the reviewed,
backed-up copy.
Devices
| File | Device | Role |
|---|---|---|
shelly-ble-proxy.yaml |
M5 Atom Echo (ESP32-PICO) | Dedicated Bluetooth proxy that lends its BLE radio to shelly-manager's ble-agent for provisioning WiFi-less Shellys over mOS RPC-over-BLE. |
Secrets
The dashboard's secrets.yaml (on the PVC — not in git) must define:
iot_wifi_ssid: "<IoT SSID>"
iot_wifi_password: "<...>"
# 32-byte base64 — dashboard "Generate", or: openssl rand -base64 32
# This value is the handoff to the ble-agent (its BLE_PROXY_NOISE_PSK).
shelly_ble_proxy_api_key: "<...>"
Flashing
USB only — the config has no OTA and no recovery AP by design. Flash (and any later update or WiFi-recovery) is browser-side over USB (ESP Web Tools / Web Serial, Chrome/Edge): plug the Atom Echo into your computer, open the dashboard, Install → Plug into this computer.