Yes! And filtering tags should not just be limited to one entity type. It would be great to be able to see all entities with the same tag in one list, whether it’s helpers, automations or sensors.
1 Like
I think there are 2 things that need addressing:
- General organization. I prefer folders but tags can work just the same
- Grouping. I have devices or templates (e.g. auto light on and auto light off) that always come together. So I create 2 or 3 automations for every device I want to automate. It would be great to create a “bundle” or expand the blueprint concept to address this. This alone will reduce the number of items in my automations list by half probably.
Awesome work you guys are doing. Thanks for listening!
1 Like
I currently manage all my 120+ automations myself in various folders and files and I have centred it all around the ‘affected device’ if that makes sense. So if I have a switch that can control both the lounge table lamp and the main lounge lights, I would have an automation for each and in each a, version of the switch listener (single / double / etc). This has made it possible or me easily find any automation as I know the target/affected device and can go to that file and make changes.
This has helped me in the past to be able to rip out old automation easily (when I don’t have the device anymore)
I also like the fact that I can add comments and I use this website a lot to make headers for my files
http://patorjk.com/software/taag/#p=display&c=bash&f=ANSI%20Shadow&t=Lounge%20Lamp
I’d support a way to better categorize automation and support tags, being able to add multiple tags to automations and use a tag multiple times
Well, this concept is already there. Just open any entity and in the “related” tab you’ll have all the automations that this entity (or is it device?) is referring to in any way.
You can simplifying it by having just one automation that takes triggers for both turning on and turning off and chooseing the action depending on which trigger it was. Automations will be more complex but with the recent UI improvements they actually are much easier to navigate now in the editor.
I use packages too.
That’s why I posted this request:
1 Like
I would be happy if I could put automations and scripts in “folders” at a single level.
Even though I have been able to cut my automations to half the number with the cool new features like choose and if-then I still have 128 automations and 65 scripts.
If I could put these in one layer of folders (visually grouped as folders in the UI - not necessarity as real directories) I would start using the UI.
The long list is too messy to work with. Today I have an automation folder and I have around 40-50 yaml files in one layer below. Each file contains automations that are related to a certain feature or physical thing. Some files have one automation. Some have up to 10.
I cannot imagine living with a list of 128 automations in one long list.
Same with scripts. I have 60 scripts in 14 files. Again one layer would be enough.
With helpers I have like 30 and those are in the UI now. That is around the limit by brains has to maintain an overview.
1 Like
Scheduler card is a good option to move away from automations, if you need time as only trigger. It allows tagging and better representation (personally)
1 Like
Sounds like you are not using packages! Aside the wish for a better system in this thread, you should leverage the benefits of packages today.
This WTF is about a vital missing UI feature with the GUI of automations. Packages just brings you even further away from using the GUI
It’s not any farther away than 50 + 14 yaml files you already have (plus additional ones for mqtt or helpers you might have). However packages would certainly improve your strcture here and now, irrespective of how and when the WTH here is worked on and published.
Anyhow, just wanted to give you a hint. Up to you 
The original posting is the WTF asking for a feature to able to group the automations in the graphical user interface so that we avoid having one big list with hundreds of automations.
Most of us use packages to some extend. It is not relevant.
We are many that would like to use the GUI to edit automations, but the GUI feature will only work if all automations are in one common automations.yaml file and the GUI displays them in one long horror list.
The WTF is about adding a feature so you can group the automations in the GUI. This is the WTF with most votes. And last time we had a WTF month an identical proposal also got the most votes.
We want to be able to create automations and scripts with the nice user friendly GUI AND at the same time having just a minimal way to organize them in groups (folders or labels or whatever)
Today I have to create an automation in the GUI, and then move it manually to a yaml file. This can be a yaml file in a folder that is picked up from configuration.yaml. Or is can be moving it to a package file. Same mess. Or I have to use some naming scheme so the automations are named with a prefix that sorts alphabetically. Not very nice.
I originally came from Homey and left when they removed the nice flow editor ( they later regretted and added it again but then I had left ). What I liked about Homey was that I could create a folder in the GUI and then drag and drop my flows into the folder. I never needed more than one level of folders.
Adding a new keyword to the yaml of scripts and automations called label, or similar and have the GUI show these grouped per unique label value should not be a big issue and it would not be a breaking change either as lack of the yaml label would just show it at root level.
With the many votes this is one I really hope will be taken up this time. And please keep the requirement simple.
Just like to point out it’s WTH not WTF 
And also, I wonder what the point of the month is if the feature with the most votes by far two years in a row doesn’t get some serious attention.
I am personally fine with yaml, but use the UI mostly because I’m often tweaking on my phone in the odd minutes I get between kids pestering me etc. i get that folk want to chip in with semi-solutions like packages here, but it’s not in the spirit of streamlining experiences which is the current development theme.
1 Like
Packages was a recommendation for you, in case you didn’t look into it growing a legacy setup, because you moved to HA just recently, or some other reason. Settled, let’s carry on.
And please keep the requirement simple.
I have to disagree with your argumentation. The goal for a feature shouldn’t be simple to implement but useful. For this purpose we must cover not only automations and scripts, but also helper items or mqtt entities. Folders/labels/x are ideally used to group by use case purpose, not by device. The real beauty is that you can use this concept however it pleases you, once implemented.
This is the WTF with most votes
Because it addresses the biggest visible day-to-day issue. I am certain whoever will eventually implement this will understand the need to address this more holistically. Very excited to see how this plays out.
Can we get to 1,000 votes?
Sadly getting 1,000 doesn’t mean that this will be implemented. Devs must implement this, the core team, or someone from the community.
I really hope that Frenck’s PR will get merged and that it will allow this functionality.
Yes, I know, but numbers passing arbitrary thresholds always seem to gain more attention.
2 Likes
Well, I believe that it should be up to the user to define what they want to use it for. For the grouping by device it actually is there already. Just open a device page and you’ll see all automations and scripts where that device is used. I often go there in case I change something related to the key way I’m using particular device or simply when I have to replace a broken device.
1 Like
I absolutely agree with this. I want to be able to identify every element that is related to a specific device. This should happen automatically, I wouldn’t want to manage labels for that manually. Of course in certain cases a user might and can.
My original argument was that tags (or packages today) should primarily serve to structure elements by the more abstract idea of use cases (e.g. presence related lights and music management).
Hope that makes sense.
