Issues With Zigbee Sensor(s) Battery State Reporting?

[JDRoberts]

@Just_Joe

Thanks for all of the information you have given so far. It has been really helpful in my general understanding of how these sensors work. Is there a way I can go about downloading the DTH’s? I would like to try to gain some knowledge on how they are put together. I really want to try to understand data parsing. I have never dealt with the Zigbee protocol before but do have some experience with various other types of data bus protocols.

It may be helpful to note that smartthings has its own architecture which puts a layer of abstraction over the top of the third-party protocols like Zigbee and Z wave. In the following graphic, the actual Zigbee communications are down at the “hub connectivity” level. The DTH is an abstraction layer one above that. (“physical graph“ in this graphic was the original URL for the smartthings cloud.)

A DTH (Device type handler) is a smartthings construct. For basic terminology and terms, see the following FAQ. Although it’s old, the concepts still apply for now with regard to “hub connected“ devices like your sensor. (The topic title is a clickable link)

[OBSOLETE] FAQ: An Overview of Using Custom Code in SmartThings (SmartThings Classic, Groovy Code)

The original FAQ information in this thread refers to the original smartthings architecture, which was in place through the end of 2022 and a little beyond. Custom code was written in the groovy programming language and ran in the smartthings cloud. As of May 2023, you can no longer add new Groovy DTH‘s or smartapps to your smartthings account. So if you came here because of a link in an old forum thread, or on another site, I’m afraid the Groovy information is no longer usable. All of this was replaced by a new architecture. Cloud to cloud integrations use the smartthings API. Hub connected devices, mostly Zigbee and zwave, now use “Edge Drivers,” written in the LUA programming language. Here’s the official announcement on those: The process for using a custom Edge Driver in the new …

Zigbee itself is pretty straightforward and it’s easy to find resources on that. Smartthings uses both the Zigbee 3.0 profile and ZHA 1.2. I may be mistaken, but I believe your tuya device is using Zigbee 3.0 and the other older devices are using ZHA 1.2

FAQ: Zigbee Application Profiles, or why not all zigbee devices work with SmartThings

Zigbee is always zigbee, but the standard allows for different "profiles,"including manufacturer proprietary ones. [image] These are not all able to communicate with each other, they don’t even use the same addressing schemes. SmartThings uses the Zigbee Home Automation profile (ZHA 1.2) and part of the Zigbee 3.0 profile. Devices using other zigbee profiles may be able to join to the network, but their communications may not be understood, or they may frequently drop off because they don’t receive a handshake message they are expecting. There a lot of different ways to explain this, but I think one of the easiest is to think of zigbee as a post office and the different profiles as different languages. The outside envelope for different messages may look similar, have a specific format…

One of the odd things about the smartthings architecture is they just sort of randomly chose terms from the other protocols, but then use them in new ways. So for example they will say that a Zwave device has “clusters“, which it doesn’t (clusters is a Zigbee term). And then “clusters” as smartthings uses it are not identical to the zigbee profile clusters. You will find the actual Zigbee clusters for your device in the “raw data“.

So I just wanted to mention all that before you start researching, because with your technical background you might find a Zigbee reference and then think that applied directly to smartthings, which it doesn’t, because of the abstraction layer.

I don’t know if the fact that your different sensors are probably using different zigbee profiles has any significance or not, but I did want to mention it.