Support for Sensorpush HT1 (older version of HT.w)

[ravenium]

Hello,

I was hoping to see if I could help add support for the HT1 series of sensorpush devices as I noticed they're not part of the existing support. I've seen vague references to "unable to decode" on the homeassistant repos, but nothing further. I was curious to see where the problem lay.

(caveats, it's been a while since I've done anything with BLE devices, and most of it was not for this purpose)

Near as I can tell, the advertisement beacon is pretty straightforward:

• len 2/type 01, flags indicating no BR/EDR support (0x06)
• len 17/type 07, 128 bit UUID, static: {EC090AA9-9DD7-93B8-BA42-D611000009EF}
• len 5, type FF (manufacturer specific data). This, I assume is where the temp/humidity is coming
• len 2, type 09, complete local name. 0x73, "s".

Here's where I fall down. I'm not 100% sure how to decode the manufacturer specific data above into a discrete temp and humidity. I've tried using the func you used for the HT.w and either my input isn't right or it's a different encoding, because I definitely don't get correct values.

Is there anywhere I can go from here? I'm certainly not short on samples, though I confess I've been obtaining them via my phone's BLE app and not my ubertooth. For example, a temp/humidity of 21.6c/54.5% seems to come out to 0xBDE78E05.

[Ernst79]

The current sensorpush devices are "recognized" here

bleparser/package/bleparser/__init__.py

Lines 365 to 366 in ecd3c59

	elif service_class_uuid128 == (
	b'\xb0\x0a\x09\xec\xd7\x9d\xb8\x93\xba\x42\xd6\x11\x00\x00\x09\xef'

Looks like the UUID is different (read the bytes reversed in between the dash (-)
yours: EC090aB0-9DD7-93B8-42BA-D611000009EF
filtered on EC090AA9-9DD7-93B8-BA42-D611000009EF

So the 1st byte is different (AF is not B0)

So adding this uuid would be enough to at least get it recognized as a sensorpush device. You can test this by changing this on line 366 in the linked file

[ravenium]

Thanks for the tips! Adding some notes so I don't forget:

in init.py:

the uuid128 for these is in adstuct_type == 0x07, not 0x06. Spec seems to back this up (https://docs.silabs.com/bluetooth/4.0/general/adv-and-scanning/bluetooth-adv-data-basics). Those two code changes (uuid and adstruct_type) got me out of the loop and into the parsing func.

in sensorpush.py:

The only non-changing byte of the payload is data[5] (as opposed to data[2] which is being used now for the HT.w and wx), which is always 05. bitwise and with 0x03 to get 1, bitwise right shift 2 gets you 1 as well. 64+1 = 65, the same device_type_id for the HT.w.

thinks to self it does the same thing and has the same spec, what are the chances the HT.w is a rebranded HT1?

looks at output

{'firmware': 'SensorPush', 'temperature': -22.6, 'humidity': 0.02, 'rssi': -68, 'mac': 'F1993BB8A2D5', 'type': 'HT.w', 'packet': 'no packet id', 'data': True}

Doh! Well, I'm close, anyway :) Can I ask where you got the unpacking specifics from? I wonder if it's just a matter of a different min/max/step or some such.

[Ernst79]

It was added by @relevante, perhaps he knows

custom-components/ble_monitor#480

[ashleigh-hopkins]

Hey, I wrote a PR to add support for the HT1 into Bluetooth-Devices/sensorpush-ble#20. You should be able to port the logic over to this library too. The algo is quite simple but it is quite different to the V2 devices.

Hope this helps!

[ravenium]

This is incredible, thank you so much! The ultimate goal I had was to backport it into HomeAssistant (my older HT1 is watching a closet at the moment and will be happy to be useful again), so I'll see if I can dust off my knowledge of that repo and fold it in.