[Deprecated] Xiaomi / Aqara ZigBee device drivers (possibly may no longer be maintained)

vjv · February 17, 2019, 10:36pm

No problem, the logs for rotation are from 2.0.4, I did not specify thar on my post. Let me know if you need any other data with other firmware. Thanks for your work, I'm very impressed with the devices, I installed one inside my safe and it didn't need an antenna modification but I opened it and it's easy to do.

andrew.rowbottom · February 18, 2019, 7:12am

Magic Cube Face handling under 2.0.5.114 issue raised and possible fix @

vjv · February 18, 2019, 8:34pm

Thanks, I replaced the lines in the driver and it works in 2.0.5, now it's just missing the rotation L and R.

vjv · February 19, 2019, 12:05am

I also noticed that text and debug turned off is not working, 2.0.5, with settings off it shows on logs it's on.

ablack-utility · February 19, 2019, 7:34am

Hi gents - I have noticed none of my leak sensors are working anymore. I'm on 2.0.5 and just updated to the most recent device driver. They are paired and are connected fine, but when I put one of the sensors in some water these Java errors appear.

[dev:322](http://10.0.0.31/logs#dev322)2019-02-18 11:27:26.472 pm [error](http://10.0.0.31/device/edit/322)java.lang.NullPointerException: null on line 69 (parse)

[dev:322](http://10.0.0.31/logs#dev322)2019-02-18 11:27:20.244 pm [error](http://10.0.0.31/device/edit/322)java.lang.NullPointerException: null on line 69 (parse)

[dev:322](http://10.0.0.31/logs#dev322)2019-02-18 11:27:19.328 pm [error](http://10.0.0.31/device/edit/322)java.lang.NullPointerException: null on line 69 (parse)

[dev:322](http://10.0.0.31/logs#dev322)2019-02-18 11:27:08.203 pm [error](http://10.0.0.31/device/edit/322)java.lang.NullPointerException: null on line 69 (parse)

[dev:322](http://10.0.0.31/logs#dev322)2019-02-18 11:26:42.162 pm [debug](http://10.0.0.31/device/edit/322) Leak Sensor - Dishwasher: Creating event [name:battery, value:100, unit:%, isStateChange:true, descriptionText:Battery level is 100% (3.025 Volts)]

[dev:322](http://10.0.0.31/logs#dev322)2019-02-18 11:26:42.158 pm [info](http://10.0.0.31/device/edit/322) Leak Sensor - Dishwasher: Battery level is 100% (3.025 Volts)

[dev:322](http://10.0.0.31/logs#dev322)2019-02-18 11:26:42.150 pm [debug](http://10.0.0.31/device/edit/322) Leak Sensor - Dishwasher: Battery parse string = 220121D10B0328190421A81305212D0006240200000000082104020A21A4B4641000

[dev:322](http://10.0.0.31/logs#dev322)2019-02-18 11:26:42.137 pm [debug](http://10.0.0.31/device/edit/322) Leak Sensor - Dishwasher: Reset button was short-pressed

[dev:322](http://10.0.0.31/logs#dev322)2019-02-18 11:26:42.133 pm [debug](http://10.0.0.31/device/edit/322) Leak Sensor - Dishwasher: Message payload: 156C756D692E73656E736F725F776C65616B2E61713101FF42220121D10B0328190421A81305212D0006240200000000082104020A21A4B4641000

I also notice my temp sensors are reporting oddly. The round sensors have wildly incorrect values (like -139 deg) while the Aqara one has the right temp and humidity but the pressure is wildly odd.

Thanks for any help!

Leak sensor logs: (putting them in water)

[dev:322](http://10.0.0.31/logs#dev322)2019-02-18 11:26:42.128 pm [debug](http://10.0.0.31/device/edit/322) Leak Sensor - Dishwasher: Parsing message: read attr - raw: 3E730100007C050042156C756D692E73656E736F725F776C65616B2E61713101FF42220121D10B0328190421A81305212D0006240200000000082104020A21A4B4641000, dni: 3E73, endpoint: 01, cluster: 0000, size: 7C, attrId: 0005, encoding: 42, command: 0A, value: 156C756D692E73656E736F725F776C65616B2E61713101FF42220121D10B0328190421A81305212D0006240200000000082104020A21A4B4641000

veeceeoh · February 19, 2019, 8:32am

Hi folks - I just want to drop a line and say I don't mean to be ignoring all these posts.

I hate to make excuses, but I've been taking care of my daughter who is quite sick. In this case, family comes first.

Thanks for your patience!

vjv · February 19, 2019, 11:56am

Yes, family is first, I hope your daughter gets well soon.

CAZ · February 19, 2019, 3:16pm

No, thank you. I appreciate the update and I wish your daughter a speedy recovery.

veeceeoh · February 20, 2019, 7:01pm

Now fixed, with changes / improvements:

[UPDATE] v0.8 of Aqara Leak Sensor device driver for Hubitat

The new working device driver code can be grabbed from here .

Major Changes

Fixes errors on wet/dry detection that occured with driver v0.7.2
The voltage range for Battery % has been changed
The minimum / maximum voltage values used to calculate battery percentage have been changed from 2.5V min / 3.0V max to 2.9V min / 3.05V max. This means your reported battery percentages will change from what you have been seeing! It should not be a cause for alarm, however. Keep in mind that using the min / max voltage values to calculate a battery percentage only gives a very very rough estimate of battery health. Also, remember that the min / max voltage values can be changed in the preference settings in the device details page for each sensor.
Added Human Readable Time/Date stamp attributes for Dashboard use
This driver had originally included custom lastCheckin and lastWet/lastDry attributes to produce (UNIX) Epoch-based date format time/date stamps for users. Now users that would like to show the the time/date of the last instance of a particular event in a Hubitat Dashboard can use lastCheckinTime and/or lastWetTime/lastDryTime.
This is in addition to the original time/date attrubutes which have been renamed to lastCheckinEpoch and lastWetEpoch/lastDryEpoch, for users of WebCoRE (if you dare) or other automation apps that may need the Epoch-based date format.
Battery % events will only occur when there's a change in the value
The lastCheckinTime and lastCheckinEpoch attributes will now only generate an event when the check in / battery report message is received from the sensor (either every 50 or 60 minutes, depending on the model), or when the reset button is short-pressed. So, if you've been relying on battery percentage reports to know whether your sensor is still on the ZigBee mesh network, then you'll need to enable and start looking at the lastCheckinTime/lastCheckinEpoch events (see the next change, below).
Time/Date stamp events are now optional (default = disabled)
Custom attributes can add dozens of extra events each day that some people say they would rather not have clutter up their events list. So I've added two preference settings to enable/disable time/date stamp events, one for lastCheckin... and one for lastWet.../lastDry... The default for these settings is disabled so if you've been making use of any of time/date events , you'll need to go to the device details page for the sensor and enable them.

Detailed Release Notes

Fixed NullPointerException error when wet / dry status messages are received from sensor
Added new preference setting to enable generation of lastCheckin___ and lastWet___/lastDry___ time/date stamp events. NOTE: the default setting is DISABLED.
Renamed custom attributes lastCheckin, lastWet, and lastDry to lastCheckinTime, lastWetTime, and lastDryTime respectively, to be used to generate human readable time/date stamp events
Removed all references to WebCoRE for use of Epoch-time/date stamp custom attribute events and replaced with "Apps that can use Epoch time/date stamps"
Added lastCheckinEpoch, lastWetEpoch, and lastDryEpoch attrubutes, used to generate Epoch time/date stamp events
Changed both lastCheckin____ events to only occur when the sensor checks in (at same time as when battery voltage is reported)
Changed driver's name to "Aqara Leak Sensor"
Removed deviceId, endpointId, and manufacturer from fingerprint entry
Added specific device join name to fingerprint
Removed isStateChange: true to stop the driver from generating redundant repeat value events. NOTE - log messages of repeat values will still be displayed, if info/debug message logging is enabled.
Changed default min/max battery voltages to 2.9V/3.05V
Other minor code fixes and reformatting

gavincampbell · February 20, 2019, 7:42pm

This this a change you are planning to do across all of the devices or do you find that they each are different when it comes to the ranges?

veeceeoh · February 20, 2019, 7:54pm

Until I have better hard data, across all devices. This change came out of an exchange on this thread some months ago, and from what I’ve seen I believe these values are little more realistic.

But as I have mentioned before, the method to derive a battery life percentage from a voltage value is about as far from precise as you can get. It really is a ballpark figure. I wish I could do more for all the people who like to have a very firm level of control of feedback from all their devices.

That said, the values can of course be adjusted to personal preference in the per-device user settings - or in the driver itself. However I’d go with the preference setting route because you only have to experience the “pain” once, and it will remain the same through all driver updates.

gavincampbell · February 20, 2019, 8:03pm

Totally understand. I'm still waiting on my first to die so I can take some measurements and contribute. But its tuff to determine. Was more of a curiosity question.

veeceeoh · February 21, 2019, 3:20am

[UPDATE] v0.7.5b of Aqara Wireless Smart Light Switch Device Driver

Version 0.7b had some issues, so I am reposting this major update which should now be working. The only hardware that hasn't been fully tested yet is the 2018 revision of the 2-button model WXKG02LM (ZigBee model ID lumi.remote.b286acn01).

~~The new beta device driver code can be grabbed from [here]~~ EDIT: The driver has been released out of beta, at v0.8 on March 5 2019. The permanent location of the code to grab from is here.

PLEASE NOTE: If you are also using any Xiaomi Temperature-Humidity Sensors (the circular type), that device driver may be incorrectly chosen when pairing an Aqara Wireless Smart Light Switch. I need to contact Hubitat to find out why this happens, but until then, if this happens, then go the the device details page for the Wireless Smart Light Switch and manually change to this correct device driver. Then, reload the device details page for the switch, and make sure to click Save Preferences to correctly initialize the driver.

Major Changes

Full support for 2018 hardware revision of switches (UNTESTED)
The new 2018 revision of the one button Wireless Smart Switch (ZigBee model lumi.remote.b186acn01) and the two button Wireless Smart Switch (ZigBee model lumi.remote.b286acn01) added hardware support for double-press and hold functions. On the two button 2018 revision, that translates to nine available types of button press functions.
I do not own either of the 2018 revision switches, so support in this driver is completely untested. If you have either of them (lumi.remote.b186acn01 or lumi.remote.b286acn01 as noted in the device details page for the switch when logged into your hub), please PM me if you'd like to help with beta testing. Also, please PM me if you would be interested in "donating" one of the 2018 revision switches to me in the name of science!
Improved Identification of model during pairing
As long as the ZigBee model information is received by the hub while pairing, the driver will set the correct number of buttons available for automations and log messages will show the model detected. Also, for some reason I have noticed that when pairing the Xiaomi Temp-Humidity Sensor (model RTCGQ01LM), this driver will be incorrectly chosen, so a warning log message will be output alerting the user to manually change to the correct driver for the Xiaomi Temp-Humidity Sensor.
Battery % events will only occur when there's a change
If you've been relying on battery percentage reports to know whether your sensor is still on the ZigBee mesh network, then you'll need to enable and start looking at the lastCheckin events (see the next point, below).
lastCheckin Time/Date stamp events are now optional (default = disabled)
This driver includes custom lastCheckin_____ attributes for users that would like to use either for displaying the time/date of the last instance of a particular event in a Hubitat Dashboard (using lastCheckinTime), or to use with WebCoRE (if you dare) or other automation apps that may need the (UNIX) Epoch-based date format (using lastCheckinEpoch).
Both of these custom attributes will now only generate an event when the check in / battery report message is received from the sensor (either every 50 or 60 minutes, depending on the model).
However, these custom attributes add 28-30 extra events a day that some people would rather not clutter up their events list. So I've added a preference setting to enable/disable lastCheckin events. The default for these settings is disabled so if you've been making use of any of lastCheckin, you'll need to go to the device details page for the sensor and enable them.

Capabilities of the different models

Model WXKG03LM (1 button) - 2016 Revision (lumi.sensor_86sw1lu):
~ Single press results in button 1 "pushed" event
Model WXKG03LM (1 button) - 2018 Revision (lumi.remote.b186acn01):
~ Single press results in button 1 "pushed" event
~ Double click results in button 1 "doubleTapped" event
~ Hold for longer than 400ms results in button 1 "held" event
Model WXKG02LM (2 button) - 2016 Revision (lumi.sensor_86sw2Un):
~ Single press of left button results in button 1 "pushed" event
~ Single press of right button results in button 2 "pushed" event
~ Single press of both buttons results in button 3 "pushed" event
Model WXKG02LM (2 button) - 2018 Revision (lumi.remote.b286acn01):
~ Single press of left/right/both button(s) results in button 1/2/3 "pushed" event
~ Double click of left/right/both button(s) results in button 1/2/3 "doubleTapped" event
~ Hold of left/right/both button(s) for longer than 400ms results in button 1/2/3 "held" event

Detailed Change List (for v0.7.5)

Fixed all errors and issues in v0.7 & v0.7.1
Reworked and refactored init() routine to correctly set number of buttons available to apps based on Zigbee model.
Refactored button press message parse code

Detailed Change List (for v0.7)

Added UNTESTED full support for 2018 hardware revision (left/right/both pressed, held, and double-tapped)
Changed the use of both lastCheckin____ attributes to only generate an event every time the sensor does its regular 50 or 60 minute check in and battery report
Added a Preference Setting to enable/disable all "lastCheckin" events (lastCheckinEpoch and lastCheckinTime) with a default of DISABLED
Improved identification of model and revision during pairing to help set the correct number of available buttons, as well as warn users when this driver is incorrectly selected during the pairing of a Xiaomi Temp-Humidity Sensor (model RTCGQ01LM)
Removed isStateChange: true parameter from battery events to avoid redundant repeat percentage values from being posted
Removed "Xiaomi" from device name (name is now "Aqara Wireless Smart Light Switch")
Edited fingerprints to remove deviceId and add DeviceJoinName
Change date formate used for battery replaced date to MMM dd yyyy (e.g., "Jan 17 2019")
removed unnecessary function calls
Edited and added comments to better reflect functions
Reorganized code (order of functions, some refactoring)
Other minor code formatting cleanup

A quick note on working on the other recently raised issues with the Mi Cube and Temp-Humidity drivers: My time is still currently limited, but I will be addressing those drivers next.

ablack-utility · February 21, 2019, 7:54am

Veeceeoh, thank you such quick turnaround. Confirmed fixed! Awesome!

Here are debug logs with it working:

[dev:119](http://10.0.0.31/logs#dev119)2019-02-20 11:50:36.573 pm [debug](http://10.0.0.31/device/edit/119)Status: ALIVE: Heartbeat
[dev:353](http://10.0.0.31/logs#dev353)2019-02-20 11:50:11.941 pm [debug](http://10.0.0.31/device/edit/353)Leak Sensor - Dishwasher: Creating event [name:water, value:dry, descriptionText:Sensor is dry]
[dev:353](http://10.0.0.31/logs#dev353)2019-02-20 11:50:11.938 pm [info](http://10.0.0.31/device/edit/353)Leak Sensor - Dishwasher: Sensor is dry
[dev:353](http://10.0.0.31/logs#dev353)2019-02-20 11:50:11.934 pm [debug](http://10.0.0.31/device/edit/353)Leak Sensor - Dishwasher: Parsing message: zone status 0x0000 -- extended status 0x00
[dev:353](http://10.0.0.31/logs#dev353)2019-02-20 11:49:55.407 pm [debug](http://10.0.0.31/device/edit/353)Leak Sensor - Dishwasher: Creating event [name:water, value:wet, descriptionText:Sensor detected water]
[dev:353](http://10.0.0.31/logs#dev353)2019-02-20 11:49:55.394 pm [info](http://10.0.0.31/device/edit/353)Leak Sensor - Dishwasher: Sensor detected water
[dev:353](http://10.0.0.31/logs#dev353)2019-02-20 11:49:55.387 pm [debug](http://10.0.0.31/device/edit/353)Leak Sensor - Dishwasher: Parsing message: zone status 0x0001 -- extended status 0x00
[dev:353](http://10.0.0.31/logs#dev353)2019-02-20 11:49:38.261 pm [debug](http://10.0.0.31/device/edit/353)Leak Sensor - Dishwasher: Creating event [name:battery, value:83, unit:%, descriptionText:Battery level is 83% (3.025 Volts)]
[dev:353](http://10.0.0.31/logs#dev353)2019-02-20 11:49:38.244 pm [info](http://10.0.0.31/device/edit/353)Leak Sensor - Dishwasher: Battery level is 83% (3.025 Volts)
[dev:353](http://10.0.0.31/logs#dev353)2019-02-20 11:49:38.241 pm [debug](http://10.0.0.31/device/edit/353)Leak Sensor - Dishwasher: Battery parse string = 220121D10B03281C0421A81305213A0006240000000000082104020A210367641001
[dev:353](http://10.0.0.31/logs#dev353)2019-02-20 11:49:38.237 pm [debug](http://10.0.0.31/device/edit/353)Leak Sensor - Dishwasher: Reset button was short-pressed
[dev:353](http://10.0.0.31/logs#dev353)2019-02-20 11:49:38.232 pm [debug](http://10.0.0.31/device/edit/353)Leak Sensor - Dishwasher: Message payload: 156C756D692E73656E736F725F776C65616B2E61713101FF42220121D10B03281C0421A81305213A0006240000000000082104020A210367641001
[dev:353](http://10.0.0.31/logs#dev353)2019-02-20 11:49:38.221 pm [debug](http://10.0.0.31/device/edit/353)Leak Sensor - Dishwasher: Parsing message: read attr - raw: 1D770100007C050042156C756D692E73656E736F725F776C65616B2E61713101FF42220121D10B03281C0421A81305213A0006240000000000082104020A210367641001, dni: 1D77, endpoint: 01, cluster: 0000, size: 7C, attrId: 0005, encoding: 42, command: 0A, value: 156C756D692E73656E736F725F776C65616B2E61713101FF42220121D10B03281C0421A81305213A0006240000000000082104020A210367641001

veeceeoh · February 21, 2019, 5:58pm

I have a bunch of both type of the Temperature-Humidity sensors, and they are all reporting with normal expected values. When testing the updated code, I also tried testing both kinds in the freezer, looking at F and C values. No issues.

Can you double check that you're using version 0.8.1 of the Xiaomi Temperature Humidity Sensor driver, and if yes and you don't mind - please PM me with some log output with both info and debug messages enabled, thanks!

JasonJoelOld · February 21, 2019, 6:02pm

Just another data point - All 10 of my Aqara temp/humidity/pressure sensors are working correctly (all 3 readings) with the 0.8.1 driver.

ablack-utility · February 22, 2019, 1:06am

Ok just doublechecking the device driver I'm using: Version 0.8.1 and hub firmware 2.0.5.

I have two that read humidity and one that doesn't (I think the square type?) The ones with humidity are working fine now. Here's the current reading from the funky one:

#### Current States
* battery :  **83**
* batteryLastReplaced :  **Tue Nov 27 23:55:31 PST 2018**
* humidity :  **112.9**
* temperature :  **-166.0**

* endpointId:  **01**
* application:  **02**
* model:  **lumi.sensor_ht**
* manufacturer:

Last activity: 2019-02-21 4:53:12 PM PST

Maybe it's just broken? I'll re-pair it tonight to see what is going on. I do know before I updated the device driver v0.8.1, all 3 had wildly odd readings... but now it's just this one. I'm not home so I can look at it to confirm if it's the square or round type.

ablack-utility · February 22, 2019, 2:12am

Ok nevermind -- I went to take a look at it at home and now it's working. Who knows ... maybe it was somehow just never updating? Either way, works now so thank you!

####
Current States

* battery :  **83**
* batteryLastReplaced :  **Tue Nov 27 23:55:31 PST 2018**
* humidity :  **54.0**
* temperature :  **65.5**

veeceeoh · February 23, 2019, 8:19am

[UPDATE] v0.3b of Xiaomi Mi Cube Controller device driver for Hubitat

I have completed some significant reworking of the code so that all the cube's functions (shake, flip, rotate, slide, and knock) are correctly recognized and generate the corresponding button X pushed events (according to the "cube mode" set in the device's preference settings), along with much more meaningful info log messages as feedback.

The updated working beta device driver code can be grabbed from here.

PLEASE NOTE: This driver is still in beta, and its features and functionality may change.

Major Changes

Resolved all issues with lost functionality in driver v0.2.1b
All cube actions (shake, flip, rotate, slide, and knock) will generate button X pushed events, but I need to evaluate the usefulness of simultaneous button pushed messages for some cube actions when the driver's "cube mode" is set to "Combined". Also, this driver produces a large number of events, and I plan to look at reducing that and making it more efficient.
Helpful info log message output has been added
With "info message logging" enabled in the preference settings, much more relevant and useful log messages will be output for all cube actions.
The voltage range for Battery % has been changed
The minimum / maximum voltage values used to calculate battery percentage have been changed from 2.5V min / 3.0V max to 2.9V min / 3.05V max. This means your reported battery percentages will change from what you have been seeing! It should not be a cause for alarm, however. Keep in mind that using the min / max voltage values to calculate a battery percentage only gives a very very rough estimate of battery health. Also, remember that the min / max voltage values can be changed in the preference settings in the device details page for each sensor.
Added Human Readable Time/Date stamp attributes for Dashboard use
This driver had originally included a custom lastCheckin attribute to produce (UNIX) Epoch-based date format time/date stamps for users. Now users that would like to show the the time/date of the last instance of a particular event in a Hubitat Dashboard can use lastCheckinTime. This is in addition to the original time/date attribute which has been renamed to lastCheckinEpoch. I plan to add custom lastPushedTime / lastPushedEpoch attributes in a future update.
Battery % events will only occur when there's a change in the value
The lastCheckinTime and lastCheckinEpoch attributes will now only generate an event when the check in / battery report message is received from the sensor (either every 50 or 60 minutes, depending on the model), or when the reset button is short-pressed. So, if you've been relying on battery percentage reports to know whether your sensor is still on the ZigBee mesh network, then you'll need to enable and start looking at the lastCheckinTime / lastCheckinEpoch events (see the next change, below).
Time/Date stamp events are now optional (default = disabled)
Custom attributes can add dozens of extra events each day that some people say they would rather not have clutter up their events list. So I've added a preference setting to enable/disable time/date stamp events, one for lastCheckin... The default for this setting is disabled so if you've been making use of any of time/date events, you'll need to go to the device details page for the sensor and enable them.

Detailed Release Notes

Resolved all issues with lost functionality in driver v0.2.1b
Reworked and refactored message parsing code
Removed unused and unnecessary functions, function calls, and custom attributes
Improved info log message output to provide much more helpful and relevant log messages
Fixed debug message output behavior so that "Enable debug message logging" now controls all debug message log output
Added new preference setting to enable generation of lastCheckin___ time/date stamp events. NOTE: the default setting is DISABLED.
Renamed custom attribute lastCheckin to lastCheckinTime, to be used to generate human readable time/date stamp events
Removed any references to WebCoRE for use of Epoch-time/date stamp custom attribute events and replaced with "Apps that can use Epoch time/date stamps"
Added lastCheckinEpoch attrubute, used to generate Epoch time/date stamp events
Changed lastCheckin____ events to only occur when the sensor checks in (at same time as when battery voltage is reported)
Removed isStateChange: true in a number of instances to reduce the number of redundant repeat value events generated by the driver.
Changed default min/max battery voltages to 2.9V/3.05V
Other fixes, reformatting, and reorganization of code

Tagging @vjv and @andrew.rowbottom so you see this driver update - please give it a try and let me know how it works for you!

veeceeoh · February 23, 2019, 11:11pm

Just a quick note regarding the updated Xiaomi Mi Cube driver:

I realized this morning that the function to set the number of available buttons based on the Cube Mode set in preferences is not working correctly. There are a number of other minor issues as well.

I have been working fixing these issues as well as on documentation on how to use the driver, but I have run out of time for today, and probably for the rest of the weekend. I will try my best to finish up work on all of that, but it may not come until early next week.

As always, thanks for your patience and support!