[ahineyushka]

Redmond SkyBalance scale support

Adds support for the following Redmond SkyBalance models:

• RS-73S
• RS-744S
• RS-745S
• RS-762S
• RS-773S

All five models use the same controller, Bluetooth protocol and functionality. They differ only in the product name and enclosure design, so they are registered under the same handler.

Verified hardware

RS-744S was tested on a real scale.

The implementation was verified using a Bluetooth HCI snoop capture and openScale on a real Android device.

Working features

• BLE GATT connection
• Bluetooth Weight Scale Service 0x181D
• Weight Measurement characteristic 0x2A9D
• Weight indications
• Live weight display while measuring
• Final/stable weight saved to openScale history
• Duplicate final measurements are ignored
• Phone date/time is used for the saved measurement because the device timestamp observed in the capture is stale

Not implemented

The following features are intentionally not implemented because they were not sufficiently verified from captured traffic:

• Body composition
• History download
• Time synchronization
• User synchronization
• Unit configuration
• Battery level

Testing

The implementation was tested on a real RS-744S:

1. The device is detected correctly.
2. The device connects successfully.
3. Intermediate live weight values are displayed while measuring.
4. The final weight is saved correctly.
5. Only one history entry is created for a measurement session.
6. The saved date and time are correct.

The other four model names are registered in the same handler based on the shared controller, protocol and functionality, but they were not individually tested on hardware.

No shared Bluetooth infrastructure was changed.
btsnoop_hci_sanitized.log

[ahineyushka]

REDMOND SkyBalance RS-744S — Bluetooth Protocol Reverse Engineering Notes

1. Overview

This document describes the Bluetooth Low Energy (BLE) communication observed between a REDMOND SkyBalance RS-744S smart scale and an Android device.

The protocol was investigated using an Android Bluetooth HCI snoop capture recorded during a real weighing session. The captured traffic was analyzed to identify the GATT service, characteristic subscription procedure, weight data format, and differences between live and final measurements.

The key finding is that the RS-744S uses the standard Bluetooth SIG Weight Scale Service, rather than a completely proprietary weight-transfer protocol.

The measurements are transferred using BLE GATT indications. The characteristic payload follows the standard Weight Measurement format, while the observed distinction between intermediate and final measurements is based on the presence of the timestamp field.

Hardware verification status: RS-744S was tested on a physical scale. The RS-73S, RS-745S, RS-762S, and RS-773S are considered related models that use the same controller, protocol, and functionality, differing in product name and enclosure design. Those four models have not been independently captured and verified in this investigation.

2. Bluetooth transport and GATT profile

The observed connection uses Bluetooth Low Energy and GATT.

Item | Value -- | -- Transport | Bluetooth Low Energy (BLE) Communication model | GATT client / GATT server Service | Weight Scale Service Service UUID | 0x181D Measurement characteristic | Weight Measurement Characteristic UUID | 0x2A9D Feature characteristic | Weight Scale Feature Feature UUID | 0x2A9E Measurement transfer | Indications Byte order | Little-endian for multi-byte characteristic fields

These examples come from separate measurement sessions in the capture.

7. Important timestamp limitation

The capture was collected in 2026, but the timestamps supplied by the scale were from July 2021.

This indicates that the scale's internal date/time was stale or otherwise incorrect at the time of capture.

No verified clock-synchronization procedure was identified in the analyzed traffic. Therefore, a client should not assume that the embedded timestamp reflects the actual date and time of measurement.

In the openScale implementation, the phone's current date/time is used for the saved measurement instead of trusting this stale device timestamp.

This is an implementation choice based on the observed device behavior, not a requirement imposed by the Bluetooth Weight Scale Service specification.

8. Practical client implementation

A client implementing this observed protocol can follow these steps:

1. Establish a BLE GATT connection.

2. Discover the Weight Scale Service (0x181D).

3. Locate the Weight Measurement characteristic (0x2A9D).

