One trigger entry for multiple device trigger types or sub-types?

Configuration
, ,
1

With state-based triggers, we can do things like this:

- platform: state
  entity_id: sensor.remote

and the trigger will fire whenever the sensor.remote entity changes state, independent of the from: or to: state in that transition. Thus, one trigger can cover many different types of state changes.

Is there anything similar available for device triggers? e.g., with the current core integrations for Hue and Lutron Caseta, the only available triggers for the remotes are device triggers, as there are no entities created for these devices.

Thus, the trigger: section for an automation/blueprint that contains all the functionality (for all buttons) for that remote would end up looking like this:

- device_id: xxxxxxxxxxxxxxxxxxxxxxxxxxxx
  domain: hue
  platform: device
  type: remote_button_short_release
  subtype: turn_on

- device_id: xxxxxxxxxxxxxxxxxxxxxxxxxxxx
  domain: hue
  platform: device
  type: remote_button_short_release
  subtype: turn_off

[...]

- device_id: xxxxxxxxxxxxxxxxxxxxxxxxxxxx
  domain: hue
  platform: device
  type: remote_button_long_release
  subtype: dim_down

Enumerating all the triggers results in a lot of repeated code when you consider button presses, button releases, short presses, long presses, double presses, etc.

I tried omitting the sub-type: entry in hopes that it would accept any sub-type:, but HA won’t even load that code. Same for omitting the type: field.

- device_id: xxxxxxxxxxxxxxxxxxxxxxxxxxxx
  domain: hue
  platform: device
  type: remote_button_short_release

Any better ideas vs. enumerating all the possible triggers in the trigger: section?

2

In contrast to most other types of triggers, which can be manually composed and modified, the Device Trigger stands apart. It was not meant to be composed manually (for example, its device_id is not easily found) but only via the UI (the Automation Editor). The code it generates should not be modified manually (unless it’s a trivial change). Whatever additional code generated by the use of Device Triggers is a moot point because it was not intended to be inspected/modified/refactored/etc.

You may want to explore the Event Trigger because almost every activity in Home Assistant generates an event.

1 Like
3

I’m almost sure that these create events, which can then be used in an event based trigger. Take a look at this from the deconz docs, should be similar for the Hue and Lutron integrations.

4

Thanks @Burningstone and @123!

Events seem like a good option in most cases. That’s how the existing blueprints for the Hue Dimmer Switch work for ZHA and deCONZ.

Their inputs look something like this:

    remote:
      name: Philips Hue Dimmer Switch
      description: Pick either RWL020 (US) or RWL021 (EU)
      selector:
        device:
          integration: zha
          manufacturer: Philips
          entity:
            domain: sensor
            device_class: battery

and then the triggers look like this:

trigger:
  - platform: event
    event_type: zha_event
    event_data:
      device_id: !input "remote"

The problem I’m having is that the Lutron Caseta and Philips Hue remote events don’t seem to have the device_id in their data, so I’m not sure how to create a blueprint (other than using individual device triggers). i.e. you can only refer to the remote as a device for an input Selector since there are no entities, and then the device_id doesn’t appear to be found in any fields in the events that get triggered by that remote.

Example zha_event:

{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "XX:XX:XX:XX:XX:XX:XX:XX",
        "unique_id": "XX:XX:XX:XX:XX:XX:XX:XX:X:XxXXXX",
        "device_id": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
        "endpoint_id": 1,
        "cluster_id": 64514,
        "command": "attribute_updated",
        "args": {
            "attribute_id": 18,
            "attribute_name": "x_axis",
            "value": 1027
        }
    }
}

Note the device_id field.

Example hue_event:

{
    "event_type": "hue_event",
    "data": {
        "id": "hue_switch",
        "unique_id": "XX:XX:XX:XX:XX:XX:XX:XX-XX-XXXX",
        "event": 4002,
        "last_updated": "2021-02-15T16:22:33"
    }
}

Note the lack of device_id field.

And here’s a lutron_caseta_button_event:

{
    "event_type": "lutron_caseta_button_event",
    "data": {
        "serial": XXXXXXXX,
        "type": "Pico3ButtonRaiseLower",
        "button_number": 4,
        "device_name": "Pico",
        "area_name": "Kitchen",
        "action": "press"
    }
}

Also note the lack of a device_id.

It seems that if I want to create a blueprint for the any Hue or Lutron remotes using the Hue/Lutron integrations, I’d need the those integrations to start putting the device_id data into their events if I don’t want to use device triggers.

Any workarounds for now other than using device triggers and enumerating all the possible events?

5

You’d need a string selector for the blueprints and this string then needs to match the unique identifier, e.g. in the hue_event id should be unique (at least it was for deconz before device triggers were a thing) and for lutron, I assume serial will be unique.
You won’t get a nice selector with a dropdown in the blueprint. For this, the lutron and hue integrations would need to add the device id to the event.

1 Like
6

They may lack device_id but I see enough information in data to uniquely identify each device. They’re not the most compact values to match in a template but they ought to do the trick.

2 Likes