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

bobbles · February 14, 2019, 7:33pm

It most certainly is. You are putting a lot of work into this in your spare time. I'm not sure my other half would be happy with me spending my spare time developing stuff and also troubleshooting when people have issues.
Enjoy your beer or whatever your tipple may be.

peter · February 14, 2019, 7:53pm

Nope unfortunately stil broken, and also breaks my double button, so the double button gives:-

2019-02-14 07:47:24.275 pm errorgroovy.lang.MissingMethodException: No signature of method: dev15501736381781508166688.$() is applicable for argument types: (dev15501736381781508166688$_parse16Message_closure7) values: [dev15501736381781508166688$_parse16Message_closure7@4b74c952] Possible solutions: is(java.lang.Object), run(), run(), any(), use([Ljava.lang.Object;), any(groovy.lang.Closure) on line 147 (parse)

And the single button:-

2019-02-14 07:51:25.571 pm errorgroovy.lang.MissingMethodException: No signature of method: dev15501736381781508166688.$() is applicable for argument types: (dev15501736381781508166688$_parse18Message_closure8) values: [dev15501736381781508166688$_parse18Message_closure8@3db8d398] Possible solutions: is(java.lang.Object), run(), run(), any(), use([Ljava.lang.Object;), any(groovy.lang.Closure) on line 161 (parse)

dev:7522019-02-14 07:51:25.545 pm debugSingle Light Button by Bedroom 2: Message payload: 0001

dev:7522019-02-14 07:51:25.542 pm debugSingle Light Button by Bedroom 2: Parsing message: read attr - raw: 1B2A0100120A5500210100, dni: 1B2A, endpoint: 01, cluster: 0012, size: 0A, attrId: 0055, encoding: 21, command: 0A, value: 0100

dev:7522019-02-14 07:51:25.538 pm debugSingle Light Button by Bedroom 2: Data type of payload is little-endian; reversing byte order

The double button is model lumi.sensor_86sw2Un
The single button is model lumi.remote.b186acn01

Regards Pete

veeceeoh · February 14, 2019, 9:48pm

I am very sorry about that. I will need to look at the code after work when I can do some proper testing with my own 2016 revision two-button lumi.sensor_86sw2Un.

If you're using those buttons on a regular basis, here's a link to the previously working v0.6b to use until I can figure out the issue: Aqara Wireless Smart Light Switch device driver v0.6b (OLD VERSION)

Many thanks, @bobbles!

And thank you to everyone else who sent donations. It is very much appreciated and encouraging!

jasonbalsor · February 14, 2019, 10:19pm

@veeceeoh I have a couple of Aqara Door Sensors, in the model field this is what they show:

endpointId: 01
application:
model: lumi.sensor_magnet.aq2�B!�(!�!$ !��d
manufacturer:

Is this normal? They work fine just seemed like odd naming

peter · February 14, 2019, 10:22pm

Keith, not a problem, been in this industry too long not to keep backups very appreciative of all the time you spend helping us numpties out. Happy to test the code when you update it. Regards Pete

veeceeoh · February 14, 2019, 11:12pm

Yes, it seems to be normal. I've seen that with my Aqara Door/Window Contact sensors and my Aqara Leak sensor.

As mentioned in my above linked post, I believe what happens is: during the pairing process the value telling the hub the length the model text string is missed somehow, so extra "garbage" characters are picked up as part of the model name.

In any of my drivers that check on the ZigBee model name to do certain things, I make sure it only confirms the model begins with the relevant characters, so for example:

if (zigbeeModel.startsWith("lumi.sensor_magnet.aq2")) ...

vjv · February 16, 2019, 6:20am

Hello,

I installed a cube and I think is not working properly, not sure what is the problem, I can't get it detect anything, just shaking as button 1, here is the logs, first was a slide, then a face change:

I noticed when I paired the Cube it did not pick up the driver, paired as a device, so I proceeded to pair a second Cube and the same, paired as a device, so I got the fingerprint just in case. Any help will be greatly appreciated.

Edit: Restoring firmware 2.0.4 and selecting the disable for the compatibility fix I got working the face flip, slide, tab and shake, rotate is not working, I'm using the 36 button option. I have a hub exclusively for Xiaomi and Tradfri so I can help doing firmware upgrades and downgrades or changing/swapping drivers for testing and help the development of the drivers.


Manufacturer: Unknown Manufacturer

Product Name: Device

Model Number: lumi.sensor_cube.aqgl01

deviceTypeId: 109

more...

manufacturer:null
address64bit: deleted, sorry
address16bit: deleted, sorry
model:lumi.sensor_cube.aqgl01
basicAttributesInitialized:true
application:null
endpoints.01.manufacturer:null
endpoints.01.idAsInt:1
endpoints.01.inClusters:0000,0003,0019,0012
endpoints.01.endpointId:01
endpoints.01.profileId:0104
endpoints.01.application:null
endpoints.01.outClusters:0000,0004,0003,0005,0019,0012
endpoints.01.initialized:true
endpoints.01.model:lumi.sensor_cube.aqgl01
endpoints.01.stage:4
endpoints.02.manufacturer:null
endpoints.02.idAsInt:2
endpoints.02.inClusters:0003,0012
endpoints.02.endpointId:02
endpoints.02.profileId:0104
endpoints.02.application:null
endpoints.02.outClusters:0004,0003,0005,0012
endpoints.02.initialized:true
endpoints.02.model:null
endpoints.02.stage:4
endpoints.03.manufacturer:null
endpoints.03.idAsInt:3
endpoints.03.inClusters:0003,000C
endpoints.03.endpointId:03
endpoints.03.profileId:0104
endpoints.03.application:null
endpoints.03.outClusters:0004,0003,0005,000C
endpoints.03.initialized:true
endpoints.03.model:null
endpoints.03.stage:4

Right rotation

Left rotation

veeceeoh · February 17, 2019, 8:46pm

To be honest, I did not test the compatibility fix with the Cube beta driver because after successfully testing just about every other driver, in "theory" it should have just worked with the one for the Cube as well. Apparently, it's not.

I'm sorry to say that the Cube driver has received the least amount of attention, so I think now is a good time to look at getting it working correctly. However...

I haven't mentioned this before, but right at the same time I found out about the change with raw ZigBee message data in Hubitat update 2.0.5, I also learned changes the next SmartThings firmware update will result in broken functionality for a number of Xiaomi / Aqara button devices, as well as open up functionality that was previously unavailable.

So I have a really big pile of code changes and updates to work through.

Thanks for the offer! I think the log output you've already shared here is quite helpful, but I will let you know if it would help to see log output from the driver running in FW 2.0.4. I have a Cube and plan to focus on making sure the driver works in FW 2.0.5 for future compatibility.

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.