config.sensitivity values not normalised

[ebaauw]

The REST API plugin doesn't normalise the values of config.sensitivity. For the Hue motion sensors, the highest value of config.sensitivity (exposed as config.sensitivitymax) indicates the most sensitive setting, whereas for the Xiaomi vibration sensor (lumi.vibration), the highest value is the least sensitive setting. For the Hue motion sensors, the lowest value is 0; for the Xioami vibration sensor it's 1. I think that for all devices, value 0 should be the least sensitive setting, and value from config.sensitivitymax should be the most sensitive setting.

Background

config.sensitivity and config.sensitivitymax were copied from the Hue API, which uses these for the Hue motion sensor. The values of config.sensitivity range from 0 to 2, the value of config.sensitivitymax, with 0 being the least sensitive and 2 being the most sensitive. The recently introduced Hue outdoor motion sensor reports 5 for config.sensitivitymax. The Hue motion sensors use manufacturer specific attributes for config.sensitivity and config.sensitivitymax, whose raw values map 1:1 to the API values.

The Xioami vibration sensor uses a different manufacturer specific attribute for setting sensitivity. According to a comment in the code, this attribute uses raw values 0x15 for low sensitivity, 0x0b for medium sensitivity, and 0x01 for high sensitivity. Currently, the REST API exposes config.sensitivity as the raw value of this attribute, see #1396; I don't know if the vibration sensor actually supports the full range of values between 1 and 21.

I think the REST API should expose raw value 0x01 as config.sensitivity value 2, 0x0b as 1 and 0x15 as 0, and expose config.sensitivitymax as 2. If the intermediate values are useable, we could expose config.sensitivitymax as 20 (!) and map raw values 0x01, ..., 0x15 to API values 20, ..., 0.

[JHenzi]

Does this issue still stand, there is no real way to get the sensor to return vibration: true based on sensitivity? Like others I want to detect the running of the washer and dryer, issue I have is that the value is always false, otherwise I get a vibrationstrength value as a number. Seems that once the dryer or washer stops it stops reporting and that's about it.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ebaauw]

Bump

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ebaauw]

Bump

[dubocr]

👍 confirmed that for Xioami vibration sensor sensitivity is full range usable from 0 (0x00) to 21 (0x15) with 0=> most sensitive and 21 => less sensitive. (then in Eve app, High/Low sensitivity are reversed).

Think sensitivity could be sensor dependant as there is a maxsensitivity, so clients like homebridge-hue can compute/map intermediate states based on maxsensitivity. But in the case of Xioami vibration sensor the state is clearly reversed and this might be managed by deconz low level API

[badewanne1234]

Is there actually a way I can adjust the sensitivity of this sensor? I'm glad I found this issue, I discovered something is wrong too. At this point, as soon as I put

{
  "sensitivity": 2
}

it is reverted to the below as soon as I reboot deconz

{
  "config": {
    "sensitivity": -8,
    "sensitivitymax": 2,
}

Actually, I want to increase the sensitivity, so if I read the above correctly, I would need to put 0 instead of 2 for the sensitivity maximum? IF it would actually work to adjust the sensitivity at this point, given that the wrong values are put and then read... Thanks so much!

[ebaauw]

Normalised sensitivity is from 0 (least sensitive) to the value of config/sensitivitymax (most sensitive).

Note that sensitivity needs to be set on the device, which might be challenging for deep sleepers, like the Xiaomi vibration sensor, that only wakes up once an hour. Best press the on-device button to wake up the sensor, when changing sensitivity through the REST API. Personally, I would verify that the device has accepted the new value by reading it back through the GUI.

Not sure if restarting deCONZ causes the API value to be reverted (in which case the new value wasn't persisted in the database), or if the change didn't make it to the device, and the API value is reverted when the device next wakes up and reports its setting.

[ebaauw]

This topic should have been closed by #7208.

[badewanne1234]

I would verify that the device has accepted the new value by reading it back through the GUI.

Which GUI are you referring to? I checked in the deCONZ GUI but I cannot see the sensitivity level there, also not in HomeAssistant either. The only way I can see the sensitivity level is actually the REST Client.

What I did is, immediately after PUT the sensitivity: 2, I requested the sensor data with a GET in the REST Client and I got sensitvity: 2 Then rebooting deConz, the value goes back to -8 Even if the value is normalised in displaying, why is it then showing -8 and not 0 instead?

[Smanar]

Then rebooting deConz, the value goes back to -8 https://github.com/dresden-elektronik/deconz-rest-plugin/pull/7618

With the GUI, it's the cluster 0x0000, attribute 0xFF0D

[badewanne1234]

Then rebooting deConz, the value goes back to -8

7618

With the GUI, it's the cluster 0x0000, attribute 0xFF0D

Thanks, found it. Its value is 11 - looks like not updated. I will wake up the sensor, then program again.

[badewanne1234]

tried to read the attributes, but it keeps saying "reading" and after about 30 seconds, it runs into a timeout. I tried it multiple times, waking up the device just before click reading. I can see the device blinking, but still, attributes are not readable - let alone writable. Any ideas?

[Smanar]

. I tried it multiple times, waking up the device just before click reading

I don't see better method. And if your device don't support this attribute, it will be grayed by deconz on the GUI.