Aqara Vibration Sensor (DJT11LM): Zigbee2MQTT + Home Assistant Setup

The Aqara Vibration Sensor (DJT11LM) is one of those devices I keep recommending but rarely see a good guide for. It does three things — detects vibration, tilt, and drop — and it does them locally over Zigbee with no hub required. Paired with Zigbee2MQTT, you get full local control, a proper Home Assistant entity, and a sensitivity you can actually tune.

That said, the configuration isn’t obvious. The sensitivity scale runs 1 to 21 in reverse (1 is the most sensitive, 21 the least), and — as we’ll see — the named low/medium/high values are wired to that scale in a way that catches almost everyone out. On top of that, the vibration state is throttled, and the current sensitivity value can’t be read back after you set it. None of that is documented clearly in one place. This guide covers the full workflow from pairing to automations.

What the DJT11LM detects

The sensor publishes three action types via the action entity in Home Assistant:

• vibration — rapid movement. Think washing machines, speakers, machinery running.
• tilt — a change in orientation from the resting position. Good for windows, cabinet doors, mailbox lids.
• drop — freefall detection. Useful for appliances on countertops or anything that might fall.

Each event fires as a distinct value on the action entity, so you can trigger separate automations for each. The sensor also publishes a binary vibration state (on/off) that stays active for a configurable window after the last vibration event — more on that below.

There is also a strength value, but it updates only every 300 seconds and represents the peak vibration intensity measured in the preceding 5-minute window. It is not real-time, so don’t try to use it as a live readout in automations.

What you need before pairing

You need Zigbee2MQTT running with a Zigbee coordinator (I use a Sonoff Zigbee 3.0 USB Dongle Plus), Mosquitto as the MQTT broker, and the MQTT integration in Home Assistant. No Aqara hub, no Aqara Home app, no cloud account. If you’re still deciding between Zigbee2MQTT and ZHA for Aqara devices, that trade-off is worth settling before you pair anything, because moving a sensor between the two later means re-pairing.

One note on Zigbee mesh topology: the DJT11LM is an end device, not a router. It doesn’t extend your mesh. If your coordinator is far from where you want to place the sensor, make sure there’s a router device (a Sonoff ZBMINI, an Aqara hub, a mains-powered device) between them. The DJT11LM has known compatibility issues with some older routers — Centralite and OSRAM devices in particular can cause intermittent disconnections. A reliable modern router nearby avoids most pairing headaches.

Pairing the DJT11LM to Zigbee2MQTT

1. In the Z2M dashboard, go to Devices and click Permit join (all), or enable pairing from the HA Z2M integration panel.
2. On the DJT11LM, find the small reset button on the side (use a paperclip). Press and hold for approximately 5 seconds until the LED blinks three times rapidly. The sensor is now in pairing mode.
3. Watch the Z2M log. The device should appear within 30 seconds. Z2M will interview the device — this takes another 20–30 seconds.

Where I ran into trouble: the interview stalled partway through on my first attempt. The DJT11LM is a sleepy end device, and if it goes back to sleep mid-interview, Z2M gives up and marks it as partially joined. The fix is to press the reset button every 2 seconds during the interview — not to re-pair, just to keep the device awake. Up to 20 presses is fine. Once the interview completes, Z2M shows the full entity list and you don’t need to do this again.

If the sensor refuses to pair entirely, replace the CR2032 battery first. Low battery is the single most common cause of persistent pairing failures on this device.

After a successful pairing, you’ll see these entities in HA:

• sensor.djt11lm_action — vibration, tilt, or drop
• binary_sensor.djt11lm_vibration — on/off based on the vibration_timeout window
• sensor.djt11lm_strength — 300-second peak intensity
• sensor.djt11lm_x_axis, y_axis, z_axis — raw accelerometer values
• sensor.djt11lm_linkquality — Zigbee link quality
• sensor.djt11lm_battery — percentage

Configuring sensitivity in Zigbee2MQTT

The default sensitivity works for some use cases, but if you’re mounting the sensor on a washing machine or a window that rattles in the wind, you’ll need to tune it.

Sensitivity is set by publishing to the zigbee2mqtt/FRIENDLY_NAME/set MQTT topic. You can do this from the Z2M dashboard under Device → Exposes, or from HA’s Developer Tools → MQTT → Publish.

Use the numeric scale, not the named values. The numeric scale runs 1 to 21, where 1 is the highest sensitivity (fires on the lightest touch) and 21 is the lowest (ignores all but strong vibration):

{"sensitivity": 10}

Z2M also accepts named strings — but this is where almost everyone gets tripped up. The named values are mapped straight onto the raw numeric scale:

• low → 1 → the most sensitive setting
• medium → 11 → midpoint
• high → 21 → the least sensitive setting

In other words, the names describe the threshold value on the device, not the resulting sensitivity, so they read backwards: sending {"sensitivity": "high"} makes the sensor less responsive, and {"sensitivity": "low"} makes it more responsive. This inversion has been a long-running source of confusion in the Z2M issue tracker. To avoid the trap entirely, set a number.

So, in numeric terms:

• For a washing machine spin cycle, a higher number (less sensitive, e.g. 15–18) often produces cleaner results — a sensitive setting fires constantly during agitation when you only want the larger spin-cycle motion.
• For a mailbox lid or a cabinet hinge where you want to catch a light touch, a lower number (more sensitive, e.g. 1–5) makes sense.
• Start around the middle (10–11) for a new deployment and adjust from there.

One important caveat: sensitivity is write-only. There is no way to query the current value back from the device. If you send a sensitivity payload and want to confirm it landed, the only approach is to watch the Z2M log for confirmation that the command was received. Keep a note of what you set.

