Support Beurer BF 105 #635
Comments
|
I am interested in this too. I plan to buy this. If there is more data needed I am willing to help as soon as my device arrived. |
|
@jensMF: thanks for the hint and I'm happy that someone else is interested in getting this model supported. I correceted my comment above. The licks should be usable now. |
|
I now have the BF105 here and did some analyses and research. I hope this helps somehow. I would really like to get advice how to proceed and, may be, get some important information. Help very appreciated. :-) |
|
I compared some data and found at least the body fat value. here is the hex dump too: In btsnoop_hci_02.log, it is the here is the hex dump: In btsnoop_hci_03.log, it is the here is the hex dump: |
|
I have captured logs for two users with two devices. General values in the app for user 1: initialia: FE Here are my logs for this user: log 2: log 3: log 4: log 5: General values in the app for user 2: initialia: TN Here are my logs for this user: log 6: log 7: log 8: |
|
May be you could help us @oliexdev ? |
|
I found out some more details: this time, I was looking in my 7th log (Filtered_BTsnoop_log_TN_2331_anon.log): The BMI is in this package, it is little endian, and in this case is 3e00. It is in the 4th and 3rd last byte (or in the 4th and 3rd byte when one starts counting form the right side): here is the hex dump: Here are the body fat (7b00, directly after the generic 9803 part) and the muscle percentage (c301) (both in little endian): here is the hex dump again: and here are the values for the upper and lower body (first comes 1e, then the fat for the upper body: [7700] then the fat for the lower body: [7f00] then the muscles for the upper body: [ae01] and then the muscles of the lower body: [d701], all in little endian): and again the hex dump: I could also verify that the 'Date of Birth', 'Gender' and 'Height' as well as the 'Initials', 'Target Weight' and 'Activity Level' services are as documented here:
But I could not find any of the other measured values. |
|
I have made huge progress today (or tonight)! (on second thought, maybe not that big, the real work was done by others) and changed the hard coded CURRENT_USER_CONSENT to the code of my user. Now the differences: The upper and lower body features do not exist in openScale. |
|
What I realized just now: |
|
Hi jensMF, welcome! It's great to have another combatant who is interested in this scale!
This is interesting. I also tried exactly this but did not come as far as you did. When I connet to the scane, I get the following on the Android Studio console: 2021-04-14 17:34:53.011 6736-6736/com.health.openscale D/BluetoothCommunication: Step Nr 7 How did you enter the user consent in your code? If its e.g. 1234 in the scale, did you then set CURRENT_USER_CONSENT = 1234? That's what I tried. How do you get the measurement? Is the scale sending them when a measurement is done? |
|
Hey @MiNGlKLW yes I put the code from the scale (let's say 1234) in the CURRENT_USER_CONSENT variable, like you did. |
|
see #502 (comment) |
|
@oliexdev Thank you for your answer. I am thinking about it and would start to implement the consent code.
|
|
I added a WIP pull request so you and other interested devs can see, what I have done already and what is missing. And to discuss the implementation I chose. As you can see, my main problem is the UI. I have never really done UI stuff. |
|
Anyone willing to help out and test latest changes for #753 on BF105? p.s. @MiNGlKLW and @jensMF if you still have access to BF105, maybe you could help me out and test this version? |
|
I started testing today. First of all, I tried to connect to an existing scale user. The app crashed immediately. and debug log: What I noticed in the debug log is that a new user gets registered anyways and the consent code for that new user is used instead of requesting the correct consent code from the user. |
|
After a restart, the scale user list was shown again, but the scale user I chose in the first run (index 10) was not present. When I selected another scale user (index 8), the consent codes of both are getting requested. Debug log: As you can see, first of all, the consent code from the first run gets used, then the correct consent code for user 8 is saved but is then overwritten by the consent code of user 10. When I reconnect the scale now, the scale user list is shown to me every time. |
|
The main problem is another one. I write you in the pull request. |
Hi, I just tested your debug build with my BF105 with the following results:
This is just for your information. No need to debug this issue for me since my first user is still working fine. |
@dynaxo Thanks for your feedback! |
|
Of course: |
@dynaxo Thanks for the log! |
|
According to my scale there is no user 5. It shows the same new user dialog like for the other unused users 6 to 10. |
@dynaxo Thanks for the response! It seems that there is some bug when creating new users on BF105. |
Yes, I will. But it could take a few days since I'll be away from home. |
|
see #753 |
|
I have a working version here: https://github.com/jensMF/openScale/tree/fix_no_user_on_scale_when_registerNewUser but I am not sure if it affects other scales using standard weight profile. So I added handling of CHARACTERISTIC_CHANGE_INCREMENT to resume the machine state here: https://github.com/jensMF/openScale/blob/bffd0927082fdcb22f97d8173316220499bd051f/android_app/app/src/main/java/com/health/openscale/core/bluetooth/BluetoothStandardWeightProfile.java#L260-L263 Instead we could override this function and add the handling when to resume machine state here. What do you think would be the better approach @krisjans @oliexdev ? |
|
Two importat things I forgot to mention: CHARACTERISTIC_CHANGE_INCREMENT has to be 4 bytes long and the birthday, too. |
|
#806 should fix it |
|
Hi there! I've recently upgraded from my Beurer BF-100 to the BF-105 and created a modified version of my BF-100 USB-data parser for it. Now I stumbled upon this project which seems to be able to read data from the BF-105 via bluetooth! nice! Though after having tried it, it seems to be missing the fat & muscle percentages for the upper and lower body halfs, and instead only features the sum values. Is that a limitation of the bluetooth interface of the BF-105 or just me not having found it in the app or "just" the current implementation not reading / storing it? |
|
It is in the Bluetooth logs: #635 (comment) So it just wasn't added because openScale is missing support to store and display upper/lower body values separately. |
Beurer BF 105
https://www.beurer.com/web/de/produkte/wellbeing/gewicht-und-diagnose/diagnosewaagen/bf-105.php
Beurer HealthManager from Google Play / App Store
To support a new scale it is necessary to gather some information.
Step 1: Read the general reverse engineer process
Step 2: Acquiring some Bluetooth traffic
Attach 3 log files with the corresponding true values, read here for further information.
user settings in the vendors app: sex : male; body height: 180cm; age: 48; activity level: 3;
measured true values in the vendors app for the 1. HCI Snoop log file:
btsnoop_hci_01.log
17.06.2020 18h51
weight: 79,4kg
body fat 19,7%
H2O: 52,3%
muscle: 38,0%
bones:3,3kg
BMR: 1689kcla
AMR 2534Kcal
--> Attach the 1. HCI Snoop log file here <--
btsnoop_hci_01.log
Bluetooth HCI Snoop log file
measured true values in the vendors app for the 2. HCI Snoop log file:
btsnoop_hci_02.log
17.06.2020 18h53
weight: 85,0 kg
body fat 22,1 %
H2O: 50,5 %
muscle: 36,7%
bones: 3,4kg
BMR: 1745 kcla
AMR 2618 kcal
--> Attach the 2. HCI Snoop log file here <--
btsnoop_hci_02.log
Bluetooth HCI Snoop log file
measured true values in the vendors app for the 3. HCI Snoop log file:
btsnoop_hci_03.log
17.06.2020 18h55
weight: 82,1 kg
body fat 20,8 %
H2O: 51,5 %
muscle: 37,3 %
bones: 3,4kg
BMR: 1716 kcla
AMR 2574 kcal
--> Attach the 3. HCI Snoop log file here <--
btsnoop_hci_03.log
Step 3: Discover Bluetooth services and characteristic
Read here how to create the openScale debug file
--> Attach the openScale debug log file here <--
openScale_2020-06-15_16-12.txt
openScale_2020-06-15_16-50.txt
The text was updated successfully, but these errors were encountered: