Comments (20)
@andrey-git group.*
currently only really supports setting states with services. What these new group platforms do is that they additionally report the states of their child entities so that they can be used better in the front-end and in state checking. (see home-assistant/core#12229, home-assistant/core#11323, home-assistant/core#12303 for reference)
You can think of them kind of like Hue light groups (or light groups of any other make) in Home Assistant. Additionally, with this you would now be able to create light groups (or other components) across domains.
from architecture.
🖐 I will work multiple climate devices if needed
(have a thermostat per room and could use a group to set away mode on/off)
from architecture.
We should actively check that all entities belong to same domain. Make it part of config validation that you check domains of passed in entities.
from architecture.
I thought I'd write a short summary of these points (also partially based on how I did it for light groups). Each of these rules are only recommendations, and can of course be changed on a per-component basis if it makes more sense.
Group platforms should:
- be called
{} Group
by default. For exampleLight Group
. - strictly only allow entities from their own component (see #18). For example, Light Groups only accept
light.*
entities, notinput_boolean.*
as members. - look like any other entity of the component in the front-end.
- do all their supported features based on a union of the supported features. For example if one light in a light group supports rgb, the entire group supports rgb.
- always try to sync the states of the children. For example toggling a light group with states A:
on
, B:on
, C:off
, should result in A/B/C:off
. - report their state intelligently. For example for light groups: the average brightness of all lights that are on; and the most common active effect amongst all members.
- report
unavailable
if no child entities have reported any states. - have a configuration format like this:
component:
- platform: group
name: Custom name
entities:
- component.entity_1
- component.entity_2
- can have additional configuration options where it makes sense, but that should be kept to a minimum.
Components where a group platform would make sense (there might be others too):
- light home-assistant/core#12229
- cover home-assistant/core#12692
- fan
- alarm home-assistant/core#11323
- potentially media_player
- climate (are there people with multiple climate devices?)
- lock
- potentially vacuum
from architecture.
How is this different from today's group?
from architecture.
The complete idea is to group components (lights, covers, ...) so that they appear as just one component. Although this is already supported with a mix of templates, template sensors and scripts, a own platform would make it a lot easier to set up. For reference a while ago I added an example to the template cover doc. With a separate platform the config would look more like what @OttoWinter wrote above, which would be awesome.
As already linked above (home-assistant/core#12303), I submitted a PR for something similar for covers. I wasn't and still am not sure though if group
would be the right name, due to the resemblance to groups
.
Features: Union / Intersection
I think the component group should support a basic set of operations at default (like all cover features, for covers) and additional functions should be parameters (e.g. tilt features). Important would be to find the right balance (not: set_position, tilt, tilt_position, ...). If some components don't support a certain function it shouldn't effect all others (like set_cover_position should only effect covers that support the function, all others should ignore the command).
State reporting
IMO it would make very little sense to report just the attribute of a selected leader
for the whole group. It could be an idea to report default values if the attribute varies from component to component (brightness = 100 if on, 0 else) and the exact number if all are the same. An alternative could be to make this configurable: the option described before, always the minimum or maximum value (default, min, max). If some don't support a certain attribute, just ignore them in this case (they don't have it to begin with and you probably already know that).
Configuration
Looks good to me.
Front-end support
I'm a bit skeptical about it. The whole idea of this platform is to group components so that they appear as one and are as such available to automations
and scripts
. Only because you are using this feature, dosn't mean that you have hidden all the other components. A dedicated state-card might not be what somebody might want who is looking for this.
These are a few of my thoughts about it. As @OttoWinter already said: I would also really love to see this being added to Home Assistant.
from architecture.
Does this mean that the new group are by design single-domain?
Would this be able to replace current groups as far as backend is concerned? (I.e. we would be able to remove the ability to call services on kegacy groups)
from architecture.
These groups would be single domain and be implemented as platforms for that domain. This has the great benefit that each group platform is able to group attributes and states appropriately. The current "group" is doing a poor job because we don't want to add too much component "knowledge" in it.
In the frontend we have two hacks in place currently:
- for a single domain group, render the more info for the first state
- show a toggle to turn group on/off
One glaring issue with current group design is that combining states is all off as binary sensor "ON" gets mixed with a light "ON".
Features: these should be union. We should be able to control any aspect of any child light via a group. When 1 light is on, the group light should be on. When 1 light has a color, the more info should allow picking a color etc.
State reporting: we should not do things like first light that is on kinda things. That is confusing to the user. I think that it depends on the domain and attribute how it should be handled. I honestly think that averaging the brightness is not a bad idea at all. If you have 3 lights next to one another, isn't that what you would expect to happen?
For frontend, I wouldn't mind showing entity state info's in the more info (like group does today). In fact, we could add this today for any entity that has an entity_ids attribute?
from architecture.
This group platform should be single domain yes (platforms are always single domain).
from architecture.
These groups would be single domain and be implemented as platforms for that domain.
That's right. One question that arose in light.group
was whether we should actually check if all child entites are lights. I mean theoretically users could add switches to that domain and it would still work. Should we actively check that?
I honestly think that averaging the brightness is not a bad idea at all.
True, the brightness does make sense. I'm not so sure about averaging RGB or even XY colors though.
This group platform should be single domain yes (platforms are always single domain).
I think I mixed up my lingo there before. What I meant was that now you would be able to combine lights from different manufacturers/components like Hue and MQTT and create light groups together. Before, within one such ecosystem such as Hue, this was already possible, across ecosystem not so much though.
Does anybody know about how other products/manufacturers do grouping (such as light groups)? I mean it would certainly be worth a look to see how they've done it and maybe learn some limitations of different systems.
from architecture.
Average brightness
Does make sense, but it should depend on the attribute. If you group all covers on the first floor, some open, some closed, it dosn't make sense to report current_position as 50 for example.
from architecture.
We should actively check that all entities belong to same domain. Make it part of config validation that you check domains of passed in entities.
but why? Will it serverely break if we call turn_on on a entity that doesn't support it?
What if I have a smart wall switch (in the switch domain) with a classic light bulb that I also want to turn on?
from architecture.
but why? Will it serverely break if we call turn_on on a entity that doesn't support it
@NovapaX As far as I Know: Yes, Home Assistant throws an error if a service is called on an entity that doesn't it. To check if a feature is supported, the state attribute supported_features
works. This is however limited to just one domain, since every domain has their own set of values for supported_features
.
Another question regarding supported features is, when to check them? Since a group
platform would already listen to state changes from every of its entities to update the state accordingly, it could make sense to store the information in a dictionary with the mapping feature --> entities
.
from architecture.
A light group will not allow any other entities. We would make the same mistake as our current group component all over again.
from architecture.
I see, makes sense. becomes unmaintainable fast. Such a case (adding a different kind of entity into such a group) could be covered with for example a template light.
from architecture.
I was also thinking about how this would be a great thing for device_trackers
So you can group multiple device_trackers (for a single person) and add some conditions like delays, combination of devices away/home to determine the state of the device_tracker.group
And if we look at #14, we could steer away from using generic groups as much as possible. (there are still some use-cases maybe, but these are probably better served by some kind of template.group)
So to keep this on-topic. I think behaviour of domain.group
could (and should) differ between domain depending on the nature of the domain, and in some cases be configurable. Configurable should be simple, but useful. If things get too complicated it should be done in a sensor or custom component.
Behaviour should, of course, be described in clear wording in the documentation.
from architecture.
I think that we can close this issue?
from architecture.
I was thinking: Isn't the min/max sensor
also some sort of a group platform?
from architecture.
@cdce8p Sensors are a different category. They don't have features/functions. They have indeed a wide range of "grouping" or 2nd order platforms already, like filter, statistics etc.
from architecture.
I think it would be convenient if we could define alternative behavior for controlling the groups as a whole too. For example, I use the Osram Lightify hub and when I create a group of Lightify lights in homeassistant it (apparently?) sends an individual request for each bulb to the hub. This results in a very noticable delay between each light changing. However, if the group is created in Lightify and then imported to Home Assistant as a single entity, everything is perfectly uniform..
I'm imagining something like:
component:
- platform: group
name: Custom name
entities:
- component.entity_1
- component.entity_2
~- component.entity_3
controllers:
- components.entity_1
- components.entity_4
In this example, components.entity_4
could be an external grouping of components.entity_2
and components.entity_3
. If that homeassistant group received the turn_on
command, it would issue components.entity_1.turn_on
and components.entity_4.turn_on
.
Edit: Just realized this is closed. Awkward.
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.