I managed only two times to receive the weight:
PUBLISH: 0(190)(1)(0)(31)home/OMG1/BTtoMQTT/70879E4C3B50{“id”:“70:87:9E:4C:3B:50”,“mac_type”:0,“name”:“MI SCALE2”,“rssi”:-74,“brand”:“Xiaomi”,“model”:“Miscale_v1”,“model_id”:“XMTZC04HM”,“unit”:“kg”,“weight”:92.25}
In most cases, however, only servicedata is transmitted:
PUBLISH: 0(177)(1)(0)(31)home/OMG1/BTtoMQTT/70879E4C3B50{“id”:“70:87:9E:4C:3B:50”,“mac_type”:0,“name”:“MI SCALE2”,“manufacturerdata”:“570170879e4c3b50”,“rssi”:-65,“servicedata”:“a22648e6070305112909”}
Does anyone have an idea how I can reliably get the weight without decoding the data myself?
Hi @ares, I’ve recently submitted extended new decoders for the Xiaomi Mi scales, which will also remedy your issue, but they are not in the current release of OMG yet.
If you’re using Platformio you can get the latest decoders by changing the decoder URL in platformio.ini to
I’m doing my first steps with the ESP32 today and I haven’t done anything similar yet.
I did the installation with “(Option 1) Upload from the web”.
I just tested the version esp32dev-ble-cont and it works, but there is a lot of traffic.
Can you estimate when the new version will be available?
Thank you for the support and best regards
Manfred
I’m afraid I cannot say, I’m also just a user, a very excited one mind you, as I very much enjoy the many capabilities of OMG, and try to get involved as much as I can and learning many new things along the way. But with the constant expansion and perpetual development of OMG - something not too common amongst some other open source software in this speed - I’m sure there will be a version including the extended Mi Scale as well as other new decoders in the not too distant future.
Yes, that would be the extreme of my suggestion of setting the interval/TimeBtwRead to 0. Maybe try again with the default esp32dev-ble binary and shorten the interval to
which should give you a weight reading, but without the extreme traffic.
Another thing you might want to look at to reduce traffic from devices which you don’t own or don’t want to include in the OMG BLE publishing is the possibility of white-/black-lists
I have tried countless times including {“interval”:1} and {“bleconnect”:false}, but get no weight with esp32dev-ble. So for now I use esp32dev-ble-cont with “white-list”.
Thank you for the feedback. I will test the new version soon and report the result back here.
I would also like to take the opportunity to test OTA updates, but I only find in the documentation that “Over the air updates” are possible, but not how.
I would also like to take the opportunity to test OTA updates, but I only find in the documentation that “Over the air updates” are possible, but not how.
Hi Manfred,
for OTA updates you really would need to get into Platformio - which I strongly recommend anyway, as it gives so many possibilities to personalise your builds - by installing Visual Studio Code and Platformio. It sounds more daunting than it actually is
Not to try and push anyone into using Platformio, binary and web uploads are perfectly fine for everybody who wants to easily install the prebuilt binaries, but the easiest way to install a Platformio setup is
Then there is information about how to configure OTA in the documentation in the Creating a portable config file section
The new version works with 55s including the weighing_mode.
In order to recognize whether it is a new measurement, the timestamp of the data from the scale would possibly also help. Or have I overlooked an already existing possibility here?
The timestamp from the scale is actually sometimes the very same or slightly different for the stabilised/scale display still on and stabilised/scale display off messages it sends and which are now both being recognised, so using it as a new measurement criteria is not always valid.
For comparison purposes though index 6-19 (timestamp) of the servicedata can be used. But for everyone only using the scales with OMG and don’t want to use the Mi Fit app for various reasons, they’ll be stuck back in the 1970s with every battery change anyway
I’d suggest, and do here myself, a routine on the backend receiving the scale broadcasts (HASS, openHAB etc.) which ignores same weight reportings within a certain time frame, like the actual Mi Fit app does for 5 minutes, and creates its own timestamp for the first received weighing. Also with the weighing_mode now being reported this also allows for any backend to ignore object weighings and only record person weights.