4. Discover its CCCD (0x2902) and enable indications by writing 0x0002.

5. Receive and acknowledge each ATT indication.

6. Parse the Flags byte before decoding optional fields.

7. Decode the two-byte weight as an unsigned little-endian integer.

8. Convert the weight according to the unit flag and resolution.

9. Treat timestamped values as final/stable results for the observed RS-744S behavior, while allowing timestamp-free values to update the live display.

10. Prevent repeated timestamped indications for the same stable result from creating duplicate history entries.

11. Use a trusted local time source if the device timestamp has not been verified as accurate.

The Weight Scale Feature characteristic (0x2A9E) is part of the standard service and can be read to determine advertised feature support. Its raw feature bitfield is not documented in this report because a validated interpretation of that value was not established here.

9. What has not been reverse-engineered

The investigation establishes the captured weight-measurement path, not every feature that might exist in the product.

The following functions have not been sufficiently verified and are not claimed to be supported:

• Body-composition measurements or proprietary body metrics

• Historical measurement download

• Clock synchronization

• User synchronization or user selection

• Unit configuration

• Battery-level reporting

• Any additional vendor-specific control commands

No vendor-specific setup command was identified as necessary for receiving weight indications in the analyzed session.

The absence of these features from this report should not be taken as proof that they do not exist; it means they were not established by the available capture.

10. Model coverage and limitations

The physical test and HCI protocol capture described here were performed with a REDMOND SkyBalance RS-744S.

The RS-73S, RS-745S, RS-762S, and RS-773S are included in the related-model support based on the understanding that they share the same controller, Bluetooth protocol, and functionality, with differences in product name and enclosure design.

Their protocol equivalence has not been independently confirmed through separate HCI captures. Anyone with access to one of these models could help validate this assumption.

11. References

• Bluetooth SIG — Weight Scale Service 1.0.1

• Bluetooth SIG — Assigned Numbers

These notes document observed behavior of a physical RS-744S and distinguish those observations from fields and rules defined by the standard Bluetooth Weight Scale Service. They are intended as a starting point for further testing and community verification, rather than as manufacturer documentation.

# REDMOND SkyBalance RS-744S — Bluetooth Protocol Reverse Engineering Notes

1. Overview

This document describes the Bluetooth Low Energy (BLE) communication observed between a REDMOND SkyBalance RS-744S smart scale and an Android device.

The protocol was investigated using an Android Bluetooth HCI snoop capture recorded during a real weighing session. The captured traffic was analyzed to identify the GATT service, characteristic subscription procedure, weight data format, and differences between live and final measurements.

The key finding is that the RS-744S uses the standard Bluetooth SIG Weight Scale Service, rather than a completely proprietary weight-transfer protocol.

The measurements are transferred using BLE GATT indications. The characteristic payload follows the standard Weight Measurement format, while the observed distinction between intermediate and final measurements is based on the presence of the timestamp field.

Hardware verification status: RS-744S was tested on a physical scale. The RS-73S, RS-745S, RS-762S, and RS-773S are considered related models that use the same controller, protocol, and functionality, differing in product name and enclosure design. Those four models have not been independently captured and verified in this investigation.

2. Bluetooth transport and GATT profile

The observed connection uses Bluetooth Low Energy and GATT.

Item	Value
Transport	Bluetooth Low Energy (BLE)
Communication model	GATT client / GATT server
Service	Weight Scale Service
Service UUID	0x181D
Measurement characteristic	Weight Measurement
Characteristic UUID	0x2A9D
Feature characteristic	Weight Scale Feature
Feature UUID	0x2A9E
Measurement transfer	Indications
Byte order	Little-endian for multi-byte characteristic fields

The service and characteristic UUIDs are defined by the Bluetooth SIG Weight Scale Service specification. The required Weight Measurement characteristic uses indications to deliver measurement data to the client.

Reference: [Bluetooth SIG — Weight Scale Service 1.0.1](https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/WSS_v1.0.1/out/en/index-en.html)

