Skip to content

Conversation

@8bitgentleman
Copy link

I recently got an ES-30M scale and since it wasn't working with openScale decided to do some investigating. The ES-30M scale was connecting but not recording measurements due to incomplete protocol handshake and incorrect frame parsing.

Fixes #986

Problem

The ES-30M scale (advertises as "QN-Scale") was connecting successfully but not
recording measurements. The app showed "step on barefoot" but weight data never
appeared.

Root Cause

  1. Incomplete handshake: The scale requires specific responses to 0x21 opcode
    before sending weight data
  2. Wrong frame format: ES-30M uses a different byte layout than other QN
    scales

Solution

1. Fixed Protocol Handshake

  • 0x21 handler: Now sends TWO 0xA0 responses (was sending one incorrect
    response)
  • 0x14 handler: Sends proper 0x20 time sync with real timestamp (was sending
    fixed bytes)
  • Added 0x22 query: After 0xA0 responses, queries stored data

2. Added Format Detection for 0x10 Weight Frames

ES-30M uses a different byte layout:
ES-30M format:
byte[3] = unit (kg/lb)
byte[4] = stable flag (0x00/0x01/0x02)
bytes[5,6] = weight (big-endian)
bytes[7-10] = resistances

Original QN format:
bytes[3,4] = weight (big-endian)
byte[5] = stable flag (0x01)
bytes[6-9] = resistances

Detection logic: If byte[4] <= 0x02 AND weightScaleFactor == 10.0, use
ES-30M format.

3. Added Opcode Handlers

  • 0x23 (user data frames)
  • 0xA1, 0xA3 (acknowledgments)

Backward Compatibility

Format detection ensures existing QN scales continue working with the original
format. ES-30M is auto-detected based on:

  • Byte pattern (stable flag at byte[4])
  • Weight scale factor (10.0 for ES-30M vs 100.0 for most others)

Testing

  • ✅ ES-30M now successfully records weight and body composition
  • ✅ Format detection works correctly
  • ⚠️ Other QN scale models should be tested to confirm no regression

Technical Details

This is based on BLE traffic capture comparing the official Renpho app (working) vs openScale (not
working). The ES-30M requires a complete handshake sequence before transmitting
weight data.

The ES-30M scale was connecting but not recording measurements due to
incomplete protocol handshake and incorrect frame parsing.

Changes:
- Fix 0x21 handler to send two 0xA0 responses (was sending one incorrect response)
- Add 0x22 data query after 0xA0 responses
- Fix 0x14 handler to send proper 0x20 time sync with real timestamp
- Add format detection in 0x10 weight parser for ES-30M vs other QN scales
  - ES-30M: byte[4]=stable, bytes[5,6]=weight, bytes[7-10]=resistances
  - Original: byte[5]=stable, bytes[3,4]=weight, bytes[6-9]=resistances
- Add handlers for 0x23, 0xA1, 0xA3 opcodes

The format detection is backward compatible and does not affect other
QN scales. Detection logic: byte[4] <= 0x02 AND weightScaleFactor == 10.0f
indicates ES-30M format.

Fixes oliexdev#986
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug on connecting to RENPHO Elis 1 (Model: ES-30M-US)

1 participant