search

dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.9k stars 498 forks source link

Sensitivity settings reset (not persistent) for lumi.vibration.aq1 after few hours #7662

Closed bcutter closed 6 months ago

bcutter commented 6 months ago

Does the issue really belong here?

Is there already an existing issue for this?

Describe the bug

After setting sensitivity and checking it has been set (using the API), after only few hours the sensitivity is reset. Not sure if it is related to https://github.com/dresden-elektronik/deconz-rest-plugin/pull/7208.

This issue was likely introduced somewhere after deCONZ v2.22.2 (updated to v2.25.3 on 2024-02-10).

Steps to reproduce the behavior

  1. Set 'sensitivity' (using the API or the deCONZ service in Home Assistant) to e. g. 0 after it was 2 or -8 before
  2. Check it is actually stored using the API
  3. Wait few hours (2 to 3)
  4. Check sensitivity again and discover it has been reset to the previous value (like 2 or -8)

Expected behavior

Set sensitivity is persistent.

Screenshots

No response

Environment

deCONZ Logs

No response

Additional context

See https://forum.phoscon.de/t/aqara-vibration-sensor-resets-sensitivity/3971

SwoopX commented 6 months ago

The switch over to negative values was addressed with #7618 and the move to the previously set value originates from the device not being awake to actually pick up the write request.

Based on that, closing this issue.

bcutter commented 6 months ago

the move to the previously set value originates from the device not being awake to actually pick up the write request.

...and that... needs to be accepted? Why not continue writing it once they are awake again?

Sounds a bit like a core issue to me if we can not guarantee commands are executed by devices. Bad comparison, but I thought we speak TCP, not UDP - if you get the point. Do other ZigBee integrations suffer from the same? Why did we start seeing this with one of the latest deCONZ updates while it seems to have worked in the past?

Don't get me wrong, unless I understand everything correctly, the closure of this issue might result in continual behavior of the issue and fix actually nothing.

Smanar commented 6 months ago

If we use the API to change the sensitivty I need to work nope ?

ebaauw commented 6 months ago

...and that... needs to be accepted? Why not continue writing it once they are awake again?

This is why the Hue API uses config/pending: to indicate which config changes to sensors resources are accepted by the API, but not yet written to the (sleepy) device. Not sure why we abandoned that in deCONZ, but I might very well have been the only one actually implementing this.

while it seems to have worked in the past?

I think the deCONZ logic might have changed with the introduction of DDFs.

Note that for this to work:

  1. The sleepy device needs to wake up and poll its parent router;
  2. deCONZ must recognise that the device has woken up, and send the Zigbee message.

1) is challenging for deep sleepers, especially Xioami devices which only wake up spontaneously once an hour. I’m not sure how long deCONZ keeps the pending Zigbee message queued. 2) should be easy when the coordinator device is the sleepy device’s parent. Otherwise deCONZ won’t see the poll, and needs to infer this from some other message (e.g. the Xiaomi special attribute report). This requires the correct configuration in the DDF (that the device is polling after sending the message).

I thought we speak TCP, not UDP - if you get the point.

Zigbee isn’t based on IP, so it speaks neither TCP nor UDP. If you mean guaranteed delivery: even TCP can time out. Unicast Zigbee messages (API calls to sensors and lights resources) should be acknowledged and resent in case no ack is received… until deCONZ concludes the device isn’t reachable and gives up. The fundamental problem here is that the API call returns once the Zigbee message has been queued, so the API cannot report the timeout. Broadcast messages (to groups resources) aren’t acknowledged, but these are repeated by every router in the Zigbee network, so these tend to be very reliable.

bcutter commented 6 months ago

Giving that input I think more than before there's a need to take care of this.

Meanwhile I'm looking for workarounds like hammering the API with the set sensitivity commands for an extensive period of time. Unfortunately I think this is necessary after every deCONZ restart, so it's quite ugly at all.

Yes, I was talking about guaranteed delivery. What we see now is the opposite. I bought a ticket and stay at the bus station. Unfortunately, no bus is coming all the day.

As mentioned, this issue creates serious real life issues. Therefore I'm urgently looking for a solution. There are good ideas already - it's just you developers need to discuss those.

Maybe it's a good start to reopen this issue now that we agreed there's a need to fix it.

SwoopX commented 6 months ago

Sorry, there is no issue which needs to be fixed and I struggle to spot any agreement on fixing anything. Within zigbee, there is no guaranteed delivery, as Erik already pointed out. Now we're discussing about Xiaomi here, which does not really care about the zigbee standard (ok, strictly speaking, they tried to improve and got better in the past few years, but still).

Yes, previously, there was config/pending used to try writing values to Xiaomi sleepy end devices. That had a very good chance to hit the wall regardless. Now, there is the new concept of state changes replacing it and that is even more robust within the boundaries Xiaomi has given us. But also with that, the messages can get lost.

Would you know how Xiaomi handles configuration of sleepy end devices within their own ecosystem? Set the desired value in the app and push the physical button on the device within 60 seconds. That is the intended way by the vendor how to do it. In that sense, we can always recommend to follow the vendor intended way to ensure the highest success rate. There is no need to hammer the API with any requests.

Unfortunately, we're no wizzards who can heal broken functionalities, inconveniences or missed opportunities for devices out there.

bcutter commented 6 months ago

Thanks for the detailed explanations and technical background.

While I initially only had one question in my mind at first ("Why isn't this an issue for ZHA or ZigBee2MQTT but seems to be just "one more thing" only deCONZ users suffer from?")

...and two facts

...I'm now going to try the vendor described way which I personally wasn't aware of and should be "okay" as a workaround because setting those values only happens very rarely.

Hopefully this works and is persistent, also surviving deCONZ updates/restarts. Otherwise I'd return here and continue to be annoyed from a pure user perspective motivating devs to revert/rethink changes which introduced this issue.

badewanne1234 commented 5 months ago

Set the desired value in the app and push the physical button on the device within 60 seconds. That is the intended way by the vendor how to do it.

@SwoopX which app are you referring to? Is this the vendor app or the deconz app? I'm only using deconz AND this aqara vibration sensor. Is there a way to persistently change the sensitivity at this point when only using DeConz and this Aqara sensor? I dont have a Xiaomi Hub... Thank you

bcutter commented 4 months ago

@SwoopX asking me the same question. I had tough times with false vibration alarms (driving me nuts, very likely due to the wrong, way to sensitive sensitivity value) and I only use Phoscon/deCONZ to control those sensors. There's no Aqara hub/gateway and therefore no Aqara app.

So please assist on how to achieve this from the deCONZ side!

bcutter commented 3 weeks ago

Unfortunately we never received an answer from SwoopX. Or did you find out meanwhile @badewanne1234 ?

badewanne1234 commented 3 weeks ago

Nope, in my environment, the distance was just too long. I figured out though that my Zigbee repeater could not send any configurations, which in turn could be an issue if the Xiaomi device is not connected directly to the deconz gateway. Did you try to bring the Xiaomi so close to the deConz gateway that a direct connection is established and not through any other repeating-device such as a lightbulb..?

ebaauw commented 3 weeks ago

As mentioned before: to change the sensitivity: update sensitivity through the API (or an API client like Phoscon), then press the small button on the sensor to wake it up. state/lastupdated should be updated when pressing the button, indicating that the gateway received a message from the sensor.

In case the sensor is orphaned, you might need to reset and re-pair it. Like most older Xiaomi sensors, it won't find a new parent router automatically. Make sure to pair it close to where it will be used, and switch off any routers that aren't powered at all time (notably smart lights behind a 20th century wall switch).