Food for thought on Mi Band decoder

[DigiH]

Hi @h2zero and @1technophile waiting for some lbs tests results on the XMTZC04HM PR I couldn't help but play some more, this time with the, now quite old, Mi Band 4 I have.

Turning ON the "Activity heart rate sharing" in its settings, similar to the "Discoverable" setting to have the steps broadcast, I found that the manufacturerdata, which previously always started with
"570102ffffffffffffffffffffffffffffffff…

changed to

"570102020171ffffffffffffffffffffffffff…

which quickly made it clear that

"decoder":["value_from_hex_data", "manufacturerdata", 10, 2, false, false]

is the activity heart rate - "71" - 113 bpm in the above case.

I haven't figured out what the newly appearing "0201" before it is yet with my very brief testing. For the condition of the unit and the actual heart rate I put multiple ORs together for index 10. One thing that came to my mind though is that in this case, and possibly others, sometime in the future - I promised not to submit any more awkward requests for a while ;) - a NOT property condition would be more appropriate and a lot shorter, as in

      }"activity_heart_rate":{
         "condition":["manufacturerdata", 10, !"f"],
         "decoder":["value_from_hex_data", "manufacturerdata", 10, 2, false, false]
      }

resulting in
… "brand":"Xiaomi","model":"Miband","model_id":"MiBand","steps":5165}
all the time, and then when an activity is started
… "brand":"Xiaomi","model":"Miband","model_id":"MiBand","steps":5207,"activity_heart_rate":105}
until the activity is stopped again.

If you also have a Mi Band, possibly even another model, maybe you want to try

https://github.com/DigiH/decoder/tree/MiBand4-Extension

It'll be a while for me to test it with proper workouts, seeing if the "0201" ever changes and what it might mean, and also if more recent models of the Mi Band follow the same scheme.

Thanks

[DigiH]

This working really nicely for me with the Mi Band 4 I was just trying to add a test case for some future possible submission and realised that it would need a new test format section like

// uuid test input [test name] [uuid] [data source] [data] [data source] [data]
const char* test_uuid[][6] = {
{"MiBand", "fee0", "manufacturerdata", "57010202016fffffffffffffffffffffffffff02e454f2fe3e5f", "servicedata", "a21e0000"},
};

as there aren't any other decoders which extract publishable data from manufacturerdata and servicedata at the same time yet.

[h2zero]

Thanks, that would be simple enough to do.

[DigiH]

Thanks for the confirmation. Since I know that Mi Band 5 and 6 (and very likely the upcoming 7) also have this Activity Heart Rate Sharing option, but don't know yet if they use the same encoding, it'll probably be a while ;)

Is it actually known if the current Mi Band decoder decodes the steps for all these models or even earlier models than my model 4, or if it is restricted to certain versions?

From this I gather that version 3 did seem to trip up with the unconditioned servicedata steps decoding

https://community.openmqttgateway.com/t/ble-with-mi-band/322/2

but could still be used as a presence beacon with the introduction of a steps condition.

Just playing out these possibilities in my mind as I think it would be nice to extend the Mi Band decoder for all the different, quite popular, hardware revisions at some stage :)

[DigiH]

Hi @h2zero @1technophile,

I have been running the Activity Heart Rate addition to the Mi Band decoder for over a week now, and it really works well, publishing the heart rate when workouts are done. I have also verified it with a Mi Band 5 in addition to my Mi Band 4, and assume it will also work with the latest model Mi Band 6, as it also allows for the same Activity Heart rate sharing - hence also renamed the branch to a more general

https://github.com/DigiH/decoder/tree/MiBand-Extension

Would you mind going over my suggested test_uuid_mfgsvcdata implementation before I create a PR. It runs fine on my fork

DigiH#4

, but I wasn't sure if you're ok with the predefined format I used

// uuid test input [test name] [uuid] [manufacturer data] [service data]

or if you'd prefer a more general

// uuid test input [test name] [uuid] [data source] [data] [data source] [data]
or even
// uuid test input [test name] [data source] [data] [data source] [data] [data source] [data]

to allow for other multi combinations?

Thanks

[1technophile]

HI @DigiH

Thanks for these tests and for the proposal.

I think having the datasource and be closer to what the gateway process is a better solution but I will keep it for later on as this will requires to impact other part of the unit tests. Your solution is good for me. Feel free to submit a PR.