markus/amazfit-scale-openscale-support
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

initial findings

Browse Source
This commit is contained in:
Markus Köbele
2023-11-05 16:35:12 +01:00
commit b3f2cddec1
4 changed files with 263 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

117
README.md Normal file
View File

@@ -0,0 +1,117 @@
# 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:
```text
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:
```text
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 <br> Simultaneous LE and BR/EDR to Same Device Capable (Controller): false, BR/EDR Not Supported: true (0x1) <br> LE General Discoverable Mode: true <br> 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