[OBSOLETE] Original & Aqara Xiaomi Zigbee Sensors (contact, temp, motion, button, outlet, leak, etc)

I’d certainly go along with pairing them next to the hub. They still pair when they feel like it (though I haven’t had one not pair yet) but they do seem more reliable. I’d like to think it is a case of preventing them connecting via a repeater that they don’t work properly with.

I’d say i agree, but with regards to repeating, anecdotal evidence from yesterday…

One of my Xiami Aquara motion sensors reported as unavailable - clicking it’s button did nothing - i tried this a number of times.

I then noticed one of my Zigbee Smart Bulbs in the same room was unavailable, and when i corrected that, and pressed the Motion Sensor button, it rejoined the network.

This suggests the motion sensors was previously repeating through the bulb successfully.

The bulb is an Osram Lightify E27 (UK). Details in Smartthings:

  • manufacturer: CentraLite
  • model: 3200-Sgb

bought seven of the window sensors, and they are incredibly temperamental. 4 have paired, 3 refuse, I’m at a loss as to why the other 3 are struggling. Gave up last night but will try again when I get home tonight

Sorry for the delay, I haven’t been ignoring your request but I was having a problem with my live logging, it wasn’t working. I opened up a support ticket with ST and just got a response that they were having an outage over the weekend and it should be restored.

Just checked it and got the log messages for you:

f66c85df-6efd-419b-9ac6-38291e352472 12:26:07 PM: error java.lang.IllegalArgumentException: Needs to be string or int, received null value: null @line 482 (changeSensitivity)

f66c85df-6efd-419b-9ac6-38291e352472 12:26:07 PM: error java.lang.IllegalArgumentException: Needs to be string or int, received null value: null @line 482 (changeSensitivity)

I can attest, at least through personal experience. I have a temp sensor. When paired away from the hub (in another room), it lasted about a day, then went offline.

I then reset it, and paired right next to the hub, waited for battery reporting, and moved it to its proper location (about 20 feet away, out the front door). It has been reporting regularly for a week now.

FYI to Xiaomi Aqara device users:

Thanks for that. The initial sensitivity level isn’t getting set up correctly. I will add a routine which will set it to “low” if the initial setup didn’t happen yet, by going into preferences and pressing save. I’ll post when the new beta code can be grabbed. Keep in mind I still haven’t confirmed whether the command to change the sensitivity setting is actually working, though.

I’m hoping the high sensitivity setting isn’t working yer! As in my tests so far, I’ve found these sensors aren’t as sensitive to tiny vibrations as the SmartThings multi sensors.

I have a few of the single wired wall switches installed (no neutral version). Interested to know if the button DH in this repo will work?


Currently using this DH

If anyone is in the Calgary area, and wants to pick up two of the aqara water sensors and a motion sensor (at cost) - send me a PM.

I have a connect hub (not the V2) and I have given up trying to get these things to stay paired.

Hopefully they fixed the issues as the firmware is rolling out soon

I’m having some trouble figuring out how to utilize these sensors, specifically with how the vibration level is reported. To put a use case out there as an example, I’m trying to send me an alert when my washing machine stops running. Right now, its not running… The device is showing as “Stationary” but the vibration level is showing 81. The last time the level was updated was over a half an hour ago. Looking back in the logs, I see that the lid to the washer was opened at 7:17am. It correctly reports the vibration and tilt with the changed axis values, etc. At 7:19 acceleration returned to inactive and vibration was reset to stationary. I then see several vibration levels reported, 21 at 7:29, 25 at 7:34, 26 at 7:42, 41 at 7:43, 54 at 7:49, 34 at 7:54, 2 at 7:59, 76 at 8:15, 80 at 8:16, 81 at 8:17… And then its been silent for about a half an hour now. According to the device, its still reporting a vibration level of 81 from 30 minutes ago.

Is it to be expected that the vibration level reporting report like that? Why did it report at 5 minutes, then 8 minutes, then 2 minuets, etc, then not for a half an hour?

I can’t answer all your questions, but i think the vibration level is just the last level reported and the device does not report zero once the vibration stops. This is something the DTH could be made do when it reports as stationary.

That makes sense. But that leads to another problem. Why did the device vibration go back to stationary and not return to “vibration” even thought it was reporting vibration levels? Could this have something to do with me not being able to set the sensitivity level? (See my previous post above).

I’ve had a quick look at the DTH. It looks like when the device reports a vibration, the Vibration status is set, and it is automatically reset back to Stationary after 65 seconds (default setting). However, it doesn’t look like there’s any code in there to set the status to Vibration when the device is reporting subsequent vibration levels.

I don’t know what events the device is emitting, and in what order, so we really need the DTH author to confirm as this may be by design. It would be ideal if you provided a copy of your logs.

Honest answer? I don’t know.

