fix(qn-scale): support store-and-forward variants that deliver 0x23 records#233
Closed
built-dev wants to merge 1 commit into
Closed
fix(qn-scale): support store-and-forward variants that deliver 0x23 records#233built-dev wants to merge 1 commit into
built-dev wants to merge 1 commit into
Conversation
…ecords
Some QN-protocol Renpho units (confirmed on a real Elis 1 advertising as
'Renpho-Scale') never stream live 0x10 weight frames. The scale measures
on its own, stores the finished measurement, and delivers it as a 0x23
record right after the handshake — frames the adapter previously ignored
('historical record, no action needed'). Every session ended in
'Scale disconnected before reading completed' with zero readings.
Observed 19-byte 0x23 layout (captured from hardware):
[3] total record count (00 = empty 'no more records' frame)
[4] record index, 1-based
[6-9] measurement timestamp (LE, seconds since 2000-01-01)
[10-11] weight (BE, factor-scaled; alternate-factor heuristic applies)
[12-13] R1, [14-15] R2 (BIA resistances)
Two changes:
- parse 0x23 records as readings, with a timestamp set to dedup replays
across reconnects
- when the history is empty (we connected mid-measurement, so the
in-progress reading is not stored yet), re-send the 0x22 start command
every 5s (max 12x); the scale then delivers the fresh record
in-session — typically by the third nudge, ~15-20s after step-on
Verified end-to-end on hardware: previously zero readings; with this
change every weigh-in lands, whether the connection happens before,
during, or after the measurement.
Owner
|
Closing this. The 0x23 stored-record support it adds is already implemented and shipped: A few things to keep in mind for any future PR here:
If you have a QN variant that still does not read on v1.18.0, please open a fresh issue with an HCI capture and the ground-truth values and I will look into it. |
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
2 participants
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
Some QN-protocol Renpho units never stream live
0x10weight frames. Confirmed on a real Renpho Elis 1 (advertises asRenpho-Scale, FFF0 + AE00 services, 18-byte0x12scale info withfactor=10): the scale measures autonomously, stores the finished measurement, and delivers it as a0x23record right after the handshake completes. Since the adapter ignores0x23("historical record, no action needed"), every session ends inScale disconnected before reading completedand the scale produces no readings at all.There's a second wrinkle: an always-on listener connects the moment the scale wakes (it only advertises when stepped on), i.e. mid-measurement — at which point the scale reports an empty history and never volunteers the fresh record on its own.
Observed 0x23 layout (19 bytes, captured from hardware)
00= empty "no records" frame)Example real frame:
23 13 ff 01 01 f0 aa c9 bd 31 1e 5a 01 f1 01 ef 00 00 e2→ 77.7 kg, R1=497.Fix
0x23records as readings, deduplicating replays across reconnects via the record's scale-side timestamp.0x22start command every 5 s (max 12×). The scale then delivers the new record in-session — typically by the third nudge, ~15–20 s after step-on. Timer is cleaned up on reconnect/record/write-failure and never starts without an active connection.Live
0x10parsing is untouched; scales that stream normally behave exactly as before (0x23empty frames merely arm the nudge, and a delivered0x10reading was already terminal).Testing
0x23path (real-capture frame, factor heuristic, multi-record session, empty terminator, replay dedup, R2 fallback) in the existingqn-scale.test.tsstyle.tsc --noEmitandeslintclean.This may explain other "connects fine but 'disconnected before reading completed'" reports on Renpho/QN units.
🤖 Generated with Claude Code