3. Enabling measurement indications

The client must enable indications on the Client Characteristic Configuration Descriptor (CCCD) associated with the Weight Measurement characteristic.

In the analyzed HCI capture, the following ATT Write Request was observed:

12 25 00 02 00

This is an ATT PDU, not a complete HCI packet. Its fields are:

Bytes	Meaning
12	ATT Write Request opcode
25 00	Attribute handle 0x0025, little-endian
02 00	CCCD value 0x0002: indications enabled

In this particular capture, the descriptor handle is 0x0025, and the Weight Measurement characteristic value handle is 0x0024.

Important: GATT attribute handles are connection/database-specific and should not be hard-coded as universal identifiers. A client should discover the service, characteristic, and descriptor by UUID.

After indications are enabled, the scale sends ATT Handle Value Indication PDUs. The client acknowledges them with ATT Handle Value Confirmation (0x1E).

4. Weight Measurement payload format

The value of the Weight Measurement characteristic follows the standard Bluetooth SIG format.

The basic structure is:

Field	Size	Description
Flags	1 byte	Units and presence of optional fields
Weight	2 bytes	Unsigned 16-bit integer
Timestamp	7 bytes, optional	Present when Flags bit 1 is set
User ID	1 byte, optional	Present when Flags bit 2 is set
BMI	2 bytes, optional	First part of the BMI/Height field pair
Height	2 bytes, optional	Second part of the BMI/Height field pair

Optional fields are included according to the Flags byte. Multi-byte values are little-endian.

Flags byte

The relevant standard Flags bits are:

Bit	Meaning when set to 1
0	Imperial units are used instead of SI units
1	Timestamp is present
2	User ID is present
3	BMI and Height fields are present

For the observed RS-744S measurements, the Flags values were 0x00 and 0x02.

• 0x00: SI units; no timestamp, User ID, or BMI/Height fields.
• 0x02: SI units; timestamp present; no User ID or BMI/Height fields.

No User ID, BMI, or Height fields were observed in the measurement payloads analyzed here.

Weight conversion

With Flags bit 0 cleared, the weight is represented in kilograms with a resolution of 0.005 kg per integer unit.

The conversion is:

weight_kg = uint16_le(weight_bytes) × 0.005

For example:

A4 56

The bytes are little-endian:

0x56A4 = 22180
22180 × 0.005 = 110.9 kg

When Flags bit 0 is set, the standard specifies imperial units, with a weight resolution of 0.01 lb.

The reserved value 0xFFFF is defined by the standard as an indicator of an unsuccessful measurement. It was not needed to decode the successful weight examples below.

5. Observed live weight packets

During weighing, the scale sends short measurement payloads without a timestamp.

One observed ATT Handle Value Indication was:

1D 24 00 00 A4 56

Breakdown:

1D        ATT Handle Value Indication
24 00     Attribute handle 0x0024
00        Flags = 0x00
A4 56     Weight = 0x56A4 = 22180

The resulting weight is 110.9 kg.

Another observed example:

1D 24 00 00 54 56

The weight field is 0x5654 = 22100, corresponding to 110.5 kg.

Intermediate values changed during weighing. In the sampled capture, these updates typically arrived at intervals of approximately half a second.

The lack of a timestamp is an observed characteristic of the RS-744S live updates. The Bluetooth standard defines the timestamp field as optional; it does not itself define the absence of a timestamp as a universal “live measurement” marker. The live/final interpretation described here is based on the observed behavior of this particular scale.

6. Observed final measurement packets

When the scale reached a stable result, the observed payload included the timestamp field.

An example ATT Handle Value Indication is:

1D 24 00 02 A4 56 E5 07 07 04 01 06 3B

The ATT header is:

1D        ATT Handle Value Indication
24 00     Attribute handle 0x0024

The characteristic value is:

02 A4 56 E5 07 07 04 01 06 3B

Decoded:

