Looks like a great start, am interested in how this develops. Found myself in a similar situation, have one of these scales, but it (the app) doesn't address a key need - I make the same (or similar) foods regularly - my lunch salad, for example - but it varies a little day to day depending on what is in the fridge. I don't want to store static, once-and-done recipes, I want to save the recipe as a 'template' and then queue up the ingredients each time I make it, based on the stored template, then step though each ingredient (as in, accepting a weight with a tap/click automatically jumps to the next ingredient/line) grabbing the current weights, and have the current nutrition pop out at the end (with bonus points for submitting to through the Fitbit API :). And, of course, their food database sucks :)
Was looking at playing with some Arduino based stuff, but it's wired USB based (until/unless I figure out adding in a BLE module) and then I came across your writeup :)
I know you said you are getting an Android device for some planned wok, but would you mind sharing the hardware stack you are / have been using to date? As in, Windows / OSX / Linux, etc?
Glad you found this (somewhat) useful 😊 , so far I managed to borrow an the Android device from a friend and managed to take dumps of data that was being sent over the network. As well as tried to disassemble the Android .apk to get a glimpse of the packing/compression algorithm.
The current status is that the project is on-hold because I've exhausted the samples of data I have and I no longer have access to an Android device to make more snapshots/samples.
In terms of the hardware stack, for development I was mainly using Linux (Ubuntu) on my personal laptop. To take the samples I (had to) use Windows (due to drivers of the specific phone model) and adb + wireshark to snoop on the bluetooth traffic between the phone and the scale. For testing the written code I used linux and noble npm package to communicate with the BLE scale while utilising the library I wrote to pack and unpack packets.
For the final use case I got a raspberry pi with bluetooth + bluez to manage BLE GATT protocol. Placed the whole thing in the kitchen (where the scale is) and it constantly scans for the scales MAC and GATT ID's, once it finds it, tries to connect and sends the measurements to my local MQTT broker from where I deal with the data.
So far the whole setup is kind of "listen only" mode because I never got time to take snapshots of the "SET_NUTRITION" packets to understand how they are packed.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Looks like a great start, am interested in how this develops. Found myself in a similar situation, have one of these scales, but it (the app) doesn't address a key need - I make the same (or similar) foods regularly - my lunch salad, for example - but it varies a little day to day depending on what is in the fridge. I don't want to store static, once-and-done recipes, I want to save the recipe as a 'template' and then queue up the ingredients each time I make it, based on the stored template, then step though each ingredient (as in, accepting a weight with a tap/click automatically jumps to the next ingredient/line) grabbing the current weights, and have the current nutrition pop out at the end (with bonus points for submitting to through the Fitbit API :). And, of course, their food database sucks :)
Was looking at playing with some Arduino based stuff, but it's wired USB based (until/unless I figure out adding in a BLE module) and then I came across your writeup :)
I know you said you are getting an Android device for some planned wok, but would you mind sharing the hardware stack you are / have been using to date? As in, Windows / OSX / Linux, etc?
Glad you found this (somewhat) useful 😊 , so far I managed to borrow an the Android device from a friend and managed to take dumps of data that was being sent over the network. As well as tried to disassemble the Android .apk to get a glimpse of the packing/compression algorithm.
The current status is that the project is on-hold because I've exhausted the samples of data I have and I no longer have access to an Android device to make more snapshots/samples.
In terms of the hardware stack, for development I was mainly using Linux (Ubuntu) on my personal laptop. To take the samples I (had to) use Windows (due to drivers of the specific phone model) and
adb+wiresharkto snoop on the bluetooth traffic between the phone and the scale.For testing the written code I used linux and
noblenpm package to communicate with the BLE scale while utilising the library I wrote to pack and unpack packets.For the final use case I got a raspberry pi with bluetooth + bluez to manage BLE GATT protocol. Placed the whole thing in the kitchen (where the scale is) and it constantly scans for the scales MAC and GATT ID's, once it finds it, tries to connect and sends the measurements to my local MQTT broker from where I deal with the data.
So far the whole setup is kind of "listen only" mode because I never got time to take snapshots of the "SET_NUTRITION" packets to understand how they are packed.