WTH is that all actions (eg switch garden lights/pump on, wait 30min, switch Off) in Automations are not state full/persistent?
When I update my Home assistant or need to reboot Home assistant my light then no longer switch off.
Could you please read/store all the actions of an automation prior executing it and make continue the Automation after a reboot? Maybe with an extra (safety)option to make it persistent so the users know the consequences would make users aware of this function. Now my gardenflowers has been flooded multiple times as the waterpump have been pumping whole night long. Same for my flood lights in the garden that burned all night long with 100 watts each. Happened also with my electric radiator. Please find a solution other than creating a separate “timer”(helper) for all automations…
Because the number of my automations will be multiply with 2 with such advise.
And don’t forget the maintainability of those automations
Designing timer based automations is also for a basic user not easy to do so and required a lot of experience.
Thank you for your reply. Thats exactly where the problem lies…this is only understandable for advanced users of Home Assistant. I think it should be easy to use within the GUI (and understand) and so available to all users of Home Assistant…
Timers can be restored after a restart of Home Assistant (I doubt you are actually rebooting the host machine). That is a useful way to ensure your delayed actions occur.
Understood but for a simple/ordinary automation with a scheduled trigger for a pump or light that needs to be on for 30 minutes and then switch off I now must:
create a helper (pump/light timer)
create a new automation that starts the timer (countdown) first and then enable the pump/switch
create a extra (new) automation that starts as soon as the new created “Light/pump Timer” goes to Idle and that will switch of the light/pump.
Sound way too complex to create to me and I think also for many other users. Hope you understand.
Your automation’s design appears to have been based on ideal operating conditions and overlooked to mitigate failure scenarios such as:
the controlled device becomes unavailable
the transmitted command isn’t received
there’s a restart while the automation is executing its actions
there’s a restart when a Time Trigger was supposed to fire
Your suggestion to automatically resume from wherever it was interrupted isn’t optimal; the conditions that originally triggered the automation may no longer be applicable after a restart.
You will have better control by simply adding a trigger to the automation that detects a restart and then proceeds to handle the situation appropriately. I have several critical automations that use this technique to make them more fault-tolerant.
The following (old) post offers a few ideas on how to mae an automation more robust.
The two automations you described can be consolidated into one.
FWIW, an application that requires one helper plus two automations is hardly “complex”. If it seems that way to you then you should know that not all applications can be fulfilled by a single automation. They may require other entities (Input helpers, timers, calendars, etc), possibly other automations, scripts, scenes, etc.
Everything about HA is pretty complex and needs a solid understanding of the underlying architecture, something most ”normal” users don’t usually have.
Well, most of my “non-technical” friends and family who’ve seen my Home Assistant setup and tried it themselves gave up pretty fast. They ended up treating me like their personal tech support for even the simplest things. But yeah, it’s definitely better these days, but still far from easy.
Home Assistant is kind of like Kodi that is aiming to be user-friendly but not quite nailing it. It’s still very much “by techies, for techies,” with a smooth but thin layer of user-friendliness on top.
No one knows it until they learn it. That’s the “normal” state of affairs.
If someone expects to know Home Assistant simply by what they see in the UI, they’re mistaken.
Its vast amount of documentation (same goes for OpenHAB) is one clue that mastering it requires time and effort.
There are alternatives to Home Assistant and, on many occasions, I have encouraged new users to explore them in order to decide which one is the best fit for them. Just because Home Assistant is popular and free doesn’t mean it’s the right choice for their needs (and their available free time for home automation).
If Home Assistant is mainly built by techies for other techies, that kind of approach makes sense. But if it’s meant to target regular home users, that’s a completely different story.
How long it takes to master Home Assistant really depends on how intuitive it is and whether it works the way people expect it to. If it doesn’t, users end up relying heavily on the documentation to figure things out. That’s why good documentation is so important, it should help people quickly grasp the basics and understand how everything fits together. To do this, the documentation needs to be clear, well-structured, and include real-world examples that even non-techies can follow.
Right now, Home Assistant’s documentation leans heavily toward technical details, often requiring YAML knowledge and a deep understanding of how the system works under the hood. For many users, this makes the learning curve feel steep, even though the system might seem simple at first glance. It also doesn’t help that some things can be managed through the web interface, while others still require YAML. That inconsistency leaves users unsure about how to move forward, especially when the documentation feels overly technical and not very beginner-friendly.
What might be improved:
An Official “Cookbook”
A centralized collection of “recipes” for common setups would be super helpful. If someone in the forums says, “Yes, you can do that with XYZ,” there should be an easy-to-follow recipe in an official cookbook. This would also help standardize solutions and cut down on repetitive support questions in the community. There’s tons of great advice and solutions scattered across forums, blogs, and GitHub, but it’s all over the place. Bringing all this knowledge together in one official resource would save users time and frustration.
More step-by-step guides
The cookbook could include more step-by-step guides focused on practical, everyday tasks—like setting up devices, automating routines, or integrating third-party services. These guides should use plain language and include helpful visuals, like screenshots or diagrams, to make things even clearer.
Real-life examples
Adding practical, real-world examples would make the documentation feel more relatable and useful. Show how to set up smart lights with motion sensors, automate turning off appliances at night, or set up energy monitoring at home. Examples like these would really help users understand the possibilities. All of this should, of course, be part of the official Cookbook.
Better Integration and add-on documentation
A lot of integration and add-on docs dive straight into the technical details without explaining what the feature is for or how to actually use it. Starting with a simple explanation of the feature’s purpose, followed by basic setup instructions, would make these docs way more user-friendly. The advanced options can still be included at the end for those who need them.
Task-focused documentation
Instead of just listing features, the documentation should focus on workflows, like “How to Set Up Smart Lights,” “How to Automate Your Thermostat,” or “How to Create a Security Camera Dashboard.” These guides would make it easier for users to achieve specific goals without having to piece things together themselves.
Connecting the dots
The documentation often feels like a bunch of disconnected pieces that don’t really explain how everything works together. For example, setting up a smart plug with a power meter to integrate with the Energy Dashboard involves several steps: Smart Plug Power Consumption > Integrals Integration > Utility Integration > Energy Dashboard. The documentation should guide users through these workflows step by step and clearly show how the components interact. Visual aids like diagrams or flowcharts would make this much easier to follow.
.
It would also help if the docs explained how different parts of the system fit together—like add-ons, integrations, helpers, and statistics. For instance, some key questions users often have are:
What gets saved in the database and what doesn’t?
What data sticks around after a system restart, and what gets wiped?
How do short-term and long-term data storage work, and what are they used for?
And so on…
.
A more holistic explanation like this would help users understand not just the individual features, but also the system as a whole. This would make it much easier to build reliable and efficient setups without unnecessary confusion.
Somewhat OT in this context but still important: simplify the web interface
Many features could be made more accessible through the web interface, so users don’t need to touch YAML unless they want to. While YAML is great for advanced users, most common tasks should be achievable without it. A simpler interface would make the platform far more beginner-friendly.
Ps…
I’ll make an separate WTH with this comment.
It’s an open-source project whose evolution depends on contributions from volunteers.
Have you contributed to the implementation of any of the bullet points you listed? If not, it’s never too late to start and the community would appreciate your efforts. For example, you have made several suggestions regarding the documentation; anyone can submit changes to it.
These types of arguments are the classic “whataboutism” you see in FOSS projects when there’s a lack of solid counterarguments.
Anyway, any suggestion about documentation changes seems to end up in the GitHub black hole where no one seems to care. And honestly, what’s the point of nitpicking the docs for individual components when there are much bigger things that need improvement?
So, where do you suggest these kinds of suggestions should actually go?
Well, that’s not entirely true, since nowadays there’s a commercial side with devs that has a pretty big impact on the roadmap. FYI - Nabu Casa employs approx 33 full-time staff members, including key contributors to Home Assistant with a annual revenue closer to $10 million.
There was no “counterargument”. You made some valid suggestions for improving the documentation and now you can proceed to implement them. The documentation is created and maintained by volunteer contributions.
FWIW, the “classic” in a FOSS project is people having lots of time to offer ideas but no time to implement them, even when they have the requisite skills to do so.
I believe Paulus mentioned that the majority of improvements are supplied by volunteers. You can check the PRs in any given release to gauge the veracity of that statement.
Simply checking the PRs in the docs repo shows this statement to be false.
FYI - Nabu Casa employs approx 33 55 full-time staff members, including key contributors to Home Assistant with a annual revenue closer to over $10 million. In reality, Nabu Casa owns the roadmap, not the volunteers.
You can argue all you want, but the reality is that Nabu Casa, with its employed key contributors, controls the roadmap - not the volunteers who are just unpaid labor and sometimes think they’re the ones in charge.
EDIT:
UPDATE - Nabu Casa employs approx 3355 full-time staff members, including key contributors to Home Assistant with a annual revenue closer toover $10 million.
