Add SensorPush HTP.xw and HT.w sensors (passive!)

[melyux]

Description:

Adding decoding for SensorPush HTP.xw and HT.w sensors. These are temperature/humidity/pressure sensors. They broadcast their readings every 1 minute, so we can just listen passively and pick these up having to do any active scans.

To make this work, we had to also:

• Use larger data types when processing post_proc since the decoding for this sensor relies on large modulos, divisions, and bit shifts past 32 bits.
• Lower the minimum manufacturing data length from 16 bytes to 8 bytes, since these sensors' manufacturing data is 8 bytes long.
• Modify anything use the library to pack the Service UUID into the empty Service Data UUID (servicedatauuid) slot if service data doesn't exist. We could add a separate check and split the uuid condition filter into servicedatauuid and serviceuuid, but I'm assuming for no reason that the Service UUID is only relevant if there is no Service Data UUID. Correct me if I'm wrong.

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]

I'm not sure if you're still working on this PR, or if you are currently stuck with the failures.

Could you also add some test cases for both sensors, for future regression testing, but also to see where the current failures are with other possibly affected test cases.

You can install the CMake, CMake Tools and CMake Test Explorer VSC extension for running test cases.

The whole .cal chaining looks like just an endian reversal of the manufacturerdata at a quick glance. Doesn't getting the whole data with little endianness result in the same?

Empty "post_proc": [] are superfluous.

The initial "*", 0, in post_procs is also not required.
"post_proc": ["*", 0, "+", ".cal", …

Could you also submit a few raw undecoded data sample messages for both sensors with advertising data turned on through OpemMQTTGateway?

Do you have a link to the BLE advertising data API for these sensors?

If I caught you in the middle of still working on this please ignore my above comments.

[DigiH]

Have a look at a very simplified test decoder for the SensorPush HTP I quickly created. It does however get different results for the example you gave in the Discussions thread, but in think the values might have been wrong then, especially with the low atmospheric pressure, and also possibly with the -16ºC temperature?!?

See the second added test case for your discussions sample.

I have taken the service uuid completely out of the equations it really is not necessary for a model condition.

It still would require to verify this with your actual sensors for possible fine tuning, as well as verifications and possible adjustments of sub-zero temperatures.

Let me know what you think.

https://github.com/DigiH/decoder/tree/htp

[DigiH]

@melyux

Did you get a chance to try out my test decoder at all?

[melyux]

Hey @DigiH, haven't had a chance yet, I will in the next couple of days. Thanks for looking through it

[DigiH]

@melyux

I have merged #619 with you as a co-author.

Closing this.

[melyux]

Hey, it works! I was running the Theengs Decoder on my laptop, and it wouldn't decode any of these unless I brought the minimum manufacturing length down to 8 from 16. Does the ESP have that set lower by default? Maybe it's because the Python API doesn't allow changing that, since that's what I was using on the laptop.

Another concern is whether just checking the manufacturing length and first byte is enough to identify these as the SensorPush devices. I was going off bleparser which requires the service UUID check to identify these sensors. But it works, so can't complain.

Good thinking on getting rid of the bit-shifting. That may have been an artifact of one of my semi-successful attempts to decode this thing without upgrading the data types.

[DigiH]

Could you double check with your laptop, to see if it decodes fine, even without lowering the manufacturerdata length? It might still be necessary for some platforms, but haven't heard any issues so far with other decoders using lower manufacturerdata.

So far just checking the manufacturerdata is fine, as other decoders using "manufacturerdata", "=", 14 have a unique different byte checking, but if need arises the service data UUID can always be added at a later stage.

Let me know if you find any issues remaining, possibly also checking with sub-zero temperatures (ºC).

[melyux]

I just tried with the laptop on the latest development, and it failed to decode the SensorPush sensors. I modified the min manufacturing data length from 16 to 8 and then it worked.

[DigiH]

I have adjusted it to 10, as that is the minimum being used and reducing it to 8 should not be required.

an you confirm it is working with 10 as well?

[melyux]

10 works!

[DigiH]

Thanks, merging it.