"XMTZC05HMKG" - Added information when value is steady and when the m…

[reifl]

"XMTZC05HMKG" - Added information when value is steady and when the measurement is the current measurement. My scale sends the measurement every scan interval and only flips that one bit.

Description:

My scale (mi composition scale 2) sends the last measurement on every scan interval. Tried to find a way to get the information if the value is currently measured or a previous one. I've found that it is one bit which is flipped when it is an old one.

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.

[DigiH]

Hi @reifl

Thanks for the suggested PR. Here are my comments about the new proposed properties.

Added information when value is steady …

"is_steady":{
         "decoder": ["bit_static_value", "servicedata", 2, 1, false, true]
      },

…
"is_steady": {
         "unit": "bool",
         "name": "is_steady"
      },

I think you had to cheat a bit there 😉 as you also had to add , "|", "servicedata", "index", 1, "20" to the model condition to actually catch any unsteady measurements.

The model condition was previously specifically defined to only catch and decode steady weighing measurements, so unless you can give us a good reason as to why you'd also watch to catch, decode and publish unsteady measurements, with the increase of decoder space and lots of additional MQTT messages published, I would think it better to keep it as is.

… and when the measurement is the current measurement

"is_current_measurement":{
         "decoder": ["bit_static_value", "servicedata", 2, 3, true, false]
      },

…

"is_current_measurement": {
         "unit": "bool",
         "name": "is_current_measurement"
      },

I'm not quite sure what you mean by current measurement here. The Xiaomi scales do send their last measured weight for an additional 20 minutes after weighing. The bit you call is_current_measurement above is very often wrongly referred to as the stepped off/weight removed bit, but from my observations it is the bit indicating the ON/OFF state of the actual scale display, after stepping off, or by keeping to stand still on the scale. So yes, while the display is ON the bit is different to when the display is off, but as it is mostly the display off state which gets decoded and published to MQTT, due to the shorts few seconds display ON window and the usually much longer scan interval times, but I also didn't think that the display state would be of interest to be published. Either way, it would then also require and additional , "|", "servicedata", "index", 1, "28" in the model condition, to catch any unstable display ON states as well, making the decoder even bigger ;) not to mention the additional then also required 60 and 68 for object weighing.

Let me know what you think about my comments.

[reifl]

thanks for the fast feedback.

You are right, i modified the model condition at the beginning of my test and forgot about it. Since normally we only need the steady measurement this should be filtered at the condition and the property is obsolete.

With the is_current_measurement you are also right, i didn't test that well. The bit I use to set this value represent the state of the Display not that somebody or something is on the scale. It could be used as an indicator but doesn't represent that. So also this change is obsolete.

My intention with the is_current_measurement was to find a way to determine if this is a new measurement without having to cache the previous value in my next component in the data chain.

Since there isn't a way, or at least this isn't the right way, to determine this, i think all my changes are obsolete because they are missleading or dumping to much data to the broker.