Is anyone having issues getting proper battery state data from their Zigbee sensors? I presently have a total of 6 battery powered Zigbee sensors in my SmartThings setup and all but 1 are reporting a constant 100% battery state. 3 are the original SmartThings multi-purpose sensors, 1 is an original SmartThings motion sensor, 1 is a Tuyatec RH3052 Temperature and Humidity sensor and 1 is an Iris Open/Closed sensor. The only one reporting something other than 100% is the Iris sensor. I have the SmartThings v2 hub with the latest Aeotec firmware and am using the latest version of the Samsung IOS App. The battery state info used to work just fine, I have routines set up to monitor them all and alert me when they reached a certain level so that I could replace the batteries as required. I donât know when this problem began and only noticed a few days ago when I was setting up the Tuyatec sensor. Any ideas?
@Just_Joe,
My zigbee smartthings multi sensor and motion sensors seem to report the battery level well, I use android and hub v3.
you can try in IDE to change the DTH version of one of the multi devices or movement from âPublishedâ to âDraftâ. This will cause it to recalculate the battery level when running configure().
In some device I have seen that the calculation of the battery level with the âDraftâ version, which runs in the cloud, varies up to 4% with respect to the level calculated with âpublishedâ local (hub)
After change dth version and update, you must wait some seconds for Device response and refresh Page or see level in app.
What is the true battery level?
Thanks for the suggestions. Changing from âpublishedâ to âdraftâ did make a difference on the motion sensor and seemed to bring the battery level reporting back to life. I am not very well versed in the intricacies of the DTH data fields and I really do appreciate your pointing out how they can be used for troubleshooting and tweaking sensor operations.
Often times battery reporting is inaccurate anyway.
If the device calculates its battery percentage itself and sends the data as Zigbee cluster 001 0x21, then we can assume itâs as accurate as the manufacturer made it.
But if it sends 0x20 which is battery voltage, well, at this point the person who wrote the DTH is guessing at what voltage the device will not have enough power to stay on, which varies from device to device.
Thanks for the reply. Iâm not necessarily concerned with the accuracy of the battery percentage as much as the fact that the device is at least reporting the data and that the calculation for the data is at least somewhat repeatable. Could you point me to where I would find the data definition for the zigbee message structure you are referring to?
20 sends the data in decivolts , divide by 10 to get actual voltage
21 sends the data as a number between 0-200, halve and round up to get the actual percentage
If you are curious to check that your sensor does the battery level calculation correctly, according to the data provided you by mvevitsis, can do the following:
- Open an IDE window with the device you want to see
- Open another IDE window and select Live logging
- Go back to the device IDE window and change the DTH version from âPublishedâ to âDraftâ
- Go to the other window and observe the live logging of device response. If is a motion sensor smarttings manufactured by samjin, you will see something similar to this capture.
You will only see it when you change from âPublishedâ to âDraftâ as it runs in the cloud and is viewed in IDE. When you go from âDraftâ to âPublishedâ you will only see the answer to the Temperature configure reporting, the Battery calculation is not visible, since it is local calculation in the hub.
I have logged data from 2 of 4 temp & humidity sensors that are all supposed to be the exact same Tuyatec RH3052 sensors but the data package being logged is a bit different between the 2 sensors.
One looks like this
And the other looks this this
It would be necessary to see the fingerprint of each sensor to see if they are the same model and which DTH type each uses. It gives the impression that they are either different models and / or have different DTH type.
What brand and model of batteries are you using? I ask because if they are by any chance rechargeable batteries, the discharge curve is different and you will not get accurate reporting.
https://batteryuniversity.com/index.php/learn/article/choices_of_primary_batteries
They are not rechargeable, just 2032 button batteries that came with the sensors.
I read in the ST community that the Tuyatec Zigbee sensors work well with ST but the DTH had to be changed to the SmartSense Temp & Humidity. Turned out there were 2 different but similar DTH so I picked 1 and the battery report was always pegged at 100% so for the 2nd sensor I used the other DTH.
1st DTH
2nd DTH
Iâll change the 1st sensorâs DTH to match the 2nd and see what happens.
Hi @Just_Joe,
it was effectively using two different DTHs and thatâs why the debug log are different.
From what I can see, the âsmartsense temperature / humidity sensorâ is newer and can calculate the battery level with the two clusters 0020 and 0021, the other only with 0020.
I see in internet, that your sensor could uses 0020 and 0021, it should work with both DTHs.
The DTHs use the same calculation formula for cluster 0020, with minimum voltages 2.1v or 2.3v (0%) and maximum 3.0v (100%).
That said, there are several considerations:
- When we use devices with a standard dth or that is not the one designed by the manufacturer, the battery values ââshould be taken only as a reference and the experience of use will tell us later how to interpret them more exactly.
- The dth âsmartsense temperature / humidity sensorâ does not include specific voltage values ââfor this model. Yes for frientSensor 2.3v minimum voltage. The 2.1v standard applies
- Each manufacturer, according to the type and consumption of the hardware of your device, determines with what minimum voltage level the device no longer works correctly and should make sure that it stops sending data, since it could be erroneous.
- For the same type of battery there are different capacities according to manufacturer and quality.
- It could be the case of a device, that the manufacturer ensures that it works with a minimum voltage of 1.9V for example, as the standard dth does not know this, it will show 0% and will continue to work correctly for a while.
- It could also be the opposite case that the manufacturer determines that the minimum level is 2.3v, as in frient and stops working when it was reporting 22%
- The configuration of the temperature, humidity and battery reports is different in the two DTHs, it is possible that they are only configured well in the âsmartsense temperature / humidity sensorâ which is more modern, but I donât know.
I can see in your log, the temperature is set in the standard, every 5 minutes if temp changes.
For humidity only see one log, but i don,t know how is configured. Your device use the cluster 0405 and DTHs send the standad humidity configutation to cluster FC45.
For the battery, the âsmartsense temperature / humidity sensorâ configures it to send every 6 hours only if there is a change in level and the other every 1 hour if there is a change in level. - I would put them with the âsmartsense temperature / humidity sensorâ if the temperature and humidity works well and I would like to see how the battery behaves and learn for the future. It should work fine.
Sorry if I have extended myself too much for you, but it may be useful to someone
I Forgot to tell you, remember to put the dth version back in âpublishedâ so that it works locally, when you are done with the live logging tests.
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.
In the IDE documentation there is all the documentation of how dth, smart app, groovy language work for the classic application, which is still valid, not 100% for many DTH, devices and smart app in the new application, but it is estimated that IDE will close a short time, until the end of the year?
There is also a link at the top of the documentation to the new developer portal and similar documentation.
As long as IDE works you can create, edit and publish DTHs and smartapp for you.
I do not know very well how to find and give you tutorial links, @JDRoberts surely can help you in that, it is better and faster than an encyclopedia. 
Iâm just telling you, try without fear. Nothing breaks. You put the dth back in good and ready, or at most you pair again and it is already fixed.
If you need more help, no problem
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)
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
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.
I have confirmed that that Tuya model is using Zigbee 3.0
ZHA 1,2 Devices often used the IAS zone report to handle battery status. But the Zigbee 3.0 devices more typically use the power configuration clusters. So when you choose a DTH for your tuya device, itâs going to work best if that DTH was designed for a Zigbee 3.0 device.
Basically ZHA treated battery reports as an âalarmâ from a security device (IAS equals intruder alert system). There was a lot of discussion about it at the time, but it didnât get settled before the specification was published.
https://www.nxp.com/docs/en/user-guide/JN-UG-3077.pdf#page457
By the time the Zigbee 3.0 specification was finalized, battery reporting was standardized and moved back into power configuration where it belonged (IMHO, of course ).
Note that both of these links are to Zigbee documents, not smartthings documents. As mentioned previously, these donât map directly. But since you have a strong technical background, I thought you might find them interesting. 
I also wanted to tell you that IDE has a tool that has helped me a lot, The simulator.
You can edit and modify a DTH and without publishing it, so that it is not visible for devices, you can install modified DTH on a real device in your home and check in the live logging how the changes you have made work on the device and if there are errors in execution, etc âŠ
This simulator works as in the classic app and there are things that do not look like this in the new app, such as tiles.
You can execute commands or methods such as configure, refresh or ping and see how the device responds.
When you click on uninstall, the original DTH is automatically reinstalled on your device.
When the changes already work as you want, you can publish the DTH for yourself
I understand that users who have been using these useful and easy-to-use tools for many years are a little disappointed or hopeless about the unknown future of smartthings tools.
I really do appreciate everything you guys have shown and explained to me. I believe I have a better understanding of things now. I am still a bit confused about why I have such different Battery Percentage data results between these two sensors. Both display the same âData & Raw Descriptionâ and both are using the same DTH yet the Battery Data Log displays are different.
I feel that this one may be correct
And this one has a problem
I plan to replace the batteries in both with newly purchased batteries to see if that changes things. Could it be a firmware issue between the sensors?