But it is silly to introduce a flag that does exactly the same as the state of the automation. If you disable the automation you decrease the workload for HA. Also you can easily see which automations are active. Why would disabling an automation be an antipattern if you don’t want the automation to do anything? Hiding that the automation is inactive inside the automation is worse i.m.o.
But it does depend on the reason, you shouldn’t do it for changes in the state of ‘normal’ entities such as temperature changes, lights being on or off, etc. Just don’t create a binary sensor to say “This automation is disabled”, and then not disable the automation. That is introducing confusion.
What I consider to be an antipattern is to put two separate triggers in one automation, only to then require if statements to make each trigger do something entirely different. Only because you think it is nice to have them grouped together? The name can group them too. The cleanest way is one behaviour per automation, together with all the triggers that may invoke that behaviour.
Your opinions on what’s purportedly “silly”, and how automations ought to work, are contrary to years of tried and true expertise established by the community. However, you are certainly free to express them, just know they reflect a lack of experience with Home Assistant.
So you are saying, because “The hammer” is a clearly established antipattern, you should never use hammers again? The point of antipatterns is to know when to avoid them. Not to be rigid.
I also explained why I think it is “silly” in this case - that is avoid having two mechanisms do the same thing. Maybe I should have avoided the word silly, sorry for that.
And this is not the first time you accuse me of being inexperienced, so by now you must know that is not the case.
You have yet to explain why it is bad. Saying “the community decided long ago” (if there even is such a thing) is not an explanation. Can you point me to a HA directive? I explained my reasons, and have got only disdain in response. If you think that will make people listen to you, think again.
By the way: I avoid scripting in my answers as much as I can by design. If there is a GUI based way I will use it. If there’s not, I use simple scripting constructs. I’m not trying to teach programming skills. I’m trying to point to easy, well understandable ways that also people without programming experience can understand. I’m one of those deadful GUI people
And I hope that when I am no longer there to maintain Home Assistant, my daughter or son can understand what I left behind.
I could explain it but, based on past discussions, you aren’t receptive to suggestions, let alone explanations, that don’t conform to your own limited experience with Home Assistant. The discussion in this thread is yet another example of it.
Feel free to continue creating a multitude of single-trigger automations, that can enable/disable one another, and are limited to only the scripting features exposed in the Automation Editor. If that’s what your experience tells you is optimal and sustainable, I won’t waste time discouraging you from it.
