Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Universal XMTZC04HM decoder #67

Closed
wants to merge 1 commit into from
Closed

Universal XMTZC04HM decoder #67

wants to merge 1 commit into from

Conversation

DigiH
Copy link
Member

@DigiH DigiH commented Feb 12, 2022

XMTZC04HM decoder with uuid condition only

Unless there were other reasons why an additional condition of "servicedata", "index", 0, was added to the MiScale v1 decoder, only using the uuid, similar to the Miscale_v2 decoder, will allow for other XMTZC04HM variants to be recognised.

Related to

1technophile/OpenMQTTGateway#1166

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.

Only use ["uuid", "contain", "181d"] condition
@kgarrels
Copy link

kgarrels commented Feb 13, 2022

ok, let's continue here.

Now also unstabilized weights are sent.
The decoder should check if byte 0 is either '2' or 'a', I think that will yield stabilized values, no matter if you still stand on the scale or not ("stabilized" and "weight removed" bits).

'a' should actually be good enough, if the BLE scan happens while the weight is still on the scale, we can just wait for the next round when the weight is gone.

I did the modification in my local copy of the decoder, and it seems to work.

This the correct data format:
https://github.com/oliexdev/openScale/wiki/Xiaomi-Bluetooth-Mi-Scale

@DigiH
Copy link
Member Author

DigiH commented Feb 13, 2022

So the additional condition check "servicedata", "index", 0, "2" was for stabilised weight, which now makes sense to me. Introducing the recognition of additional unstabilised readings probably ins't the best idea though.

@kgarrels It might be best to look into why your scale didn't seem to stabilise and then send the service data accordingly - possibly it standing on uneven ground, carpet, movement on the scale?!?

Looking back into the issue and PR history, which I really should have done before, this 'stabilised' check was specifically introduced because of unwanted "undefined" values.

1technophile/OpenMQTTGateway#801

1technophile/OpenMQTTGateway#868

Closing this PR as NA for removing the additional "servicedata", "index", 0 completely.

We can have further discussion about additional checks in the initial issue, possibly in conjunction to the Mi Body composition scale issue

1technophile/OpenMQTTGateway#760

@DigiH DigiH closed this Feb 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants