Fix sensitivity for lumi_vibration_aq1

[ebaauw]

See Discord, upon sniffing the Aqara app / Hub M2, it appears that the Xiaomi vibration sensor uses Zigbee values 1: High, 2: Medium, 3: Low.

The device seems to accept and report back any value, even higher then 21. This was carried over from the C++ code when the sensor was supported initially, but, apparently, never verified.

See also:

• Aqara Vibration Sensor Set Sensitivity #1396 (comment)
• config.sensitivity values not normalised #1935 (comment)
• Xiaomi special attribute in DDF #6919

[SwoopX]

I'd advise some changes here:

1. Change refresh.interval from 600 to 3600 - We only want a forced read if the special reporting didn't come in. Most likely, the following special report will provide the values anyway before the actual read kicks in. A smaller value does not make much sense either way as the device is a deep sleeper
2. Add "state.timeout": 2 to the write function - This is barely documented, I know, but it speeds up the state change when the device is awake and chances are high that the whole state change can finish within the few seconds the device is awake.
3. Add "change.timeout": 3600 to the write function - This grants the state change a life time of 1h rather than the default 2 or 3 mins. So, whenever you change sensitivity and do not explicitly wake the device, the change will be applied when it wakes up later.

Other than that, the values changes look fine to me 👍

[ebaauw]

Change refresh.interval from 600 to 3600

Done. I suppose we would need to check this for other Xiaomi DDFs for this as well, as they all do periodic reporting only on the special attribute.

Add "state.timeout": 2 to the write function

Done. Not sure I understand what this does exactly. What operation is timing out here, and how does the code react to this? In what circumstances, for devices with what characteristics, should be we adding this?

Add "change.timeout": 3600 to the write function

Done. This makes very much sense, and, I suppose should be added to all deep sleepers with changeable config items. Notably the Hue sensors and controllers, with periodic reporting per 5 minutes.

[manup]

Note to myself: It's time to better document how the StateChange works and is related to "read" and "write" functions in DD, and also add a state diagram to better visualize what's going on (internally it is a small state machine). The logic behind it is not too complex and stabilized since a while.

Special care needs to be taken for the awake keyword on items in the DDF. For sleeping devices it acts as a trigger to process open tasks.

For example a Xiaomi device that sleeps for one hour and sends the special report, should have the awake = true set for the respective "special" item. When the special report is received the const char *REventAwake = "event/awake"; is triggered and handled in device.cpp to proceed with polling and StateChanges.

But here comes the hard part: To know that a device is truly awake when a certain ZCL command is received can only be seen in the sniffer! Awake is only true if a device sends a ZCL command and does a MAC Data Request (aka parent poll) afterwards to check if there is any response/ message to receive.

This is not always the case, some Xiaomi devices report sensor values without doing a MAC Data Request, which means sending anything to the device will timeout because it's sleeping.

That's the reason why not every item should have awake = true, because we would send into the void.

---

The StateChange is designed to survive any error that may happen, like sending to a device that is sleeping, routing errors, or the device simply being powered off. It will retry as long as the change.timeout > 0, this is triggered by REventAwake and REventPoll. Having proper awake knowledge helps to prevent useless requests to a device which will timeout anyway as the device is sleeping (which the legacy code does a lot).

[ebaauw]

awake is (and already had been) specified on items based on the Xiaomi special attribute, and not on other items. I can confirm that the special attribute report is followed by a data request to the parent, also when triggered by pushing the button on the device. The XIaomi app actually prompts you to do so, when changing the sensitivity, unless you're happy to wait for some time.

Note: instead of sniffing, you could also get this info from the deCONZ log, if the coordinator device is the parent of the sensor (which is probably achieved easiest when its the only router in the network).

[raducotescu]

@ebaauw, without this issue being fixed, is there a way to correctly configure the sensitivity? The Internet is full of the 1-21 value range, where 1 is considered the most sensitive, most likely based on https://dresden-elektronik.github.io/deconz-rest-doc/devices/xiaomi/aq_vibration_sensor/#config-attributes.

I'm asking because I recently had to replace one of the sensors I have at home and the new one seems to randomly trigger. Since in my case this is connected to a security system, I'd really like to avoid false positives, otherwise my neighbours will hate me.

Thank you! (and sorry for not actually contributing to the issue)

[ebaauw]

You can write any raw value to the corresponding Zigbee attribute (0xFF0D in the Basic cluster) from the deCONZ GUI, bypassing the API altogether. Press the button to wake the device to have deCONZ send the Write Attributes command. Press the button again, and read back the attribute, to make sure the value sticks.

As I've mentioned on Discord:

• The Xiaomi app only uses values 1 (high), 2 (medium), and 3 (low) [verified in the Zigbee sniffer; sensor connected to an Aqara M2 hub);
• The device seems to accept and report back values larger than 21 just as happily [verified in the deCONZ GUI]. The documenation you refer to is likely based on the above mentioned comment, but I have not been able to trace back on what that comment was based.
• I don't have the equipment to test in a controlled way whether the device actually changes its sensitivity for settings higher than 3.

I would love to hear your experience, at what setting the false positives stop if they still appear at 3.

[bcutter]

Could someone please summarize if this fix creates the need of users to actually change something?
E. g. if one uses sensitivity values of 1 or 2 according to https://dresden-elektronik.github.io/deconz-rest-doc/devices/xiaomi/aq1_vibration_sensor/#config-attributes - will everything work as before?

[cracyfloyd]

Iam a little bit confused. Which values can i now use for sensitivity ??. I need less sensitivity. Before this change i use 11.

[bcutter]

Iam a little bit confused. Which values can i now use for sensitivity ??. I need less sensitivity. Before this change i use 11.

Never got answered here unfortunately. But according to the (updated?) docs here it seems the answer to your question is: 0 (zero).

https://dresden-elektronik.github.io/deconz-rest-doc/devices/xiaomi/lumi_vibration_aq1/#config-attributes