Neither - Homeassistant Packages with VS Code…
By mass-edit are you implying needing to edit a bunch of similar automations or scripts? Never.
I rarely use the UI. I find for simple, no all, automations it’s easier to edit the YAML. 95% of the time I just go right to the YAML. And most of my config is in packages as well.
Please post an example (in YAML). Thanks.
Software engineer is a job title - whilst I agree that a significant chuck of software engineers can code (some can’t 
).
I believe that anyone with a “tinkering” mindset can pick up enough coding ability to be effective with home assistant.
Being effective is going to be a reflection of the persons skill, desires and time investment - someone who doesn’t have any of those 3 will likely be able to create a bunch of simple automations that meet their needs. Sure they may need to put a bit more time into organizing them (giving them descriptive names) but thats okay - works for them.
If someone has a strong programming aptitude or they are a professional software engineer, they may choose to structure things differently.
In my own case:
- I make heavy use of variables - one of my automations has 118 lines of variable declarations in a 178 line automation.
- I have moved all of my helper declarations to YAML - I have roughly 1 helper for every actual device.
- To manage this style, I need to make heavy use of naming conventions - I use prefixes and suffixes.
- 1/2 of my automations have no branches (loop, if, or choose blocks).
- I don’t use any wait for triggers
- I don’t use any timers
- All of my delays are handled by template binary sensors with
delay_onordelay_off - I only use a few sub second waits to synchronize IR codes.
- Other than when sending IR codes (which can be up to 2 seconds) all automations exit immediately - there are no waits.
- I don’t use any blueprints - primarily because I need to define helpers inside them and that isn’t supported yet.
This comes from some philosophical choices I have made with how I want to implement my HA deployment:
- Configuration is done in YAML - variables blocks are expressed “raw” in the YAML for an automation, so there is no boiler plate.
- State has to be done in helpers - I am not going to have a long running automation just so I can hold onto state.
- I can use any editor to cut and paste helpers, if I need to add a bunch of new ones for something - this typically only happens with lighting as most other functions are more unique.
- I don’t want to have to deal with race conditions - I can usually assume each automation is the only one running - since they all exit so quickly.
1 Like
You side-stepped my question. Why is complex more advanced? Take this example:
I would consider this a sophisticated automation, but it’s very simple - so much so that I suspect a lot of the “complicated is good” crowd dismiss it.
Going back to your original post, I suspect that some of the issues you’re discussing come from this…
I know you wanted the OP to answer, but I would say this:
Complexity is usually indepedent of other factors:
- Good code can be simple or complex.
- Bad code can be simple or complex.
- Complex code may be easy to maintain or it may be a complete nightmare.
I would say that someone is using HA in an “advanced” way when they use thier knowledge of and skill with HA to reduce the ongoing maintenance costs / improve the readability of their automations.
I don’t see any value in trying to cite specific examples of “advanced usage” because everyone will have a different opinion.
TBH - I think there is a sweet spot (likely different for different people) for each of:
- The total number of automations.
- The amount of complexity to add to a single automation.
- The amount of branching in an automation.
- The amount of state stored in helpers.
- The usage of naming conversions.
I doubt the sweet spot for the number of automations is 1, I also doubt it’s > 100 however the bigger your setup the more likely your sweet spot will be a bigger number.
1 Like
You can’t have it both ways. Templates were added to give you the power to make complex automations.
Or, arguably, make complex automations simple.
1 Like
Exactly!
Templates are a particularly good way, for my interests, to have LLM write some code without giving over major pieces of system design. I don’t care to learn enough jinja to do highly specific formatting, and LLMs are good at that sort of function.
For example, audio weather forecasts can often include a lot of unimportant wind information. I have an LLM write the ninja to include the weather output I want. But if that black box of ninja breaks it’s not confusing where the problem lies.
My approach overall with automations has become more and simpler rather than fewer and complex. My concern long term is the number of helpers I have created. I don’ like having so much code not in the primary YAML automation.
I’ll add that I find the changes to the visual editor to be terrible. Conditional logic is a mess IMO.
You can (I do) create all helpers from Yaml code - so you don’t have to create any helpers through the UI.
This is one of the reasons I try to keep branching to a minimum, the other being that branching is what makes code difficult to read - even when the presentation is nice.
I’ll bring up Packages one more time. I really didn’t like having automations in one place and helpers elsewhere and no way to really track them together. Very messy.
I use packages so I can group all the related helpers, sensors, automations, and scripts in once place. I then name all the entities with a common prefix which I use to exclude (entity_glob) from recorder and logbook, and just include specific entities I want to track.
Then there’s those dangerously addictive triggered template sensors that really simplify, if not eliminate, the automations. Because of that, I think I’ve now replaced about four integrations with YAML in packages – which means I can easily customize them (since it’s my code).
I think the dev team has done an amazing just on the front end updates. Again, I rarely use it because small automations are easier to bang out in YAML and larger ones are just to hard look at in the UI.
One gripe is it’s now generating code like this:
triggers:
- type: turned_on
device_id: 1ef9ee22b1fbe5c3fddbd0edcf9a8a5f
entity_id: 8b7b0dd1a21f2baa31405346546d694b
domain: light
trigger: device
Which:
- if you now the id of the entity why not translate that into the actual entity id?
- what happens if you replace that device and the IDs change?
- hard to know what is happening when someone posts the YAML here for help.
Call me old fashioned, but this seems easier to read and won’t break if the device is replaced or excluded/included again.
triggers:
- trigger: state
entity_id: light.kitchen_sink_light
to: 'on'
But, I know not everyone uses HA the same way.
5 Likes
The “intended” way is in my first post, the guide. I’m trying to get your opinion. If you said you want a bunch of simple automations, then each automation probably has 1 job, and you’re minimizing the number of triggers in each.
Like you’d have a separate automation for lights on versus lights off.
OMG no. I’m a software engineer by trade and used to code 16 hours a day for 10 years.
I use Home Assistant to get away from self-managing code. I’d rather let Home Assistant natively handle as much as possible.
But… I’ll look into packages. I was looking at your link the other night, but I’m not yet understanding.
To me, this is insane! Who wants to look at YAML ever? I use it for copy-paste and some small fixes, but I never use it to do any automation work in Home Assistant, and I’d hope others don’t as well, but that’s not what I’m seeing in responses.
Seems like Packages are where it’s at. I’ll have to check 'em out.
If I could use YAML for helpers, it’d be easier to create them as part of automations. It’s a slog creating Helpers in the UI because there’s no copy-paste, duplicate, batch-process, etc. I have to do everything manually by hand which makes me less likely to wanna do that.
I thought that was the case, but if most Home Assistant users are like the guys replying in this thread, I’m absolutely wrong in my assumption. People are actually well above me in terms of ensuring little to no copy-paste occurs. I’m actually the outlier using the UI and trying to make everything work as natively to Home Assistant as possible.
I’d love to see usage statistics.
I wanna answer your question here, but I’m not sure what’s being asked 
.
Complex allows you to avoid copy-paste code. It’s doesn’t have to be more advanced.
Your motion automation is dead simple, but it has no extra features:
- Does it handle button presses? My automations do because you need an “out” to disable occupancy sensing controlling the lights, and that now requires at least 2 button presses (on and off) and a helper to maintain the state of “are occupancy sensors controlling the lights?”
- Are you handling changing the color temperature throughout the day in a separate automation? If so, how do you have so many automations and ensure they don’t step on each others’ toes? “Restart mode” works well if your triggers for on and off and dim are in the same automation. If you separate them, how does it cancel the previous command?
I think we can agree that having a native control from Home Assistant is always gonna trump a template.
“If the date is between x and y, then do this.” → This isn’t possible in Home Assistant today, but as a template, I have to read and understand what the template is doing, I can’t say: “this is a date condition”.
Templates reduce complexity at the cost of readability. If you have to understand Python-like to understand, that’s a gap Home Assistant could fill with a native control.
This is why I’m opposed to templates. I only used them when I’m forced to. I have a complex one right now for changing the porch lights based on the date, but I absolutely hate it and would prefer a native control instead.
Agreed.
Sorry, I do not agree. Native controls are almost always more clunky and slow to create than typing on a keyboard. I prefer that at all times over point and click GUIs. I understand that’s not for everyone, you should also understand the other side too.
Well, look at this from our shoes. You’re here talking about scalability issues while purposely avoiding the one thing that was added to address scalability issues.
You have these overly complex looping automations because you’re avoiding using scripts, script canceling, and automation modes.
It’s like you just want to do things your way without taking advantage of the systems that HA provides. You mine as well write your own software at that point.
It would be great if you could just post some of these “repeated automations” you’re talking about. I think you’ll find them to be much more approachable than you think.
3 Likes
I dunno how this got misunderstood, but it’s a long thread already 
.
I am using scripts. In fact, that’s exactly what’s doing the loop. It’s a reusable script with all the shared logic in it. I have multiple automations that call that script and pass values to fields. Each script can kill itself off if another script runs firing the same ID in an event. That should’ve been detailed in the first post.
Can you point out where I make this easier to understand in that first post? I thought I noticed you should be using scripts.
I can post some, but it’s not that simple. I’d have to post the automation, the script it calls, and 5 others that potentially get called depending on how you configure the first script.
Is that okay? The script YAMLs are gonna be pretty long when you put them all together.
how about we start at the top level, just post the automation’s that are similar that call scripts.
2 Likes
I got rid of most of the standard helpers (and many automations) in favor of trigger-based templates. This naturally led me to avoid using the -delay or -wait_for actions, as the template engine only supports single mode (which then behaves like queued mode). The hardest part was the UI editors, but I learned to use basic frontend elements (like ha-texbox, ha-switch, etc.) with custom:button-card as a canvas.
1 Like
The only helper that I have found that can’t be created from YAML is:
“Change device type of a switch”
And I worked around that by using a fan template:
- fan:
- default_entity_id: fan.work_desk
name: Fan Work Desk
state: "{{ is_state('switch.fan_work_desk', 'on') }}"
turn_on:
- target:
entity_id:
- switch.fan_work_desk
action: switch.turn_on
turn_off:
- target:
entity_id:
- switch.fan_work_desk
action: switch.turn_off
What is stopping you from migrating to YAML config?
1 Like
As @petro suggested, starting from the top would be good. Your original post has some great info for people unfamiliar with doing just the basics. Trigger IDs and conditionals and even scripts are very useful things to learn and help prevent repeating yourself. But those are also the “intended” way of doing things. Sometimes you have to dig around the toolbox to understand the tools at hand.
This might be a good exercise: Instead of stating your solution, what if you described the the problem you want to solve (e.g. “I have 5 similar lights that I want to turn on and off, and set the color level at sunset and would like to combine into a single automation”) and see what is suggested?
You can post short snippets of YAML showing your attempted solution if you like. You could post your looping script as a possible solution and ask for how others might do that.
I think @petro said all that in a single sentence.
Update: Oh, we have moved over here:
1 Like
It’s all here in a separate thread because it’s pretty off-topic for this one. This thread was meant to be a guide for other folks and not help with my particular implementation.
Separate thread with the automation and 3 scripts (2 of those loop):
What is this magic? 
I’ve never used template sensors like this. Is there a good guide or YouTube (preferred) link I could use? Does this allow you to create custom helpers 
?
This is the entire template platform that a few of us have said is why we don’t think your idea works…
That, specifically is template fan…
Im a fan of template_select, personally…