Patch release on top of v1.10.0. Two fixes driven by a Phase 1 test report on #116.
ESPHome proxy: no more silent drops on dual-mode scales
If a scale matched an adapter that defines both parseBroadcast and charNotifyUuid (e.g. a QN-Scale family scale like the Elis 1 / ES-30M), and the broadcast frame was not weight-bearing, the ReadingWatcher dropped it without logging anything. You would step on the scale, see the Renpho app read instantly, and nothing would happen in BLE Scale Sync.
The handler now warns once per MAC (LRU-deduped) whenever a matched adapter has a GATT path and produced no usable broadcast. Concretely:
[BLE] QN Scale at FF:04:00:22:55:0F needs a GATT connection for weight data, which
the ESPHome proxy transport does not yet support (Phase 1 is broadcast-only). Use
the native BLE handler or the ESP32 MQTT proxy for this scale until Phase 2 lands.
The Elis 1 specifically is a pure GATT scale (see #75 for the full handshake). Phase 1 of the ESPHome transport cannot read it today. Phase 2 (mapping ScaleAdapter GATT primitives onto bluetooth_gatt_* Native API calls) is the fix, tracked on #116.
Logger: honor runtime.debug: true from config
Setting debug: true under runtime: in config.yaml did not switch the log level to DEBUG. Only the DEBUG=true env var did. HA Add-on users who toggled debug as an option saw no verbose BLE logs in the Supervisor log viewer. Fixed: index.ts now calls setLogLevel(DEBUG) when appConfig.runtime?.debug is set, alongside the existing env-var path.
Install
Home Assistant: update the BLE Scale Sync add-on from the add-on store.
Docker: ghcr.io/kristianp26/ble-scale-sync:1.10.1 or :latest.
Standalone: git pull && npm install.
Full changelog: CHANGELOG.md