Random SONOFF MINI-ZBRBS routers disappear from Zigbee2MQTT database and require re-pairing (Ember adapter)

What happened?

Random SONOFF MINI-ZBRBS roller shutter switches occasionally stop responding in Zigbee2MQTT.

This is not limited to one physical device. During the last weeks multiple different MINI-ZBRBS devices have shown exactly the same behaviour.

When the problem occurs:

• the physical wall switch continues to operate the shutter normally
• the device remains powered
• Zigbee2MQTT commands fail
• Home Assistant can no longer control the device
• Zigbee2MQTT reports "Delivery failed"

The most interesting observation is that I compared complete Zigbee2MQTT backups before and after the incident.

The affected device was completely removed from:

• database.db
• state.json

After re-pairing, the exact same IEEE address returned and a new database entry was created.

This indicates that the device was removed from the Zigbee2MQTT database rather than simply becoming unreachable.

Affected devices so far:

• 0xc02cedfffef0e5a4
• 0xc02cedfffe7543c2

The issue has occurred on multiple different MINI-ZBRBS devices.

What did you expect to happen?

The router should remain present in the Zigbee2MQTT database even if communication temporarily fails.

A router device should not disappear from database.db and require re-pairing.

How to reproduce it (minimal and precise)

Unfortunately I cannot reproduce the issue on demand.

It occurs randomly after days or weeks of normal operation.

One occurrence happened shortly after a Home Assistant restart, but I cannot confirm whether the restart triggered the issue or whether it was only noticed afterwards.

The issue has also happened independently of Home Assistant restarts.

Zigbee2MQTT version

2.12.1

Adapter firmware version

7.4.5 GA

Adapter

ember

Setup

Home Assistant OS

Zigbee2MQTT Add-on

SONOFF Dongle-M

Connection via TCP:

tcp://dongle-m.local:6638

Channel: 25

Device database.db entry

No response

Debug log

No response

Notes

Additional investigation already performed:

• compared multiple complete Zigbee2MQTT backups
• compared coordinator backups
• compared database.db before/after
• compared state.json before/after
• PAN ID identical
• Extended PAN ID identical
• Network Key identical
• Channel identical
• Coordinator unchanged
• Zigbee2MQTT configuration unchanged

Only the backup timestamp and network frame counter differed.

I also found recent discussions regarding unsolicited device_leave events. I do not know whether this is related, but the observed behaviour appears similar because the affected device disappears completely from database.db.

If the issue happens again I can provide:

• Zigbee2MQTT debug logs
• before/after database.db
• before/after state.json
• before/after coordinator backups

Start by reviewing the device-removal behavior around database.db and state.json, then compare the before/after backups described in the report. Examine the available Zigbee2MQTT debug logs and coordinator backups if the issue recurs, focusing on unsolicited device_leave events. Done means identifying why a powered router is removed and preserving its database entry during temporary communication failures.