List of available platforms and events

Hi guys,
could you please tell me how to find a list of all available “platforms” and corresponding “events” ?
For example I found an example of how to fire a notification when HA starts:

- alias: HomeAssistant Start
  trigger:
    - platform: homeassistant
      event: start
  action:
    - service: notify.pushover_notifier
      data:
        message: "HA just (re)started!"

Fine - it works!
Now I want to send a notification when HA stops.
I tried the same code above but changed “start” to “stop” (seems to be logical, isn’t it?) but as you know - it did not work. After many hours of searching through doco and this forum, I found it had to be “shutdown”, not a “stop”.
Is that possible to get a list of those “platforms” and “events” somewhere somehow??

Thanks!

1 Like

This is the most comprehensive list I know of


1 Like

Thank you but I was reading exactly those two pages again and again and again…
Still can’t find what I need there.
In my case, gpbenton, if you wanted to send a notification when HA stops - how would you find what exact event you need? Imagine it was not briefly mentioned somewhere there in a comment section? Would you go somewhere else? Or may be you would check a source code? What people generally do when they just start with HA and have no idea where to go?!

have a look at dev-event, for available events:

1 Like

Seems fairly explanatory to me. What don’t you get?

Home Assistant trigger

Triggers when Home Assistant starts up or shuts down.

automation:
  trigger:
    platform: homeassistant
    # Event can also be 'shutdown'
    event: start

There is the search option within the website, you can use an internet search engine to search only the HA website using the site directive

https://duckduckgo.com/?q=site%3Awww.home-assistant.io&ia=web

or they can ask on this forum.

Looking on the HA front page is also a good idea, although it doesn’t give any explanation of what the event is used for, so you may need to search the website anyway.

Checking the source code is also possible, if you are that way inclined, but I have only done it once or twice in two years of using HA.

I have also turned on logging to debug to see what events are being sent from the log file.

Ok thank you guys for your help - I guess I just need to adapt to the HA “way of thinking”.
Not the most user-friendly system I’ve met :slight_smile: but hey - it is free so no reasons to comply :slight_smile:

Once you have figured it out, you are quite at liberty to submit a PR to update the documentation.:grinning:

I’m having the same reaction to the documentation. It seems to be based on common examples of what could be done, which is great, but it needs to be rooted in a more precise definiton of what is required, what is optional, and what the vocabularies are. For instance, what are the valid platforms? Valid events? In the case of a trigger, say, what is valid and where? Can I mix and match platforms, events, and entities? When can I use fields?

It remains mostly unclear except for the examples in the documentation, combined with is learned from very time-comsuming trial and error.

5 Likes

This depends on the contenxt. For integrations/components, platforms are endless and ever changing. Integrations/components are typically 1 to 1 with platforms. I.E. The RESTful integration/component is configured using -platform: rest in locations that it’s configurable. You can find that information out in the integration/components documentation.

In terms of triggers, they are all spelled out in the trigger documentation. This information is accessable inside the automation->trigger section of the documentation located on the sidebar.

All the core home assistant events are documented. This is also located on the docs sidebar. What you see is what exists. Some components create their own events. Those should be (but not always) covered by the integration/component.

The previously linked trigger doc section covers exactly what you are asking here. Everything on that page is valid. The only ‘ambigous’ trigger is event triggers because users can create their own events. All other trigger types are covered with all required and optional attributes in the examples on that page. There is no reading between the lines. What you see is what you get.

No, never.

I find this funny because the documentation is actually very good at this, just people don’t understand yaml so it looks like the documentation doesn’t cover this.

My recommendation here is to learn and understand yaml. Once you know yaml, the documentation is very clear on how and when to use fields.

Let me show you an example of what I’m referring to. Lets look at the MQTT sensor integration. Lets take a look at a snipit of the documentation.

So by just looking at this section of documentation I can tell you that the yaml will look like this:

device:
  identifiers:
  - identifier1
  - identifier2
  connections:
  - connection1
  - connection2
  manufacturer: foo
  model: foo
2 Likes

Thanks for the educational reply. You make a lot of good points about learning yaml, which I admit I am not there yet. I think having command of yaml could fill in the gaps that I am seeing and make the HA documentation more effective.