Closed DigiH closed 1 year ago
If you are confident the first byte should be ignored, I'm ok with it. Is there any other values than 0x08 and 0x88 that have been seen in the wild?
AFAIK it can also be 0x04 for some Qingping devices, and whichever additional variations come up in the future or already exist. I'm not sure if this is hardware revisions or region variations, but with the second byte already getting additional variants I think this is enough of a catch up already, unless you want to keep doing that with the first byte as well.
Just doing a quick search here I also found
https://github.com/Bluetooth-Devices/qingping-ble/blob/main/src/qingping_ble/parser.py
which makes me realise we should probably also extend the existing device IDs with these additional variations, affecting CGG1 and CGDN1 for Decoder, with the recent addition of
https://github.com/Bluetooth-Devices/qingping-ble/pull/18/files
Indeed, it looks like 0x04 and 0x80 can occur as well, and I (probably) remember a 0x48, but maybe not from the type of sensor we are interested in.
Adjusting device IDs for CGG1, CGDK2, CGP1W and CGD1 to correctly only use the second byte.
As described in https://github.com/theengs/app/issues/56
Checklist: