[Release] Xiaomi / Aqara device drivers

community_driver

#295

I think I've said it before, but I'll say it again.

I am not a paid developer. I am an end-user. I am not a coder by trade. I took up learning Groovy language last year with the purpose of helping to improve Xiaomi / Aqara Zigbee device handlers for SmartThings, and after buying my Hubitat hub, I ported them over. For free.

I don't receive anything for what I do, other than the custom device drivers and apps by other users who have also decided to freely share the products of their time, energy, and efforts.

In fact, I pay for what I do. I have bought devices just for the purpose of helping others to be able to make use of them. I can't really afford to buy loads of devices I might not actually use myself, so this makes the testing process a lot more difficult, not having them in front of me to work with.

Furthermore, since this is not my paid job, I can only use spare time to maintain, improve, and introduce device drivers, as well as to field a constant stream of questions from other users on both platforms. Spare time that I don't have a lot of. So even though it shouldn't have to be said, apparently I have to ask for some patience.

But if you really need to know how I am going with the update, here you go:

I have been working on updates to the entire set of Xiaomi / Aqara device drivers for Hubitat. This includes working adding support to some device drivers for a number of recently released new revisions of some Aqara devices I don't own myself.

Add to this the fact that I have been having major issues with the overall speed of my Hubitat hub, despite removing all custom apps. So while I have been trying to troubleshoot that for more than two months, at the same time I've working on updates for numerous Hubitat device drivers and SmartThings device handlers. If you look at my recent post with the table showing all Xiaomi / Aqara ZigBee devices and their various revisions, you'll see that there are a LOT of them.

The slowness of my Hubitat hub directly affects the ability of some of the device handlers to execute time-sensitive operations as expected. One of them is the device handler for the "original" Xiaomi Button, which is making it very very difficult to test improvements I'm trying to make to the reliability of the software-based button held feature. But since you've mentioned it @mike, I assume the "original" Xiaomi button driver is the other one you're really hoping can have human readable date/time stamp events when the button is pushed to use in a Hubitat dashboard. With that in mind, I'm going to share a beta update for that device driver (see below) which only includes the custom attributes for human readable time/date stamps as well a big update to the Aqara button driver to maintain consistency.



[BETA] Hubitat Device Driver for Xiaomi "Original" Button version 0.85b

Device driver code available here.

Changelist

  • Renamed custom attributes lastCheckin, buttonPressed, buttonHeld, and buttonReleased to lastCheckinEpoch, buttonPressedEpoch, buttonHeldEpoch, and buttonReleasedEpoch, respectively,
  • Added custom attributes lastCheckinTime, buttonPressedTime, buttonHeldTime, and buttonReleasedTime, which are 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"


[UPDATE] Hubitat Device Driver for Aqara Button version 0.6

Device driver code available here.

This update takes v0.55b out of beta as a full release. It now provides support for all three known versions of the Aqara Button:

Model WXKG11LM (original revision)

  • Single click results in button 1 pushed event
  • Double-click results in button 2 pushed event
  • Triple-click results in button 3 pushed event
  • Quadruple-click results in button 4 pushed event
  • Button release is automatic, based on user-adjustable timer, resulting in button 0 pushed event

Model WXKG11LM (new revision)

  • Single click results in button 1 pushed event
  • Hold for longer than 400ms results in button 1 held event
  • Release of button results in button 1 released event
  • Double click results in button 1 doubleTapped event

Model WXKG12LM

  • Single click results in button 1 pushed event
  • Hold for longer than 400ms results in button 1 held event
  • Release of button results in button 1 released event
  • Double click results in button 1 doubleTapped event
  • Shaking the button results in button 2 pushed event

Changelist (from v0.5)

  • Changed driver's name to "Aqara Button"
  • Added specific device join names to all the fingerprint entries
  • Removed deviceIds and endpointIds from fingerprint entries
  • added compatibility for the new revision of Model WXKG11LM (ZigBee reported model: lumi.remote.b1acn01) with help from Hubitat user @guyeeba
  • changed event type functionality for Model WXKG12LM to include DoubleTapableButton and ReleasableButton capabilities, so that pushed , held , doubleTapped , and released events are all assigned to button 1 , and shaking the button results in a button 2 pushed event.
  • added a routine to determine model at time pairing / when saving preferences and set appropriate number of buttons available to Hubitat apps
  • added buttonPressedTime , buttonHeldTime , and buttonReleasedTime attributes used for generating human-readable date/time stamp events which can be utilized for Habitat dashboard display
  • Renamed custom attributes lastCheckin, buttonPressed, buttonHeld, and buttonReleased to lastCheckinEpoch, buttonPressedEpoch, buttonHeldEpoch, and buttonReleasedEpoch, respectively
  • renamed updateCoREEvent() to updateDateTimeStamp
  • 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"
  • changed default battery voltage range used for calculating percentage to 2.9 V minimum / 3.05 V maximum
    Fixed error in info log messages displayed when button is pushed, double-clicked, held, etc.
  • removed redundant call to init() function in installed()
  • removed push() and hold() command "trap" functions which are no longer necessary
  • various minor formatting / comments fixes


