Mi Scale not decoded

[kgarrels]

Before submitting a problem please check the troubleshooting section
https://docs.openmqttgateway.com/upload/troubleshoot.html

Describe the bug
the Mi Scale without impedance is not decoded.

To Reproduce
I receive:

{"id":"70:87:9E:5B:33:42","mac_type":0,"manufacturerdata":"570170879e5b3342","rssi":-79,"servicedata":"a2e45ce607020c001103"}

or

{"id":"70:87:9E:5B:33:42","mac_type":0,"name":"MI SCALE2","manufacturerdata":"570170879e5b3342","rssi":-76,"servicedata":"a2bc5cb20701020f1629"}

Also no entry in .../homeassistant/...

I can see that service uuid is 181D in LightBlue iOS app.

Expected behavior
Decoding of correct weight.

Environment (please complete the following information):

• OpenMQTTGateway version used (V0.9.9 development)

[kgarrels]

from the serial debug:

I NimBLEScan: "Updated advertiser: 70:87:9e:5b:33:42"
T: Creating BLE buffer
N: Device detected: 70:87:9E:5B:33:42
T: getDeviceByMac 70:87:9E:5B:33:42
T: Get services data number: 1
T: Converted service data (10) to a2f45be607020c092d23
T: Service data: a2f45be607020c092d23
T: Service data UUID: 0x181d
T: Removing servicedatauuid
N: Send on /BTtoMQTT/70879E5B3342 msg {"id":"70:87:9E:5B:33:42","mac_type":0,"name":"MI SCALE2","manufacturerdata":"570170879e5b3342","rssi":-78,"servicedata":"a2f45be607020c092d23"}

[DigiH]

Hi @kgarrels

the Mi Scale without impedance is not decoded.

I can see that service uuid is 181D in LightBlue iOS app.

181D is the uuid of the Miscale_v1, so I'm surprised to see "MI SCALE2" in the reply you're getting.

But the XMTZC04HM decoder condition

"condition":["uuid", "contain", "181d", "&", "servicedata", "index", 0, "2"],

does not meet the second "servicedata", "index", 0, "2"

Could this be a newer model of the XMTZC04HM/Miscale_v1 with "servicedata", "index", 0, "a"?!

Can you give the model number of your Mi Scale, is it also XMTZC04HM, or something else?

[kgarrels]

the printing on scale says "Mi Smart Scale 2 Model XMTZC04HM".
Date code on the product "2021.02".

It is without impedance sensor.

[DigiH]

the printing on scale says "Mi Smart Scale 2 Model XMTZC04HM".

Ok, so it's definitely a XMTZC04HM, without the impedance sensor, and the current decoder condition does not recognise the "2021.02" "servicedata", "index", 0, "a" condition.

All other decoding might still be the same though. Is it correct that you are using the kg unit on your scale and not lbs?

Are you building your own binaries to upload the OMG gateway, and would you be able to test an amended decoder?

[kgarrels]

yes, I have managed to build from source.
and yes, kg, not lbs

Nice project BTW, thanks for your efforts!

thanks,
kai

[DigiH]

Nice project BTW, thanks for your efforts!

That definitely goes to @1technophile @h2zero @NorthernMan54 and many other regular hard core contributors! I'm just a user who tries to chip in when I feel I can be of help :)

I've made a quick test fork, so if you can change the decoder library to

decoder = https://github.com/DigiH/decoder

in platform.ini, to see if your scale is now recognised, and also if the reported weight values are in sync with what is showing on the scale.

[kgarrels]

that is so :-(

[DigiH]

Not here for judging :) just want to help getting your scale recognised.

Let me know once you get the chance to test with the above test decoder change, and if it correctly recognises your scale.

[kgarrels]

continue here:
theengs/decoder#67

[DigiH]

Hi @kgarrels having commented and closed the PR, and with doing some more testing with my XMTZC05HM and commenting

#760

So far I found

"servicedata", "index", 2, "2" - stabilised, on scale
"servicedata", "index", 2, "a" - stabilised, stepped off scale

So probably depending on your TimeBtwRead value it might be that you mainly got the above servicedata starting with 'a'

You said you've implemented the additional condition and it's working fine for you now. You might want to submit this as a PR to the decoder.

Rebuilding with pubKnownBLEServiceData set to true will give an easier history of all the service data in the MQTT broker to see if you also get "2...."

[kgarrels]

correct, but it is index 0 (not 2).
I think the need to have the "weight removed" bit false was intentional, maybe to have the time correct.
I suggest to leave it like so.

Thanks again for your help!

[DigiH]

correct, but it is index 0 (not 2).

@kgarrels Yes, for XMTZC04HM, with my XMTZC05HM testing it is at index 2 ;) so slight difference between the models' service data.

Testing further here with my XMTZC05HM with many real world testing I came to the conclusion that 'a' - indicating stepped off scale, weight removed, scale display off - would actually be a better stabilised indicator than '2', as many times this - still standing on scale, weight on scale, scale display on - is being missed, depending on the TimeBtwRead setting and how quickly one steps off the scale after it has registered the weight or it runs itself off even when still standing on the scale. Probably cases which made you create this issue in the first place.

The only issue I can see is that using 'a' as the stabilised indicator it is being recognised and published during every scan for quite a long time after the weighing. But since the service data, including the date/time stamp, stays the same with these repeated messages it could be easily filtered. But I think it will definitely be a more guaranteed and robust recognitions of every weighing.

From your experience with the XMTZC04HM I'm wondering how you'd feel about a stabilised shift from '2' to 'a' for that model as well?

Thanks

[kgarrels]

For me, 'a' is the better and more likely state.

In think there was a reason behind using '2', somewhere I read about the timestamp in the service data being only correct then (make sense...). As I send the value to influxdb, I do not care about the time, I gets timestamped during ingestion.

So I think that the condition should be written as "either '2' or 'a'", but I don't know how to write that in the JSON language.

[DigiH]

@kgarrels I agree, 'a' is far more robust in reliably registering the last weight.

Form my testing with the XMTZC05HM there is no other change in the service data - also not the time stamp - apart from the '2' to 'a' switch. Can you also confirm that for the XMTZC04HM.

Since registering both options, which I don't really think necessary, when a single switch to 'a' should be sufficient it would need a nested OR within the AND condition already existing. Something like

"condition":["uuid", "contain", "181d", "&",("servicedata", "index", 0, "2", "|", "servicedata", "index", 0, "a")],

which I don't think is possible in the decoder yet. I'm already discussing this in the decoder discussions.

But if you can also confirm the above identical time stamp for the '2' and 'a' messages it would make a good case to shift the stabilised flag for both scale versions to 'a'.

Thanks