A small but meaningful patch: a real-world bug fix for Renpho ES-26M owners contributed by the community, and a UX improvement that saves ESPHome proxy users a two-minute head-scratching loop when they happen to own a GATT-only scale.
Fixed
Renpho ES-26M handshake (#128, contributed by @fromport)
The ES-26M sends an 18-byte 0x12 scale-info frame where byte[1] is the packet length and bytes[2-7] carry the device MAC. The QN-Scale adapter was interpreting byte[2] as the protocol type, which on the ES-26M is actually the first MAC byte. That yielded proto=0xFF, caused every subsequent handshake command to be rejected by the scale, and produced a session where no 0x10 weight frames ever arrived.
The adapter now detects the long-frame format (data.length >= 18 && data[1] === length) and falls through to the ES-30M code path with weightScaleFactor=10, so the existing heuristic auto-corrects the weight divisor. The unconditional skip of R1=R2=0 stable frames in ES-30M mode is also lifted: the ES-26M never reports impedance when the user is wearing socks, and those frames are the only stable reading available in that scenario. Bare-feet measurements (with impedance) still take priority via the existing final-frame path.
If you own an ES-26M and it has been silently failing for you, this release fixes it end to end. Huge thanks to @fromport for running the full diagnosis with HCI captures and iterating the patch through review.
Changed
ESPHome proxy Phase 1 capability summary on connect (#133)
Reported by @geniusliang: running a Yunmai Mini (a GATT scale) through ble.handler: esphome-proxy only produced the generic line Timed out waiting for any recognized scale broadcast via ESPHome proxy after 60 seconds, with no hint that the real problem was that Phase 1 of the ESPHome proxy transport only supports broadcast scales. The per-MAC GATT warning added in v1.10.1 only fires when the scale's advertisement actually reaches the proxy and matches an adapter, which is not guaranteed for slow-advertising scales, so users with a Yunmai / Mi Scale 2 / Beurer / etc. could hit the silent timeout.
The handler now logs a one-line capability summary the moment it connects, naming every configured adapter as either broadcast-capable or GATT-only and pointing at the native BLE / mqtt-proxy workarounds. The constraint is visible in the first second of logs instead of after a reproduce-and-wait cycle.
Phase 2 of the ESPHome proxy (full GATT over Native API) is still tracked in #116.
Docs
- CONTRIBUTING project tree refreshed to reflect the current layout (HA Add-on, ESPHome proxy handler, updated scale/test files).
- README contributors moved to a GitHub-style table with inline avatars. @fromport added for the ES-26M contribution.
Thanks
- @fromport for the ES-26M deep dive and the PR that ended this release's "Fixed" section before it even reached me
- @geniusliang for the clean ESPHome proxy repro that exposed the UX gap in the Phase 1 log output
Full changelog: CHANGELOG.md#1102---2026-04-24