Github Gist: https://gist.github.com/gregoryduckworth/c41e0abced1a3001f0e038ac52890cab
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.
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.
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.
I agree, I think that blueprints should be complicated (where appropriate) so that the resulting automation is comprehensive and easy to understand.
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:
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.
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.
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}")
print_thing("a")
print_thing("b")
print_thing("c")
It could also be done this way:
def print_things(things):
for thing in things:
print(f"From Print Things {thing}")
print_things(['a','b','c'])
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.
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.