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

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.

The blind time is the time after a motion when the device will not “see” another motion. So a motion detected will turn the light on, but if you turn it off immediately, it’ll be ~60 seconds before another motion will turn it on again.

Its for that reason that your 10 second reset does not do what you’re expecting.

Thanks for ur reply!
Now I understand that behaviour but I don’t understand why that…what’s the use to have that blind time? I want my sensors to detect at all times, not every 60 seconds.

I guess to save batter life.

But, can you solder (or do you have a 4B pencil)…

Anyone else just have nearly all their xiaomi devices drop over the last two days?

I have somewhere between 30-40 xiaomi devices most of which have been connected and stable for over a year. Yesterday I noticed I lost about half of them, today nearly all the remaining ones have dropped.

Does this have anything to do with the firmware release they announced last week?

Last week I had a slew of these devices drop off too from buttons, motion and door sensors.

It gets tiring having to readd and then reconfigure rules when it happens :joy:

It could be something in the update but more likely is when the update happened and your hub restarted these Xiaomi devices connected through a different Zigbee repeating device that does not work with those devices. Search on Xiaomi and Iris 3210-L to better understand what’s going on with those devices.

I have had some drop too that have been solid for the past year or more. From aquara motion sensor, button, magic cube
I don’t have any going through a repeater and they all dropped at different times so maybe something to do the with the update

While this post is related to Hubitat the information related to Xiaomi devices applies on Smartthings.

Slightly lost here
have a new aqara Vibration sensor …I have loaded the device handler here and published it
Xiaomi Aqara Vibration Sensor

  • Model DJT11LM (thats what I have)
  • Version 0.9b

added a new device I think correctly …should I even be doing this or trying to pair with the instructions at top of this page without adding the device manually?

now in the smarthings app it shows up as stationary how exactly do I PAIR with the actual sensor? tried a long press on the device it flashes blue but then no motion appears to show in the smarthings page of “right now” only thing that shows up under "recently " tab is battery runtime oct 24 2018

any help much appreciated…new to all this !

Bill P

Hey @ArstenA, Brian
Mine are all solid on 000.024.00011 - is that what you have?

That said I did have one new Aqara temp/humidity that dropped because it had connected to a SmartThings Plug instead of to the hub or to one of three XBEEs. Once I got it on an XBEE it did fine.


I am on the same version.

The only other zigbee devices I have is a xbee router which I know works.

So they dropped from the hub.

I was never able to figure out how zigbee devices were being routed with Smartthings. How are you able to determine this?