Proposal for dual 'stabilised' recognition change for XMTZC04HM - WIP

[DigiH]

Proposal for 'stabilised' recognition change for XMTZC04HM and introduction of 'stabilised' check for XMTZC05HM

While discussing with @kgarrels and his initial recognition issues for logging the issue

1technophile/OpenMQTTGateway#1166 (comment)

and reading postings on the community forum, like

https://community.openmqttgateway.com/t/looking-for-tips-on-more-reliable-mi-scale-weight-reading/1743/3

and with my own testing with the XMTZC05HM, where even with my TimeBtwRead set to 20 seconds often misses the '2' stabilised reading, and finding the following for the XMTZC05HM

"servicedata", "index", 2, "0" - unstabilised
"servicedata", "index", 2, "8" - unstabilised, stepped off scale, scale lights off
"servicedata", "index", 2, "2" - stabilised, on scale
"servicedata", "index", 2, "a" - stabilised, stepped off scale, scale lights off

I would like to propose this change for the XMTZC04HM scale and to introduce it for XMTZC05HM to avoid many misses of "2" stabilised weighings.

The only difference is that the scales transmits the "a" service data for 20 minutes (XMTZC05HM), so depending on the TimeBtwRead setting this will produce multiple identical publishings. While this wouldn't be an issue for myslef or @kgarrels, it could introduce issues for others. But since the service data is identical in all those messages it could also easily be filtered.

I'd like to use this PR for discussing this change and how others with XMTZC04HM or XMTZC05HM feel about this.

Thanks

Checklist:

• The pull request is done against the latest development branch
• Only one feature/fix was added per PR and the code change compiles without warnings
• I accept the DCO.

[1technophile]

Thanks, @DigiH for all these research, unfortunately my XMTZC04HM doesn't advertize the a when I'm not on it

{"id":"","mac_type":0,"name":"MI SCALE2","manufacturerdata":"5701c8478cd2fc19","rssi":-79,"servicedata":"22e632b2...","servicedatauuid":"0x181d","brand":"Xiaomi","model":"Miscale_v1","model_id":"XMTZC04HM","unit":"kg","weight":XX}

and even several minutes after.
It may depend on the firmware version, I think we should find a way to OR both criteria a and 2

[DigiH]

@1technophile oh yes, in that case a nested OR for 2 and a, together with the AND for the 181d uuid is needed.

It's a bit of a shame, as the 2 is so easily missable unless you have a very short TimeBtwRead, whereas the a, at least on my XMTZC05HM with its 20 minutes broadcasting, give a definite hit every time.

Did you ever get a firmware update for your version of the XMTZC04HM through the Mi Fit app? Or depending on its hardware revision it might not have ever received one.

It could also be interesting to make a posting in the community forum to collect the experiences of other XMTZC04HM or XMTZC05HM users, together with their firmware versions and stabilised 2 a behaviour.

Another thing which always confuses me when communicating about the scales is the weird naming convention when not using the model IDs.

{"id":"","mac_type":0,"name":"MI SCALE2","manufacturerdata":"5701c8478cd2fc19","rssi":-79,"servicedata":"22e632b2...","servicedatauuid":"0x181d","brand":"Xiaomi","model":"Miscale_v1","model_id":"XMTZC04HM","unit":"kg","weight":XX}

Since there are/were version 1 (XMTZC01HM and XMTZC02HM) and version 2 of both the Mi (weight only) Scale (XMTZC04HM) and the Mi Body Composition Scale (XMTZC05HM)

https://www.china-gadgets.de/xiaomi-waagen/
(In German, but the two model charts are self explanatory, even if their naming is not that consistent either:)

it might be an idea to clarify the model names with any future decoder updates.

So PR on hold until a nested AND OR condition is possible. I don't suppose two decoders with the different conditions would already work, because of the identical model_id?!?

As I'm still working on the advanced XMTZC05HM features decoder implementation I will also implement a stabilised condition there once it's done, to avoid unstabilised messages coming through. I even had to fix an unstabilised 8 in the tests of this PR which I unintentionally added when reimplementing the impedance feature ;)

Thanks

[1technophile]

Did you ever get a firmware update for your version of the XMTZC04HM through the Mi Fit app?

I don't think so I updated it. So this maybe the cause for the different behaviour, in all the case I would like to keep it with the current firmware.

Another thing which always confuses me when communicating about the scales is the weird naming convention when not using the model IDs.

Indeed, maybe more accessible than in github,github is also quite well indexed

Another thing which always confuses me when communicating about the scales is the weird naming convention when not using the model IDs.

Agreed, the name comes from the scale itself for info.

Since there are/were version 1 (XMTZC01HM and XMTZC02HM) and version 2 of both the Mi (weight only) Scale (XMTZC04HM) and the Mi Body Composition Scale (XMTZC05HM)

Interesting, never heard about the first 2

So PR on hold until a nested AND OR condition is possible. I don't suppose two decoders with the different conditions would already work, because of the identical model_id?!?

Can you take a look to CGG1_json.h, it may be the way to go

[DigiH]

Agreed, the name comes from the scale itself for info.

Sorry, I meant naming the "model":"Miscale_v1" which is being assigned in the decoder, something like "Mi Weight Scale" (XMTZC04HM) and "Mi Body Scale" (drop the Composition to make it shorter for XMTZC05HM)

Can you take a look to CGG1_json.h, it may be the way to go

Oh yes, that looks very interesting! Thanks! It might also be a solution for my current stumbling block with cramming all the new XMTZC05HM features for both kg and lbs into one decoder.

[DigiH]

Not the best late night activity ;) but definitely gave me a lot more insight.

It would be great if you @1technophile could test the DigiH-StabilisationChanges branch with your always 2 MiScale, and @kgarrels with his preferred a behaviour, still seeing the occasional 2 messages as well now.

Thanks

[DigiH]

WIP - on hold. Going through the XMTZC04HM manual, it has the same possibility of differentiating between weighing people or small objects/items as I'm implementing in the XMTZC05HM decoder.

Press on the scale to turn it on. Wait until “0.00” is displayed and place the item you want to weigh onto the scale.

Wouldn't it be good to also have this in the XMTZC04HM decoder?

@kgarrels @1technophile or anyone else with a XMTZC04HM on for testing to see which servicedata index indicates this difference?

My assumption form the XMTZC04HM servicedata I've seen so far would be the same index 1 showing 6 (kg weighing) or 7 (lbs weighing) for objects.

     "mode":{
        "condition":["servicedata", 1, "2", "|","servicedata", 1, "3"],
        "decoder":["static_value", "person"]
     },
     "_mode":{
        "condition":["servicedata", 1, "6", "|","servicedata", 1, "7"],
        "decoder":["static_value", "object"]
     },

Thanks

[1technophile]

Hey, for 9.55kg,

With an object with the lcd ON

{"id":"C8","mac_type":0,"name":"MI SCALE2","manufacturerdata":"5701c8","rssi":-42,"servicedata":"627607b2070101000111"}

After some time With or without the object lcd OFF

{"id":"C","mac_type":0,"name":"MI SCALE2","manufacturerdata":"5701c8","rssi":-43,"servicedata":"e27607b207010100012e"}

[DigiH]

for 9.55kg

thanks, so actually on index 0, where 2/a indicate a person.

@github768484 would you be willing to run a lbs test?

[github768484]

Yes. I'll test with lbs @DigiH

[DigiH]

Oops, that wasn't the intention, but cleaner start to continue this here

#76