Bytes	Meaning	Value
02	Flags	SI units, timestamp present
A4 56	Weight	110.9 kg
E5 07	Year, little-endian	2021
07	Month	July
04	Day	4
01	Hour	01
06	Minute	06
3B	Second	59

The embedded timestamp is therefore:

2021-07-04 01:06:59

The same stable weight and timestamp were repeated in multiple indications during the captured session. The client consequently needs to avoid treating every repeated indication as a new historical measurement.

Other stable results observed in the capture included:

Weight bytes	Decoded weight	Embedded timestamp
A4 56	110.9 kg	2021-07-04 01:06:59
70 58	113.2 kg	2021-07-04 01:08:20
C4 59	114.9 kg	2021-07-04 01:10:27

These examples come from separate measurement sessions in the capture.

7. Important timestamp limitation

The capture was collected in 2026, but the timestamps supplied by the scale were from July 2021.

This indicates that the scale's internal date/time was stale or otherwise incorrect at the time of capture.

No verified clock-synchronization procedure was identified in the analyzed traffic. Therefore, a client should not assume that the embedded timestamp reflects the actual date and time of measurement.

In the openScale implementation, the phone's current date/time is used for the saved measurement instead of trusting this stale device timestamp.

This is an implementation choice based on the observed device behavior, not a requirement imposed by the Bluetooth Weight Scale Service specification.

8. Practical client implementation

A client implementing this observed protocol can follow these steps:

1. Establish a BLE GATT connection.
2. Discover the Weight Scale Service (0x181D).
3. Locate the Weight Measurement characteristic (0x2A9D).
4. Discover its CCCD (0x2902) and enable indications by writing 0x0002.
5. Receive and acknowledge each ATT indication.
6. Parse the Flags byte before decoding optional fields.
7. Decode the two-byte weight as an unsigned little-endian integer.
8. Convert the weight according to the unit flag and resolution.
9. Treat timestamped values as final/stable results for the observed RS-744S behavior, while allowing timestamp-free values to update the live display.
10. Prevent repeated timestamped indications for the same stable result from creating duplicate history entries.
11. Use a trusted local time source if the device timestamp has not been verified as accurate.

The Weight Scale Feature characteristic (0x2A9E) is part of the standard service and can be read to determine advertised feature support. Its raw feature bitfield is not documented in this report because a validated interpretation of that value was not established here.

9. What has not been reverse-engineered

The investigation establishes the captured weight-measurement path, not every feature that might exist in the product.

The following functions have not been sufficiently verified and are not claimed to be supported:

• Body-composition measurements or proprietary body metrics
• Historical measurement download
• Clock synchronization
• User synchronization or user selection
• Unit configuration
• Battery-level reporting
• Any additional vendor-specific control commands

No vendor-specific setup command was identified as necessary for receiving weight indications in the analyzed session.

The absence of these features from this report should not be taken as proof that they do not exist; it means they were not established by the available capture.

10. Model coverage and limitations

The physical test and HCI protocol capture described here were performed with a REDMOND SkyBalance RS-744S.

The RS-73S, RS-745S, RS-762S, and RS-773S are included in the related-model support based on the understanding that they share the same controller, Bluetooth protocol, and functionality, with differences in product name and enclosure design.

Their protocol equivalence has not been independently confirmed through separate HCI captures. Anyone with access to one of these models could help validate this assumption.

11. References

