Lumi.vibration.aq1 sensor with phantom triggers since deCONZ 2.29.5

deCONZ General Support
1

Since updating deCONZ to latest v2.29.5 yesterday, another vibration sensor, working completely fine so far, now wents nuts, meaning: it is triggered very often for no obvious reason (no actual vibration!). 19 triggers in last 40 hours, where 16 to 17 were false alarms (phantom/ghost triggers) and few right in the middle of the night…

First one shortly after updating deCONZ:

grafik
grafik844×320 11.9 KB

Last one of those 19 (up to now):

grafik
grafik838×313 12.8 KB

Before/after comparison:

grafik
grafik3708×311 56.1 KB

API excerpt for that sensor

catched right now during last phantom trigger: 
    "61": {
        "capabilities": {
            "sleeper": true
        },
        "config": {
            "battery": 100,
            "duration": 65,
            "on": true,
            "reachable": true,
            "sensitivity": 0,
            "sensitivitymax": 2
        },
        "ddf_hash": "23d408187fbf7f04607f523bd8c3f1208dac0b418c11b45f915b3e304eb8675a",
        "ddf_policy": "latest_prefer_stable",
        "ep": 1,
        "etag": "xxx",
        "lastannounced": null,
        "lastseen": "2025-04-24T21:30Z",
        "manufacturername": "LUMI",
        "modelid": "lumi.vibration.aq1",
        "name": "Vibration Briefkasten",
        "nwkaddress": 19388,
        "state": {
            "lastupdated": "2025-04-24T21:30:30.603",
            "orientation": [
                -5,
                1,
                -85
            ],
            "tiltangle": 112,
            "vibration": true,
            "vibrationstrength": 6
        },
        "swversion": "0.0.0_0008",
        "type": "ZHAVibration",
        "uniqueid": "xxx"
    },
catched during 'normal' operation before last phantom trigger: 
    "61": {
        "capabilities": {
            "sleeper": true
        },
        "config": {
            "battery": 100,
            "duration": 65,
            "on": true,
            "reachable": true,
            "sensitivity": 0,
            "sensitivitymax": 2
        },
        "ddf_hash": "23d408187fbf7f04607f523bd8c3f1208dac0b418c11b45f915b3e304eb8675a",
        "ddf_policy": "latest_prefer_stable",
        "ep": 1,
        "etag": "xxx",
        "lastannounced": null,
        "lastseen": "2025-04-24T20:59Z",
        "manufacturername": "LUMI",
        "modelid": "lumi.vibration.aq1",
        "name": "Vibration Briefkasten",
        "nwkaddress": 19388,
        "state": {
            "lastupdated": "2025-04-24T20:59:22.120",
            "orientation": [
                -5,
                1,
                -85
            ],
            "tiltangle": 112,
            "vibration": false,
            "vibrationstrength": 9
        },
        "swversion": "0.0.0_0008",
        "type": "ZHAVibration",
        "uniqueid": "xxx"
    },

grafik
grafik1363×682 48.7 KB

1. Any idea why this single sensor introduced this behaviour right once deCONZ got updated?

2. Are the vibration settings wrong or do other information reported via API look suspicious?

2

Can you please test if a restart of the container/deCONZ helps to get rid of the ghost events, might be same issue as in:

https://forum.phoscon.de/t/ghost-button-events-with-deconz-2-29-5-and-aqara-smart-button/6300/13

3

Indeed that sounds very similar. I’m not sure on the DDF part but the symptoms and negative results are the very same.

I restart the addon now and will monitor things for a few hours, will report back.

4

@manup Unfortunately the restart did not solve or improve things: had a few ghost trigger events again in the last hours :frowning:

IMG_0221
IMG_02211061×356 58.5 KB

How to make any progress here? Can I do / test / provide something?

Should I put some bets at/hope in Ghost button events with deconz 2.29.5 and Aqara smart button? - #15 by manup ?

