Measurments for Logs

• 15:03 Pairing
• 15:03 88,6 Kg
• 15:04 Firmware Update
• 15:06 Update done
• 15:07 Avatar selected
• 15:08 88,6kg 0,0kg change 104bpm 30,3%
• 15:09 92,3kg 108 bpm (not connected)
• 15:11 20,65kg not connected 102bpm

Findings

Timestamps seem to be off by a few minutes in logs, investigate further

Data received from scale through advertisements

Wireshark filter: bthci_evt.bd_addr == 70:87:9e:38:52:27

There are lots of packages sent as bluetooth advertisement.

Theory: Some of those packages already contain weight measurements. This explains, why the Zepp App could show measurements so fast.

The advertisement packages are mostly 54 and 60 bytes in length. Both those packages seem to be sent right after each other.

Example 54 byte message:

0000   04 3e 33 0d 01 1b 00 00 27 52 38 9e 87 70 01 00   .>3.....'R8..p..
0010   ff 7f b9 00 00 00 00 00 00 00 00 00 19 0e 09 41   ...............A
0020   6d 61 7a 66 69 74 20 53 63 61 6c 65 09 ff 57 01   mazfit Scale..W.
0030   70 87 9e 38 52 27                                 p..8R'

Example 60 byte message:

0000   04 3e 39 0d 01 13 00 00 27 52 38 9e 87 70 01 00   .>9.....'R8..p..
0010   ff 7f b9 00 00 00 00 00 00 00 00 00 1f 02 01 06   ................
0020   03 02 e0 fe 17 16 e0 fe ba 00 e7 67 8b e3 cc 2e   ...........g....
0030   45 4a 65 2a 00 00 43 5d cb a5 01 00               EJe*..C]....

Decoding the 54 byte message

Packet: 1332

byte(s)	Meaning
04	HCI Packet Type: HCI Event
3e	Event Code: LE Meta
33	Total lenght: 51
0d	Sub Event: LE Extended Advertising Report
01	Num Reports: 1
1b 00	Connectable, Scannable, Scan Response, Legacy, Data Status: Complete
00	Peer Address Type: Public Device Address
27 52 38 9e 87 70	BD_ADDR: 70:87:9e:38:52:27 (Bluetooth adress of device)
01	Primary PHY: LE 1M (?)
00	Secondary PHY: No packets on secondary advertising channel
ff	Advertising SID: not available
7f	TX Power: 127dBm (not available)
b9	RSSI: -71 dBm
00 00	Periodic Advertising Interval: None
00	Direct Address Type: Public Device Address
00 00 00 00 00 00	Direct BD_ADDR: 00:00:00:00:00:00
19	Data length: 25
0e 09 41 6d 61 7a 66 69 74 20 53 63 61 6c 65	Device Name: Amazfit Scale
09	Length: 9
ff	Type: Manufacturer Specific
57 01	Company ID: Anhui Huami Information Technology Co., Ltd.
70 87 9e 38 52 27	Data

The first 45 bytes seem to be meta information, only the last 9 bytes contain relevant data.

Idea: Use first 45 bytes to identify device and message type, interpret message correctly.

Decoding the 60 byte message

byte(s)	Meaning
04	HCI Packet Type: HCI Event
3e	Event Code: LE Meta
38	Total lenght: 57
0d	Sub Event: LE Extended Advertising Report
01	Num Reports: 1
13 00	Connectable, Scannable, Legacy, Data Status: Complete
00	Peer Address Type: Public Device Address
27 52 38 9e 87 70	BD_ADDR: 70:87:9e:38:52:27 (Bluetooth adress of device)
01	Primary PHY: LE 1M (?)
00	Secondary PHY: No packets on secondary advertising channel
ff	Advertising SID: not available
7f	TX Power: 127dBm (not available)
b9	RSSI: -71 dBm
00 00	Periodic Advertising Interval: None
00	Direct Address Type: Public Device Address
00 00 00 00 00 00	Direct BD_ADDR: 00:00:00:00:00:00
19	Data length: 31
02	Length: 2
01	Type: Flags
06	Simultaneous LE and BR/EDR to Same Device Capable (Host): false Simultaneous LE and BR/EDR to Same Device Capable (Controller): false, BR/EDR Not Supported: true (0x1) LE General Discoverable Mode: true LE Limited Discoverable Mode: false
03 02 e0 fe	16-bit Service Class UUIDs (incomplete): Anhui Huami Information Technology Co., Ltd.
17	(Service Data) Length: 23
16	Type: Serice Data - 16 bit UUID
eo fe	UUID 16: Anhui Huami Information Technology Co., Ltd.
ba 00 e7 67 8b e3 cc 2e 45 4a 65 2a 00 00 43 5d cb a5 01 00	Service Data

Again the first block of bytes seem to be meta data and there are 20 bytes of "Service Data" which might contain interesting information for our use case.

TODO: Take a look how these service data entries change over time

TODO: Compare with findings of https://github.com/custom-components/ble_monitor/issues/910