Original & Aqara Xiaomi Zigbee Sensors (contact, temp, motion, button, outlet, leak, etc)

Which device are you getting the Java error when the refresh button is pushed? And you mean the refresh button while looking at the device in the SmartThings app, right?

The Temp / Humidity sensor round version.

my brand new cr2032 reported 3215.
documentation mentions; “the voltage range is 0-3300mv, in normal usage below 2800mv mean low voltage”

Something very wrong, I guess with the DTH, but could be the Sensor. This is my log from the Temp Humidity sensor. Started at 100% in a few minutes dropped to 99%, and now 95% in a very short time.

My Aqara temp hum baro sensors are not updating temperature any more. Using last DH and the sensors are online and are checking in.

That is non-Aqara version, also known as the “Original” Xiaomi Temp / Humidity sensor.

Anyhow, I looked the DTH code, and I am quite sure I know why pressing the refresh button in the ST App causes a Java error.

Here’s the explanation for @ArstenA and anyone else interested in the technical / coding of the DTH:

In the refresh() function, this line is causing the Java error:

return zigbee.readAttribute(0x0000, 0x0001) + zigbee.configureReporting(0x0000, 0x0001, 0x21, 600, 21600, 0x01) + zigbee.configureReporting(0x0402, 0x0000, 0x29, 30, 3600, 0x0064)

The issue is there is an invalid values in one of the configureReporting() calls.

The first one is setting up reporting on cluster 0x0000 (Basic), attribute 0x0001 (Application Version), data type 0x21 (unsigned 16-bit integer), min report interval 600 seconds, max report interval 21600 seconds, and 0x01 (1 unit) min change required to generate a report.

Looking at the ZigBee Cluster Library User Guide, The data type for the Application Version attribute is unsigned 8-bit integer, not unsigned 16-bit integer, so that’s what is creating a Java error. Also, there’s really no reason to set up reporting on the Application Version, because it’s not part of the sensor reporting and will never change. I recommend removing this. I also recommend removing the readAttribute() call for the same cluster / attribute.

The second configureReporting call is setting up reporting on cluster 0x0402 (Temperature), attribute 0x0000 (Measured Value), data type 0x29 (signed 16-bit integer), min report interval 30 seconds, max report interval 3600 seconds, and 0x0064 (100 unit = 1 degree) min change required to generate a report. This is exactly the same as the code given on the SmartThings ZigBee Reference page in the Capabilities section. So that is valid, and not causing the error.

If you’re working with improving the configure and refresh function code I’d recommend looking at the information on zigbee.configureReporting() as well as the list of ZCL DataType constants on that same ST ZigBee Reference page. In particular, any zigbee.configureReporting() call needs the data type to match that of the attribute, and if the attribute has a boolean (0x10) data type, then the 6th parameter must be “null”, like this configureReporting call that sets up reporting on the On/Off state attribute (0x0000) of the On/Off cluster (0x0006):

zigbee.configureReporting(0x0006, 0x0000, 0x10, 0, 600, null)

With all of that information, you should be able to put together the zigbee.configureReporting() call for Relative Humidity (assuming the Xiaomi sensor uses the standard ZHA protocol for that information). Page 443 of the ZigBee Cluster Library User Guide lists 0x0405 as the Cluster ID for Relative Humidity Measurement, and the first attribute is MeasuredValue, stored as an unsigned 16-bit integer value. It is supposed to stored with one unit (0x0001) being equal to 0.01%, so the range is from 0x0000 to 0x2710. So if you want to request reporting of a 1% change in RH, that would be 100 units (0x0064). Min / Max reporting time could be the same as for temperature, so that gives us everything for the code:

zigbee.configureReporting(0x0405, 0x0000, 0x21, 30, 3600, 0x0064)

The ZigBee Capabilities table in the ST ZigBee Reference shows that a readAttributre() call is not needed for refresh, but it doesn’t list commands for Relative Humidity. I’m going to guess that it’s fine to do a zigbee.readAttribute() call on refresh, so the whole refresh function would become:

def refresh(){
    log.debug "${device.displayName}: refreshing"
    return zigbee.readAttribute(0x0405, 0x0000) +
    zigbee.configureReporting(0x0402, 0x0000, 0x29, 30, 3600, 0x0064) +
    zigbee.configureReporting(0x0405, 0x0000, 0x21, 30, 3600, 0x0064)

Also note that if a 1 degree temperature change is what you want reported, there’s a slightly shorter call: zigbee.temperatureConfig(30, 3600) as explained in this post. It can replace zigbee.configureReporting(0x0402, 0x0000, 0x29, 30, 3600, 0x0064) in the refresh() code above.

Please note that since I don’t have either of the Xiaomi Temperature / Humidity sensors, I am not able to test this code. If it works, the configure() function should also be updated to include the same readAttribute() and configureReporting() calls.

I hope that helps.

1 Like

Where in the code does it go?

Don’t pay so much attention to the percentage. Look at the raw voltage values:

3.245V, then 3.235V, then 3.235V again, then 3.225V. These are 1/100th of a volt changes. Your battery is fine, and I imagine that really high starting voltage of over 3.2V won’t last so long.

The Temp Humidity DTH is currently set up to calculate the battery percentage on a voltage range from 2.7V to 3.3V, which means it won’t display 100% for long, or not at all, if most people aren’t getting new batteries reading at 3.3V (or higher.) Your 2.255V battery already started below 100% according to that range, but it was getting rounded up from 99.x% to 100%.

Really the big problem here is that the only value available to convert to a percentage is Voltage, and the correct way to calculate the remaining life of a battery is to look at capacity in milliAmp hours (mAh) as compared to the average milliAmp load of the device.

With lithium cell batteries, they generally stay at a stable voltage for most of their lifecycle, and then drop off quickly (see this webpage with a bunch of information). So it’s probably better to lower that maxVolts value used in the DTH so any voltage above is calculated to 100%, and when the battery is really nearing the end of it’s life, you’ll start seeing the percentage drop quite quickly - an indicator to replace it very soon.

I haven’t tested it so I don’t recommend replacing the code in your copy of the DTH to be honest.

Also, the refresh button feature should not need to be used normally. It would only be helpful if you wanted to get an immediate reading of the current relative humidity value, if the code I suggested were used.

That said, if the DTH didn’t have that same code in the configure() function that is used when the device is first paired, then you’d want to press the refresh button once after updating the DTH to make sure the reporting is configured correctly.

I continue to have the button not able to turn on a light with this device handler. It does show button presses in the Smartthings app. If I switch to another device handler then the button will work to turn on a light. Does anyone know what could be the problem? Thanks

The original DTH from the other developer refresh works no errors. So the error was brought over with the change.

You mean the DTH by a4refillpad? The refresh code in that DTH does absolutely nothing with the Xiaomi Temp / Humidity sensor. Here it is:

def refresh() {
	log.debug "refresh called"
	def refreshCmds = [
		"st rattr 0x${device.deviceNetworkId} 1 1 0x00", "delay 2000",
		"st rattr 0x${device.deviceNetworkId} 1 1 0x20", "delay 2000"

	return refreshCmds + enrollResponse()

This function is using a depreciated method, st rattr, to read ZigBee attrributes, which is explained in this archived copy of the SmartThings developer documentation from 2015.

The two st rattr commands are reading endpoint x01, cluster 0x001 (Power Configuration), attributes 0x00 (Mains Voltage) and 0x20 (Battery Voltage). But the none of Xiaomi devices use mains power, and also they do not use standard ZigBee HA 1.2 protocol for battery reporting. So these read attribute calls don’t do anything.

Additionally, the enrollResponse() call is for IAS (Intruder Alarm System) capable device, but the Xiaomi Temperature / Humidity sensor is not an IAS capable device, so the code does nothing.

If you are worried about the error when pressing the refresh button, don’t be. The DTH continues to work correctly after displaying the error.

Besides not agreeing with the battery reporting percentage, what issues are you having with the sensor?

Not worried, understand this is coming from a purist.

I am finding a huge lag when pressing the button to an action happening. Normal? It also only works in Webcore, does not work with the smart lighting app


What I don’t understand is I went fromm100% to 86% since early today. By tomorrow the battery will be dead.

The barometric pressure is not updating either, only humidity, battery and checkins. I reverted back to a version of the code from december and now it’s all working again. Anyone else with this problem?

Check the Recently tab in the ST app on a Aqara temp device and see if you get any baro/temp updates.

Setting temperature and pressure offset to 0 in the settings resolved this issue for me

With the latest DH? I have tried that, but still no go.

My battery is now 25% from 100% yesterday morning, on the original Temp Humidity sensor.

What is the voltage reported in the log?

© 2019 SmartThings, Inc. All Rights Reserved. Terms of Use | Privacy Policy

SmartThings; SmartApps®; Physical Graph; Hello, Home; and Hello, Smart Home are all trademarks of the SmartThings, Inc.