Don’t want to mix topics so I try to stay here :slight_smile:

5

Yeah I assume these two have the same underlying problem. I’ll continue tomorrow and Monday to debug. There aren’t too many code paths which need to be traced so hopefully this will be fixed in the next days. Have to go now to catch the bus :smile:

6

OK, thanks for the update. Until then I’ll definitely need to disable all automations getting falsely triggered by those ghost/phantom trigger events.

Let me/us know in case you need something. Willing to help, of course! :slight_smile:

7

Latest status?

8

There is a PR for this issue Fix ghost events for sensors by manup · Pull Request #8189 · dresden-elektronik/deconz-rest-plugin · GitHub
But some more about the websocket notification, will be lot of changes on this part on next version.

1 Like
9

Expected to arrive in the next stable release in how many days?

10

I had 38 false positive trigger events for only ONE sensor only today. Absolute nightmare folks !!! :angry:

IMG_0412
IMG_04121206×2389 268 KB

Why does it take so long to receive fixes?

11

Because your on ha addon?

13

No. Because of the regular process:

  1. fix creation
  2. fix merge to beta
  3. wait several beta releases
  4. stable release made of beta releases
  5. on top: wait for HA addon to receive new stable

Now we are at stage 2, not being able to at least check if the fix actually fixes the issue. And the HA addon never got the „feature“ to switch to beta releases (temporarily). So summary:

  1. It takes several months as HA user to receive a new stable deCONZ version.
  2. There is no option to run/test beta releases with the HA deCONZ addon.
  3. A (stable!) deCONZ upgrade introduced the issues. Which now take several months to get fixed. Maybe. User conclusion: don‘t update to new stable releases of deCONZ because you can get screwed. Let other users run into issues (that‘s not the community mindset I like) and wait few weeks, check user reports and monitor next beta releases for fixes related to hardware in place.

Now 25 % of my smart home use-cases are not working. Thanks. I hope you see how frustrating this situation is for users. There‘s no speed, even we are already past stage 1.

Proposal: finally implement a beta release channel option for the HA deCONZ addon. That would be at least a workaround and cool down things, giving low-effort options in case they are needed.

Personal note: next time don’t even try to investigate or report or fix things, but immediately restore addon backup and that way try downgrading deCONZ to maintain the ZigBee smart home fully operational. Long-term: migrate away from deCONZ in case nothing improves after watching and suffering for more than 4 years.

14

The new stable version v2.30.2 is now online https://github.com/dresden-elektronik/deconz-rest-plugin/releases

As described in the v2.30.1-beta changelog it took one more release since bugs were reported which needed to be addressed as some REST-API clients had issues with previous API output.

2 Likes
15

That‘s great news :tada:

:arrow_right: How to bring the new v2.30.2 stable release to the HA deCONZ addon?

The last troubleful updates where it in some cases took months for the update to arrive was e.g.

EDIT: ah here‘s the PR. Grabbed my popcorn and stop watch, finger‘s crossed :crossed_fingers:t3:

16

Not a bad idea, for users with locked OS making custom intallation more complex, it’s not in place because of HA devs decision ?

17

Hi,

I was also affected by the issues associated with the v2.29.5.
Thanks for your work and the following fix which I followed with interest.

To make a future better and avoid such issues (like this one or the API contract format), do you think it would be possible to add some unit test ?
I’m not familiar with the Deconz environment and I dont know if it is possible or if it was already discussed in the past but it could be verry valuable for this project.

1 Like
18

Obviously a good idea, and not the first time it came up, in fact:

…

1 Like
19

And here it is, only 1 day later arrived for HA addon users:

IMG_0421
IMG_04211206×1229 102 KB

Phenomenal :tada::+1:

Going to update and test vibration sensor behavior soon.

20

Hi,

I have updated on 2.30.2 (via the 8.2.0 HA addon) yesterday and the problem is still there on my side.
Example of this night, there is phantom event every 1 or 2h (around):

