Conversation
* Implement Phase 2 of the sync protocol using a self-describing JSON format (`VALUES_JSON`) to synchronize all measurement types, including custom ones. * Add a snackbar notification in `SharedViewModel` to prompt the user to open the sync app if it is installed but unreachable (e.g., force-stopped). * Introduce coalesced "changed" sync triggers for bulk import and backup restore operations to improve efficiency and prevent foreground service spam. * Update sync intents and `DatabaseProvider` to include `userId` and measurement IDs for better multi-user routing and bidirectional synchronization. * Implement measurement deletion support in `DatabaseProvider` via timestamp matching. * Bump sync API version to 2.
I added the values for my Beurer BF450 scale in BeurerSanitasHandler.kt and it worked
* feat: Add support for Taylor 5331891 BIA Scale Adds TaylorBIAHandler for the Taylor Body Composition Bathroom Scale (advertised as "5331891 BIA Scale"). The scale exposes service 0xFFB0 (FFB1 write, FFB2 notify), the same GATT layout as the MGB family, so MGBHandler previously mis-claimed it and the session timed out with no measurement because the notification format differs. Protocol (reverse-engineered from btsnoop HCI logs): - 20-byte NOTIFY frames "AC 27 <flag> <chan> <hi> <lo> ... 24 D5 <cksum>". - weight_kg = (((chan & 0x01) << 16) | (hi << 8) | lo) / 1000.0, where the channel byte's low bit is weight bit 16 (0x8C < 65.536 kg, 0x8D >= 65.536 kg). - flag 0x80 = stable, 0x01 = summary record. Verified against two captures (171.2 lb and 173.0 lb readings). The scale transmits weight only; body composition is computed app-side by the vendor and is not exposed over BLE, so only LIVE_WEIGHT_STREAM is implemented. TaylorBIAHandler is registered ahead of MGBHandler in ScaleFactory (first non-null supportFor wins). Includes unit tests for the weight decode. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat: publish Taylor 5331891 reading via stability detection Under openScale's minimal init the scale never sends an explicit stable (0x80) or summary (0x01) frame; it streams live values that plateau. The previous code published only via a flat fallback timer, which could capture a still-settling value. Publish instead when the same weight repeats STABLE_FRAMES (4) times in a row (~1s at the scale's ~4Hz stream) — the settled value repeats verbatim while step-on ramp values are all distinct. Explicit stable/summary frames are still honored, and a last-resort timer (FALLBACK_DELAY_MS) covers weight that never settles. Verified on device: records 77.65 kg = 171.2 lb. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* Simplify `supportFor` by removing the service UUID check and relying solely on device name matching.
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
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.
No description provided.