RFC: Wildcard support for entity_id lists about architecture

[OttoWinter]

I guess we should also reference home-assistant/core#12381 and/or move that discussion here.

[balloob]

First, let's make sure we don't customize as an example of something "good". It's a hack that is bolted on top of the whole system. We've been working in reducing it's necessity.

So if this is a good change will need to be evaluated on a per component/platform basis. We can't just say: everywhere that we accepted entity IDs, we will now accept entity wildcards.

For recorder, history and logbook I would say a hard no. We already use (domain) include/exclude. I think that adding more functionality will be very confusing. (it's called Entity Filter btw and is quite a common pattern)

For other things, I am also not fully convinced that this is a good change. Is the complexity worth not having to type a second line for a group? My concern with these changes is that there is no way back. We figure out in the future that we overcomplicated things and we're stuck.

• It adds a lot of complexity and overhead. Things like groups will now have to listen and check ALL state changes in case one of the states matches the pattern.
• It means that we cannot see what the impact of a configuration is in advance. This might impact template platforms that now limit the state changes to the ones they detect from the template.

So where might this be a good idea? This might be a good idea in service calls (EntityComponent.async_extract_from_service). But still, aren't we getting lazy?

[andrey-git]

If we ever separate backend groups (i.e. service call targets) from frontend groups (i.e. visual groupings) it might be beneficial for the frontend. For example put everything with a "bedroom" in the name into "Bedroom" group.

But such usecase is solved easy enough with point-and-click group UI.

That said, CustomUI already implements arbitrary rules for frontend groups ;)

[cdce8p]

@balloob Yes this is about getting lazy ;)
I only see a true benefit for those who have a large numbers of entities they want to group or do something with. For everybody else (including myself) it just would be: Why should I write down all those weather sensors when sensor.yr_* works as well.

Regarding your concerns:

• Yes this would have to be evaluated on a per component/platform basis.
• At least in the current implementation the impact on groups and template platforms might not be as strong as you think:
  • To enable this function in a component, the component has to implement an update_entity_ids method of some sort. This method will be called after homeassistant has started and will receive a list/set with new entity_ids, which have been matched by the helper class.
  • Usually the update_entity_ids method should include some call to update_ha_state.

Some problems I see:

• To match patterns against entity_ids, you need a list of all entities. This in return means that matching can only begin if all or nearly all components have been setup. Components that enable this feature have to be prepared to handle situations where they have no entities to work with.
• Not all entities are setup after the event homeassistant_start, especially for zwave this is only the case after the event network_ready.
• Since every pattern must be check against every entity at least ones, it does take time after the initial setup until all components are completely ready. There are some ways to exclude some entities from matching beforehand which might optimize this though.

Despite all this, I think that this feature is at least something we should consider if not for groups, than for the countless other components. It dosn't come from nowhere that the forum has at least three feature requests for this. People are lazy, so sometime to be lazy is just what they want :)

[andrey-git]

Entities can be added & removed while HA is running, so glob support would need to listen to entity changes and not do a 1-time scan at some "late-enough" point of time.

[cdce8p]

@andrey-git I didn't know that. That complicates things a little. I guess than you would need something like an entity_changed event that fires every time a entity is added, removed, ... Every component that uses a pattern would than need to check every pattern against this entity.
It might not be worth it afterall.

[balloob]

So there is no class to hold an "entity" in the Home Assistant core. There are events, states and services.

States will track the state of an entity. You can derive from a state changed event if an entity was added or removed as per the docs. And that's also what I said in my above comment:

Things like groups will now have to listen and check ALL state changes in case one of the states matches the pattern.