Capture d’écran 2025-05-10 à 10.52.03
Capture d’écran 2025-05-10 à 10.52.031968×128 7.33 KB

Here is some example of the associated logs I can see on the deconz addon logs:
1/ Vibration detected at 05:10:11 and “disabled” at 05:11:16

05:10:03:682 ZCL attribute report 0xA4C13820522715A6 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
05:10:10:620 ZCL attribute report 0x00158D00010FCC9D for cluster: 0x0000, ep: 0x01, frame control: 0x1C, mfcode: 0x115F 
05:10:11:722 Door lock debug 0x00158D00010FCC9D, data 0x0000000A 
05:10:11:722 ZCL attribute report 0x00158D00010FCC9D for cluster: 0x0101, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
05:10:12:248 Set sensor check interval to 100 milliseconds
05:10:32:683 discovery for zombie 0x84BA20FFFE804F6D dropped, last try was 417 seconds ago
05:11:16:948 sensor 61 (lumi.vibration.aq1): disable vibration
05:11:17:548 Set sensor check interval to 1000 milliseconds

2/ Vibration detected at 05:02:44 and “disabled” at 06:03:49

06:02:30:107 ZCL attribute report 0x7CB03EAA0A07C245 for cluster: 0x0006, ep: 0x03, frame control: 0x18, mfcode: 0x0000 
06:02:43:381 ZCL attribute report 0x00158D00010FCC9D for cluster: 0x0000, ep: 0x01, frame control: 0x1C, mfcode: 0x115F 
06:02:44:492 Door lock debug 0x00158D00010FCC9D, data 0x0000000A 
06:02:44:492 ZCL attribute report 0x00158D00010FCC9D for cluster: 0x0101, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
06:02:44:747 Set sensor check interval to 100 milliseconds
06:02:46:506 ZCL attribute report 0x04CF8CDF3C7E4BDC for cluster: 0xFCC0, ep: 0x01, frame control: 0x1C, mfcode: 0x115F 
06:03:29:277 ZCL attribute report 0x804B50FFFEB56D26 for cluster: 0x0006, ep: 0x01, frame control: 0x08, mfcode: 0x0000 
06:03:33:544 ZCL attribute report 0xA4C138A58AEFCA95 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
06:03:47:084 discovery for zombie 0x84BA20FFFE804F6D dropped, last try was 1682 seconds ago
06:03:49:948 sensor 61 (lumi.vibration.aq1): disable vibration
06:03:50:548 Set sensor check interval to 1000 milliseconds

0x00158D00010FCC9D is my lumi.vibration.aq1 :

{
    "capabilities": {
        "sleeper": true
    },
    "config": {
        "battery": 100,
        "duration": 65,
        "on": true,
        "reachable": true,
        "sensitivity": 2,
        "sensitivitymax": 2
    },
    "ep": 1,
    "etag": "18168547200e86fbe73dc3d40bc6b61a",
    "lastannounced": "2025-02-27T19:18:45Z",
    "lastseen": "2025-05-10T08:55Z",
    "manufacturername": "LUMI",
    "modelid": "lumi.vibration.aq1",
    "name": "Vibration MAL",
    "nwkaddress": "0xFC40",
    "state": {
        "lastupdated": "2025-05-10T08:56:13.148",
        "orientation": [
            1,
            0,
            89
        ],
        "tiltangle": 10,
        "vibration": false,
        "vibrationstrength": 8
    },
    "swversion": "0.0.0_0008",
    "type": "ZHAVibration",
    "uniqueid": "00:15:8d:00:01:0f:cc:9d-01-0101"
}

For sure, I can help to debug more precisely if needed.

Thanks

21

Same for me. Updated deCONZ at 00:04, reloaded the deCONZ integration at 00:13.

Behavior did not change at all. Massive frequent phantom triggers as before.

IMG_0425
IMG_04251206×2234 201 KB

IMG_0424
IMG_04241206×2221 203 KB

Back to start.