SONOFF ZBDongle-P / E / SLZB-06 vs ConBee II - same setup, years of testing, only ConBee II reliably solves my 2-way switches

What happened?

SONOFF ZBDongle-P / E / SLZB-06 vs ConBee II — same setup, years of testing, only ConBee II reliably solves my 2-way switches

Environment

• Home Assistant running in Docker

• Raspberry Pi 4

• Zigbee2MQTT

• Multiple separate homes with essentially identical installations

• Chinese Zigbee 2-way wall switches purchased from AliExpress

• Home Assistant groups (not Zigbee2MQTT groups)

• Tested coordinators:

  • SONOFF ZBDongle-P

  • SONOFF ZBDongle-E

  • SLZB-06

  • ConBee II

---

The problem

I have been fighting this problem for several years.

During this time I have run many different:

• Zigbee2MQTT versions

• Home Assistant versions

• Coordinator firmware versions

• Coordinator hardware models

• Zigbee network configurations

Despite all of this testing, the behavior remains remarkably consistent.

I have also reproduced the same behavior in multiple different homes with essentially the same setup.

This is why I am increasingly convinced that this is not simply a bad installation, RF interference, a specific coordinator, or a bug in one particular Z2M/HA release.

---

The surprising part: coordinator comparison

I have tested four different coordinators.

The SONOFF ZBDongle-P, SONOFF ZBDongle-E and SLZB-06 all behave similarly.

The ConBee II behaves differently.

Coordinator       2-way switches        HA group control
-------------------------------------------------------
SONOFF ZBDongle-P  ❌ Unreliable        ✅ Generally good
SONOFF ZBDongle-E  ❌ Unreliable        ✅ Generally good
SLZB-06            ❌ Unreliable        ✅ Generally good
ConBee II          ✅ Reliable          ❌ Some devices miss

This is the main reason I am opening this issue.

With the SONOFF/SLZB coordinators, my 2-way switches are intermittently slow or fail to synchronize.

With the ConBee II, the exact same switches and the exact same Home Assistant automation work reliably.

However, the ConBee II introduces a different problem: Home Assistant group commands do not reliably reach all devices.

---

My 2-way switch setup

I have physical 2-way switches controlling the same light.

The switches are inexpensive Chinese Zigbee switches from AliExpress.

Unfortunately, these devices do not provide a practical native mechanism that allows me to implement the required behavior directly through Zigbee2MQTT.

Therefore I synchronize the switch entities in Home Assistant.

For example, the automation is essentially:

trigger:
  - platform: state
    entity_id:
      - light.2way_switch_1
      - light.2way_switch_2
      - light.2way_switch_3
action:

synchronize the corresponding switch with the state of the switch that triggered the automation

The important point is:

The automation itself works correctly and reliably.

I have tested it extensively.

Most importantly, the exact same automation works reliably when the coordinator is a ConBee II.

So I would strongly prefer to keep the discussion focused on Zigbee2MQTT/coordinator behavior rather than rewriting the automation.

---

What I have already tried

Over the years I have tested a large number of combinations, including:

• Multiple Zigbee2MQTT versions

• Multiple Home Assistant versions

• Multiple coordinator firmware versions

• SONOFF ZBDongle-P

• SONOFF ZBDongle-E

• SLZB-06

• ConBee II

• Re-flashing coordinator firmware

• Reinstalling/reconfiguring Zigbee2MQTT

• Checking Z2M debug logs

• Investigating ZCL command timeouts

• Investigating failed device pings

• Testing the same switch configuration with different coordinators

• Reproducing the problem across multiple homes

• Optimizing Wi-Fi and Zigbee channel usage

The problem has survived all of this.

---

What I would really like to understand

How are other Zigbee2MQTT users implementing 2-way switches?

I cannot believe I am the only person running into this.

I would especially like to hear from users who have two physical Zigbee switches controlling the same light.

Are you using:

• Home Assistant state synchronization?

• Zigbee binding?

• Zigbee groups?

• Device-to-device commands?

• Some other mechanism?

And, more importantly:

Has anyone else observed this kind of behavior where the ConBee II handles this 2-way-switch scenario reliably, while TI-based coordinators such as SONOFF/SLZB do not?

Could this be related to differences in the coordinator/adapter implementation or in zigbee-herdsman?

I would really appreciate input from anyone who has dealt with a similar real-world setup.

---

One more important detail

I am not able to solve this simply by using a native 2-way-switch feature in Zigbee2MQTT, because my switches are cheap Chinese AliExpress devices and do not expose the functionality I need.

This is why the reliability of normal state/command handling is so important in my case.

I am not looking for a theoretical "use a proper switch" solution — I would like to understand whether there is a Zigbee2MQTT-level explanation or solution for this behavior.

Any help from people familiar with the Z2M coordinator/adapter implementation would be greatly appreciated.

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

2.1.0

Adapter firmware version

0x26780700

Adapter

ConBee2/RaspBee2

Setup

Home Assistant running in Docker

Raspberry Pi 4

Zigbee2MQTT

Multiple separate homes with essentially identical installations

Chinese Zigbee 2-way wall switches purchased from AliExpress

Home Assistant groups (not Zigbee2MQTT groups)

Tested coordinators:

SONOFF ZBDongle-P

SONOFF ZBDongle-E

SLZB-06

ConBee II

Device database.db entry

No response

Debug log

No response

Notes

No response

No source file, test, minimal reproduction, database entry, or debug log is identified. Start by reviewing the Zigbee2MQTT coordinator/adapter implementation and zigbee-herdsman behavior, then compare the reported ZCL command timeouts and failed device pings across the listed coordinators. Done would require a reproducible case with logs and a confirmed explanation or targeted fix.