Add support for the Hume Health Dara 2.0 scale - #1486
Open
andyjk15 wants to merge 1 commit into
Open
Conversation
Fixes oliexdev#1448. This device advertises literally as "Dara 2.0" and its BLE Device Information service reports manufacturer "LeFu Scale" — not FitTrack, despite sharing a model name with FitTrack's unrelated "Dara" scale (a different product on a different chip family, 0xFFB0/AC02 framing vs this device's 0xFFF0/0xCF framing). That name collision is why FitTrackDaraHandler's "FITTRACK"-prefixed name match never fired for this unit, even after 3.1.2 shipped named FitTrack Dara 2.0 support. New HumeDara2Handler matches on the device's actual advertised name and decodes the real 11-byte measurement frame (reverse-engineered from five real weigh-ins, ground truth documented in the class doc comment): weight and a raw BIA impedance reading, both cross-checked against the official Hume app's own display. Body composition (fat/water/muscle/ bone/BMR) is computed from that impedance via openScale's existing StandardImpedanceLib generic formula rather than guessed frame offsets, since the remaining frame bytes don't correlate with anything Hume's own app displays — this is an approximation of Hume's proprietary numbers, not a device reading, and the class doc comment states the measured accuracy against a real reading (~1-2% off on skeletal muscle %/BMR, ~15% on fat%/water%/lean mass, ~24% on bone). Kept as a sibling of ExcelvanCF36xHandler (same GATT layout and 0xCF frame header, evidently the same underlying chip family under a different rebrand) rather than merged into it, since the measurement frame shape differs and the device names don't collide — matching this codebase's existing one-handler-per-rebrand pattern.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #1448.
What
Adds
HumeDara2Handlerfor the Hume Health "Dara 2.0" (BLE Device Information reports manufacturer "LeFu Scale"). It's a different, unrelated device from FitTrack's own "Dara" (added in #1430) despite sharing the model name — a different chip family (0xFFF0/0xCF framing vs. 0xFFB0/AC 02…), which is whyFitTrackDaraHandler's"FITTRACK"-prefixed name match never caught it, and why it still showed "Not Supported" after #1430 shipped.Same GATT layout as
ExcelvanCF36xHandler("Electronic Scale" units) — 0xFFF0/0xFFF1 write / 0xFFF4 notify, same0xCFframe header, same 8-byte user-config write — evidently the same underlying chip family under a different rebrand. Kept as a separate handler since the measurement frame is a different, shorter shape and the device names don't collide.Measurements
StandardImpedanceLib(generic BIA formula), not the device's own numbers. The remaining frame bytes don't correlate with anything the Hume app displays, and there isn't room in an 11-byte frame for the ~13 metrics Hume shows — most of it is evidently computed client-side by Hume, not transmitted. Measured accuracy against one real reading: skeletal muscle %/BMR within ~1-2%, fat%/water%/lean mass within ~15%, bone ~24%. Full reasoning and the ground-truth frame table are in the class doc comment.How it was verified
HumeDara2HandlerTestcovers weight/impedance decode, checksum, and live-vs-locked frame detection against the real captured frames.ScaleFactoryTestpins this device against the FitTrack/Excelvan collision that caused the original bug.Notes
implementedstill claimsBODY_COMPOSITIONsince the handler does populate those fields, but they're a generic-formula approximation, not device-reported values — documented prominently in the class doc comment so nobody mistakes them for exact.