Hes set the 100% at 3.3v your new battery is 3.255 which 93% is about right
[OBSOLETE] Original & Aqara Xiaomi Zigbee Sensors (contact, temp, motion, button, outlet, leak, etc)
So a new battery never reads 100% with this DTH?
My Garage senor reads 2.97 volts and 50% with the DTH. Only in since the 12th.
If its fresh of the factory floor it might but your 3.255 is the highest I have seen so far
If that is what it is then something needs to be changed in the DTH and the JAVA errors need attending.
UPDATE: I changed the battery setting to 3.25 volts, and now says 100%. Also the JAVA error only shows when refresh button is pushed.
I recently read that post as well. Unfortunate, but in the end their goal should be to provide the same functionality across all their products, no matter what it’s branded as. If it’s a hub, it’s a hub. This obviously isn’t the case, but it may certainly be something they hope to rectify. Especially considering their announcement of consolidation at CES.
This is really good information. I appreciate your collection and speculation. I agree with you on most everything and drawn the same conclusions myself.
Thankfully I did not. I believe I only spent $10 with a coupon.
I am currently holding out for a sale on the hub and I will pick one up then. With that in mind, can the Link act as a repeater allowing me to expand past the 32 device limit?
Yeah, I only came to my conclusions that the Link was probably never going to match the full capabilities of the hub just after the $50 v2 hub Christmas sale finished. Hopefully there will be another mid-year ST sale.
As far as I know, the ST Link is only designed to extend ZigBee / Z-Wave capability to the Android-based ST hub App running on a NVIDIA Shield. Personally I just wish I could hack the firmware to turn my link into a ZigBee / Z-Wave sniffer device.
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.