In my testing, instead of new Date(), it's better to use new Date().toLocaleString() which will make sure the time/date stamp is correct for your location's time zone (and presumably 12 or 24-hour clock setting).

However, the above two updates incorporate new Date().toLocaleString(), so you could just try using those, for the Xiaomi / Aqara Buttons at least.


#296

Ho can I have information like this on Hubitat, Max/Min/Battery screen shoot from ST

image


#297

Hubitat does not have a graphical mobile app like SmartThings. So the answer is no, this cannot be user interface cannot be presented in the same way using a Hubitat hub.

However, there is a Hubitat feature that allows you to see the visual status for some aspects of device, called the "Dashboard". Please see here for more information:


#298

Vibration sensor:

I'm interested in getting one of these for mail delivery detection. The mailbox is all-metal and I plan to mount it on the underside. For delivery, the latch is pretty sturdy, so the box shakes when it is opened/closed. Do you think this will detect the box vibrations?


#299

Very likely. I can try a test with my mailbox in the next week or so (though I'm not sure it's within range of my ZigBee mesh network!)


#300

Range turned out to be an issue, so I haven't completed this test yet. Stay tuned.



Continuing discussion about the Vibration Sensor beta driver from this post on the Xiaomi devices - are they pairing / staying connected for you? thread.

I can't remember - have you also tried the Hubitat device driver that I ported over from my SmartThings DTH code? I'm not sure how your port compares, but since I worked on both, my intention is to stick with the code for Hubitat I have been working on.

In theory, using it or laundry notifications should be an appropriate use case for the sensor. I think the key is figuring out how to get the sensitivity level command sent by Hubitat to be recognized. I do know from all my reading that it seems to only accept the command when it has been "awakened" by short-pressing the reset button, or possibly immediately after a check-in/battery report (or other reports). Sending the command doesn't work when a sensor is just sitting idle.

As for the "margin of error" setting, it's clear that needs to be opened up as a user-configurable setting, probably with a default of 10 as I have it now.


Xiaomi devices - are they pairing / staying connected for you?
#301

Its been a while so hopefully I get it right.

I originally tried the port you did. I think it was a .5b version or something like that. I saw a lot of activity and decided to port over a newer version of the ST code which was 0.91b and that is what I'm using now.

The port was pretty straight forward except for the line "zigbee.readAttribute(0x0000, 0xFF0D, [mfgCode: 0x115F])" which I ended up changing to a sendHubCommand based on your other port. For some reason it just didn't like that line at all.

If there is a specific HE port you want me to test let me know. I'll load that and work with it so we are using the same version.

My findings was that making any sort of changes didn't affect anything. So it was way to sensitive. My door next to the washing machine was setting it off so I just gave up as zigbee commands are above me at this point.

This might be good. My garage doors technically go up and down and should rest in the same position. But who knows if the sensor isn't exact. Adjusting the error solved this issue and now it properly detects opened and closed. I use these sensors with the MyQ control. This way you don't have to poll the server for door status.


#302

I'm here for testing if needed


#303

To clarify Keith's answer, you can, have that display, absolutely. And I like it better than the dashboard. This is a hubitat device in ST mobile app

You leave your ST hub active and load the Other Hub Event Pusher, and BAM all your hubitat devices show in the ST mobile app and can be controlled ! The setup has about 12 steps, just go slow and read carefully. You'll need to install apps on BOTH hubitat & smartthings to get this working.

I just had to redo my whole setup last night, as I discovered my device prefix was too long and resulted in cutting off critical sensor names. I reccommend the prefix of "H", that's it
We have Kevin Laframboise to thank for developing this amazing app


Sorry for the off topic post


#304

The device page seems to reflect the change in sensitivity. Are you saying that the change hasn't really been accepted by the device?


#305

That's correct. I set up the mechanism in the device driver for changing the sensitivity level, but it's missing the correct command to send to the sensor. I have some good news, though:

Just in the last couple of weeks, I have figured out what the correct command should be. Also, after a bunch of reading and viewing of YouTube video reviews of the vibration sensor, I realized that when used with the Xiaomi/Aqara hub, the user must push the reset button on the sensor itself after selecting the sensitivity level in the Xiaomi mobile app.

