Aqara Water Leak Sensor T1 (SJCGQ12LM) never reports water_leak: IAS enrollment skipped by the lumi..* interview quirk

What happened?

The Aqara Water Leak Sensor T1 (SJCGQ12LM / lumi.flood.agl02) never reports a leak. It pairs, interviews as SUCCESSFUL, is supported: true, exposes water_leak, and last_seen updates on a button press — but water_leak stays false forever. Shorting the two probes produces no Zigbee frame at all.

Over 24h of debug logs the device only ever sent one kind of message:

[2026-08-09 15:10:04] debug: z2m: Received Zigbee message from 'Water sensor', type 'attributeReport',
  cluster 'genBasic', data '{"modelId":"lumi.flood.agl02"}' from endpoint 1 with groupID 0

Zero ssIasZone / zoneStatus / commandStatusChangeNotification frames, ever. battery and voltage also stay null.

Root cause

Reading the IAS Zone attributes directly (the read queues and fires on the next button press, since this is a sleepy end device) shows the device is not enrolled:

z2m: Received Zigbee message from 'Water sensor', type 'readResponse', cluster 'ssIasZone',
  data '{"iasCieAddr":"0x0000000000000000","zoneState":0,"zoneStatus":33,"zoneType":42}'

• zoneType: 42 (0x2A) — correct water sensor zone type
• zoneStatus: 33 — bit 0 (Alarm1) is set: the sensor hardware detects the shorted probes just fine
• zoneState: 0 — NOT_ENROLLED, iasCieAddr all zeros

An unenrolled IAS zone is not allowed to send commandStatusChangeNotification, so the alarm never leaves the device.

zigbee-herdsman does enroll IAS devices during the interview (Device.interview(), "Enroll IAS device" block), but lumi devices match the lumi..* modelID quirk:

Interview procedure failed but got modelID matching 'lumi..*', assuming interview succeeded

That shortcut marks a failed interview as successful and returns before the enrollment step runs. Harmless for most lumi devices (they use the manufacturer-specific 0xFF01 attribute), but lumi.flood.agl02 is a genuine IAS Zone device and stays unenrolled permanently. Re-pairing hits the same quirk again, so it does not help.

Workaround

Enroll manually over MQTT. Both commands queue for ~1 hour and flush on the next transmission, so press the sensor button once afterwards:

zigbee2mqtt/<FRIENDLY_NAME>/set
{"write":{"cluster":"ssIasZone","payload":{"iasCieAddr":"0x<COORDINATOR_IEEE>"}}}
{"command":{"cluster":"ssIasZone","command":"enrollRsp","payload":{"enrollrspcode":0,"zoneid":23}}}

Immediately after this the sensor started reporting normally:

z2m: Received Zigbee message from 'Water sensor', type 'commandStatusChangeNotification',
  cluster 'ssIasZone', data '{"delay":0,"extendedstatus":0,"zoneID":23,"zonestatus":33}'
z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Water sensor', payload '{... "water_leak":true}'

water_leak then tracked the probes across three open/short cycles with no button press needed (zonestatus 33 → true, 32 → false). Note the enrollment lives in the sensor's NVRAM, so it has to be redone after a factory reset or re-pairing.

Proposed fix

Koenkk/zigbee-herdsman-converters#12870 — enroll in configure() for SJCGQ12LM, mirroring the existing NYCE NCZ-3011-HA fix added in #32480 for the same class of problem.

Other lumi definitions using fz.ias_*_alarm_* (e.g. SJCGQ13LM / lumi.flood.acn001) are probably affected the same way, but I could only verify the T1.

What did you expect to happen?

water_leak changes to true when the probes get wet / are shorted.

How to reproduce it (minimal and precise)

1. Pair an Aqara Water Leak Sensor T1 (lumi.flood.agl02).
2. Short the two probes.
3. Observe that no ssIasZone frame is received and water_leak never changes.
4. Read ssIasZone zoneState / iasCieAddr and observe 0 / all zeros.

Zigbee2MQTT version

2.13.0 (Docker, koenkk/zigbee2mqtt:2.13.0)

Adapter firmware version

ZStack3x0

Adapter

zstack (/dev/ttyUSB0), channel 11

Device

Aqara Water Leak Sensor T1, SJCGQ12LM / lumi.flood.agl02, dateCode 20230825, appVersion 32, hwVersion 1, batteryVoltage 31 (3.1 V)

Start at the SJCGQ12LM converter's configure() entry point and compare it with the NYCE NCZ-3011-HA enrollment fix from #32480. Verify the behavior with the listed Aqara reproduction: after pairing and shorting the probes, the device should emit ssIasZone status changes and update water_leak without another button press.