Remember that with Xiaomi devices in general, the user has zero control over it’s behavior. It works the way the Xiaomi engineers designed it. Here’s how native Xiaomi Mi mobile app presents the “Vibration Level”:

(NOTE: Screenshot is from another website, not from me)

I should probably rename that value to “Activity Level” because from all of my extensive testing it does not directly correlate to vibration level. I wrote a rather long post here about my findings, but I’ll repeat the important bits again here:

Here are the values I saw on one of the sensors over a period of 12 hours:

Example attribute 0x0505 (“Vibration Level”) values observed

(click arrow to reveal list)
Time Hex value Integer Notes on prior activity
19:42:25 00d1 0000 209 after a good number of vibration & tilt events
19:56:15 0047 0000 71 after 3 vibration, 3 tilt, & 1 drop events
20:05:38 0006 0000 6 after no events (stationary)
20:11:46 002b 0000 43 after 1 vibration & 2 tilt events
20:26:19 001b 0000 27 after 1 vibration event
20:33:58 0029 0000 41 after 1 vibration & 2 tilt events
20:39:46 0061 0000 97 after 2 vibration, 3 tilt, & 3 drop events
20:46:47 0041 0000 65 after 2 vibration events
20:55:22 004e 0000 78 after 3 vibration, 1 tilt, & 2 drop events
21:05:14 0003 0000 3 after no events (stationary)
21:28:22 0010 0000 16 after 1 vibration event
21:40:43 0009 0000 9 after no events (stationary)
22:21:48 004c 0000 76 after 2 vibration, 7 tilt, & 1 drop events
22:30:58 0036 0000 54 after no events (stationary)
22:48:27 006f 0000 111 after 3 vibration & 6 tilt events
22:49:26 00ca 0000 202 after 3 tilt events
22:55:19 00d2 0000 210 after 4 vibration & 6 tilt events
23:00:17 00ff 0000 255 after 3 vibration, 24 tilt, & 1 drop events
23:05:16 0107 0000 263 after 4 vibration & 24 tilt events
23:10:14 00b4 0000 180 after 2 vibration & 10 tilt events
23:20:29 007e 0000 126 after 4 vibration events
23:28:23 000c 0000 12 after no events (stationary)
03:23:46 0015 0000 21 after 1 vibration & 1 tilt event
03:28:47 000a 0000 10 after no events (stationary)
04:02:05 000c 0000 12 after 1 tilt event
04:52:47 0001 0000 1 after no events (stationary)
05:00:31 000b 0000 11 after 1 tilt event
05:27:44 0001 0000 1 after 1 tilt event
05:45:00 000a 0000 10 after 1 tilt event
05:50:00 000d 0000 13 after no events (stationary)
06:07:19 0056 0000 86 after 2 vibration & 2 tilt events
06:15:02 0049 0000 73 after 1 tilt event
07:28:00 000f 0000 15 after no events (stationary)
07:32:58 0055 0000 85 after 3 vibration & 8 tilt events
07:43:27 006f 0000 111 after 2 vibration & 7 tilt events

Some observations about the “Vibration Level” reports / values:

  • The time intervals between reports are inconsistent, but the most frequent intervals I see are about 5 minutes apart.
  • The values seem to represent past levels of vibration or activity, and not what is happening currently
  • The lowest value I’ve seen is 1 and highest is 265.
  • There seems to be some correlation between the number of vibration, tilt, and drop events and the “Vibration Level” value, but I think it’s not solely related to those events, especially since some events seems to prevent others from being reported when moving the sensor around a lot.
  • The values reported do not seem well suited to use for sleep movement detection, unless the sensitivity level has some effect, just based on leaving it under my pillow while sleeping and observing long periods without any reported values.

So I am definitely NOT planning to allow use of the “Vibration Level” (as it’s called now) for any home automation purposes in the DTH.

This is because the vibration event message works differently from the “Vibration Level” reports. As explained above, my findings show pretty clearly that the “Vibration Level” is reported after the fact, the timing and intervals of the reports are inconsistent, and the values do not correlate 100% to actual vibration levels. So I feel pretty sure that it cannot be properly used to generate motion - active events in SmartThings.

On the other hand, the vibration event message is sent from the sensor as soon as vibration or a shock is detected. So this can be used to generate a motion - active event in SmartThings. As long as the vibration continues, the sensor will send vibration event messages at roughly 60 second intervals. But the sensor does not send a message when it stops vibrating.

This is why I put the default 65 second timer to reset back to Stationary (which sends a motion - inactive event to the SmartThings hub.) If the sensor sends subsequent vibration detected messages, the 65 second timer starts over, and from the SmartThings hub’s point of view, the sensor remains in the motion - active state. 65 seconds after the last vibration detected message we can safely assume the vibration is over, and the state changes to motion - inactive.