I believe the reason for this is that short-pressing the sensor's reset button is the only way to make sure it is "awake" and ready to receive the change sensitivity level command.

So, in my next beta version of the device driver (which I am releasing today!) the method for changing the sensitivity level has been changed so that each press of the reset button on the sensor will cycle through the sensitivity levels.

HOWEVER... In my testing, I still don't see any evidence that the sensitivity level is changing. Unfortunately, the sensor won't respond to what are called "read attribute" commands, which is the only way to check if the sensitivity level has changed. Except if you have a ZigBee network sniffer device.

So I have ordered a ZigBee sniffer, and hope with the help of that to be able to put this to bed after it's arrived.


#306

Whe you receive the sniffer there are a couple tests that would be interesting for you to do (in the back of my current ordeal with support).

Have it sniffing a few devices that are connected to the HE radio directly and through an IKEA outlet for example. Just curious if the outlets will do some "translation" services.


#307

I'm surprised you couldn't do this with the xbee. I was googling it earlier and got side tracked by work related stuff. Damn work. Would have been a nice bonus with xbee.


#308

[BETA] v0.7b of Aqara Vibration Sensor Device Driver

The new beta device driver code can be found here .

Although the main functionality of the driver remains the same, I've made significant changes "under the hood", especially in terms of how events are reported as well as adding control over the volume of custom events that are reported. This is a change I am planning to make to all of the Xiaomi/Aqara device drivers moving forward.

Beyond this, there are some new preference settings that can be accessed in the device details page, and probably the most important change is that I am now very very close to getting the sensitivity level change function working.

Major Changes

  • Changing the sensitivity level
    As mentioned in my previous post, I realized that the sensor's reset button must be short-pressed before the command to change the sensitivity level is sent. So the "button" in the device details page has been removed, and now the only way to send the sensitivity level change command is by short-pressing the reset button.
    The setting will cycle through the 3 levels on each press: low -> medium -> high -> low, etc. However, in my testing, the sensitivity level still does not seem to be changing and the only way I can troubleshoot at this point is by using a ZigBee network sniffer. I have ordered one and will post my findings here as soon as I've received it and got it working. If you happen to have a ZigBee sniffer and an Aqara Vibration sensor, please let me know if you'd like to try to help before my sniffer arrives.

  • Time/Date stamp events are now optional (default = disabled)
    There are a number of custom time/date attributes I included in the device driver for users that would like to use either for displaying the time/date of the last instance of a particular event, or to use with WebCoRE (if you dare) or other automation apps that may need the (UNIX) Epoch-based date format.
    All of the custom attributes begin with last and the human-readable time/date stamp ones end with Time and the Epoch-based ones end with Epoch. So for example if you want to display the time/date stamp of the last time the hub received any message from the sensor in a Hubitat Dashboard, you'd want to use the attribute lastCheckinTime.
    However, these custom attributes add a good number of extra events that some people would rather not clutter up their events list. So starting with this beta device driver, I am adding preference settings to enable/disable lastCheckin events, and another setting for all of the other last_____ events. The default for these settings is disabled so if you've been making use of any of them, you'll need to go to the device details page for the sensor and enable them, like this:

  • New setting: Margin of error for open/close position
    The open/close contact feature of this driver uses some "complex" math to convert the accelerometer XYZ data to a position in 3D space, but since doors and things don't always open or close in exactly the same position, there needs to be some way to adjust how far off from the originally set open/close positions the sensor can be in order to be considered in the open or closed positions.
    That margin of error value is now opened up to users to adjust as seen in the above screenshot. The default is 10.0, and larger numbers will increase the range of positions that will be considered open/closed. Don't ask me how many inches there are to a change of 1.0 in the value, because it doesn't work that way! It's based on the XYZ angles, so this is a setting that needs to be tested for each particular use case/installation.

  • Repeat/redundant events are not posted anymore
    Another thing I am changing in the Xiaomi/Aqara device drivers to reduce "clutter" in the events lists is to stop posting events that are redundant or repeats of the same information. This is a really important thing to be aware of if you have been looking at battery percentage reports as an indication of "device" health. With this change, battery events will only occur when the percentage changes from the previous value. There is one exception to this, which is TiltAngle events, because it is entirely possible for the sensor position to change with the same change in tilt angle as the last time the sensor was tilted.
    Note that this change to the way events are posted does not change info and debug log output (if it has been enabled in the preference settings).

  • Other Changes
    See the Detailed Change List, below.

IMPORTANT: For detailed information on the features / functionality of this device driver, please see my post from the initial beta release. For quick reference, here's a chart of the available functions taken from that post:

