No error message. No idea if the issue is in deCONZ or the devices, but as this was working for years and I suspect recent update (deCONZ 2.25.3), I put my bets on deCONZ.
1 Like
also I was wondering, is it normal that these Aqara vibration sensors are seen as “locks”? I see locks related tabs in deconz, see image attached
This is an information from the device firmware, you can found tuya covering described as smart plug.
1 Like
Still no progress on this. This really sucks. Plenty of false alarms driving me nuts from time to time. How to persistently set the damn sensitivity of those devices with deCONZ ?!?
1 Like
I have the same problem with the vibration sensor, are there any workarounds available?
Thx
Paul
it’s one of the last outstanding issues for 2.27.0-beta release, based on the info that is in github: v2.27.0-beta Milestone · GitHub
but I am not sure this really means it’s going to be looked at.
well now there’s a newer milestone, 2.27.3-beta, when 2.27.0-beta is still open with outstanding issues 
so I guess the use of milestones here is like the jungle and shouldn’t be trusted too much.
There’s more pressing issues atm. There’s a issue with ddf loading causing it not to work.
I’ll let manup know the above so it doesn’t get forgotten.
3 Likes
Well, certainly, if your smart homes drives you crazy due to regular false alarms multiple times a day, you might have a different view on “pressing issues”.
Looking forward to see a fix, which will arrive in Home Assistant deCONZ addon until Christmas (2024, if lucky).
Mine works like a charm 
Lucky you. Wanna swap smart homes?
Not funny at all, really. You deCONZ guys break stuff with shipped updates - and afterwards don’t do anything to fix the broken stuff. Everything was running fine before. Freaking annoying!
Its open source, feel free to contribute.
I do want to remind you to stay civil and constructive. Negativity doesn’t add anything to the conversation at hand
Other than pinging @de_employees there’s nothing I can do.
Yes, my PR would look like this: undo everything after v2.22.2 which was shipped with v2.25.3 and is related to this device.
If you’d know what issues that single issue creates in everyday real-life, you’d consider my behaviour as very civil and constructive.
So let’s sit and wait. I put my bets on Christmas. Prove us wrong. Please. Thanks.
Interesting case, when I read the code right. A 0 is written to the device when the sensitivity is set to 3. In which case 3 - 3 = 0 will be written. When the value is read back for validation it is set to 3 - deviceValue (0) which again verifies the 3.
So if I understand right the problem here might be that the value is exactly inverted from what one expects 3,2,1,0 instead of 0,1,2,3.
Given by the logic from current DDF:
| Sensitivity (API) | Device value |
|---|---|
| 3 | 0 |
| 2 | 1 |
| 1 | 2 |
| 0 | 3 |
Hi Manu!
I cannot read nor write the sensitivity value in deconz with the attribute editor
It says „reading fails“ or „writing fauls“
The sensor in general works fine, just the high sensitivity is really anoying.
Thx for your support!!
You are using deconz ?
If you try to awake the device in same time, same result ?
The value needs to be written via REST-API (which also takes care to transmit as soon as the device is awake) otherwise it can be reverrted later on.
I tried to awake the device by moving de sensor and or pressing its button and trying to write the new sensitivity value via deconz short after, but that didn’t do the job…
I even took out the battery and tried it after putting it in again…
I’m not really familiar with using the REST-API MANUally ( ) is there another way or maybe will there be a bugfix?
thx for your help
I m trying to do both action in same time, but your procedure is fine for me, you are trying to set “0” instead of “1” ?
Yes I try to set sensitivity to low.
Right now the sensor reacts way to often what really is annoying.