Setting the vibration timeout

The vibration_timeout parameter controls how long binary_sensor.djt11lm_vibration stays in the on state after the last vibration event fires. The default is 90 seconds.

Adjust it the same way as sensitivity:

{"vibration_timeout": 60}

Value is in seconds. What this means in practice:

• Lower timeout (30–60s): useful when you want the binary sensor to clear quickly between events. If you’re using the binary sensor state in an automation (rather than the action event), a shorter timeout means less lag between “vibration stopped” and the automation triggering.
• Higher timeout (120–300s): useful for noise filtering. If the sensor is on a vibrating surface and fires repeatedly, a long timeout keeps the binary sensor in on state continuously rather than flickering on and off. Cleaner for dashboards.

One thing to be aware of: separate from the configurable vibration_timeout, the device firmware enforces a fixed lockout of roughly 60 seconds after a vibration detection, during which further movement does not generate a fresh detection. That lockout is hardwired and cannot be adjusted — it’s the reason vibration events don’t stream continuously while a machine runs.

Building automations in Home Assistant

The three action types each suit different use cases. Here are the patterns I use.

Trigger on vibration: washing machine cycle complete

The vibration event fires when the machine starts moving, not when it finishes. To detect cycle completion, you want to trigger when vibration stops — which means triggering on binary_sensor.djt11lm_vibration going from on to off.

trigger:
  - platform: state
    entity_id: binary_sensor.djt11lm_vibration
    from: "on"
    to: "off"
action:
  - service: notify.mobile_app
    data:
      message: "Washing machine done"

This is cleaner than triggering on the action = vibration event, because vibration events fire repeatedly during the cycle. You’d get a notification each time. Triggering on the binary sensor going off fires once when the cycle ends.

If you want an “is the machine running right now” check, use the binary sensor state directly in a template or condition.

Trigger on tilt: window alert

Tilt is a single event that fires when the sensor’s orientation changes from its resting position. Place the sensor flat on a window sill or attached to the window frame — tilt fires when the window opens.

trigger:
  - platform: state
    entity_id: sensor.djt11lm_action
    to: "tilt"
action:
  - service: notify.mobile_app
    data:
      message: "Window opened"

The tilt event isn’t throttled the same way as vibration, which makes it more responsive for security-style alerts. If you want a dedicated open/close sensor for windows and doors rather than a tilt workaround, a contact sensor like the Aqara P1 is the more natural fit — but the DJT11LM tilt trigger works well when you also want vibration on the same device.

Trigger on drop: appliance fall detection

Drop fires on freefall detection — attach the sensor to something lightweight that should never fall (a small appliance, a decorative item you want to protect). This one is niche but works reliably.

trigger:
  - platform: state
    entity_id: sensor.djt11lm_action
    to: "drop"
action:
  - service: notify.mobile_app
    data:
      message: "DJT11LM: drop detected"

The vibration lockout and how to design around it

As covered above, the vibration action fires shortly after vibration onset, then the ~60-second firmware lockout suppresses further detections until it clears. This behavior is intentional and cannot be disabled.

What this means for automation design: do not rely on counting action = vibration events to infer duration or intensity. Use the binary_sensor.djt11lm_vibration state for “is it currently vibrating” logic, and use the action event only to detect the start of vibration if you need that trigger.

Accelerometer and strength values

The raw accelerometer axes (x, y, z) are available as sensors in HA, but they come uncalibrated from Z2M. The values are useful for understanding orientation relative to a baseline, but not for precise measurements without applying calibration offsets in a template sensor. (Some firmware/Z2M combinations don’t report the angle and accelerometer values at all — if your axes stay empty, that’s a known issue rather than a misconfiguration on your end.)

The strength value is the one most people expect to be real-time, and it is not. It reports the maximum vibration intensity detected in the preceding 300-second window. By the time it updates, the washing machine has probably been running for 5 minutes. Don’t use it for anything time-sensitive.

Honestly, for most practical use cases — laundry alerts, window sensors, appliance monitoring — you don’t need either of these. The action event and binary sensor cover the real workflow. The accelerometer data is there if you want to build something more experimental, like detecting which axis a device tilted on.

Troubleshooting

Sensitivity setting has no effect.
The command may not have reached the device. The DJT11LM is a sleepy end device and only wakes periodically to receive configuration writes. After publishing the sensitivity payload, press the reset button once to wake the device, then check the Z2M log for a configuration confirmation. If Z2M doesn’t show it acknowledged, try again. This is the most common issue in the HA forum threads about this sensor.

Device disconnects after a few hours or days.
Check linkquality — very low values cause intermittent dropouts. Move the device closer to a Zigbee router, or add a router device between the sensor and your coordinator. Avoid routing through Centralite or OSRAM devices if you have them; they have known compatibility problems with this model.

Pairing fails or interview never completes.
Replace the battery first. A partially drained CR2032 provides enough power for the LED to blink but not enough to sustain a Zigbee interview. If the battery is new, use the keep-awake technique: press the reset button every 2 seconds during the Z2M interview process, up to 20 presses.

Vibration fires constantly when the sensor is on a hard surface.
The sensitivity is set too high (too responsive) for that surface. Remember the scale is inverted: set a higher number to reduce sensitivity — try a numeric value in the 15–21 range. If you prefer the named values, high corresponds to the least-sensitive end (value 21), which is what you want here — but the numeric value is less error-prone.

The Zigbee2MQTT device page for the DJT11LM is the authoritative reference for payload specs and known issues — worth checking if you hit something not covered here, since the community updates it regularly.