Home Assistant restart notification

Tags: #<Tag:0x00007f32702fe8e8> #<Tag:0x00007f32702fe708> #<Tag:0x00007f32702fe5c8>

Github Gist: https://gist.github.com/gregoryduckworth/c41e0abced1a3001f0e038ac52890cab

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

This is a simple notification that I use quite a lot when developing/creating items on Home Assistant that require a restart. So rather than watch HA come back up, I prefer getting the notification on my phone which then prompts me to go back to HA.


This blueprint can generate multiple automations that trigger when Home Assistant starts.

Home Assistant has only one startup event so why would anyone need more than one automation to announce it?

I personally only use the one automation but that isn’t the case for everyone.

My motivation for making this was to play around with blueprints and I moved something that I already had as an automation and thought I would share and give back to the community.


How do you envision someone will use more than one instance of it?

If I had to hazard a guess it would be to multiple devices, for example a phone and a tablet, where someone wants the notification to be across both.

Again, I’m only sharing this as I find it useful and wanted to play around with blueprints.


Then it’s simpler (and more efficient) to put multiple notifications into one automation’s action instead of creating a separate automation for each notification.

Effectively this is like creating three separate automations to control three lights, when all three can be easily controlled by a single automation.

1 Like

Fair point but you can also create a notification group which would be reusable and send the nofitication to that.

Exactly and it obviates the need for the additional overhead of the blueprint. It’s a one-off automation without the need for a frontend UI.

A blueprint is a useful new feature but not every automation benefits from it.

1 Like

There are lots of benefits to blueprints. Sure, repeatability is one of them, and probably the most powerful. But another aspect is the easy nature of installation and configuration.

Even if ONE person would only ever have ONE instance of the automation having it as a blueprint means all configuration of the automation is handled in one location (though, the fairly recently added variables feature can do this too in most cases). It also fosters community as I’m sure there have been many users wanting to contribute to Home Assistant but not well versed enough in Python or able to get over the Developer hurdles to do so. This allows them to contribute.

Sure, we don’t NEED 50 different varieties of “motion activated lights”, but, when the dust settles, hopefully one will prevail and be maintained and updated. And, when Home Assistant adds “updating blueprints by URL” to the feature list, those bug fixes and feature enhancements make it to the end user. Even something as simple as this blueprint, having it as a blueprint exposes this as a functionality that users may not have thought about before.

Additionally, while, yes, multiple notification actions in a single automation would be the most efficient way to go, having a separate automation for each makes the blueprint code simpler and it allows users to easily turn off (or delete entirely) one notification without turning off the others

I’m not advocating turning EVERY automation into a blueprint. There are certainly some parts of my system that are so specific to me no one else would ever use them as they are, and so specific to the use case that even I won’t repeat that functionality in another location of my home.

All in all, a blueprint just makes it easier. Sure, there may be a bit of additional overhead involved because it’s a blueprint, but, if they were written the way I think they were, that overhead is only at startup/reload and, for most people, will be unnoticeable.


This seems bass-ackwards to me. The focus shouldn’t be on simpler blueprints but simpler automations. Otherwise, you’ve advocated for turning on 12 lights with 12 cloned automations, because it makes the blueprint simpler and “easily turn off (or delete entirely) one notification [light] without turning off the others”.

There are good use-cases for blueprints; this one is an anti-pattern.

1 Like

I agree, I think that blueprints should be complicated (where appropriate) so that the resulting automation is comprehensive and easy to understand.

1 Like

I agree with both of these points. I mean, nothing should be more complicated without reason. But, if a more complicated blueprint leads to an easier to use automation, then that’s the road that, ultimately, should be taken.

But, in the case of this particular automation, there’s only one input that doesn’t have a default: the notify service to use.

So, there are two ways this can work:

  1. I add an automation with this blueprint three times, because there are three people in my house that care about Home Assistant starting up. Adding a user means adding another automation. Removing a user temporarily means turning off the automation. Deleting a user means deleting the automation.

  2. with modifications to the blueprint, I add an automation with this blueprint once and add all three notification services to it. Adding a user means editing the automation to add one. Removing a user temporarily isn’t possible (without even more modifications to the blueprint). Deleting a user manes editing the automation to remove them.

These are both easy to understand and easy to use. Option #2 means that if I’ve customized the “title” or “message” I don’t have to put those customizations in with each automation. Option #2 also means I CAN’T customize the notification sent to each device. Option #2 also means I can’t temporarily disable a single notification service.

There isn’t a right answer. Each methods provides different features and makes certain tasks more difficult while making others more complicated. In this particular case, most people won’t need more than one notification endpoint. And option #1 is a bit more flexible and much easier to write (on the blueprint side). So, I’d go for option #1. But option #2 would be fine as well (and could still be used like option #1 if desired).

