Open ghost opened 3 years ago
krisjans
commented
3 years ago @sebastian-arnhold Hi! Please read project wiki about how to contribute to new-scale support: https://github.com/oliexdev/openScale/wiki/How-to-reverse-engineer-a-Bluetooth-4.x-scale (collect data, without programming). Provide btsnoop_hci.log and debug log from openScale and then someone might be able to check if new scale version is compatible with old one.
ghost
commented
3 years ago Hey, thanks for your response. I just did three measurements:
For whatever reason, though I stood on the scale barefoot, it still didn't measure my body fat percentage - not even directly on the scale's on screen display integrated into the device itself.
The scale identifies itself as "1byone scale" with a MAC address of D0:45:00:01:EB:29.
Logs are included. I was not able to find my own weight in the snoop data using Wireshark, but maybe I'm just too stupid for that.
openScale_2021-07-24_17-44.txt V1 btsnoop_hci.log V2 btsnoop_hci.log V3 btsnoop_hci.log
krisjans
commented
3 years ago For whatever reason, though I stood on the scale barefoot, it still didn't measure my body fat percentage - not even directly on the scale's on screen display integrated into the device itself.
@sebastian-arnhold Maybe you scale was shipped with thin transparent protective film on top of scale? if it does, you have to remove that. If there is no protective film, then I have another idea - did your feet touch all four electrodes (oval, metallic plates on top of scale) when you weight yourself?
krisjans
commented
3 years ago The scale identifies itself as "1byone scale" with a MAC address of D0:45:00:01:EB:29.
Logs are included. I was not able to find my own weight in the snoop data using Wireshark, but maybe I'm just too stupid for that.
openScale_2021-07-24_17-44.txt V1 btsnoop_hci.log V2 btsnoop_hci.log V3 btsnoop_hci.log
@sebastian-arnhold I checked your btsnoop_hci.log files and there is no communication to/from MAC address D0:45:00:01:EB:29. Did you installed manufacturer's provided app and paired it with scale before making measurements? The idea is to collect Bluetooth snooping logs while manufacturer's application is communicating with scale.
ghost
commented
3 years ago Got it!
For whatever reason, the scale refuses to show any data (except weight) unless the manufacturer's app is used.
Since I wanted to avoid using a manufacturer's cloud based app for privacy reasons, I created a profile using fake data and a fake one-way e-mail address. My fake person has a height of 170cm and is currently 31 years old (app's default values).
I once again took three measurements (V4-V6):
Note: As with most modern scales, it measures body fat percentage via sending current from the electrodes through the legs and back into the electrodes. The actual body fat percentage is then estimated by using an equation. Since V4 was taken without any additional weight and V6 was taken by holding a massive wooden IKEA stool in one hand :D, the body fat estimation seems to be working nicely as well. Resistance of the legs / fat content of the legs didn't change, but overall weight did, so body fat percentage was correctly estimated to be higher in V6. Compared to many other contemporary scales, this seems to actually be working consistently with this scale - while with many other scales, results often fluctuate wildly, even with much more expensive models. So point for this one again!
Would love this to work with OpenScale. Hope you can use the information from the snoops. If you need anything else, let me know! V4 btsnoop_hci.log V5 btsnoop_hci.log V6 btsnoop_hci.log
krisjans
commented
3 years ago I think I figured out where weight measurements are encoded. Service UUID: 0000-ffb0-0000-1000-8000-00805f9b34fb UUID: 0000-ffb2-0000-1000-8000-00805f9b34fb Handle: 0x0019
--------- v4 20:15 63,5 kg, BMI 22,0 fat 17,1%
370 25.589659 d0:4d:00:01:eb:29 (1byone scale) 22:22:65:e3:d4:12 (sebastian-smartphone) ATT 32 Rcvd Handle Value Notification, Handle: 0x0019 (Unknown: Unknown)
0000 02 02 20 1b 00 17 00 04 00 1b 19 00 ab 2a 80 8c .. ..........*..
0010 f8 16 00 00 00 00 00 00 00 00 00 00 00 0a d5 19 ................
0x8cf816 & 0x03ffff == 0x00f816 == 63510 == 63,51 ~= 63,5 kg
372 27.073414 d0:4d:00:01:eb:29 (1byone scale) 22:22:65:e3:d4:12 (sebastian-smartphone) ATT 32 Rcvd Handle Value Notification, Handle: 0x0019 (Unknown: Unknown)
0000 02 02 20 1b 00 17 00 04 00 1b 19 00 ab 2a 01 00 .. ..........*..
0010 02 12 00 00 00 00 00 00 00 00 00 00 00 0a d6 15 ................
0x0212 == 530 Ohms? impedence?--------- v5 20:19 66,1 kg, BMI 22,9 fat 19,0%
417 28.491468 d0:4d:00:01:eb:29 (1byone scale) 22:22:65:e3:d4:12 (sebastian-smartphone) ATT 32 Rcvd Handle Value Notification, Handle: 0x0019 (Unknown: Unknown)
0000 02 02 20 1b 00 17 00 04 00 1b 19 00 ab 2a 00 8d
0010 02 02 00 00 00 00 00 00 00 00 00 00 00 0a d5 10
0x8d0202 & == 0x010202 == 66050 == 66,05 ~= 66,1 kg
418 33.869497 d0:4d:00:01:eb:29 (1byone scale) 22:22:65:e3:d4:12 (sebastian-smartphone) ATT 32 Rcvd Handle Value Notification, Handle: 0x0019 (Unknown: Unknown)
0000 02 02 20 1b 00 17 00 04 00 1b 19 00 ab 2a 80 8d .. ..........*..
0010 02 02 00 00 00 00 00 00 00 00 00 00 00 0a d5 10 ................
0x8d0202 & == 0x010202 == 66050 == 66,05 ~= 66,1 kg
420 35.353206 d0:4d:00:01:eb:29 (1byone scale) 22:22:65:e3:d4:12 (sebastian-smartphone) ATT 32 Rcvd Handle Value Notification, Handle: 0x0019 (Unknown: Unknown)
0000 02 02 20 1b 00 17 00 04 00 1b 19 00 ab 2a 01 00 .. ..........*..
0010 02 10 00 00 00 00 00 00 00 00 00 00 00 0a d6 13 ................
0x0210 == 528 Ohms? impedence?
--------- v6 20:24 70,1 kg, BMI 24,2 fat 21,9%
392 29.548551 d0:4d:00:01:eb:29 (1byone scale) 22:22:65:e3:d4:12 (sebastian-smartphone) ATT 32 Rcvd Handle Value Notification, Handle: 0x0019 (Unknown: Unknown)
0000 02 02 20 1b 00 17 00 04 00 1b 19 00 ab 2a 80 8d .. ..........*..
0010 11 b6 00 00 00 00 00 00 00 00 00 00 00 0a d5 13 ................
0x8d11b6 & 0x03ffff == 70070 == 70,07 ~= 70,1 kg
393 31.034519 d0:4d:00:01:eb:29 (1byone scale) 22:22:65:e3:d4:12 (sebastian-smartphone) ATT 32 Rcvd Handle Value Notification, Handle: 0x0019 (Unknown: Unknown)
0000 02 02 20 1b 00 17 00 04 00 1b 19 00 ab 2a 01 00 .. ..........*..
0010 02 11 00 00 00 00 00 00 00 00 00 00 00 0a d6 14 ................
0x0211 == 529 Ohms? impedence?@sebastian-arnhold Unfortunately this scale seems to be quite different if compare to already supported OneByone model.
More bt snoop-logs will be needed:
ghost
commented
3 years ago I'm happy to help. I made the snoops your requested (S1 to S4):
S1: I uninstalled an reinstalled the manufacturer app and made a new account (username "scale", male, 170cm, born in 1990). Paired the scale to the app as instructed by the app. Then closed the app.
S2: I created a new user "scaletta", female, 160cm, born in 1991. Then, I took a measurement for scaletta: 22:54 (10:54 pm) 64,2kg BMI 25,1 38,0% body fat After that, I switched the user back to "scale" and took a measurement for him as well (using additional weight to get a different result): 22:56 (10:56 pm) 70,9kg BMI 24,5 22,4% body fat
S3: Tried for an hour. App behaves erratic by default. I sometimes could get the scale to sync offline data, but not in a reproducable manner. According to the manual, it should be able to store 50 data sets for each user, so the functionality is clearly there. An example for "not willing to sync offline data":
I weighed myself on the scale with bluetooth off and the app closed. The results were: 23:59 (11:59 pm) 70,2kg BMI 24,3 22,0% body fat The scale had switched its display off shortly after the measurement as usual. I then re-enabled bluetooth, started the app (still logged in as "scale", the male user), and the app showed the scale as disconnected. I stepped on the scale to activate it, and the app changed its status to connected. I waited approx. 1-2 min for sync.; nothing happened. Then, I took a new measurement (which usually triggers the sync) with minimal extra weight as to create different data points. The results were: 00:02 (00:02 am) 70,6kg BMI 24,4 22,3% body fat There was no trace of the offline measurement I took. I then re-started the app. Even after waiting a minute and then taking a new measurement (which usually triggers the sync), there is still no trace of the data from 23:59 / 70,2kg.
Sadly, I have no snoops from the several times the app did indeed offer to sync the data points.
S1 btsnoop_hci.log S2 btsnoop_hci.log S3 btsnoop_hci.log S4 btsnoop_hci.log
ghost
commented
3 years ago I got it! Steps for my test run (S3b, re-do of S3):
Removed batteries over night Deleted all data in the app (without resetting user) Did first initial measurement with bluetooth active: 12:21 (12:21 pm) 62,4kg BMI 21,6 16,2% body fat
Deactivated bluetooth. Did offline measurement: 12:23 (12:24 pm) 62,2kg BMI 21,5 16,0% Waited for scale to switch off
Started snooping Started app, app shows disconnected Activated scale by touching App shows connected Waited for scale to switch off App shows disconnected No sync notification!
Did two more measurements: 12:27 (12:27 pm) 62,7kg BMI 21,7 16,4% 12:28 (12:28 pm) 62,7kg BMI 21,7 16,4% (those were indeed seperate measurements, I stepped on the scale twice - very repeatable results)
Offline measurement from 12:21 magically appears in data history at the very bottom? Raised eyebrow. Then closed app. Stopped snooping.
Then found out who's guilty: --> App programmers obviously didn't account for German daylight saving time -.- <--
Offline measurements are automatically assigned to user by using weight etc. parameters. App only notifies user when it can't auto-assign values. According to manual, this is the case when weight measurements from two users deviate less than 2kg from each other. Therefore, for most of my test runs, I didn't get a notification since it must have auto-assigned the values correctly - and then put them at the very bottom of the list, since they all appear to have happened exactly 1 hour before they actually happened.
Makes sense, since we currently are using time zone GMT+2 instead of the usual GMT+1 for Germany in summer. As I said, programmers didn't account for that.
Control: My measurement from this test run (12:23) is shown in app as 11:23! All good.
krisjans
commented
3 years ago @sebastian-arnhold Thanks for the logs! great job!
If you would like to to help further, then I suggest you grab latest Wireshark and start analyzing your logs. I took a look on them and I can confirm that the information needed is there.
If you newer worked with Wireshark before then here goes few hints:
bluetooth.src == d0:4d:00:01:eb:29 or bluetooth.dst == d0:4d:00:01:eb:29 when looking at your logs.
ff (like 0000-ffb0-0000-1000-8000-00805f9b34fb or 0000-ffb2-0000-1000-8000-00805f9b34fb).
In Wireshark you can right-clik on UUID (or handle) and create new filter from it with "Apply ad filer" -> "Selected":
No. column on the left side of table).ghost
commented
3 years ago I'm sorry, that's way over my head. But good to know that the data is in there!
krisjans
commented
3 years ago I'm sorry, that's way over my head. But good to know that the data is in there!
It is way easier than you imagine!
In the log there seems to be a lot going on, but in reality there is only few frames that transfers data that we care about. And those packets for your particular scale have Value field length 23. I even tried to filter only those packets with filter btl2cap.length == 23 and it seems show all relevant packets (plus some extra packets, that I don't care about).
@sebastian-arnhold if you have some time to spare - try out Wireshark with different filters. Give it a shot!
p.s. yet another interesting filter that may help: btl2cap.length == 23 and (btatt.opcode == 0x1b or btatt.opcode == 0x52)
ghost
commented
3 years ago I've just noticed that my scale seems to be "eating" my batteries. It eats through one set of good rechargable AAA batteries every 2-3 days. I've returned it and ordered a new one, will be here in a couple of days. I might try again then.
ghost
commented
3 years ago Good news: My new scale has arrived and yes, the battery drain issue is gone. So I was probably just unlucky to get a bad copy. It can happen, but other than that, it's still a good value-for-money scale! The new scale also shows very reliable weight measurements, just like the first one.
Bad news: I am totally out of time and therefore cannot analyze the data at the moment. I would very much appreciate if someone else tried.
mirko-laruina
commented
2 years ago Hi, I've recently bought this scale and I would like to help support it. I've just started analyzing the packets with Wireshark, but I would like to know what exactly should I be looking for.
For now, I think I have found the byte used to communicate the height of new users. Using the log S2 by @sebastian-arnhold, I think frame no. 485 was sent when user was set to "scaletta" (female, 160cm, born 1991) and frame no. 954 when set back to "scale" (male, 170cm, born 1990).
Frame no. 485 value : ab2a60fc7e01000002a000001e0000000000d772
Frame no. 954 value: ab2a60fc7e63000001aa00009f0000000000d75eAt offset 10, we have 0xA0 = 160 (scaletta's height) and 0xAA = 170 (scale's height)
Another thing I've noticed is that between frame 485 and 487 and between 954 and 956, some data is just shifted
Frame 485: ab2a60fc7e01000002a000001e0000000000d772
Frame 487: ab2a020101a000001e000002aa00009f0000d4e1The shifted part is a000001e00000
After the measurement is taken (results in 492 and 493), in frame 494 (phone -> scale) we have
Frame 494: ab2a020101a019141e021302aa00009f0000d421where the "tail" of the packet is shared with the frame 487 ( 02aa00009f0000d4 )
Even more strangely, the packet 956 is very similar to 494 (19141e0213 switch with 00009f0000)
Frame 956: ab2a020101aa00009f000002a019141e0213d4f4Do you have any idea what it can mean?
mirko-laruina
commented
2 years ago Frame no. 963
Value: ab2a0201 01aa1bb29f0212 02a019141e0213 d4d3
0xAB2A is the same for all the packets exchanged with the scale
0x0201 is different for different type of requests, should be opcode
0xD4D3 checksum ? 01 | aa | 1bb2 | 9f | 0212
01: entry number
aa: 170, height
1bb2: 7090, 70.9kg, weight
9f: 1 | 001 1111
1: male
001 1111: 31 year old (born 1990)
0212: same bytes sent by the scale in the second packetRegarding the last two bytes, they could be the impedence as @krisjans suggested since it is the only info missing
02 | a0 | 1914 | 1e | 0213
02: entry number
a0: 160, height
1914: 6420, 64.2kg, weight
1e: 0 | 001 1110
0: female
001 1110: 30 year old (born 1991)
0213: could be impedence
Before each measurement, the phone sends two packets. E.g. frame 954 and 956 in S2 btsnoop
I think it setups the measurement, providing info on timestamp and user
Value: ab2a 60fc7e63 0000 01aa00009f0000 000000 d75e
0xAB2A: scale packet header
0x60FC7E63: Unix timestamp.
In decimal, it is 1627160163 which corresponds to Sat Jul 24 2021 20:56:03 GMT+0000, the logged time is Jul 25, 2021 00:56:03.948569000 W. Europe Daylight Time so +4 hours, but it could be dependant on phone settings.
0x0000: no idea, but is seems to be always the same
0x01aa00009f0000: it is an entry like the one sent after the measurement, but with empty weight and impedence. I think it is used to set up the user on the scale
0x000000: padding
0xd75e: checksumEdit: the entry could be empty only the first time the user takes a measurement. From the analysis of further logs I've found out that weight and impedence are also filled in, but the impedence has reversed endianess (e.g. the scale sends 0x0210, in the frame after the measurement the phone sends 0x0210 but, when the user wants to take the next measurement, the phone sends 0x1002)
It is the same as the frame sent after the measurement, but with the empty entry like in the previous frame.
Value: ab2a 0201 01aa00009f0000 02a019141e0213 d4f4
0x01aa00009f0000 : entry with height, sex and age only
0x02a019141e0213 : filled entry from the last measurement taken (even if from a different user)Thank you for taking the time to try and get the scale to work! If you need any help, let me know.
mirko-laruina
commented
2 years ago I've reversed engineering (almost) all the protocol and I've added the support to openScale. I'm able to read the values from the scale and compute the various metrics quite like the original app (there are some small differences).
Known bugs/missing features:
Everything is implemented here: https://github.com/mirko-laruina/openScale ( df4d5f2d775ddde5d38a85ea2a536527d2444cb0 ) As soon as I have a more stable version, I will send a pull request.
@sebastian-387 could you try it and let me know if you have issues? Thanks
ghost
commented
2 years ago If you could compile me an .apk, I'd be happy to test it! :)
mirko-laruina
commented
2 years ago Here it is :smile: openScale-debug.zip
ghost
commented
2 years ago :+1: Works like a charm on my factory-resetted scale that's never seen the manufacturer's app since!
Just 5 mins into my testing but wanted to leave this here in excitement :D
mirko-laruina
commented
2 years ago Just noticed I was setting the muscle mass wrong (kg instead of percentage as expected by openScale). Weight, BMI, water, muscle, body fat and body mass should be the same exact values with respect to the original app. Lean body mass is different from the fat-free body, but I was reading up it is normal for it to be slightly higher because it includes also some fat. Anyway, I would like to change the way it is compute since I use it to store the impedance (it is needed when setting up the scale for the next measurement) since I wasn't able to store it internally to openScale. Everytime I need the impedance, I read the lean body mass and reverse the formula. Visceral fat is also different (higher in my case) and I don't know why. I know to compute the BMRR to obtain the same value of the original app, but I don't know how to set it in openScale.
Let me know if the metrics are computed correctly for you too.
Note: it should be possible to set a different measurement unit (kg, lb and st), but not a different scale unit (only cm working) since I forgot to perform a unit conversion and the scale would calculate the BMI wrongly. It is an easy fix and I will do it ASAP
ghost
commented
2 years ago After some testing, I can recommend this for merging. I have tested multiple scenarios on two different users, everything checks out fine. BMI is always correctly calculated as kg/m². Body fat % is plausible when taking into account that this type of scale uses a combination of bioimpedance and a mathematical model to calculate the value.
Luckily, my own body fat percentage was measured by a medical doctor just two months ago. She used a medical-grade bioimpedance scale with electrodes on both feet AND HANDS. The professional scale calculated 7%, this scale says 12% so it's probably fine! I therefore can confirm it's higher than expected, though.
Weight (63kg) an BMI (20,0) are also very identical, with the deviation in weight being <1kg. Of course, with only one scale, there is no way for me to actually measure my "true weight" today, so we're comparing old data vs. new data here and therefore can't be sure whether any deviation is from weight gain/loss or measuring error.
Muscle Mass is close, too (53kg vs. 56kg on the professional scale). Same goes for Body Water (68% vs. 60% on the professional scale), which traditionally is the most volatile parameter anyway.
I'm therefore positive that the data is accurate!
It would still be nice to use the actually-measured impedance reading from the scale, though. Since this is what the scale actually measures. :D
Thanks for your awesome work!!
mirko-laruina
commented
2 years ago It would still be nice to use the actually-measured impedance reading from the scale, though. Since this is what the scale actually measures. :D
The actually-measured impedance is used to compute all the metrics. The thing about reversing the LBM function is used when we have to setup the scale for a new measurement: to do that we need to send the previously measured weight and impedance, but I haven't found a way to store the second one in openScale so I extract it from the LBM. This procedure is lossless (except for some rounding errors)
Luckily, my own body fat percentage was measured by a medical doctor just two months ago. She used a medical-grade bioimpedance scale with electrodes on both feet AND HANDS. The professional scale calculated 7%, this scale says 12% so it's probably fine! I therefore can confirm it's higher than expected, though.
This concerns me. Did you have similar results (12 %) from the official app too? Regarding the body fat I'm measuring the same value, however the visceral fat is slightly higher on openScale (in my case 10.66 instead of 10.0). I'm starting to suspect that it is truncated in the official app since I've never seen something without a .0
Have you tried the scale with multiple users?
ghost
commented
2 years ago I don't use the official app at all, so I can't tell. Other "feet-only" scales always gave me around 10-14% in the past. The "feet and hand" scales at my fitness studio a while ago and at my doctor's recently always gave me around 7-9% in the past. I strongly suspect this is a measuring-type issue, since number and position of the electrodes changes impedance quite a lot.
Maybe someone with a "feet and hand"-type scale can do a comparison?
Oh, and I did try two users. No problems! :)
mirko-laruina
commented
2 years ago @sebastian-387 oh okay, so it seems the scale is quite accurate and the implementation is working properly.
Right now I'm writing the handling of the history. The scale sends all the measurements which were taken previously (with no connection) when a measurement is taken while connected.
The frames have this format:
ab2a 00 timestamp 80 weight 00000000 impedence 0a d8 1b
mirko-laruina
commented
2 years ago Update version ( c13ee4c386466b0edace338f84cec02b0ae4c70b ): openScale-debug.zip
I've tested the multi-user and it seems to work correctly too.
@sebastian-387 if you can test the new version, it would be great. Is the scale fully supported now or am I missing some other features?
mirko-laruina
commented
2 years ago APK and latest commit: openScale-debug.zip ( 3307efe2b7d735ad486a54205ffaf08724c1c75a )
ghost
commented
2 years ago @sebastian-387 if you can test the new version, it would be great. Is the scale fully supported now or am I missing some other features?
Please uninstall and reinstall your OpenScale. With the latest version, I do get a bluetooth connection, but no data is transferred. I don't get any measurements in the app, and the scale itself doesn't show my body fat, BMI etc. anymore - probably because it doesn't get any info about my height etc. from the app.
mirko-laruina
commented
2 years ago @sebastian-387 strange, I've just reinstalled openScale and it works as intended. I think it has something to do with the state machine. Can you attach a log file obtained when taking a measurement? You can start logging from Menu > About > Development
mirko-laruina
commented
2 years ago Just to be sure, this is the latest version openScale-debug.zip
ghost
commented
2 years ago Ah, now it works! 😅
Measurement today (Measurement Nov 2021 with medical scale) Weight: 63.88kg (63.3kg) BMI: 19,72 (19.3 kg/m²) Water: 59,89% (68.1%) Muscle: 45,76% (88.9%, so much for professional equipment lol) Fat: 12,70% (6.9%) BMR: 1616 kcal (1679 kcal) TDEE: 1939 kcal
Reasonable values. Body fat is actually far more reasonable when compared to mirror image and medical literature pictures of various body fat percentages!
Though I'm not sure why in both cases, Water+Muscle+Fat don't add up to 100%. Might be due to me not understanding the underlying model.
The scale even saves measurements when you don't use your smartphone, and then transmits them the next time you use your smartphone, with proper date and time stamps! 😎
Only bug is that when taking a measurement without the smartphone, scale only displays weight, but no other values. These are then correctly calculated/transmitted the next time the app is used. For the common user, this behaviour will be irritating.
Otherwise, great job! 👍
mirko-laruina
commented
2 years ago @sebastian-387 I'm no medical expert, but I think water + muscle + fat should not add up to 100% since water is stored all over your body (so in muscles and fat too). What should give you 100% is Lean Body Mass (LBM) + Body Fat ( https://en.wikipedia.org/wiki/Lean_body_mass ).
If you go on Settings > Measurement you can toggle additional metrics which are not shown by default. LBM, bone mass and visceral fat are actually computed by the current implementation, so you can activate them and check the values.
With the LBM, you should have 100 * LBM / weight + body_fat equal or really close to 100% (in my case it is 100.7%).
Concerning the bug, it is quite strange. If I take a measurement on my scale with no phone, it still shows weight, up/down arrow, BMI and body fat. What is happening to you (the ----, I suppose) should only happen before the phone is connected for the first time (or after a factory reset). After that, the user infos are transmitted and the scale can calculate BMI and body fat by itself.
Let me know if you notice something or if the problem persists even after few measurements with the phone connected.
ghost
commented
2 years ago Yeah, water is definitely stored in fat and muscle tissue, so your explanation makes sense! Fat-free body mass is 56.57kg in today's measurement vs. 58.9kg in the professional measurement, so seems plausible.
Your formula, to make it more user-friendly (for reference, since the units are important):
TBM [%] = (LBM [kg] / weight [kg] * 100) + fat [%]
For me, it yields:
TBM [%] = (56.57kg / 63.88kg * 100) + 12.70% = 101,26%
Concerning the bug, I got it! I tried to add extra weight (by holding a heavy object in my hand) so that I could be sure which measurement was which. Even with "intelligent user recognition" turned off in OpenScale, the scale still tried to use its brains to assign the measurements to a person, which failed because of the simulated weight gain. xD
When creating a user, making the first measurement, then doing an offline-measurement, everything works fine!
mirko-laruina
commented
2 years ago @sebastian-387 I didn't know about the intelligent user recognition (this is the first time I'm using openScale). Currently I'm assigning all the measurements (including the historic ones) to the selected user. What do you think it would be better:
I lean towards the second option for two reasons:
What do you think?
ghost
commented
2 years ago Whatever we do, we should keep it consistent.
I bet the scale has a way to automatically detect the user even when using offline-measurements. If so, we could assign the live-measurements to the user selected in the app at that moment, while assigning the offline-measurements automatically to the user the scale has selected. That way, there should be no inconsistencies.
mirko-laruina
commented
2 years ago @sebastian-387 The problem is that the scale doesn't report the user to which the offline-measurement belongs to. It just sends the timestamp, the weight and the impedance. Nothing else. So the choice is really between "guessing" the right profile or just assigning everything to the selected user. Just for your information, the guessing part ("Intelligent user recognition") is done by selecting the user with the closest weight from the measured one
ghost
commented
2 years ago Then I vote for your second option: "the measurement being taken in that moment assigned to the selected user while the historic measurements use intelligent user recognition"
Makes more sense.
mirko-laruina
commented
2 years ago @sebastian-387 Here it is, updated with the intelligent user recognition for historic measurements. openScale-debug.zip
Note: it seems there is an openScale bug which updates the "overview" (and maybe other pages too) with the WRONG measurement. To see the correct data, switch page or user (forcing a view update). This is not a bug of the scale's implementation.
ghost
commented
2 years ago I've tested it thoroughly and could find no bugs. I think we can merge this with OpenScale.
mirko-laruina
commented
2 years ago Pull request sent #820
bbigras
commented
2 years ago I think this issue can be closed now.
bigheart2
commented
1 year ago Total newbie here... If I purchase the new 1 BY ONE scale, could I easily connect it to my OpenScale app or is "coding" knowledge required?
This is the link to what I'm looking to purchase: https://www.amazon.com/gp/product/B07FM621RK/ref=ox_sc_act_title_1?smid=A14DJCV85IJ30N&psc=1
mirko-laruina
commented
1 year ago @bigheart2 this issue is about a different 1byone model (see the amazon link in the first message). A previous model was already supported and it seems to match the scale you want to buy (see #159)
Hey,
I just bought the newest version of the "1byone" scale from Amazon for just 20 Euros: https://www.amazon.de/1-BY-ONE-Digitale-Personenwaage/dp/B089VPXBX6
It seems to be a very good, accurate scale. In my test runs, I could step onto the scale ten times in a row and it would always give me the exact same result for my weight. So far, a really interesting option on the market - especially since its predecessor is supported by openscale!
Sadly, I was not able to pair the scale with the latest openscale App on my Android smartphone. Bluetooth works fine with other devices and applications, e.g. Bluetooth speakers. The scale is simply not recognized by the app.
I would very much like to help supporting the scale. Could the existing code be used, since one can assume that the manufacturer didn't alter the scale's internal bluetooth protocols? Or are additional steps required?
Kind regards, Sebastian