Sensor Function Hubitat event Notes
Movement/Shock Detected motion = active motion inactive is timer-based
Tilt Detected acceleration = active acceleration inactive is timer-based
Tilt Angle tiltAngle = value custom attribute (see notes here)
Drop Detected button 1 = pushed
XYZ accelerometer values contact = open/closed (see notes here)
Activity Report values Custom attribute (see notes here)
Change sensitivity level n/a not yet working

Detailed Change List

  • Changed method of changing sensitivity level - the sensor's reset button must be short-pressed to cycle through levels (low > medium > high > low, etc.)
  • Renamed custom attributes lastCheckin, lastDrop, lastStationary, lastTilt and lastVibration to lastCheckinEpoch, lastDropEpoch, lastStationaryEpoch, lastTiltEpoch, and lastVibrationEpoch, respectively
  • 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 Preference Settings to enable/disable all events that use 1) custom attributes lastCheckinEpoch and lastCheckinTime, and 2) all custom time/date stamp attributes (e.g., lastDropEpoch, lastDropTime, etc.) with a default of DISABLED for both settings
  • Added Preference Setting to change the "Margin of Error" range value used when determining whether the sensor's position matches either of the user-set open / close positions
  • Changed method of storing current XYZ angle values (angleX, angleY, angleZ) to state objects (currentAngleX, currentAngleY, currentAngleZ) instead of custom attribute events
  • Removed Three Axis capability and recording of threeAxis events
  • Removed isStateChange: true parameter from all events except TiltAngle to avoid any redundant repeat events being posted
  • Removed unnecessary displayed: true & false parameter from all events
  • Removed redundant vibration/movement, tilt, and drop detection description text from motion active, acceleration active, and button pushed events
  • Fixed reset battery replaced date command function
  • Change date formate used for battery replaced date to MMM dd yyyy (e.g., "Jan 17 2019")
  • Improved initialization and configuration when sensor is first paired
  • Reorganized code (order of functions, some refactoring)
  • Added more (hopefully) helpful comments to code
  • Edited and cleaned up log and event description output
  • Other minor code formatting cleanup and fixes

#309

So a Xiaomi Button fell into my lap.
I was trying to see what all of the buzz was about.
I got stuck initializing while trying to connect it.
I grabbed the Zigbee address and pasted it into a virtual device with a driver I found here.

It wasn't really working, and I wanted to try to re-pair it but when I try to delete it I get an Error 500: A Server error has occurred.

I know support is taking a break or ramping back up.
Anyone here have this issue?

Thanks.


#310

No, but searching for "Error 500:" leads me to think it may be related to the model, etc. name fields found in the "Data" section of the device information not being populated because you made a virtual device for the Xiaomi Button.

If you can't revert using a previous hub backup, I'd suggest blanking out the Zigbee Id, changing the Device Network to a random word, and changing the device Type to some generic Hubitat built-in driver, hit "Save Device" and then try removing the device.

Which button did you get? The circular one (model WXKG01LM)?


#311

Yes that's the one.
I'll try to clear it all out when I get home.


#312

That worked.
Then I successfully paired the device next time and now the next day it's stopped working.
I think this thing will fall out of my lap right about now.
I'm thinking it "fell off" the zigbee network...


#313

If you have any Zigbee devices that act as repeaters, then yes that's probably what happened.

Here's the story:

Xiaomi devices aren't very well-behaved guests of the Zigbee mesh party.

Although Hubitat made the party host (your hub) a little more patient about how often Zigbee guests should check in with it, most assistant hosts (repeater devices) aren't as patient and follow strict rules about kicking guests off the Zigbee mesh party list if they don't check in frequently enough. And Xiaomi devices are slow to check in, so the assistant hosts give them the boot.

Then when Xiaomi devices finally try to check in, even though the hub or repeater requests them to rejoin the party, those little rebellious devils simply refuse to do as told. Bad Zigbee citizens!

The way us Xiaomi lovers get around that problem is to only let lenient assistant hosts (repeater devices) join the Zigbee mesh party. XBees and IKEA Tradfri Smart Outlets are two such devices friendly to Xiaomi devices.


Pros and Cons of Xiaomi Zigbee Devices
#314

Excellent explanation, I was a big Xiaomi zigbee hater, but after looking and looking and get angry with their prices I finally used a spare hub exclusively for Xiaomi and Tradfri plugs, after having a stable mesh I ordered 8 contact sensors, 2 cubes and 1 motion, they arrive in February but I keep my 2 humidity sensors and 2 Tradfri playing nice until I get the rest of the party.