Thanks for the tip… you’ve found another place where I misunderstood the functionality based on the HA name. To me a “Blueprint” sounded like a “plan from which to build something”, in other words, I figured making a blueprint of an automation I wanted to repeat would help me with the “making multiple copies of this automation”, but I didn’t think it would work for handling the “making changes to the logic later”, which is why I went with Scripts, because to me those mean “reusable code snippets which can be called with dynamic parameters”.
Now that I understand that automations built using a blueprint aren’t just individual independent copies “based on the Blueprint at the time they are built”, but actual connected instances “inheriting from the Blueprint”, I’ll probably rework my logic into a Blueprint.
FWIW, “Blueprint” is a terrible name for this functionality. “Automation Template” would have been perfect, but I guess since the word “Template” was already being used to confusingly describe a computed value, here we are.
EDIT: And I can see why I was confused… even the Documentation for Blueprints makes it sound like they’re basically an “accelerator” to getting an automation set up with the same steps, not a common centralized automation definition that all instances of it will share.
Imagine you want to control lights based on motion. A blueprint provides the generic automation framework, while letting you select one specific motion sensor as a trigger, and the exact light to control. This blueprint makes it possible to create two automations. Each automation has their own configuration and act completely independently. Yet, they share some basic automation configuration so that you do not have to set this up every time.
I guess it’s time to figure out how to contribute edits to the documentation…
Good luck with this. I tried several times and never anything I added was accepted. Most of the time I was told that I had added to much or the example wasn’t needed. I was taught in an earlier life, that if the target reader can’t follow the document then the document is inadequate. Not that the reader of the document was. Most of the documents in HA (in my opinion) assumes way too much knowledge.
the level of required knowledge is mixed between neighborhood sentences.
Another issue I see is, that documentation is not well organized for newcomers. I found it closer to reference documentation, rather than user documentation.
And as reference one is very inconsistent in level of details.
From a new user perspective, there is no top-down structure, allowing to easily comprehend the architecture or structure of HA and its dependencies.
Let me give you a great example of what I mention. The main page of HA documentation. The first subject the reader can see is “Automation”. Second are dashboards and 3rd are Voice assistants. Two pretty advanced topics on the very top.
Maybe I opened the wrong page. But this is what Google proposed to me on “Home Assistant documentation” query
I don’t think it has ever been or ever will be a user manual where you can go from step 1.
That kind of documentation will be way to hard to build since each installation and devices will be different.
And even if it’s done then everything will need to be looked through on each release.
Now “only” the updated integrations need an update.
That’s been commented on quite a few times, not just here, and I know I’ve banged on about it to Missy (most recently, many others before this). They’re (well) aware of this, but it’s just one of a great many things on the list so I don’t know when it’ll get addressed.
Yeah, amen to that! It’s probably hard to find a worse combo than YAML/Jinja/{%%}. Maybe some esoteric programming languages like Befunge or Brainf*** could top that.
[*** It seems you can’t write the full name of Brainf*** without being caught by some automatic censorship algorithm.]
I know this is an old topic, but I found it while searching for an answer to something that was frustrating me (“how are scripts and automations different?” I still don’t really know!), and I want to add my thoughts if that’s alright.
I’ve been using HA for about 6 weeks. I’m working on a proof of concept for a more sophisticated setup, and while I’m blown away at the breadth of what the system will ultimately be able to do, the problems I’ve been frustrated by are mostly in the realm of “things that seem like they should be pretty simple, but are made rather difficult due to taxonomy or UX choices.”
I think that a concrete example will help. Earlier today, I was trying to create a set of buttons to pause, stop, and add/subtract time from a stopwatch/timer from a dashboard – the kind of thing I can set up on its own home screen on my smartphone in a handful of taps. A stopwatch is one of the built-in Helpers in HA now, so it seemed like this would be a pretty quick job.
Problems I ran into right away:
The dashboard card creation UI itself is quite unintuitive and fussy, especially when dealing with stacks (which I have found crucial in controlling overall layout). Once you create a card inside a stack, the card type is not apparent by its visual representation and is not named in anyway, nor can the type be changed (unless, perhaps, you go into the code editor). Heading / title sizes are all over the place, and there seems to be no standard for when/whether an entity’s title will show on a card, so you often end up with nested sets of titles 3 layers deep by default. Cards in a stack just appear as a set of numbers, and you have to count rows to know which number you intend to edit. It would be a huge improvement right out of the gate to somehow highlight the card/element in the visual representation of the stack once you are viewing it or have started editing it, just so it’s immediately clear what you’re working on.
Adding a button as a Button type card, an Entity type card, or as one entity in an Entities type card all expose totally different options. The fact that the latter two are different is particularly unintuitive.
There are too many places to edit the name & icon of an entity, and it’s not clear that when you edit it on a card you’re only editing it for that card. Relatedly, entity names tend to show up as blank by default in a dashboard card. I’ve figured out that this means they will take the name for the entity that’s already been set in the entity settings, but this is very unintuitive, as a blank field usually implies that nothing will be shown. (And there are a lot of options to show/hide various names & titles of things.)
Different option sets exist for the same unit/thing (I want to say “entity” but that has a specific meaning in HA already ), and it’s not very clear what distinguishes them or how to access them consistently. For example, an automation has “Settings” (accessed via the “…” menu in Automations), but its primary attributes are accessed/edited by clicking on the row itself in Automations. Confusingly, you can also find an Info screen about any given automation through a few different routes (e.g. “Entities” search), and from that screen, Settings is accessed with a gear icon while the automation’s primary attributes are edited via the “…” menu – in some ways the opposite of how you access these option sets from the Automations screen.
Buttons themselves are needlessly confusing. The fact that a button’s state is a timestamp is, shall we say, not intuitive; and the fact that you can’t simply add “button pressed” as a trigger to an automation is a big missed opportunity, as this seems like the most intuitive expression of a super common need.
“Devices & Services” and “Automations & Scenes” should be options for the sidebar. They are the items I access the most frequently.
How a user would know to click & hold “Home Assistant” to remove/reorder the sidebar items is beyond me. This is a common need and should not be hidden.
Ultimately, the (seemingly) simplest way to set up my stopwatch/timer changes appeared to be:
Set up an automation for each change (add time, subtract time, pause, resume). Make the Add and Subtract automations triggerless. (Very unintuitive!)
Create 2 buttons and 1 toggle / binary switch
Add each of the buttons as Button cards, and set their Tap Behavior to Perform Action → Automation: Trigger → (Choose Entity) → the corresponding automation. The toggle’s behavior stays its default.
Add the timer itself as the only entity in an Enties card. (When I add it as an Entity card, none of the display options shows me the countdown / current time remaining – the closest I can get is the default “duration” i.e. start time.) {Update: I’ve found a Github topic on this where the conclusion is that this is “not a bug” because this is how Entity cards work and what they are supposed to display etc etc. This rubs me the wrong way. Considering bad or counterintuitive UX to be “not a bug” and therefore not a problem worth fixing is very much a programmer mindset that invariably leads to – you guessed it – bad UX.}
To be quite honest, I expected it to work a lot like my phone stopwatch. I was hoping for the process of adding it to my dashboard to look like this:
Add the timer as an Entity card.
Check/uncheck visibility of various built-in entity options: pause, restart, add time, and subtract time.
Tell everyone I know how intuitive and user-friendly Home Assistant is.
As it is, right now, I can’t recommend HA to a casual user. Not because “advanced functionality requires complexity” (which is a sentiment I have read a lot), but rather because simple functionality also seems to entail a high level of complexity for the user.
I hope the Home Approval Factor improves over time and I’m glad that HA seems to be focusing on it.
Can you be more specific about the problems that might arise, or how I might trigger the add/remove time functions from the UI without button entities?
General unreliability of the automation, usually manifesting as random failure to execute any actions when fired by the automation.trigger action.
Put your action sequence in a Script, call that script as one of the card’s actions. If you set up the script with enough forethought, you may only need one script to services all your timers and button functions.
In the simplest terms, script is like the actions part of an automation. So the automation has trigger(s), condition(s) (optional) and action(s). Script is just the last part.
Because of this, the script will not ruin by itself, something must start it, either it has to be started manually by user input, or an automation may start it. On the other hand, automations are meant to stay on their own (hence the name), when something happens (the trigger).
Have you tried using the relatively new sections view type? It may be a bit more intuitive for you, it supports drag and drop. It has it’s own limitations though.
In general, I would say the task you started with is just not a typical task for home automation system. The main purpose is to manage and automate devices. But you started by adding a virtual stopwatch.
But also I have to say that in general tasks related to timers, custom delays etc. could use some improvements in HA. Some things have already been improved, but common tasks related to this (like: turn this device on for X minutes) are far from as easy to do as in some other smart systems.
Regarding the two settings groups you mentioned, the fact that they are the most commonly used is why they are at or near the top of the list of settings pages. I really don’t see the benefit of moving them elsewhere.
The benefit would be that the left-hand menu offers immediate (one click) access; this is why top level menus are usually designed to contain the most frequently accessed items. Having to go to Settings first doubles the clicks.
“Settings” is also (in most apps, OSes, etc) a term typically used for relatively persistent & infrequently accessed configuration options.
I’m not a UX professional, but I do know that menu design is about both 1) giving users easy access to what they want and 2) showing/guiding new/infrequent users to the parts of the app they’re most likely to need. Placing the biggest building blocks of HA inside “Settings” falls short on both fronts IMO. To take another example: I’m not privy to the analytics that HA gets from users who opt in, but I’d wager that items like Tags and People (2 clicks each) get used less frequently than Scenes (3 clicks) or Helpers (3 clicks).
Thank you! I think I understand the distinction better now and I am starting to transition over to making more things Scripts instead of defaulting to making triggerless Automations (since apparently this can cause issues).
I guess this sparks another piece of UX feedback: If the only (major) conceptual distinction between Scripts and Automations is how they are triggered, why not just get rid of the confusion and merge them into one type – maybe we can call them “Tasks.” Tasks may be triggered by external events (like Automations), may trigger other discrete Tasks, or may be trigger-less / triggered manually (by another Task or by a button press).
Maybe it will become clearer to me as I go along that there is some UX reason for making the Automations/Scripts distinction, but so far it just seems to me like a legacy of how they were initially built and not an inherent requirement of the system.
), and it’s not very clear what distinguishes them or how to access them consistently. For example, an automation has “Settings” (accessed via the “…” menu in Automations), but its primary attributes are accessed/edited by clicking on the row itself in Automations. Confusingly, you can also find an Info screen about any given automation through a few different routes (e.g. “Entities” search), and from that screen, Settings is accessed with a gear icon while the automation’s primary attributes are edited via the “…” menu – in some ways the opposite of how you access these option sets from the Automations screen.