DJT11LM adjustable vibration timeout vs fixed 60 sec lockout

JonSilver commented 2 years ago

What happened?

I've been trying to make sense of the Xiaomi Aqara DJT11LM vibration sensor, so I ran some structured experiments. Somewhere behind the scenes, there appears to be a fixed 60 second lockout (completely separate to the configurable timeout) after a vibration detection event, during which time any amount of movement or vibration caused no extension to the period of vibration = true detection even though other properties (angle etc) are updated and sent.

What did you expect to happen?

I expected that setting the timeout to a short period (e.g. 10 secs) would result in further detections upon timeout expiry. However all vibration events were ignored during the first 60 secs after vibration became true.

Setting the timeout to a longer period (e.g. 90 secs) resulted in further vibration events received during the first 60 secs being ignored, whereas any events after the first 60 secs (i.e. in the last 30 secs of the timeout period) extended the period of vibration = true.

If the 60 sec lockout is a driver issue, please could I request that someone takes a look at the code, identifies what's causing the lockout and makes the lockout configurable?

If it's a sensor issue, please could I request that this "feature" be added to the documentation?

Many thanks, Jon

How to reproduce it (minimal and precise)

Establish test framework:

DJT11LM sensor, sensitivity set to High
client for observing sensor state
timer

Tests:

set vibration timeout to 90 secs
jog or tilt the sensor; simultaneously start the timer; observe vibration = true
during the first 60 secs, jog or tilt the sensor again; observe other properties (angle etc) changing
at the end of the 90 secs, observe vibration = false
jog or tilt the sensor; simultaneously start the timer; observe vibration = true
during the last 30 secs of the 90 sec period, jog or tilt the sensor again; observe other properties (angle etc) changing
at the end of the 90 secs, observe that vibration = true
vibration = false occurs at some time well after 90 secs has elapsed (time of last extension event + 90 secs)

Conclusion:

there is a 60 sec fixed period of lockout after vibration is detected, during which further jog/tilt events are ignored; once this period has passed, within the variable (90 sec in this case) timeout, further jog/tilt events will extend the period of detection. However, jog/tilt events are clearly detected by the sensor and reported even during the lockout period.

Zigbee2MQTT version

1.24.0

Adapter firmware version

20200417

Adapter

Texas Instruments LAUNCHXL-CC26X2R1

Debug log

No response

lux73 commented 2 years ago

https://www.zigbee2mqtt.io/devices/DJT11LM.html#options

its adjustable

JonSilver commented 2 years ago

its adjustable

No, it's not.

The timeout is adjustable/variable.

The lockout is not. It is fixed at 60 secs. It is undocumented. It is at odds with the timeout. It makes the sensor timeout behave strangely.

I have documented all this in reproducible detail above, obtained using experimental observation.

JonSilver commented 2 years ago

OK, @lux73, if it helps, I did some poking around in the code and couldn't find anything that would implement a fixed 60-second lockout. The code that implements the variable timeout takes msg.data['85'] as its source event, which suggests that the lockout is probably implemented in the device's firmware rather than its converter.

Since the fixed 60 second lockout after a vibration event acts at odds with the timeout, and can make a >60sec timeout behave very oddly indeed, this should at least be documented on the device's info page.

However during observations, other events generated during the 60 second lockout did change the sensor's state, causing tilt, vibration and drop action events as well as changes to the angle properties. Therefore these could be employed in the timeout code to better implement the timeout and work around the 60 second lockout after a msg.data['85'] event.