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
I don’t think anyone should be aiming for 100% automation. You just want to get close and have a system robust and user friendly enough to handle the few exceptions.
To put it simply. You want your lights to turn on at the correct brightness almost every day of the year. But during a party it is fine if you adjust them manually, as long as you don’t have to fight the automation.
3 Likes
If I’m not aiming for 100%, why should I need ML at all and not continue with my working automations? To enable ML, I would need to disable all my automations an do everything manually for at least 1 year to gather sufficient data, wouldn’t I? I think my life is just too unpredictable to get the desired results from ML (at the moment).
Don’t understand me wrong, I’m definitely for ML for Home Assistant at one point, but not now. I’d prefer to have the focus on “finishing” HA, before starting with ML. Just my two cents.
We’re pretty far from using effective machine learning for HA imo, but not necessarily no. It would help to have some historical data to set it up of course, but a good ML algorithm will correct itself based on your actions.
But you don’t want to push it to the last 100% in general, because then it will tend to ‘overcorrect’. For machine learning to work I tihnk you need to accept a little bit of noise.
So what is the advantage then? I expect ML to be way more effective in the end in capturing more complex behaviour and to work with relatively little setup. It will cost you in ‘learning’ time though. But for my home at least, a lot of behaviour has proven to be quite difficult to catch in simple automations. It should become as simple as picking an algorithm, tweaking some variables and picking the involved entities/devices.
Bayesian sensors have already proven to be more effective for me for instance even though they are very crude, but need some work before they are generally usable I think. (I’ve tried, but I need more UI-coding knowledge, but I’ve got the ML part with active learning somewhat working for a prototype).
Oh, and to add, since this was a bit of a tangent, it is my personal believe that a home can never be fully automated so you shouldn’t try/aim for that. What I mean is that cases were the automation doesn’t work have to be handled well, because they will always happen and are integral to the experience. unexpected things WILL happen and ML isn’t magic.
1 Like