I updated my deconz (as home assistant add-on) to 2.29.5 (8.1.0 add-on version). It went well first but then I saw that automations have been triggered (like opening my garage door, light going on) by “ghost button events”. This happened for two of my several lumi.sensor_switch.aq2.
Consequently, I went back to 2.28.1 (7.0.0) and this issue did not appear anymore. Any ideas? I noticed that this device doesn’t have a DDF if I am not mistaken.
Interesting, did this happen repeadedly for the same devices or once?
Hi @manup, yeah so it happened repeatedly in an interval of around 50 minutes, and I know that it happened at least for four devices - I assume that it happened for all of the smart minis.
I assume it is a “replay-event”, because one of my automations is triggered by a double click only, which is reported as 1004 event I think. I found a similar issue #4232 for a smartthing button which has been resolved by #4986. However, this piece of code is still there in the latest version although I don’t know of course whether it is executed.
Btw I got the name wrong, it is lumi.remote.b1acn01. No DDF - I tried to create one but it didn’t work.
Indeed the lumi.remote.b1acn01 is currently handled by legacy code and the 1004 event extracted directly by the incoming packet from the Multistate Input cluster with value 2.
The hourly interval would indicate some connection to the hourly packet which Xiaomi devices send (includes battery and other state variables). But this shouldn’t trigger button events 
Do you receive this event on Websocket?
I assume the answer is “yes”, because the home assistant integration uses websockets. No logs because I got too scared and reverted back quickly 
Disclaimer: I did the usual sanity stuff like restart HA, reload the deconz integration, restart the add-on container, etc.
I would be happy to try whether a DDF would resolve the issue (?), but need a bit of design help. I drafted one based on a Xiaomi switch but it didn’t work (DDF was assigned to the device but no button events in the API).
Our of curiosity I found the lumi.remote.b1acn01 switch in one of my testing boxes
It joined right and does indeed not have a DDF.
Gonna make some tests, first to see what the issue with the legacy code is (which may affect other Xiaomi devices too). And once this works also create a DDF for it.
Here is the test result so far:
2025-04-24T13:32:42.212.{
"capabilities": {
"sleeper": true
},
"config": {
"battery": 100,
"on": true,
"reachable": true,
"temperature": 3100
},
"ddf_hash": null,
"ddf_policy": "latest_prefer_stable",
"ep": 1,
"etag": "909bb4532d9dce7b82cbf506dd349400",
"lastannounced": null,
"lastseen": "2025-04-24T13:32Z",
"manufacturername": "LUMI",
"mode": 1,
"modelid": "lumi.remote.b1acn01",
"name": "Switch 370",
"nwkaddress": 21124,
"state": {
"buttonevent": 1004,
"lastupdated": "2025-04-24T13:32:42.212"
},
"swversion": null,
"type": "ZHASwitch",
"uniqueid": "00:15:8d:00:04:4b:5d:30-01-0012"
}
{
"capabilities": {
"sleeper": true
},
"config": {
"battery": 100,
"on": true,
"reachable": true,
"temperature": 3000
},
"ddf_hash": null,
"ddf_policy": "latest_prefer_stable",
"ep": 1,
"etag": "b08748ef64d704c658a46c769ebc071f",
"lastannounced": null,
"lastseen": "2025-04-24T14:23Z",
"manufacturername": "LUMI",
"mode": 1,
"modelid": "lumi.remote.b1acn01",
"name": "Switch 370",
"nwkaddress": 21124,
"state": {
"buttonevent": 1004,
"lastupdated": "2025-04-24T13:32:42.212"
},
"swversion": "20180525",
"type": "ZHASwitch",
"uniqueid": "00:15:8d:00:04:4b:5d:30-01-0012"
}
{
"attr": {
"ddf_hash": null,
"ddf_policy": "latest_prefer_stable",
"lastannounced": null,
"lastseen": "2025-04-24T14:23Z",
"manufacturername": "LUMI",
"mode": 1,
"modelid": "lumi.remote.b1acn01",
"name": "Switch 370",
"nwkaddress": 21124,
"swversion": null,
"type": "ZHASwitch",
"uniqueid": "00:15:8d:00:04:4b:5d:30-01-0012"
},
"e": "changed",
"id": "370",
"r": "sensors",
"t": "event",
"uniqueid": "00:15:8d:00:04:4b:5d:30-01-0012"
}
and
{
"config": {
"battery": 100,
"on": true,
"reachable": true,
"temperature": 3000
},
"e": "changed",
"id": "370",
"r": "sensors",
"t": "event",
"uniqueid": "00:15:8d:00:04:4b:5d:30-01-0012"
}
To me this looks all correct, there is no button event thrown, only events for config and attr objects.
I also created a DDF for the switch, but it will basically do the same as above legacy code. I don’t understand why it triggers in your setup
You can check websocket without using logs.
Just on Phoscon/HELP/API Information/event
With it you will see if the problem is from deconz or HA.
Dear both, thanks for spending time on this.
I think it would be quite surprising if HA would be the issue. The events do appear in the HA recorder function exactly like a deconz event. But let’s find out.
This is a bit mysterious issue - maybe it is an artifact of the upgrade in some way. Since the smart buttons do not really have a critical function in my setup, I will do some more experiments and report back.
And just by curisosity, there is a logic in the event ? Like always the same button or the same event, or always the same butonevent than the previous one ?
I could observe the issue with all buttons which are currently in use (four of them). The emitted events correspond to the last event triggered by a button press - in most cases this is 1002, but in one case (said garage) it is 1004, double click. For each button, the same event was emitted several times in a fixed interval (approx. 50 min).
Restarting deconz did not resolve the issue which is curious.
[EDIT] Ok guys I did now install the update to 2.29.5 again (10 minutes ago). Until now, everything works fine. I deactivated all automations except one.
I also managed to create a working DDF, but I did not activate it yet in the new version. Let’s see. Ghost in the machine?
[EDIT 2] I could now catch it - nobody did press this button.
{
"22:41:08:623": {
"attr": {
"ddf_hash": null,
"ddf_policy": "latest_prefer_stable",
"lastannounced": null,
"lastseen": "2025-04-24T20:41Z",
"manufacturername": "LUMI",
"mode": 1,
"modelid": "lumi.remote.b1acn01",
"name": "Smart Switch Mara",
"nwkaddress": 62791,
"swversion": "20180525",
"type": "ZHASwitch",
"uniqueid": "00:15:8d:00:06:7c:9c:3e-01-0012"
},
"e": "changed",
"id": "98",
"r": "sensors",
"t": "event",
"uniqueid": "00:15:8d:00:06:7c:9c:3e-01-0012"
},
"22:41:08:671": {
"capabilities": {
"sleeper": true
},
"e": "changed",
"id": "98",
"r": "sensors",
"t": "event",
"uniqueid": "00:15:8d:00:06:7c:9c:3e-01-0012"
},
"22:41:08:673": {
"config": {
"battery": 100,
"on": true,
"reachable": true,
"temperature": 2500
},
"e": "changed",
"id": "98",
"r": "sensors",
"t": "event",
"uniqueid": "00:15:8d:00:06:7c:9c:3e-01-0012"
},
"22:41:08:674": {
"e": "changed",
"id": "98",
"r": "sensors",
"state": {
"buttonevent": 1002,
"lastupdated": "2025-04-07T22:41:38.287"
},
"t": "event",
"uniqueid": "00:15:8d:00:06:7c:9c:3e-01-0012"
}
}
Corresponding event in HA (which triggered an automation):
Good: I am not crazy. Will now try what happens if I install the DDF.
[EDIT 3] It also happens with a working DDF. I will try the last option and reboot the system But I think we can summarize so far that indeed ghost buttons events are emitted on the websocket. Why?
{
"23:02:25:629": {
"attr": {
"ddf_hash": null,
"ddf_policy": "latest_prefer_stable",
"lastannounced": null,
"lastseen": "2025-04-24T21:02Z",
"manufacturername": "LUMI",
"mode": 1,
"modelid": "lumi.remote.b1acn01",
"name": "Smart Switch Bettlampe",
"nwkaddress": 23450,
"swversion": "20180525",
"type": "ZHASwitch",
"uniqueid": "00:15:8d:00:06:7b:d3:b6-01-0012"
},
"e": "changed",
"id": "79",
"r": "sensors",
"t": "event",
"uniqueid": "00:15:8d:00:06:7b:d3:b6-01-0012"
},
"23:02:25:707": {
"capabilities": {
"sleeper": true
},
"e": "changed",
"id": "79",
"r": "sensors",
"t": "event",
"uniqueid": "00:15:8d:00:06:7b:d3:b6-01-0012"
},
"23:02:25:708": {
"config": {
"battery": 100,
"group": "20003",
"on": true,
"reachable": true,
"temperature": 3000
},
"e": "changed",
"id": "79",
"r": "sensors",
"t": "event",
"uniqueid": "00:15:8d:00:06:7b:d3:b6-01-0012"
},
"23:02:25:714": {
"e": "changed",
"id": "79",
"r": "sensors",
"state": {
"buttonevent": 1002,
"lastupdated": "2025-04-22T23:08:08.773"
},
"t": "event",
"uniqueid": "00:15:8d:00:06:7b:d3:b6-01-0012"
}
}
After the reboot, no button events anymore so far, only status updates. Well, it is a bit depressing that “did you try to switch it off and on again” seems to work more often then it should.
At least the DDF could be added, I can do it tomorrow (today). Cheers
BTW, just want to add that the latest versions of deconz are really working well for me in general - stable, fast, and it appears robust (there are still the usual USB dis/re-connects but I am starting to think that this is by design if the stick gets into an unstable state or something).
Interesting I have an idea where to look now, if the restart of deCONZ/container helps this could be related to timestamps which where not fully stored/restored in earlier versions and the first startup could be inconsistent. I think it makes sense to exclude a few items like buttonevents and presence from this.
Story is not yet over:
For the freeze there is already a bug fix in https://github.com/dresden-elektronik/deconz/commit/a8cd54828522e1335bac32159b909727611062a6.
There will be a smaller bug fix release soon. I hope to also get rid of the ghost events (also without restart).
Small update, I found the place in code where it goes wrong. Need to add a few filters to prevent events where none should happen.
Great to hear! When browsing through deconz issues (funny hobby), I stumbled upon #8141. Number four of @ebaauw 's list says:
- Currently supported IAS ACE devices expose IAS Zone (0x0500) and IAS ACE (0x0501) on a single
ZHAAncillaryControlresource. This causesstate/lastupdatedto be updated when the IAS Zone sends a supervision report, causing API clients to see ghost button presses.
Not sure whether this applies here of course, just trying to connect dots.
Interesting. What’s the progress?
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.
Thanks for sharing. Parsing through the comments
