Extend Purpose-Specific Triggers to Support Generic Entity State Changes with Label Filtering

[hugoovf]

Describe the feature

The current "Purpose-specific triggers and conditions" lab feature provides domain-specific triggers (like light.turned_on, switch.turned_off) with label support, which is excellent. However, I'd like to request adding generic/cross-domain triggers that work across all entity types:

• entity.turned_on - Fires when any entity (regardless of domain) with specified label(s) turns on/becomes active
• entity.turned_off - Fires when any entity (regardless of domain) with specified label(s) turns off/becomes inactive
• entity.toggled - Fires when any entity with specified label(s) changes state in either direction

Current Limitations:

The existing purpose-specific triggers are domain-locked (e.g., light.turned_on only works for lights). This means:

• Can't create a single trigger for "any labeled device turned on" if those devices span multiple domains (lights, switches, fans, etc.)
• Need multiple parallel triggers for the same logical concept (one for lights, one for switches, one for media players, etc.)
• No way to trigger on mixed-domain groups defined by labels

How it should work:

trigger: entity.turned_on
target:
  label_id: always_on
options:
  behavior: any

This would fire when ANY entity with the always_on label turns on, regardless of whether it's a light, switch, fan, climate device, or media player.

Use cases

1. Multi-domain monitoring: Trigger when ANY device labeled always_on (critical infrastructure like servers, security cameras, network equipment across different domains) turns on unexpectedly to send alerts. Currently requires separate triggers for each device domain.

2. Cross-domain energy monitoring: Monitor when any device labeled high_power activates across different domains (lights, switches, climate, appliances) to track total load. Can't do this with domain-specific triggers without multiple automations.

3. Unified presence detection: Trigger when any device labeled presence_indicators (motion sensors, door sensors, cameras, media players - different domains) activates. Label them all once and trigger with a single automation.

4. Smart scene activation: When any device labeled entertainment (TV, game console, streaming box - different domains) turns on, automatically adjust lighting and blinds with a single automation.

5. Maintenance and diagnostics: Track when any device labeled requires_monitoring changes state for logging purposes, without maintaining separate automations per device type.

Current workarounds

Currently handling this through event-based triggers with template conditions:

triggers:
  - event_type: state_changed
    trigger: event
    event_data: {}
conditions:
  - condition: template
    value_template: >-
      {{ trigger.event.data.entity_id in (labels() | map('label_entities') |
      sum(start=[])) }}

Why this is problematic:

1. Performance impact: Triggers on EVERY state change in the entire system, then filters afterwards. This means the automation evaluates thousands of irrelevant state changes (every sensor update, every attribute change) just to catch a few relevant ones.

2. Difficult to maintain: The template syntax is complex and not intuitive for average users. It requires understanding Jinja2, the labels() function, piping, and list operations.

3. Hard to debug: When something doesn't work, troubleshooting why a template condition failed is much harder than debugging a purpose-built trigger type.

4. Not discoverable: New users won't find this solution in the UI automation editor or documentation. It requires forum searching or community knowledge.

5. Fragile: If the internal structure of how labels work changes, these templates could break silently across many automations.

6. No selective filtering: Can't easily limit to specific labels without making the template even more complex, or filter by on/off states at the trigger level.

A purpose-built trigger would be more efficient (filtering at the trigger level), more maintainable, and accessible through the UI editor.

Anything else?

• This would be a natural extension of the existing "Purpose-specific triggers" lab feature
• Would maintain the same clean syntax: trigger, target, options structure
• Could support the same behavior: any/all options as domain-specific triggers
• Reduces automation duplication when working with multi-domain scenarios
• Makes label-based automations truly domain-agnostic, which is one of the key benefits of the label system
• Room/area/floor filtering already exists, so this fills the gap for custom cross-domain label-based triggers