• [Bluetooth SIG — Weight Scale Service 1.0.1](https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/WSS_v1.0.1/out/en/index-en.html)
• [Bluetooth SIG — Assigned Numbers](https://www.bluetooth.com/specifications/assigned-numbers/)

These notes document observed behavior of a physical RS-744S and distinguish those observations from fields and rules defined by the standard Bluetooth Weight Scale Service. They are intended as a starting point for further testing and community verification, rather than as manufacturer documentation.

[oliexdev]

capabilities should list what the scale can do, implemented what the handler does. The
SkyBalance also measures body composition, stores readings and has a settable clock (your capture
shows the Current Time Service 0x1805 with a writable 0x2A2B), so please add BODY_COMPOSITION,
HISTORY_READ and TIME_SYNC to capabilities and keep implemented at LIVE_WEIGHT_STREAM.
The scale table then lists them as known but not yet implemented.

If you get the chance: the capture only exposes the Weight Scale Service, so the body composition
values must reach the Redmond app another way. A capture of a sync with the Redmond app would show
where they come from.

Minor:

• uuid16Static duplicates ScaleDeviceHandler.uuid16(); instance properties as in the other
  handlers are enough.
• The 0 kg live frames after stepping off log a warning each; they're not invalid, just empty.
• Reading 0x2A9E only logs it, that can go.

[ahineyushka]

Thanks for the review. I've updated the PR to address your comments.

Code changes

• Separated capabilities from implemented. The handler now declares LIVE_WEIGHT_STREAM, TIME_SYNC, and HISTORY_READ in capabilities, while implemented contains only LIVE_WEIGHT_STREAM.
• Removed the redundant uuid16Static helper in favor of the existing ScaleDeviceHandler.uuid16() method.
• Removed the read of the Weight Scale Feature characteristic (0x2A9E), since its value was only logged and not used by the handler.
• Zero-weight frames are now ignored without emitting a warning.
• Added tests for the capability metadata across all five registered models, including an explicit assertion that BODY_COMPOSITION is not declared.

Hardware testing

I built the Debug APK and tested it with a real REDMOND RS-744S scale. The scale is detected correctly, live weight readings are displayed during weighing, and the final weight is saved to the database. The test confirmed that the normal weighing workflow works as expected.

Only the RS-744S has been tested on physical hardware; the other four model variants have not been individually tested.

Why HISTORY_READ and TIME_SYNC are listed only as potential capabilities

I included these two flags in capabilities at your request, but neither is marked as implemented. The evidence remains inconclusive, and I would not claim that either feature is fully supported.

History reading (HISTORY_READ)

During our diagnostic sessions, we did not observe packets containing previously stored offline weigh-ins being sent while connected to the scale. The models' manuals and the manufacturer's published specifications do not mention offline measurement history or history download. The current official REDMOND app also does not appear to expose this functionality.

However, we have not established whether a separate, as-yet-undiscovered command is required to request stored measurements. The absence of unsolicited history packets does not conclusively rule out such a command.

Time synchronization (TIME_SYNC)

We confirmed that writing the date and time to the standard Current Time characteristic (0x2A2B) receives a successful GATT write acknowledgement. However, the clock's behavior is unreliable: after roughly a week, the reported time was about 14 hours behind, although the date was still correct. At that rate, the date would also drift after a longer period.

Writes to the Local Time Information characteristic (0x2A0F) were acknowledged at the GATT level, but readback continued to return 08 00 (UTC+02:00), rather than the phone's UTC+03:00 setting. The timezone experiment is therefore inconclusive, and I have not implemented automatic time synchronization.

The official app does not appear to synchronize the scale's clock either; after using it, the scale's date remained in 2021 in our observations.

If offline history retrieval is not supported, time synchronization has limited practical value for this integration. Nevertheless, since writing the date and time appears to work at least partially, I have left TIME_SYNC in the potential-capabilities list for now.

Body composition (BODY_COMPOSITION)

I have deliberately not included this capability. Body-composition measurements are not listed in the models' specifications or documentation, and the current official app does not provide this functionality. More importantly, the physical devices themselves lack the sensors required to measure body-composition parameters. Therefore, this is not simply an undocumented or unverified software feature: the necessary measurement hardware is absent. A generic Bluetooth controller or standard Bluetooth characteristics are not evidence that body-composition measurement is supported.

Ultimately, I am not convinced that TIME_SYNC or HISTORY_READ should remain in capabilities without stronger evidence. I have included them as potential capabilities, not implemented features, and will leave it to you to decide whether you prefer to retain or remove these two flags.

Thanks again for the review.