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

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?

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

1 Like

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.

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.

I'm here for testing if needed

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

1 Like

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

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.

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.

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.

[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