Issues With Zigbee Sensor(s) Battery State Reporting?

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.

1 Like

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.

2 Likes

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

1 Like

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.

1 Like

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.

1 Like

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. :wink:

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

1 Like

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. :thinking:

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.

1 Like

I have confirmed that that Tuya model is using Zigbee 3.0

https://zigbeealliance.org/classic-product-search/#zigbeecertifiedproducts/productdetails3/5e1d70c356a43f0016622595/

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 :wink:).

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. :sunglasses:

1 Like

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?

What’s the brand and model of those two devices?

Yes, That device may have a problem.
I would do the following:

  • remove the device from the hub from the app.
  • In the app, enter the hub and select safe mode, if it is not selected.
  • reset the device
  • Re-pair it near the hub
  • In IDE select the dth “smartsense temperature / Humidity sensor”
  • Wait 1 minute for the configuration to run
  • Check if the battery value has been resolved
    Update:
    I see in screenshots this device worked with old dth “Smartsense temperature/Humidity” and is possible a device bad configure procedure

They are branded and sold as Smekitlly and I bought them through Amazon. They look exactly like the Temp & Humidity sensor sold by Tuya and show up in the IDE as Tuya RH3052.

Smekitlly

Tuya

Were they sold by Amazon itself, Smekitlly itself, or a third party using Amazon’s platform?

It looks like those are indeed just re-branded Tuya devices, which is common.

Sold by Smekitlly

1 Like

Ok, that’s good, then they should be legitimate Tuya products. :sunglasses: