fix: measureData returns no data on AP/SG v1 API due to missing deviceModel and lossy MAC-derived serial#25
Open
tlvu2697 wants to merge 1 commit into
Conversation
… MAC-derived serial Two independent bugs in OmronConnect1.get_measurements() combined to make the Kii measureData call always return deviceModelList: null, even for a valid registered device and date range: 1. The request body omitted `deviceModel`, which the backend silently requires to route the query correctly (confirmed by comparing against a real traffic capture of the official app, which always sends it). 2. `device.serial` reconstructs the 8-byte Kii deviceSerialID from the 6-byte BLE MAC via ble_mac_to_serial(), but serial_to_mac() (used when storing the device from get_registered_devices) discards the serial's last two bytes converting to a MAC in the first place. The round trip is lossy, so the reconstructed serial rarely matches the real one. Fix: send deviceModel in the request (derived from OmronDevice.name, which is always "<deviceModel>:<userNumberInDevice>"), and store the real deviceSerialID on OmronDevice when it's known (from get_registered_devices) so `serial` no longer needs to guess. Devices added before this fix won't have real_serial populated in their config entry and will still use the lossy fallback; re-run `add`/`init` device discovery to pick up the real serial. Verified against a live account: measureData now returns real measureList/bodyIndexList data instead of an empty stub, and `sync` successfully downloads and cross-matches real weigh-ins against Garmin.
Author
|
Hi @bugficks, I was unable to pull weight data on my account (AP/SG region) - sync always reported "No new measurements" regardless of date range. With Claude's help I diagnosed and fixed it (see PR description for the full root-cause writeup), and I've confirmed it now works end-to-end on my own account. I don't have much background in Python or the OMRON APIs myself, so I'd really appreciate it if you could take a look and let me know if the approach looks right, or if there's a better way to fix it. Thanks for maintaining this project! |
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.
Problem
On the AP/SG v1 API,
sync/get_measurementsreports "No measurements found" for a valid, correctly registered device — even with a wide date range and correct device/user selected. The account authenticates fine,omron listfinds the device correctly; the measurement query just always comes back empty.Root cause
Two independent bugs in
OmronConnect1.get_measurements()combine to make the KiimeasureDatacall always returndeviceModelList: null:Missing
deviceModelin the request body. The backend silently requires it to route the query — omitting it always yields an emptydeviceModelList: null, even for an otherwise-correct request. This was confirmed by capturing traffic from the official app, which always sends this field (there's even a comment in the existing code noting the field exists, but it was never actually included:# "deviceModel": "OGSC", "HBF-xxx", ...).Lossy MAC↔serial round-trip. Kii's real
deviceSerialIDis 8 bytes, butserial_to_mac()(used when storing a device fromget_registered_devices) only encodes 6 of those bytes into the MAC address, discarding the last two.ble_mac_to_serial()— used to reconstruct the serial for the query — can't recover those discarded bytes, so it produces a serial that doesn't match the real one on accounts/devices where those trailing bytes aren't the assumed fixed pattern. The query then targets a device ID that doesn't exist, so it correctly (from the server's point of view) returns nothing.Fix
deviceModelin themeasureDatarequest body, derived fromOmronDevice.name(always stored as"<deviceModel>:<userNumberInDevice>", so no schema change is needed to get it).real_serialfield toOmronDevice.get_registered_devices()now populates it with the server's actualdeviceSerialID, and theserialproperty prefers it over the reconstructed value. Devices without it (e.g. added manually viaadd --macaddr, or added before this fix) keep falling back to the existingble_mac_to_serial()derivation, so this is backward compatible with existing config files.Verification