Not exactly. I’m saying each use case deserves different treatment. In the case of “home assistant startup notification”, for all the reasons above, multiple automations is just fine in my opinion. In the case of motion activated lights, for instance, I’d have to setup the motion portion of the automation for each of the 12 lights if it was 12 different automations. That’s tedious and makes the blueprint a lot harder to use. So, in that case, a single automation handling multiple lights is the only thing that makes sense. If a user sometimes wants to to turn off the automation on SOME of those 12 lights, then they can still make two instances of the blueprint (with the same motion triggers on each, but different lights) so they can easily turn off a portion of them.

Every case is different. In this case, having a different automation for each notification endpoint makes sense to me. But, if the author changes it to accept multiple endpoints, I can still use multiple instances of the automation if I choose, so there’s no issue there.

My reference to 12 lights was a metaphor. This blueprint literally does generate a separate automation for each notification. All of them are triggered by precisely the same event. That’s just clumsy.

In the two years I’ve been participating in this community, I have never seen anyone advocate for writing cloned automations (all have exactly the same trigger and nearly identical actions). Yet now that blueprints have arrived it’s considered to be an acceptable practice?

There are good applications for blueprints; this is not one of them.

1 Like

Hopefully, you grok at least a little Python, because it’ll make the following point of view a bit easier to understand.

Blueprints, are kind of like Python functions: They are named things that take several inputs to perform an action. So, here’s very simple pattern to encapsulate logic.

def print_thing(thing):
  print(f"From Print Thing {thing}")


It could also be done this way:

def print_things(things):
  for thing in things:
    print(f"From Print Things {thing}")


Neither of these is “better” without context.

The overhead in Home Assistant is negligible between two automations with the same trigger and a different action in each, vs one automation with a trigger and two actions.

Actually writing cloned automations (i.e. without a blueprint available) was never advocated because it’s cumbersome and requires a lot of extra work if modifications are ever made. In the above Python example, imagine if print_thing was more complex, and then imagine if we didn’t have definable functions. Cloning it would look like this:

thing = "a"
print(f"From Print Thing {thing}")

thing = "b"
print(f"From Print Thing {thing}")

thing = "c"
print(f"From Print Thing {thing}")

But, not cloning it would look like this:

things = ['a','b','c']
for thing in things:
  print(f"From Print Things {thing}")

In this case, the second version is less verbose and much easier to modify. So, our advice was always “don’t clone the automation, add a trigger/action to it instead”. However now that we have blueprints (functions) that advice can change if it benefits readability, functionality, or ease of development/troubleshooting. And, in some cases, it will.

I don’t think a python function is an apt metaphor for blueprints. A blueprint is effectively a template to generate an automation (I believe when the concept was first discussed it was referred to as an ‘automation template’).

If you use a single blueprint six times, it generates six separate instances of the same automation, only the inputs differ. To be more precise, the data in the six separate instances is just the inputs and a link to the blueprint’s automation. Nevertheless, there will be six separate instances.

That might be perfectly reasonable for certain applications but, in my opinion, not this one.


I see your stance. I really do. And I’ve seen you around these forums enough to respect you and your opinion. So, I guess we’re just going to have to disagree on this particular point.

I’ll like your last post but I’ll post this in lieu of also giving every one of your posts in this thread the same love.

I completely agree with you. I’m seeing this all over the blueprints forum. And there are even people asking for the same blueprint to cover multiple automations even if those automations are literally identical except for the inputs!

It makes no sense. What’s going top end up happening is that we will have thousands of pretty useless blueprints to wade thru and almost every one of them will be for one-off automations that don’t justify a blueprint.


I just want to say thanks for this blueprint!
For all people nagging around: If you don’t find it useful, it doesn’t mean others won’t eventually benefit from it. Yes, I won’t add this more than once.
But the blueprint made me do the automation I wanted to to for weeks but didn’t (because before blueprints I just used Node Red and this didn’t work out when I first tried). It just makes things easier and me happier!

Thank you for confirming what was predicted.

It takes about the same amount of time to create this automation in the Automation Editor as it does filling out the fields in this blueprint.

This is one of the easiest automations to create because the Homeassistant Trigger has only two possible events: start and shutdown (choose the first one). The action is just a matter of choosing which notify service to use and supplying a title and message. The steps involved are almost identical to using a blueprint.

1 Like

Why criticize someone who spend his free time providing something to the community, just because you don’t need it? That’s just bitter. Just scroll past it thinking, "already have this, don’t need a blueprint)
Also think ahead if what blueprints can be in the future: some kind of store for automations. Search for blueprint and add it to your install. Way easier then using yaml. The more (non redundant blueprints, the better).
Merry Christmas time to everyone.