Comments (7)
I guess we should also reference home-assistant/core#12381 and/or move that discussion here.
from architecture.
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?
from architecture.
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 ;)
from architecture.
@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 toupdate_ha_state
.
- To enable this function in a component, the component has to implement an
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 eventnetwork_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 :)
from architecture.
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.
from architecture.
@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.
from architecture.
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.
from architecture.
Related Issues (20)
- Splitting tests files in smaller files in components/modules tests HOT 1
- Feature Request HOT 1
- Add favorite position to Cover entity HOT 10
- Add feature light distribution control to LightEntity
- Add new CURRENT_HVAC constants HOT 1
- Add Home Appliance entity
- Officially allow enities to set their entity ID not based on their names HOT 2
- Custom Device Class for Binary Sensors HOT 9
- Installed homeassistant supervised on my Linux machine; can't get it to run. HOT 1
- Expand enqueue options media player HOT 2
- Extend Rest API - unique_id HOT 3
- Add "status" as an attribute to CalendarEvents HOT 5
- Add list of (upcoming) calendar events to templating HOT 1
- Creating automations on the fly HOT 1
- Optional health check HOT 2
- Open letter for improving Home Assistant's Authentication system HOT 7
- Add device_class Heater HOT 2
- Area Units HOT 3
- New Device class for Reactive Energy (varh) HOT 1
- "Lost" device HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from architecture.