Hallo HomeAssistenten
Wer hat einen Aqara P100 (9-Achsen-Multi-Sensor) über ZHA bei sich im Einsatz? Finde keine Antwort auf folgende Frage:
Kann der Tilt (Kippen) und Move (Bewegung = Türöffnung) gleichzeitig? Bekomme ich diese Werte, wenn ich ihn direkt in HA über ZHA verbinde?
Habe einen Briefkasten, bei dem der Briefeinwurf gegen oben gedrückt wird (Kippen/Tilt) und wenn ich leere, muss ich die ‘Tür’ aufmachen, d.h. Bewegung ohne Kippen (=Türöffnung). So hätte ich Einwurf und Leerung voneinander getrennt.
Kann der Sensor das?… und zwar gleichzeitig über ZHA?
Schöne Grüsse
Wie immer bei Aqara, bekommst Du den vollen Funktionsufang nur in Verbindung mit dem Aqara Hub garantiert.
ZigBee2MQTT unterstützt bereits viele Features.
ZHA Unterstützung, aktuell nur mit einem Custom Quirk
offen 09:45PM - 16 May 26 UTC
## Device
- **Manufacturer:** Lumi / Aqara
- **Zigbee model / modelId:** `lum… i.vibration.agl002`
- **Marketing model / SKU:** DWZTCGQ11LM — Aqara Multi-State Sensor P100
- **Name in HA:** AqaraP1001
- **IEEE:** `54:ef:44:10:01:5e:53:10`
- **ZHA-reported firmware:** `0x00000015` (Firmware line in HA can still show Unknown)
- **Coordinator:** cod.m (CZC), “COD.M Coordinator”, CC2652P7; Zigbee over network/TCP socket `192.168.178.203:6638`; coordinator Zigbee FW on device UI `20250321`
## Home Assistant
- **Install:** Home Assistant OS
- **Core:** 2026.5.2
- **Supervisor:** 2026.05.0
- **Operating System:** 17.3
- **Frontend:** 20260429.4
## Zigbee stack
Only **Zigbee Home Automation (ZHA)** is used on this coordinator. **No Zigbee2MQTT** (and no second client) concurrently using the cod.m Zigbee TCP socket — ZHA owns the connection to the coordinator.
## Problem
The device pairs to ZHA but support is incomplete and confusing:
- **Misleading entities:** a generic **toggle** plus a **door lock** (“Abschließen”) style control that does not match a **sensor** SKU.
- **Reconfiguration/cluster setup:** **`DoorLock`** binding succeeds but **attribute reporting for `lock_state` fails** during ZHA device reconfiguration.
- **Feature parity:** compared to behaviours documented for DWZTCGQ11LM — modes, door/window vs object semantics, calibrated install, vibration / triple-tap–style signalling — **ZHA does not expose equivalent entities/events**.
Upstream reference (other stack, but same radio model identifiers):
- zigbee-herdsman-converters: [#11974](https://github.com/Koenkk/zigbee-herdsman-converters/pull/11974) — `zigbeeModel: lumi.vibration.agl002`, `model: DWZTCGQ11LM`
- Device documentation: https://www.zigbee2mqtt.io/devices/DWZTCGQ11LM.html
## What works
- Device joins the network and stays connected via ZHA (`COD.M Coordinator`).
- **LQI** in HA Diagnostics was recently **47** (varies over time).
## What doesn’t / symptoms
- **DoorLock**-related scaffolding and **`lock_state` reporting failure** after reconfigure.
- Missing or incomplete exposure of the multi-state behaviours described for DWZTCGQ11LM.
- Firmware field sometimes **Unknown** in the UI beside `0x00000015`.
## Logs / diagnostics
- Please see **GitHub Comment #2** immediately below this issue for the **full ZHA device signature** for IEEE `54:ef:44:10:01:5e:53:10` (Developer tools / ZHA “get device signature” — paste as-is).
- If attachable easily: diagnostics export for integration **Zigbee Home Automation** (redacted if it contains unrelated secrets).
## Request
Add a proper **zha-device-handlers** quirk for `lumi.vibration.agl002` / DWZTCGQ11LM so ZHA exposes/collects behaviour consistent with DWZTCGQ11LM docs and avoids incorrect **DoorLock** mapping.
Thank you!
_Disclaimer: This report was written with assistance from Cursor (AI). I’m not a software developer — device facts, screenshots, and Home Assistant/ZHA versions come from my own running system._
Gruß Osorkon
