Mi Scale v2 driver hangs in "waiting for notification" on weight-only Mi Smart Scale 2 (XMTZC04HM)

[l9i]

Summary

The "Xiaomi Mi Scale v2" driver assumes the Body Composition service (0x181B / characteristic 0x2A9C, i.e. the XMTZC05HM "MIBFS" protocol). The weight-only Mi Smart Scale 2 (XMTZC04HM) advertises as MI SCALE2 but does not expose 0x181B — it serves the Weight Scale service (0x181D / 0x2A9D indications, Mi Scale v1-style protocol). Auto-detection routes this hardware to v2 mode with no user-facing override, the notify subscription on 0x2A9C fails, the failure is only logged at warning level, and the UI hangs indefinitely in "waiting for notification" with no user-facing error.

Every XMTZC04HM owner hits this: model detection is fully automatic, both heuristic branches (name match and vendor-service match) misclassify this device, and no manual model selection exists — the scale is simply unusable with openScale.

Environment

• openScale 3.1.2-oss (76), package com.health.openscale.oss
• Google Pixel 10, Android 17 (API 37), build CP2A.260805.005
• Reproduced identically on Pixel 9
• Scale: Xiaomi Mi Smart Scale 2 (weight-only), advertises MI SCALE2, firmware V1.0.0.12 (from 0x2A28)

Steps to reproduce

1. Add a weight-only Mi Smart Scale 2 (XMTZC04HM) in openScale. Auto-detection classifies it as "Xiaomi Mi Scale v2" — MiScaleHandler.supportFor() forces V2 for the advertised name MI SCALE2 (and independently via the present 0x1530 vendor service), and there is no way to override the detected model.
2. Step on the scale, wait for a stabilized measurement, connect from openScale.

Actual behavior

• Connection and service discovery succeed.
• Driver attempts to enable notifications on 0x2A9C (service 0x181B); this fails because the service does not exist on this hardware. Log line:
  W/GattScaleAdapter: Failed to initiate notify for 00002a9c-0000-3512-...
• UI shows "waiting for notification" indefinitely. No error, no hint that the device model doesn't match the driver.

Expected behavior

• After service discovery, the driver should validate that its required service/characteristic exists. If 0x181B is absent, fail fast with an actionable message, e.g.:
  "This device does not expose the Body Composition service (0x181B)." — or better, auto-detection should reclassify it as v1 from the GATT table, since the hardware speaks the v1 protocol (0x181D) fine.
• Since detection is automatic and unoverridable, GATT-based disambiguation (0x181B vs 0x181D presence at connect time) is the only robust fix — advertised names cannot distinguish the models.

Evidence (Debug handler GATT dump)

Full service dump from the Debug driver — note no 0x181B service present:

Service 0x1800  (Generic Access)
Service 0x1801  (Generic Attribute)
Service 0x180a  (Device Information)
Service 0x181d  (Weight Scale)
  └─ Char 0x2a2b props=READ|WRITE       (Current Time)
  └─ Char 0x2a9e props=READ             (Weight Scale Feature)
  └─ Char 0x2a9d props=INDICATE         (Weight Measurement)
  └─ Char 00002a2f-0000-3512-2118-0009af100700 props=WRITE|NOTIFY
Service 00001530-0000-3512-2118-0009af100700  (vendor/DFU)
  └─ 00001531-... WRITE|NOTIFY
  └─ 00001532-... WRITE_NR
  └─ 00001542-... READ|WRITE|NOTIFY
  └─ 00001543-... READ|WRITE|NOTIFY

Indications on 0x2A9D deliver valid weight frames while connected, e.g.:

[22 2E 3B B2 07 01 01 00 36 15]   → weight LE 0x3B2E = 15150 / 200 = 75.75 kg
[A2 2E 3B B2 07 01 01 00 36 1A]   → same weight, control 0xA2 = stabilized

(Timestamp bytes decode to 1970-01-01 — scale RTC never initialized by a vendor app; unrelated to this issue but may matter for stored-history parsing.)

Full openScale debug log available on request.

Suggested fixes (any subset)

1. Fail fast: v2 driver checks for 0x181B after service discovery; if absent, disconnect with an explicit error naming the likely model mismatch instead of waiting forever.
2. Elevate the log: Failed to initiate notify for a driver-critical characteristic should be an error surfaced in the UI, not a warning in the file log.
3. GATT-based model detection: distinguish XMTZC04HM vs XMTZC05HM by service list at connect time, not advertised name — required, since users cannot override the auto-detected model.
4. Docs: note in the supported-devices list that the weight-only "Mi Smart Scale 2" advertises MI SCALE2 but speaks the v1 protocol.

I have a patch implementing fixes 1–3 (connect-time variant re-detection via the history characteristic, fail-fast with a user-visible error, plus unit tests) and will open a PR referencing this issue.