Detect battery level in LYWSD02 decoder

[koenvervloesem]

Description:

This detects the battery percentage in the LYWSD02 decoder and adds test data for it. The LYWSD02 only advertises its battery level if it's running firmware 1.1.2_00085 or later.

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]

Thanks @koenvervloesem, I'm just wondering if we should keep the single index 25 conditions as before.

Looking at the LYWSDCGQ decoder it seems that, even if at a different index, the same bits are being used to indicate temperature, humidity and battery broadcasts, with the LYWSDCGQ also having the extra 'd' for temp and humidity together, which I wouldn't know if the LYWSD02 might have as well.

I suppose eventually we could/should actually turn the conditions into direct bit evaluations.

Just a thought for consistency ;) works either way, until possibly the now other used indexes are being used for something else in a future firmware update.

[DigiH]

Since the servicedata of the LYWSD02 also seems to include parts or in full the MAC address of individual devices I do find it clearer and safer to just use the defining single index in the conditions, instead of adding unnecessary and possibly unknown bytes to them.

[koenvervloesem]

All these Xiaomi devices are using the same Mi Beacon protocol. I used 0410, 0610 and 0a10 instead of 4, 6 and a because these are the values defined as "type of measurement" in the protocol documentation I found. So I think it's safe to use the full four characters. Even safer than only using one character, because there's also 1410 for water immersion state and 1610 for gas state (not that there would be a version of the LYWSD02 that would advertise those :-)).

After finding the 0d10 type of measurement in the protocol documentation, I was also wondering whether my LYWSD02 advertised this type, but I haven't detected this in a long series of measurements, both using the pre 1.1.2_00085 and post 1.1.2_00085 versions of the firmware.

[DigiH]

All these Xiaomi devices are using the same Mi Beacon protocol.

Now that makes things clearer. As I don't have any of these devices I just took the original definitions at face value.

Looking at the above I think we then need to not just adjust the "type of measurement" conditions, but also all the current model conditions with the Product IDs seem to always include the last byte of the preceding frame control, which, according to the protocol sheet, would break the model recognition when Protocol (version 0x30?) is applicable - just after looking briefly at it.

So probably best to already include this variation in the model condition either as an OR or just using the product ID.

A further investigation of the service uuid would also be good to be able to further narrow down the model conditions.

[DigiH]

Thanks, I really think we need to go through all the other existing Xiaomi decoders and amend several of them at some stage.

Also in the above linked Mi Beacon protocol page for

Protocol (version 0x70?)
and
Protocol (version 0x50?)

the protocol definitions
…

14+	data		Payload

and
…

13+	data		Payload

could be amended to

14	data		Length of Payload
15+	data		Payload

and

13	data		Length of Payload
14+	data		Payload