Z4D Zigbee button triggering after update.

Xiaomi, Ikea TRÅDFRI, Philips Hue and more.

Moderator: leecollings

Post Reply
Houthakker
Posts: 19
Joined: Friday 04 February 2022 11:57
Target OS: -
Domoticz version:
Contact:

Z4D Zigbee button triggering after update.

Post by Houthakker »

Hi all,

So after the update i've had a strange issue with my Aqara wireless mini switch.
It has been spontaneously triggering, at random.
Very annoying because I use them for my bedroom lights.
I disabled the original function and coupled them to a virtual dummy switch to monitor the triggers, which show it triggering at randomly, at different times.

Me and Claude (well mostly Claude, I suck at coding and diagnosing this type of problems) have been trying to figure out what's going on and this is the result:


**Setup:**
- Domoticz V2026.3, running natively on Raspberry Pi (not Docker)
- Z4D stable9-9.1.002, using DomoticzEx
- Transport: ZigpyEZSP over USB-serial (Sonoff Zigbee 3.0 USB Dongle Plus V2 coordinator) — no MQTT involved
- Device: Xiaomi/Aqara `lumi.remote.b1acn01` single-click button ("$slaapkamer knop 2"), IEEE `00158d00066b45ff`, idx 211, ZDeviceID `83dd`

**Symptom:**
Since migrating from stable8 to stable9, this button spontaneously fires a "One click" (level 10) event in Domoticz/dzVents at irregular intervals (tens of minutes to a few hours apart), with no physical button press. A second button of the same model on the same coordinator, with a stronger signal, does not exhibit this behavior.

**Evidence:**

1. dzVents trigger log (custom logging added to isolate the issue):

2026-08-21 07:31:08.470 TRIGGER: name=$slaapkamer knop 2 level=10 lastUpdate=2026-08-21 05:00:27
2026-08-21 08:21:29.130 TRIGGER: name=$slaapkamer knop 2 level=10 lastUpdate=2026-08-21 07:31:08
2026-08-21 09:11:44.852 TRIGGER: name=$slaapkamer knop 2 level=10 lastUpdate=2026-08-21 08:21:29

No physical button presses occurred at these times (confirmed by removing all toggle logic and only logging).

2. Z4D plugin log confirms Z4D itself issued the UpdateDevice call:

2026-08-21 09:11:44,857 INFO :UpdateDevice - ($slaapkamer knop 2) 1:10


3. The DeviceList-18.txt entry for this device (ZDeviceID 83dd), captured right after the spurious trigger, shows:

'Stamp': {'time': 1787296304.81, 'Time': '2026-08-21 09:11:44', 'MsgType': '8102', 'LastSeen': 1787296304}
...
'PreviousStatus': 'Leave'
'RSSI': -76


Note: `MsgType 8102` alone does not appear to be the distinguishing factor — it shows up as a routine/periodic timestamp on most devices in the plugin database, including ones that never misbehave. The field that does stand out is `PreviousStatus: 'Leave'`, which is present on this device and indicates it had dropped off the network and (re)joined shortly before. The timestamp of that entry (09:11:44) matches exactly the timestamp of the spurious dzVents trigger.

For comparison:
- The other button of the same model (ZDeviceID 7351, IEEE `00158d00066f9362`), which does NOT produce spurious triggers, has no `PreviousStatus` field and a stronger `RSSI: -60`.
- A separate battery/mains-powered 4-gang switch (TS0004, "Router"/Main Powered, ZDeviceID ed31) has an even weaker `RSSI: -84` but also no `PreviousStatus` field, and has not (yet) shown spurious triggers. This suggests it's not signal strength alone, but specifically whether the device actually dropped off and rejoined the network (more common for battery-powered end devices that sleep, less common for mains-powered router devices).

**Hypothesis:**
When this Aqara button rejoins the network after dropping off (possibly related to weaker signal / RSSI -76), Z4D appears to re-send the last cached attribute value (level 10, "one click") to Domoticz via UpdateDevice at the moment of rejoin — rather than treating the rejoin as a connectivity-only event. This did not happen (or wasn't visible) before the stable8→stable9 migration.



So it looks like it's falling off the network, and after a rejoin it sends it current states back resulting in the trigger of a Dzvents script and the activation of a scene for the doubleclick action of the switch.


For the other switch, i replaced the battery and put it closer by a router, but I would not want to wait until the battery runs out and start to trigger my lights in the middle of the night again.
What can I do to fix the issue? I could replace the buttons with other buttons that are not showing this strange behaviour, but I would like to try and fix it before buying new gear.

Thanks!
User avatar
waltervl
Posts: 7020
Joined: Monday 28 January 2019 18:48
Target OS: Linux
Domoticz version: 2026.3
Location: NL
Contact:

Re: Z4D Zigbee button triggering after update.

Post by waltervl »

I would recommend to file a bug report on the Z4D repository. Looks like you did a good analysis (together with Claude :) )
Domoticz running on Udoo X86 (on Ubuntu)
Devices/plugins: ZigbeeforDomoticz (with Xiaomi, Ikea, Tuya devices), Nefit Easy, Midea Airco, Omnik Solar, Goodwe Solar
pipiche
Posts: 2035
Joined: Monday 02 April 2018 20:33
Target OS: Linux
Domoticz version:
Contact:

Re: Z4D Zigbee button triggering after update.

Post by pipiche »

9.1.003 should be fixing it
Houthakker
Posts: 19
Joined: Friday 04 February 2022 11:57
Target OS: -
Domoticz version:
Contact:

Re: Z4D Zigbee button triggering after update.

Post by Houthakker »

Thanks Pipiche, I just updated and will monitor it.
Post Reply