Wildcard operators for groups

Was thinking about this as a fix for automations and script groups. I see that a fix for that exact problem has been merged.

I still think this idea has merit but needs refining based in some feedback. That where you guys come in…

What I was thinking was something like the following for the use of wild cards in the groups yaml.

All lights
light.*

All lounge lights
light.lounge_*

All sensors from one component
Sensor.bom_*

All lamps
light.*_lamp

I have no idea if this is possible or while crate havoc with yaml.
Any further thoughts?

3 Likes

I like this idea. Would make groups more dynamic and easy to scale.

1 Like

I went looking for something like this today. I wanted to have a group display all persistent_notification’s

Once you start using default_view in groups (and lose the catch-all), you have to implicitly add notifications to a group.

Which can be annoying if you want to have multiples (and not use the notification_id since that’ll overwrite existing notifications with the same ID).

i would like it extended even more.
also in automations, in scripts, in customisations, etc. would wildcards make things a lot easier.

4 Likes

I agree, wildcard could be very useful for zwave component too
for example my Fibaro fgsd-002 is actually shown has many sensors, binary switches… it would be more user friendly to have a card with all informations of the Fibaro component

+1

I really want this for grouping weather:

darksky:
  name: Darky Sky Weather
  entities:
    - sensor.dark_sky_*
3 Likes

I’m adding wildcards support for customize: in PR 5215

@andrey
That look really good. I like the use of regex as this makes if significantly more flexible.
I look forward to testing it out. I don’t have much time til later next week.

What about regexp vs glob syntax?

regexp is more powerful but reinterprets . which is a legal entity character.
glob is more readable, bring in just []!?* which are not legal entity characters.

Do we really need the power of regexp?

I did not know that it was called glob syntax until just then.
For all my use cases glob syntax would do the job. But I am sure someone will come up with some unique case for it.

I did notice te same issue with the ‘.’ In the regex example. I was wondering if some way to define the use of regex (or glob) using something like the template brackets might differentiate a named entity_id from the paterna based ones.
Maybe something like this:

  • light.sample
  • {{regex_entity_id : light.s.*}}
  • {{glob_entiry_id : light.s*}}

It could be a bit simpler and use glob as part of the normal named entity_ids and add regex as a special template. This could even be added later.

  • light.sample
  • light.s*
  • {{regex_entity_id : light.s.*}}

I was just thinking about groups with regex so I figured I’d search to see if anyone else was also looking at it… so hi everybody! :joy:

In my case I was thinking it might be helpful to group a bunch of sensors by unit_of_measure too… That might be difficult to implement nicely though.

. is a regex operator, but \. is a literal period if you need to match it explicitly.

I’m partial to regex myself, as long as this isn’t constantly re-evaluated - regexes can be expensive. I’m thinking that globs would probably suit 99% of the use cases people need.

Any news on this? @andrey you fixed customize, not group? This feature is very wanted by me also…

The general development direction is configuration UI.
Glob\Regexp is incompatible with that idea.

Emby/Plex clients would really benefit from globbing or something along those lines. I’d like to have a tab that has all my “Emby” clients. Since these are very fluid, I can’t really define them ahead of time.

Did this ever make it any further? I’ve been setting Hass.io up over the last few days and this would be a really useful way of adding all current and future Emby clients to a single media tab.

I don’t think so. I played with creating something in HA but the api for manipulating a group won’t work. Without changes in the core of group handling, I don’t think it can be done, and since there doesn’t seem to be interest amongst the dev team, I’m not sure they’d go for it.

i created an appdaemon app for it.

I have created a pull request, that if implemented, will allow me to create and provide a custom component that will be able to modify group membership based in globing.

When/if they merge it, I’ll post the custom component.

Well this went well over my head incredibly quickly! But thanks for the responses :grinning: