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:
0x0505 (“Vibration Level”) values observed
(click arrow to reveal list)
|Time||Hex value||Integer||Notes on prior activity|
||209||after a good number of vibration & tilt events|
||71||after 3 vibration, 3 tilt, & 1 drop events|
||6||after no events (stationary)|
||43||after 1 vibration & 2 tilt events|
||27||after 1 vibration event|
||41||after 1 vibration & 2 tilt events|
||97||after 2 vibration, 3 tilt, & 3 drop events|
||65||after 2 vibration events|
||78||after 3 vibration, 1 tilt, & 2 drop events|
||3||after no events (stationary)|
||16||after 1 vibration event|
||9||after no events (stationary)|
||76||after 2 vibration, 7 tilt, & 1 drop events|
||54||after no events (stationary)|
||111||after 3 vibration & 6 tilt events|
||202||after 3 tilt events|
||210||after 4 vibration & 6 tilt events|
||255||after 3 vibration, 24 tilt, & 1 drop events|
||263||after 4 vibration & 24 tilt events|
||180||after 2 vibration & 10 tilt events|
||126||after 4 vibration events|
||12||after no events (stationary)|
||21||after 1 vibration & 1 tilt event|
||10||after no events (stationary)|
||12||after 1 tilt event|
||1||after no events (stationary)|
||11||after 1 tilt event|
||1||after 1 tilt event|
||10||after 1 tilt event|
||13||after no events (stationary)|
||86||after 2 vibration & 2 tilt events|
||73||after 1 tilt event|
||15||after no events (stationary)|
||85||after 3 vibration & 8 tilt events|
||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
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.
[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
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 - openand
contact - closedevents when the sensor is in nearly the same positions.
- Added two new UI tiles to display current
- 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
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.
contact - openor
contact - closedevents 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 sensorcapability, when the sensor is in any position outside the set open and closed positions, a
contact - unknownevent 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 I will be testing it more soon… But so far AWESOME…
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
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 !
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?