So, @MABeatty1978, to answer your question about the washing machine use case, you’ll want to base it on the Motion ability of the sensor when setting up a SmartApp automation. I don’t know what SmartApp you’re using, so I can’t really comment on how that could be set up. Perhaps to only send a notification when the sensors motion state changes to inactive?

Note to anyone having trouble pairing a newly purchased Xiaomi device (from this post):

I am unsure whether the Xiaomi devices with new firmware this ST Staff is referring to new revisions of sever Aqara button/switch devices that I previously mentioned here.

I cannot specify the Sensitivity Level.
Any idea why?

[BETA UPDATE] Xiaomi Aqara Vibration Sensor (Model DJR11LM) SmartThings DTH v0.9b

This version finally adds a open/close capability to the DTH, using code graciously shared by GitHub user @_Oltman. His code calculates the angle position of the sensor based on its XYZ accelerometer reports, and allows the user to set and store open/close positions that are then linked to SmartThings contact sensor capability, with open and closed states.

The new DTH code can be grabbed from here.

Changes & Fixes

  • Added NEW FEATURE: Open/Close position, which links to the Contact Sensor capability. Using code kindly shared by GitHub user @_Oltman, custom open and close positions can be stored by pressing the Set Open and Set Closed UI tile buttons while the sensor is in your desired open & closed positions. Once set, the DTH will generate contact - open and contact - closed events when the sensor is in nearly the same positions.
  • Added two new UI tiles to display current Motion (vibration) and Acceleration (tilt) states
  • Changed “Vibration Level” UI tile to more representative name “Recent Activity Level”
  • Removed icon displayed in main sensor status tile
  • Added “refresh” tile that can be used to initialize blank UI tiles if needed
  • Changed the 3-Axis tile to display the calculated position angles instead of the raw accelerometer values
  • Reorganized UI tiles
  • Changed the method to initially set and display hardware Sensitivity level when the sensor is paired (If the sensor is already installed, either press the new “refresh” tile (bottom right) or open preferences and press “save” to set up the Sensitivity level UI button
  • Added code to initialize Recent Activity Level and Last Angle Change UI tiles to display “–” if no reported values have been received yet when the sensor is paired. If this doesn’t work, they can be manually initialized either by pressing the new “refresh” tile (bottom right) or opening preferences and pressing “save”
  • Improved the code that cycles through the 3 levels when Sensitivity level UI button is pushed
  • Fixed mapSensorEvent to correctly set a status reset timer of 2 seconds for Tilt or Drop events
  • Changed the timer reset code for Tilt/Drop events: If a Vibration/Shock event is followed by any Tilt or Drop events, the main UI tile will display “Tilt” or “Drop” for approximately 2 seconds, and then change back to display the “Vibration/Shock” status until the Vibration/Shock reset timer is finished (or until another different event occurs.)
  • Moved code to reset to Stationary status from updated() to configure() so that that status isn’t reset to Stationary when preference settings are saved, instead only resetting it when the sensor is first paired
  • Added info log messages to report open/close/unknown position
  • Added info log messages to report successfully set open/close positions
  • Various code cleanup/reorganization and formatting fixes

Screenshots of updated User Interface

(A vibration event results in motion - active state)

(A tilt event results in acceleration - active state)

(The open/close/unknown status is displayed in a separate small tile,
because other events can happen simultaneously.)

(Here are the rest of the UI tiles)


  • After updating to this new DTH code, I recommend opening preferences and pressing save. That should fix any issues that some users have been reporting about the Sensitivity Level UI button not working.
  • I still cannot confirm that the command to change the hardware sensitivity is working. On the SmartThings platform, no confirmation message is received from the sensor.
  • No contact - open or contact - closed events will be sent until both the open and closed positions are set. If the open and closed are set for the same position, then it that position will only report contact - closed.
  • Although not officially supported by the contact sensor capability, when the sensor is in any position outside the set open and closed positions, a contact - unknown event will be sent and the tile will display “unknown”.
  • The open/close position algorithm uses a margin of error value to allow for some variance from the stored open/closed positions set by the user. This is not user adjustable yet, but may be added to the preference settings in a future release.

Sorry for disappearing for a bit … Family issues … ANYWAYS. I just started playing with the NEW DH and leaps and bounds better than the last version. I can get it to light up lights by using it as an inactive/active Trigger
So Im going to try it as a way of turning on my Bedroom light via bumping the door:)see if that works :slight_smile: I will be testing it more soon… But so far AWESOME…

1 Like

May I ask what’s the use of the sensor be blind for 60 seconds?
If u use it for open lights for example. It means the light will not turn on after atleast 60 seconds.

I don’t understand why this feature. If anyon is so kind to explain me pls.
As well if I setup a motion reset of 10 seconds it doesn’t work. so the motion sensor loses it’s functionality for me.