Files
homelab/esphome/shelly-ble-proxy.yaml
claude-botandClaude Opus 4.8 33283754ba feat(shelly-manager): ServiceAccount + RBAC for ESPHome firmware pipeline
shelly-manager will build+flash BLE proxies by spawning short-lived
esphome Jobs (on the shelly-manager-iot macvlan → mDNS → OTA:3232) and
streaming their logs. Give it a namespace-scoped identity to do so:

- ServiceAccount shelly-manager + Role shelly-manager-firmware
  (jobs: create/get/list/watch/delete; pods: get/list/watch;
   pods/log: get) + RoleBinding. No cluster-wide, secret, or exec rights.
- Wire serviceAccountName into the Deployment.
- Sync esphome/shelly-ble-proxy.yaml logger to the lean level already
  OTA'd to the device (esp32_ble_client DEBUG, not VERBOSE) so the PVC
  stops filling; VERBOSE is now an on-demand diagnostic via the pipeline.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 11:54:04 +02:00

76 lines
2.8 KiB
YAML

# M5 Atom Echo — DEDICATED Bluetooth proxy for shelly-manager BLE provisioning.
#
# Source of truth for the device config. Load it into the ESPHome Device Builder
# (https://esphome.home.renner.uno) — paste as a new device, or keep in sync with
# the dashboard's /config copy on the esphome-data PVC (the dashboard reads from
# the PVC, not from git).
#
# Intentionally NOT a voice satellite: the mic/speaker/voice_assistant components
# are omitted. bluetooth_proxy + voice together overflows the ESP32-PICO (no
# PSRAM) and boot-loops (esphome/issues#6166, #6217). Lean = active BLE
# connections fit.
#
# Role: this proxy lends its BLE radio to shelly-manager's ble-agent, which drives
# it over the ESPHome native API (aioesphomeapi / bleak-esphome) to provision a
# WiFi-less Shelly over mOS RPC-over-BLE. Dedicated to the ble-agent — do NOT also
# adopt it into Home Assistant, or they contend for the few BLE connection slots.
substitutions:
name: shelly-ble-proxy-1
friendly_name: Shelly BLE Proxy 1
esphome:
name: ${name}
friendly_name: ${friendly_name}
esp32:
board: m5stack-atom
framework:
type: esp-idf # required for a stable bluetooth_proxy
# Lean steady-state logging: DEBUG globally is enough to see a GATT connection
# attempt's outcome without the per-packet VERBOSE firehose that fills the PVC.
# Bump esp32_ble_client back to VERBOSE temporarily (via the flash pipeline)
# only when actively diagnosing a failed BLE provisioning.
logger:
level: DEBUG
logs:
esp32_ble_client: DEBUG
esp32_ble_tracker: DEBUG
bluetooth_proxy: DEBUG
# ESPHome native API — how shelly-manager's native client connects. The
# encryption key is the shared fleet Noise PSK (Ble__Discovery__Key there must
# equal this value).
api:
encryption:
key: !secret shelly_ble_proxy_api_key
# OTA enabled so the config can be iterated remotely (no more USB re-flash per
# change). Bootstrapping it costs one USB flash; after that, push over WiFi from
# the ESPHome Device Builder. Set shelly_ble_proxy_ota_password in the dashboard
# secrets before flashing.
ota:
- platform: esphome
password: !secret shelly_ble_proxy_ota_password
wifi:
ssid: !secret iot_wifi_ssid
password: !secret iot_wifi_password
# The IoT VLAN advertises a global IPv6 prefix (RA/SLAAC). Enable IPv6 so this
# device is dual-stack like the rest of the segment, rather than v4-only.
network:
enable_ipv6: true
# Active BLE proxy — enables the GATT connect + characteristic read/write that
# Shelly's mOS RPC-over-BLE needs to provision a WiFi-less device
# (WiFi.SetConfig / Mqtt.SetConfig / Shelly.SetAuth). Default 3 connection slots
# is ample; provisioning is one device at a time. Active scan surfaces the
# Shelly's advertised name/service so the agent's /scan can filter to it.
esp32_ble_tracker:
scan_parameters:
active: true
bluetooth_proxy:
active: true