Prebuilt automations would be in line with @balloob’s original vision. In an ideal world I would have a ML powered automation for specific scenarios. For example, if there was a ML based automation that I could point thermostat and various temperature sensors to; it would automatically learn and adjust the temperature exactly as we want it.
I’ve seen this on other platforms and always leads to an endless line of feature requests for the creator. Since everybody needs something different in the end.
I rather see the current automations editor (GUI) be changed to something less nerdy and more intuitive.
5 Likes
I agree.
I use Node Red because its good, but also because I find HA automations confusing enough that I can’t be bothered. Inbuilt, inactive automations would be great.
I am struggling to see what you mean? How can it be prebuilt when I have different lights (for example) to you?
I think it’s like this:
Light automations: choose lights, choose motion sensors or switches and done…
So instead of the IFTTT like editor whe have now (which serves pretty much the whole basic scope of what you can think of), it’s more refined for particulair uses.
Another example is a security automation: Choose contacts, motions, locks and maybe a keypad or something like that and done. The rest is prebuild.
1 Like
Have you tried the almost prebuilt automations? The one you get when you go in the automations editor and are give a number of choices like"turn on lights at sunset"? It pretty well does it for you, you just need to choose the lights by area, or individually.
2 Likes
This sounds good in theory, but I think humans are just too unpredictable for ML processes to work out when to set temperature to which level etc. There are just too many one-time occasions in a “normal” human life that would render ML useless in my opinion.
I’ve never seen those. Though I don’t use the UI to make automations. I find it easier to use yaml in the end. Tried Node-red, but was soon back to yaml and some basic templating.
It was never built. Still on some todo… Shared it as an example of how it could work.
2 Likes
Not trying to be sarcastic, but tell that to Nest/Ecobee/Any other learning thermostat. It’s the 80/20 rule. If the ML works 80% of the time, then it’s very useful.
Yes. I have tried those and they are a great start. I was thinking one level above that. For example, what if there was a prebuilt automation for turning on lights at sunset and sunrise and all I had to do was add a list of lights without trying to understand what trigger is, what conditions are etc. Can help newbies who are starting out.
1 Like
I love this idea… Was it not built due to prioritization or was that not considered a good use case ?
It’s not impossible but it would require some effort. If the product had a UI-based way to share and then install automations it could have some logic in there about entity types.
For example such an import process could identify references to lights in the shared config and instead of importing it exactly as is instead prompt you to replace any references to light type entities with valid light type entities in your HA before importing. It would know the automation would still work since all light type entities have the same basic featureset but now the automation is configured correctly for you. This could be repeated with all entity/service types (switch, media_player, notify, etc.)
I almost hesitate to bring it up now given the topic got so loaded but this use case was one of the pros I brought up for switching from YAML to UI-based config. When the only way to share automations is via YAML then you have no choice but to do all this fixing yourself via find and replace. But with a UI-driven sharing and import process then the tool itself can build in intelligence about entity types. It could walk you through this process by identifying entities and asking you to replace them with equivalent entities in your config to ensure all dependencies are satisfied.
A tool like that could even go further and identify integration dependencies during import when specific services are in use and ask users to configure those before import as well. That’s effectively what IFTTT does when users share and reuse applets. They don’t have the device/entity type concept so they work purely in integrations and track them as dependencies.
The idea would be that you define automations with placeholders, and for each placeholder you will define the requirements (ie lights, persons etc), and then also define a summary string (translatable) that can be updated with the names.
Then people can share their templated automations easily.
Never happened because of time. Maybe 2021?
2 Likes
The iOS shortcuts app (and its gallery) is a good example of how sharable automations could work. Like Balloob suggested, placeholders are used where specific things (entities, etc.) go, then you fill in your specific when adding a shared shortcut from the gallery. If you have an iPhone, search the gallery for “Open App on Apple TV” for a super simple example.
1 Like
That makes sense. The downside there is that people would have to take specific actions to make their automation shareable by templatizing it so to speak. That might limit the amount of sharing since not everyone will be willing to put in that time. But on the other hand what does get shared should be higher quality and quality is probably preferable over quantity anyway.
Good to know you’re thinking along those lines too. Not stressed about the timeline. It’ll probably take me that much time to make my automations 100% defect free anyway 
1 Like
I think actually that people will be inclined to make them with placeholders to begin with, so they can also easily reuse them in their own home. Maybe you have 5 motion-light related automations that you need to fine tune with some custom logic and want to share that.
(but it will need to be easy)
6 Likes
Would it be difficult to have built in automations at least for most common devices say per room level thus the user would only need to define which device is which? There are several basic automations that could be standardized for a set of devices (although there are very different examples of implementations by several users).
Like, in order to control lights, after defining a room, the user would relate (at least) light, motion sensor, switch, light sensor, door/window sensor, etc. for the respective room and there would be automations already taking these inputs. Basic automations would be something like turn on light when switch is pressed (regardless of time of the day) and set a timer to turn it off or turn on when motion sensor triggers (case the light level from the light sensor is low or if sun is below horizon), ignore the motion sensor input case the light was already turned on from the switch and the remainder of the timer from the switch is above the nominal timer for the motion sensor, etc. Then have input numbers to control the amount of time the light stays on, custom schedules, random triggers (to deter thieves case house mode is set to away), input booleans to control circadian light levels.
Or, for the HVAC component bake in the automations and only have the user to define (alongside current used inside temperature sensor) also schedule, door/windows sensors (to generate warnings case windows are opened), outside temperature (to prevent freezing), automate away function (based on the motion sensors), power consumption sensor (also can be used as feedback for commands sent to the device) etc.
1 Like
Something like this will get there partially https://github.com/home-assistant/architecture/issues/340
1 Like