The polymer implementation looks pretty okay. Would need some cleaning up but it’s a good start. With such an implementation the group extension on the server side wouldn’t be needed and we could do it all in the frontend, including generating a combined state.
I don’t like the group modification. The group component should not be aware of any implementation details of other component. It should be able to work 100% independently. Without modification the frontend already has all the knowledge it needs to know.
I think there may be some value in having the combined state computed by subclasses of Group for a few reasons
The combined state may be useful to other components. For example, what if I had a group of 3 sensors and wanted to perform some automation based on their combined value? By exposing the combined state users get that ability right out of the box. In my opinion it makes intuitive sense that by grouping some “things” of the same type the system will give you some sane combined values to use.
There will always have to be domain specific logic pertaining to groups somewhere if group control beyond on/off is going to be supported. The logic is identical to do it fully client side, ex: the brightness of a group of lights would still need to be calculated by getting all of their states and averaging the brightness.
It may result in less code reuse and duplication. Domain specific logic can be reused in group subclasses where it might need to be re-implemented in javascript to generate useful combined state client side.
The group component is essentially unmodified in my proposed solution. If a group does not belong to a single domain or does not have a domain specific subclass then nothing has changed. In the case where it does have a domain specific subclass that domain specific code is as minimal as possible, is confined to a single file, and does not affect the behavior of the group. It only adds domain specific state attributes.
Then again I don’t have much experience with python, nuclearjs, or polymer so I may be missing a more elegant solution. What are your thoughts?
I am not a big fan of just having a group show averages of values. It makes little sense. For the frontend we can just use the first state and after their first interaction with the controls the state will be the same anyway.
I am not too concerned not supporting a group showing attributes within Home Assistant because that’s not a problem I’ve ever heard off. We shouldn’t try to solve problems that people don’t have, especially if we have to sacrifice component independence.
For automation, if people really want something like that, they can probably already do it today with the tmeplating language but I doubt it’s really useful at all.
I think the most important use case is being able to set the brightness or color of a group of lights. I have four Hue lights at home and it’s really annoying setting the color for all of them.
And what about exposing the list of groups that are in the Hue bridge? Unlike LIFX, Hue bridge cannot receive 5+ API calls asynchronously, so for me, I don’t mind adding 5 bulbs to a Hue group so that I can execute something such as this:
curl -X PUT -H "Content-Type: application/json" -d $1 http://philipshue1/api/$APIKEY/groups/1/action
where $1 is JSON code for brightness, color, and transition time, “philipshue1” is your bridge’s host name or IP address, and $APIKEY is the username assigned in the bridge. Oh, and “1” is the Group ID.
The last time I checked in the Philips Hue component, there’s already a group class, but Home Assistant does not expose the list of groups.
That solution would be platform (hue) specific. The one in the commit above is a more general case for any group of devices.
I have had no issue controlling 5 hue bulbs at the same time using this solution. The hue bridge seems to have no problem with the extra api calls. If you can figure out how to make HA automatically pick up on hue’s built in group functionality that would be cool! I am not interested in investigating it myself however since the general solution seems to work fine and my time is limited.
I agree with most of the above points (too many api calls will fail : I have about 20 hue + lifx) so had to resort to light groups and hundreds of scenes, especially color profiles change depending on light versions (strips vs bulbs, etc). In the end I set up sliders linked to scenes for group brightness (with booleans to select subgroups + automations to reset switches for the group once one has been activated). I used a wider range (10-100 for 1,2,3,4,5,6,7,8,9,10 until 300) and with templating it’s been working great. Only thing that bugs me are the logbook entries for those light groups that I cannot disable with logbook_hidden = true I also managed dynamic timers and manually switching on/off the lights triggering my dynamic timers. Delay is acceptable (less than 2 seconds) but I still have much cleaning up to do (8100 lines total) before sharing.
I’m curious if this Has this been resolved into a workable solution that I may have missed? I have multiple instances of Cree bulbs via Wink Hub (due to old non-neutral wired switches) in overhead room lighting such as my kitchen, dining room, and ceiling fans. To make the transition to HA (and the interface) more user friendly to my wife and kids I would prefer to just have a single switch for the Ceiling Fan as opposed to a group switch for the kitchen with 4 bulb switches below it.
I thought about setting a up scene but those don’t seem to have a true ‘off’.
I thought this may have been possible through using a switch template but have not had any luck yet.
Basically, create a switch that is tied to the group.ceiling_fan_light. I don’t really understand the template command, but this seems dependent on the actual switch state. Is there a way to make it independent?
I’ve managed to use a switch template and a pair of script to add an input_slider to my front end and control a set of bulbs. It’s an ugly solution though. It doesn’t do color or temperature, the slider doesn’t drop to 0 when off and it only poles a single bulb for the brightness attribute, but it works…
You might have to change the service it’s calling from light.turn_on. I don’t have any scenes set up yet, so I can’t test, but that’s the first thing that stands out to me.
Now, anyway to make this a dimmable/slider or does it have to remain a switch? I did not see anything in the components/template any may have overlooked it in my discussion search.
I also managed dynamic timers and manually switching on/off the lights triggering my dynamic timers. Delay is acceptable (less than 2 seconds) but I still have much cleaning up to do (8100 lines total) before sharing.
