Aqara P100 (DWZTCGQ11LM) repeatedly goes offline for ~1 hour, several times a day, even when joined directly to the coordinator

What happened?

Two independent Aqara P100 Multi-State Sensor units (lumi.vibration.agl002 / DWZTCGQ11LM), used as door/window sensors, repeatedly stop communicating for roughly one hour, several times per day, then resume on their own. This has been happening for about 3 weeks straight, on both devices, with an essentially identical pattern.

Devices affected:

• 0x54ef4410016cb0ab - friendly_name "Capteur Aquara Fenetre Salon"
• • 0x54ef4410016cd224 - friendly_name "Capteur Aquara Fenetre SaM"
    Both are the same device model/firmware (App 0.0 build 0 | Stack 0.0 build 24), in different physical rooms. Battery 100%, ~2.98V on both at time of investigation (not a low-battery issue).

Steps already taken to rule out other causes:

1. Configured per-device availability tracking (availability.timeout) to actually surface the offline/online transitions instead of guessing.
2. 2. Forced both devices to join directly to the coordinator (no intermediate router) via Z2M's "Permit join" scoped to the coordinator only, about 3 weeks ago - specifically to rule out a flaky mesh/router hop. The ~1h offline/online cycle persisted identically after this change.
3. 3. Lowered availability.timeout from 60 to 15 minutes to check whether the previous 60-minute setting was itself creating an artificial "offline for ~1h" reading. After the change (and a Zigbee2MQTT restart), one of the two sensors still stayed genuinely offline (no messages received at all) for close to an hour before recovering - confirming this is a real, sustained radio silence from the device, not a config/threshold artifact.
4. 4. Checked LQI and battery voltage at various points - both healthy, rulinThe devices should report continuously like the other ~85 Zigbee end devices on the same network, none of which exhibit this pattern - not go unreachable for close to an hour, several times a day.g out a weak-signal or low-battery brownout explanation.
5. 5. Both units (separate physical hardware) show the same behavior, which argues against a single defective unit.
      This device's Zigbee2MQTT support is relatively new, so this may be an undocumented interaction between the P100's firmware/power-management behavior and Zigbee2MQTT/zigbee-herdsman's handling of it (e.g. sleepy end device check-in / polling), rather than a hardware defect. Happy to provide debug-level logs or further diagnostics.

What did you expect to happen?

The devices should report continuously like the other ~85 Zigbee end devices on the same network, none of which exhibit this pattern - not go unreachable for close to an hour, several times a day.

How to reproduce it (minimal and precise)

Not directly reproducible on demand - it happens spontaneously several times per day on both P100 sensors. Pair a P100 (DWZTCGQ11LM), enable availability tracking for it, and watch zigbee2mqtt/<friendly_name>/availability: it will flip to offline for roughly an hour, then recover on its own, repeating multiple times per day.

Zigbee2MQTT version

2.13.0

Adapter firmware version

Not precisely recorded at time of writing (Silicon Labs EmberZNet coordinator revision, visible in frontend Settings -> About -> Coordinator revision).

Adapter

Silicon Labs EmberZNet-based coordinator (adapter: ember in Zigbee2MQTT config), network-attached via TCP (serial.port: tcp://192.168.1.19:6638) rather than a direct USB dongle.

Setup

Zigbee2MQTT running as the official Home Assistant Add-on (Studio Code Server used to edit configuration.yaml, MQTT broker is the built-in core-mosquitto add-on).

Device database.db entry

No response

Debug log

No response

Notes

No response

Start by reproducing the reported availability transitions for the Aqara P100 (DWZTCGQ11LM) on Zigbee2MQTT 2.13.0 with availability tracking enabled. Collect the missing debug log and database.db entry, then compare coordinator and device behavior; done means identifying whether the outage is in device support or Zigbee2MQTT handling and documenting a verified fix or next diagnostic.