Create new automations could be made a lot simpler by setting obvious defaults in the front end.
I would like to propose the following:
after entering a single trigger, the conditions and actions when added should default to whatever the trigger was. For example if I set a trigger for a switch state, then add an action, the default action should be the same as the trigger. Now this is not so useful until I select “Choice” and then the fisrt option appears and I have “State” or whatever set as default. Now here is my second suggestion.
Setting defaults for choices. If the user sets option 1 to state “on”, its not rocket science to guess that option 2 will almost certainly be state :off", and vice versa. These could be filled in as defaults.
So now adding a switch automation becomes really easy.
Select switch state as trigger, go down to actions, click on Choice, the default is switch state
set an action for state “on”
add another option, the default is already state “off”, so I just add the action
done
Since about 4 out of 5 of my automations are setting switch on → action / switch off ->action,
at least for me it would save the effort of having to click on state, select the entity, type in on, then select state again, find te entity again.
Not sure I understand this, what if I use a lux / light sensor trigger to then action my blinds - the two have nothing to do with each other directly, what your suggesting (i think) is that the action fields self populates based on the trigger! What if I have multiple triggers of time, temp, lux value - whats going to happen then? There are surely way to many variables for anything like what your suggesting to be viable.
I did include in the description that this would only apply when there was a single trigger defined. In that case it is pretty common, I would think that if the sole trigger is the state of the switch, the next step involves assigning actions to the on and off states. If there are multiple triggers, then I agree, it doesn’t make sense. As I said, this is aimed at the common case where an action is assigned to switch “on” and another to switch “off”. The majority of my automations are like this.
You could also make it only do this when there are no conditions. Definied. Singel trigger - state of a swittch, no conditions, and the user clicks on choice…it’s almost certain, what he intention is.
To clarify further I was refering specifically to Switch Device, not binary toggles in general. I agree that wouldn’t be very helpful. But fort the specifc case I am conseidering it would be an obvious time saver.
Not really seeing why a switch is special from other binary entities. But as an aside if you have a whole bunch of automations that are basically the same thing (extending the actions of a switch from the sounds of it?) then make a blueprint. That’s kind of their whole point.
Yes, making a blueprint was a good suggestion. I hadn’t really looked at them much. I always assumed hey were intended just for exporting and importing things. I suppose that is because when creating an automation it always asks if you want to use a blueprint and if you click on yes it opens the website.
Until now it was not apparent that they could be useful solely for internal purposes too
Before this get closed, perhaps I could just quickly mention two other things - I still don’t fully understand why when making a trigger just for state, it is necessary to manually edit the script and change to To: to null. What I read was, if you don’t do that, then the automation also checks attributes. This makes absolutely no sense to me. Surely it should be the other way round, the default should be to only check the state since that is the only thing mentioned in the automation. Secondly, there is seemingly no logic behind setting something to null, in order to affect something else (i.e attributes), its also meaningless, how can the state become null, that isnt even a valid state. If To is null, and I don’t enter the From state, then what is the from state ? Just none-existent ? Or Any state ? You see how it makes no sense. Even worse, as soon as you do this you can no longer edit in the visual editor. So basically its a nonsensical, no obvious workaround for a non-obvious problem that shouldn’t really exist, and the workaround actually breaks functionality.
Secondly, and this caught me out a lot at the beginning, and I have seen people asking about this on discord…when you start making an automation, if you click add action and then dont fill it in, then go back and alter triggers or conditions, you get some cryptic error message about integration not found…this is entirely due to the halfway added action left at the end. But the error message is so utterly cryptic, until somebody pointed this out to me, I had no idea what was causing it. So really that ought to be fixed.
