Zigbee 3.0 Temperature Humidity Sensor Detector With LCD Display

Zigbee Temp/Humidity/ Luminance with display Sensor

I am hoping I can get this working with Hubitat - if it is using Tuya inside most likely possible.

Literally a slow boat from China so won't get it for a month.

Interested because it runs on 2 AA batteries - which makes a candidate for a USB battery eliminator so can run forever on mains power AND gives people a screen to read the temperature on, thought it may be useful for bedrooms where I need a Temp Sensor for the zone heating.

Will report back in a month when it has arrived.


Watching, I'd love something just like this as well :slight_smile:

1 Like

It arrived.

Paired with HE easily - but I cannot get a reading out of it, been working my way through Drivers but not managed to get a squeak out of it apart from what you see in the zigbee logs - so it is taking to HE but no one is home that speaks its language.

This was a long shot - understand if I can't get it working.

It is a nice device, feels solid and is easily readable 6ft away.

Now the journey to see if it will work with HE - open to any ideas :slight_smile:

Can you post the fingerprint for this device?, that may clue us in to it's capabilities...

How do you get the fingerprint?

I found a driver call Zigbee - Generic Device toolbox that looks like it may allow me to capture fingerprint

Doing it now

Hopefully I captured the right data

fingerprint model:"TS0201", manufacturer:"_TZ3000_qaaysllp", profileId:"0104", endpointId:"01", inClusters:"0000,0001,0400,E002", outClusters:"0019,000A", application:"44"

0000, 0001, and 0400 I know... What is E002?

Yes, thats it., by the way based on that data, the device is not totally zigbee 3.0 compliant.
0400 is illuminance, 0402 is temperature and 0405 is humidity. As you can see 0402 and 0405 are missing, which means they probably jacked them into E002, which is a manufacturer specific cluster, and we would have no way of knowing how they encoded the data.


Ok thanks, it’s a non starter then :frowning:
Nice idea.

I'll never understand why they do things like that...

Once you've read the specs enough to know to use 400, why wouldn't you just use 402/405 too?

Must be some reason, but it eludes me.

I couldnt agree more...

Temperature and Humidity is also typically hosted by the same physical sensor. The value of the readings can be read in one transaction. Therefore, this manufacture may think that there is no point of sending the attribute for temperature and humidity independently.

Perhaps, this is also an optimization. If you have 2 clusters, each cluster can report independently. Each reporting cost battery life. If they can send both clusters in one report, they figure that they may safe some power.

I am just guessing since this kind of optimization is negligible in its intended usage. The specs says 60uA idle consumptions. This is reasonably high for sleepy end device. I am not surprise this manufacturer take an extreme approach to optimize their products.


I'm currently working on trying to get a similar device working:

I'm using the "SmartSense Temp/Humidity Sensor" driver I pulled from Smartthings and with a few changes temperature and battery are working, just not humidity yet.

It's using 405 for humidity so I think I should be able to make it work. The only bummer about this device is that the display is only celsius, doesn't seem to be a way to change that.

It is. Although segmented lcds are pretty low power, I would bet a chunk of that is from the display nonetheless.

I certainly do MUCH better than 60uA idle on my non-display having LoRa devices.

They stopped reading at the page about cluster 0400 and did not bother reading more? There were coffee stain on pages about cluster 0402 and 0405? They just don't care and would rather hope people will buy there low end hub and have other hub users buy there sensors?

All of the reasons above probably.

I have a couple of these using this driver hubitat/konke-zigbee-temp-humidity-sensor.groovy at master Β· muxa/hubitat Β· GitHub


They could have just shut down the lcd when the light is low. It will be hard to read anyway. The energy saving could be significant during this time. Then, they can afford to give us a normal cluster implementation with the energy saved during dark time.


Nice, I'll give it a try!

Did you make this adjustment?

1 Like