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

[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
2 Likes

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.

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)?

1 Like

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

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...

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.

2 Likes

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.

Using a second Hubitat Hub just for Xiaomi devices is a perfect workaround to the checkin timeout / rejoin issue, by creating a "sandbox" environment. I missed my chance with their recent discount sale, but I plan to get a second Hubitat in future when there's a good deal (or someone sells one!)

If you need any info from my hub I'm available, right now I just have zigbee for Xiaomi and Tradfri, z wave is turned off. I had plans to get a sniffer but I'm not a coder so I have no use for the data.

I just installed 2 Xiaomi door contacts yesterday, they are working great, love the size, price and speed. I have some more coming and a few motion sensors too. I have 5 ikea tradfri outlets splashed around the house/garage so maybe thats why im having good luck with them, granted its only been a short time

Thanks for the breakdown. The only zigbee repeater near the button overnight is an Ikea Tradfri switch oddly enough. I'll be returning it to the kind friend. I'll just buy another Samsung button when the time is right.

What do you think about using our old smartthings hub for the xiaomi devices? I too have becoming frustrated with them dropping off, but I have too many xiaomi devices to just scrap them... Would smartthings give them the boot because of the aforementioned check in frequency?

Should work, using other hub to link them to HE.

why would smartthings handle them any better?

Questions for the Xiaomi nerds here.

Were you able to make RM detect the the multiple clicks on the Xiaomi original button?
If so how? I'm trying to figure it out.

I see on the logs that double, triple and quadruple click are being detected as pushed (values 2, 3, and 4 respectively).

Thanks

It wouldn't handle them better per se, it would just be a way to isolate them on their own zigbee network with no other devices other than xiaomis.

I'd never move them back to my ST hub, for two reasons:

  1. A major loss of functionality. On SmartThings, you lose access to a bunch of functions of the Xiaomi / Aqara buttons & Wall switches. For example, the two button Smart Wireless wall switch is only "seen" as one button (both buttons send the same message when used in SmartThings), while with the Hubitat Hub, it works perfectly.

  2. Local execution of code. That's the main reason I switched over to the Hubitat hub. Cloud executed code makes a very noticeable hit on the speed and responsiveness of motion sensor and button activated automations and routines.

Another example: Combine those two factors, and the original Xiaomi button goes from being rather inconsistent on ST when using the driver-based button hold feature to working great with the Hubitat hub.

1 Like

The multi-clicks on the Xiaomi round button are assigned to different button numbers. So in RM, select that Xiaomi button, and then for double-clicks, choose button 2 pushed as the trigger, for example. Triple-click is button 3 pushed, etc.

Note that with all the Aqara buttons, if there's a double-click function, then that is assigned to button 1 double-tapped, not pushed.

Works thanks

With the newest Xiaomi Aqara Vibration sensors, how is everyone finding the battery life? Mine are in a colder section of house and after a month are at 30%. Since these are so new I'm not sure what to expect from them or if this short life is exposing a communication issue. I know the driver is beta for this DJT11LM sensor and not sure IF that could affect battery life or if they are reporting so frequently it's killing the battery