Matter devices: different triggers (When) vs conditions (And) in Automations v2

Marc3k · April 13, 2026, 1:01am

I’ve noticed something with Matter devices in Aqara Automations (v2) and I’m curious if others are seeing the same behavior.

When creating an automation, Matter devices (in my case, a speaker) don’t expose the same triggers (“When”) and conditions (“And”) as native Aqara devices.

For example:
Under “When”, I can see detailed states like music status changes to (playing, paused, buffering, etc.)
But under “And”, I only get very basic conditions like is on / is off
So the available conditions are much more limited compared to the triggers, even for the same device.

Is this a limitation of the Matter standard itself (since it exposes fewer attributes/conditions), or is it something on Aqara’s side that could be expanded in the future?

JohnD · April 13, 2026, 6:48am

I don’t think this is a limitation of the Matter standard itself. If we look at the Matter specifications for the Media Playback cluster (see attached screenshots), we can see exactly what is happening under the hood.

The first screenshot shows the StateChanged Event → CurrentState. This is what the Aqara When trigger is based on. When the playback status changes, the device actively generates this event and sends it to the Hub. The fact that we have these triggers in the app proves the Aqara Hub is successfully receiving and understanding this data.

The second screenshot shows the Attributes table for the Media Playback cluster. As you can see, CurrentState is an actual, persistent attribute. More importantly, it has “R” (Read) access and “M” (Mandatory) conformance. This means every Matter media device must maintain this state, and the Hub is officially allowed to actively read it at any time.

The third screenshot ties it all together by defining the PlaybackStateEnum (Playing, Paused, etc.). Both the StateChanged event and the persistent CurrentState attribute use this exact same vocabulary.

Since this state also exists as a proper attribute, the hub could obtain it either by maintaining a local representation (e.g. via subscriptions) or by actively reading the attribute when evaluating an And condition.

Because of this, it seems more like a limitation in Aqara’s current implementation (UI/backend mapping of Matter attributes to conditions) rather than a fundamental limitation of Matter itself.