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

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!

vjv · February 23, 2019, 11:29pm

I noticed something odd in the rotation, it just works the first try, for example if you rotate left works but if you continue and rotate again left it doesn't work, so if you rotate right it works, then rotate left it works, then rotate left again doesn't work, rotating is a great way to change the brightness, I noticed the rotate buttons are doing the same, but in the previous driver the rotate buttons worked fine but not the physical rotation of the cube. Thanks for you efforts, take your time.

Edit, I noticed that the problem is on other functions/buttons too, for example if you shake it work but if you shake again it doesn't work, you must use another function like slide then shake to make it work. I reverted the driver to the previous version.

Thanks.

earlgreytea · February 24, 2019, 10:56am

I am on Version 0.5.1 of Xiaomi MiJia Honeywell Smoke Detector driver.

After pairing it with Hubitat, I did a test through the use of the test button on the detector. I observed the below error in log:

[dev:37](http://192.168.1.250/logs/past#dev37)2019-02-24 18:31:19.700 [error](http://192.168.1.250/device/edit/37)java.lang.NullPointerException: null (parse)

[dev:37](http://192.168.1.250/logs/past#dev37)2019-02-24 18:31:19.508 [info](http://192.168.1.250/device/edit/37)Kitchen Smoke Detector: Battery level is 100% (3.055 Volts)

Is this a cause for concern?

veeceeoh · February 25, 2019, 6:40am

[BETA] Xiaomi Mijia Honeywell Smoke Detector device driver for Hubitat v0.6b

I have attempted to address the errors reported by @earlgreytea, but since I do not own a Xiaomi MiJia Honeywell Smoke Detector, I have to ask that anyone who has this device please try out this updated beta driver, and either PM or post here with any feedback or log output (in the case you experience errors or unwanted behavior).

~~The beta code is available at a special temporary location here.~~
EDIT: The driver has been updated and taken out of beta. Please see this post for more information.

Major Changes

Hopefully resolved reported error and other issues introduced in driver v0.5.1
Added Human Readable Time/Date stamp attributes for Dashboard use
This driver had originally included a custom lastCheckin, lastClear, lastDetected, and lastTested attributes to produce (UNIX) Epoch-based date format time/date stamps for users. Now users who would like to show the the time/date of the last instance of a particular event in a Hubitat Dashboard can use lastCheckinTime, lastClearTime, lastDetectedTime, and lastTestedTime. This is in addition to the original time/date attributes which have been renamed to lastCheckinEpoch, lastClearEpoch, lastDetectedEpoch, and lastTestedEpoch.
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 another for the other time/date stamp events (lastClear___, lastDetected___, and lastTested___). 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

Reworked and refactored message parse code to (hopefully) eliminate errors introduced in driver v0.5.1
Corrected an undefined object used when parsing IAS Enroll Request messages
Fixed debug message output behavior so that "Enable debug message logging" now controls all debug message log output
Renamed custom attributes lastCheckin, lastClear, lastDetected, and lastTested to lastCheckinEpoch, lastClearEpoch, lastDetectedEpoch, and lastTestedEpoch, respectively, used to generate Epoch 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 lastCheckinTime, lastClearTime, lastDetectedTime, and lastTestedTime custom attributes, to be used to generate human readable time/date stamp events
Changed lastCheckin___ events to only occur when the sensor checks in (at same time as when battery voltage is reported)
Added two new preference settings, one to enable generation of lastCheckin___ time/date stamp events, and the other to enable lastClear___, lastDetected___, and lastTested___ time/date stamp events. NOTE: the default setting is DISABLED.
Removed isStateChange: true in a number of instances to reduce the number of redundant repeat value events generated by the driver.
Other fixes, reformatting, and reorganization of code

Yes. Can you give the above linked updated beta driver code a try and let me know whether it's working as expected?

earlgreytea · February 25, 2019, 6:44am

Thanks so much for the beta fix. A different error is observed:

[dev:38](http://192.168.1.250/logs#dev38)2019-02-25 14:42:52.844 [error](http://192.168.1.250/device/edit/38)java.lang.NullPointerException: Cannot get property 'descriptionText' on null object on line 113 (parse)

[dev:38](http://192.168.1.250/logs#dev38)2019-02-25 14:42:52.833 [debug](http://192.168.1.250/device/edit/38)Kitchen Smoke Detector: Battery parse string = 280121B70C0328200421A81305211E00062402000000000A21E18C08210410642000962300000000

[dev:38](http://192.168.1.250/logs#dev38)2019-02-25 14:42:52.829 [debug](http://192.168.1.250/device/edit/38)Kitchen Smoke Detector: Map of message: [raw:16610100005601FF42280121B70C0328200421A81305211E00062402000000000A21E18C08210410642000962300000000, dni:1661, endpoint:01, cluster:0000, size:56, attrId:FF01, encoding:42, command:0A, value:280121B70C0328200421A81305211E00062402000000000A21E18C08210410642000962300000000]

[dev:38](http://192.168.1.250/logs#dev38)2019-02-25 14:42:52.817 [error](http://192.168.1.250/device/edit/38)java.lang.NullPointerException: Cannot get property 'descriptionText' on null object on line 113 (parse)

[dev:38](http://192.168.1.250/logs#dev38)2019-02-25 14:42:52.772 [debug](http://192.168.1.250/device/edit/38)Kitchen Smoke Detector: Parsing message: read attr - raw: 16610100005601FF42280121B70C0328200421A81305211E00062402000000000A21E18C08210410642000962300000000, dni: 1661, endpoint: 01, cluster: 0000, size: 56, attrId: FF01, encoding: 42, command: 0A, value: 280121B70C0328200421A81305211E00062402000000000A21E18C08210410642000962300000000

[dev:38](http://192.168.1.250/logs#dev38)2019-02-25 14:42:52.756 [debug](http://192.168.1.250/device/edit/38)Kitchen Smoke Detector: Parsing message: zone status 0x0000 -- extended status 0x00

Let me know how I can assist further, thanks!

veeceeoh · February 25, 2019, 7:06am

That error was just on the line that outputs an "info" log message of the Description Text of the event about to be generated.

From that log output it looks like you first had an "All Clear" message, and then a checkin / battery report message. If you look at your smoke detector's Events list, you should hopefully see that those events were still correctly generated.

However, I've identified the cause of the error, and fixed it. It's so minor that I didn't change the version number.

The link to the fixed beta code is the same as above, here.

Thanks for reporting back and please let me know how this works for you.

earlgreytea · February 25, 2019, 8:06am

@veeceeoh appreciate your quick fix, the latest beta code works as expected!

I had performed a self-test and an actual trigger (used a burning paper). Both events were triggered correctly.

Kudos to you.

veeceeoh · February 25, 2019, 8:32am

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

After more testing with the v0.3b update, I realized that the method to set the number of buttons according to the Cube Mode selected in preferences wasn't working correctly. Also, I saw that the cube occasionally sends catchall: messages which are of no use, but produce (harmless errors.) Those issues have been fixed. Finally, I re-did the fingerprint data used to match the driver to the cube during pairing, it's working perfectly (for me, at least.)

The updated device driver code can be grabbed from here.

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

Change List

Added conditional check for catchall: messages to avoid unwanted java exception errors
Removed unused EnrollResponse command and Actuator attribute
Edited fingerprint data to improve selection of driver during pairing
Fixed issues with setting the correct number of buttons according to the user-selected Cube Mode

With the above v0.3.1b update, I am unable to replicate your experience. Here's some log output to show repeat gestures working just fine with my cube (note the entries below are reversed from normal output order, so the first is on the top, last is on the bottom):

Sample cube log output (click arrow to reveal)

12:10:15.239 am [info] Mi Cube: Updating preference settings
12:10:15.249 am [info] Mi Cube: Number of buttons set to 36
12:10:15.251 am [info] Mi Cube: Info message logging enabled
12:11:40.574 am [info] Mi Cube: Rotated by 29°
12:11:40.619 am [error] java.lang.NullPointerException: Cannot execute null+19 on line 349 (parse)
12:13:08.174 am [info] Mi Cube: Stale face data, updating
12:13:08.179 am [info] Mi Cube: Flip to face #3 detected (button 4 pushed)
12:13:08.182 am [info] Mi Cube: Knock detected with face #3 up (button 16 pushed)
12:13:12.928 am [info] Mi Cube: Rotated by 34°
12:13:12.951 am [info] Mi Cube: Right rotation on face #3 (button 22 pushed)
12:13:18.361 am [info] Mi Cube: Rotated by 16°
12:13:18.370 am [info] Mi Cube: Right rotation on face #3 (button 22 pushed)
12:13:23.163 am [info] Mi Cube: Rotated by -24°
12:13:23.170 am [info] Mi Cube: Left rotation on face #3 (button 28 pushed)
12:13:25.559 am [info] Mi Cube: Rotated by -20°
12:13:25.585 am [info] Mi Cube: Left rotation on face #3 (button 28 pushed)
12:13:31.730 am [info] Mi Cube: Flip to face #5 detected (button 6 pushed)
12:13:36.770 am [info] Mi Cube: Flip to face #0 detected (button 1 pushed)
12:13:40.957 am [info] Mi Cube: Knock detected with face #0 up (button 13 pushed)
12:13:44.846 am [info] Mi Cube: Flip to face #1 detected (button 2 pushed)
12:13:47.355 am [info] Mi Cube: Knock detected with face #1 up (button 14 pushed)
12:13:52.053 am [info] Mi Cube: Shake detected with face #1 up (button 32 pushed)
12:13:54.699 am [info] Mi Cube: Shake detected with face #1 up (button 32 pushed)
12:13:57.767 am [info] Mi Cube: Shake detected with face #1 up (button 32 pushed)
12:14:03.625 am [info] Mi Cube: Stale face data, updating
12:14:03.630 am [info] Mi Cube: Flip to face #2 detected (button 3 pushed)
12:14:03.635 am [info] Mi Cube: Slide detected with face #2 up (button 9 pushed)
12:14:06.497 am [info] Mi Cube: Slide detected with face #2 up (button 9 pushed)

If you are concerned about the driver not acting on messages received from the cube, then enable debug message log output, then you'll see every message the driver receives from the cube. Look for entries that start with Parsing message:

What I see, with my cube at least, is that it doesn't send a message every time I interact with it. For example, I have to be deliberate when I flip it, rather than moving it gently, in order to generate a "flip" message.

Also, if using the Advanced or Combined Cube Mode, keep in mind that sometimes the driver loses track of which face is up if the cube is moved in some way without causing any message being sent. For example, I can rotate the cube around in mid-air, gently set it on a surface, and the driver won't know which face is up anymore. The original author wrote code to extrapolate that as best as can be done, but it's an imperfect science. I will be adding a much more complete post on this thread soon to explain how the driver works as it stands right now, along with all the caveats and limitations due to the way the hardware itself works.

You probably noticed there is a java exception error in my sample log output. This is because it's log output from right after I freshly paired the cube, and the driver doesn't have any way to know what face is up if the first thing you do is rotate it. That's something I need to fix, but it's resolved as soon as another type of gesture occurs which supplies face up data. I'll get to fixing it soon, but that error is not breaking anything, though.

EDIT: I just noticed that my cube is reporting it's battery voltage at 2.735 Volts, below the minimum Volts value, so the percentage is calculated at -110%! It's still working fine, so perhaps I need to consider a lower min Voltage threshold for this particular Xiaomi device. Regardless, I'm going to get a new CR2450 just in case the original battery is near the end of it's useful life. Any observations from other cube users on reported battery voltages would be greatly appreciated!

That's wonderful news! I am going to keep it as a beta until I hear from at least a couple other people with the smoke detector, and then I'll make it "final".

By the way, I de-selected the "Solution" tick-box, because this thread isn't really about trying solve a specific issue.

Thanks again for testing the fixed code and reporting back here, much appreciated!