Is there any way for a template to list ALL devices?

Configuration
,
1

Every solution I have seen starts with the states object or an entity list, so it misses any device that has no entities. For example (and the reason for this question), Pico remotes in the lutron_caseta integration don’t have any entities; they exist only to emit events.

I know I can open the device registry file core.device_registry and look manually for the entry I want and pull the information from there. It looks like I can also download diagnostics from the integration page and, again, manually review that JSON to find it. Neither of those seems ideal.

The use case: if I want to trigger an automation on a Pico button press, I have to start the event listener in the GUI and actually press the button to see what comes out, which is something like this:

event_type: lutron_caseta_button_event
data:
  serial: 44269999
  type: Pico2Button
  button_number: 4
  leap_button_number: 2
  device_name: Family Room Reading
  device_id: 999999c4996082fd89f8b6b3d7ec58bc
  area_name: Family Room
  button_type: "off"
  action: release
origin: LOCAL
time_fired: "2025-02-02T15:16:31.263090+00:00"
context:
  id: 01JK3KR5CZ21TXAPYVK17XNZE4
  parent_id: null
  user_id: null

And then I can use the name, serial, and device_id as I wish. But without pressing the actual button I’m not sure where to get this info.

If the answer is “just look at the JSON” then so be it, but I wonder if I’m missing something.

Thanks!

2

According to the documentation for the Lutron Caseta integration, it creates button entities (for transmitting) and it supports Device Triggers (for receiving; available button events are revealed when the trigger is composed in the Automation Editor).

Perhaps that’s only available when your system uses certain models of the bridge?

FWIW, the technique you described represents the traditional way that a remote-control’s button events were handled. The drawback is what you have already encountered, namely button events aren’t documented, or self-evident, and must be discovered empirically.

What came afterwards were Device Triggers, button and event entities. Both Device Triggers and event entities reveal the available events.

How many of these concepts are incorporated into an integration is determined by the integration’s maintainers.

3

If you’re seeing the device’s button events in the device registry then it implies the integration supports Device Triggers.

4

Thanks, all good points. I think you accurately homed in on my real question: the only reason I wanted a template to identify all devices was to easily find the device_id for something I wanted to use in a trigger.

So maybe this ends up as more of a gripe than a question; Device Triggers are definitely a pain to use in yaml. Even the documentation for Device Triggers suggests creating an automation from the GUI, then copy-pasting the trigger info into yaml. That’s a weird approach.

After seeing your responses and reformulating my search I ran across this WTH post:

WTH are MQTT device triggers so annoying to work with? - Month of “What the heck?!” - Home Assistant Community

It never occurred to me that the device_id showed up in the URL for the device info page (probably because I’m usually using the mobile app). That’s helpful. And the MQTT INFO link for my Zigbee devices is helpful too, but it still takes some interpretation to figure out what the appropriate actions and other parameters for the trigger should be, and other integrations don’t even have that option.

I think I’ll pop on over to Feature Requests and make a suggestion: perhaps on the Device info page there could be a “Trigger Info” link that contains device_id, other identifiers, and the legal combinations of type, subtype, button_type, and other trigger parameters that are available for the integration/device.

5

They were never meant be composed in YAML. They’re designed to be created via the UI.

They were created to simplify the process of detecting a button event. The user selects the device and the UI reveals all possible button events.

The integration models a remote-control as a device along with appropriate device triggers to represent the remote-control’s button events.

To simplify it for YAML, there’s an entirely different concept known as the event entity. However not all integrations have implemented it.