Can someone explain, how the status filter is working?
How can I show/filter only the deactivated or only the hidden ones or only the not available …?
2 Likes
Have you tried categories for Automations ? That then puts them in sections in the list
This could be confusing:
These functions accept both “label_id” & “name”.
“label_id” is unique, and “name” may be not - wrong, names are also unique.
Here 2 labels:
with different “label_id”:
and only a label with “label_id = test_1” has an entity.
And what we see here:
The “test_1” is a name of the 2nd labels & id of the 1st label.
This is rather confusing.
Functions should accept ONLY id or ONLY names.
3 Likes
I got excited about FINALLY being able to organize automations. But I’m finding it useless. Instead of getting simple FOLDERS, I now have to multi click my way to access automations. And the automations page remembers nothing. I have to ask to hide disabled automations every time! There is no permanence. Every time you access automations it loses all your fileter settings. Just give me simple folders! I want to arrange accessing my automations in a permanent way, not have to select filtering every single bloody time.
I hope this is just buggy and this all get fixed. But REMEMBER our settings!
And there is no overall “don’t show me disabled automations” setting. You have to sort. How do you remove disabled automations from my view? You still end up endlessly scrolling way too much to find your automation.
2 Likes
This is no different than area or devices. It was modeled after those functions, so this is nothing new.
Resolved by running the following command on HA CLI:
ha dns options --fallback=false
To see if settings are still OK:
ha dns info
After this no more PTR queries.
And how this can justify this inconsistency?
If it is done the same way in other places - may be it is a reason to fix it everywhere?
1 Like
Categories are permanent, give them a try. Also calm down. I really shouldn’t have to tell you this with every post you make.
2 Likes
It was done that way on purpose… You have the option to use the name or the id.
OK, but it may give unexpected results.
This approach “use id or name” could be more convenient for some people - but this is a software, it should return 0 or 1, nothing else.
As a conclusion: people, use absolutely different ids & names to avoid possible confusions.
Sorry, I just don’t see your point. It’s very clear that if you give it a label name or label id, that you’ll get a result. And if you give it something that doesn’t exist, you’ll get None. That’s very 0 and 1.
I thought that I explained it clearly in my post.
There are 2 labels:
- label 1: id = ‘test_1’ (associated with sensor.x)
- label 2: name = ‘test_1’ (associated with sensor.y)
Question: what output will we have here?
label_entities(‘test_1’)
1 Like
Sorry, your post is not clear. You make the assumption that we know what entities are attached to your 2 labels, we don’t.
Anyways, it tries for the label name first, then the label_id second.
I see, that is why I provided a detailed description with screenshots here.
Everyone can reproduce it.
Ok. Just testing. Imho inconsistent, but not crucial (unless a user have similarly looking labels/areas/devices).
1 Like
Completely agree!
Great update, but it would be much more useful if the settings for filters/group by/sort by would be persistent (per user?), either per default or with a “save”/“set as default” button.
3 Likes
I would vote for this FR.
I think filtering by “no label” or “no category” should be helpfull for a lot of people!!?
7 Likes
Seems this is opposite in fact.
(acc. to my tests)
Finally, this is inconsistent. I wonder why it was made in such way.
1 Like
Specially if you are on a touchscreen. I don’t think the disable functionality is so frequently used as to make it so accessible. You may have critical automations that certainly do not want disabled.
1 Like
had to roll back - something does not sit right - hassOS on NUC, core keeps restarting/crashing at different times, no indicators in the logs as to what crashes it as logging stops at different indicators all the time - maybe some hacs extensions require some updates before this actually works. all other addons work perfectly fine as I can access them individually so it is definitely something in/around core.