Group platforms - mixed domains about architecture

[balloob]

Yeah the biggest issue is that there is no solution that is going to be able to work with all different combinations our users can think off.

[OttoWinter]

I mean most of the things of light or other group platforms were already possible with the group component and templates. Group platforms are more of a state reporting/visual thing: Having switches, lights or covers show up together as a single entity in the frontend and simplifying use in templates.

[balloob]

Well, it actually already does that @OttoWinter. The frontend will load the more info card if all entities are from the same domain.

[andrey-git]

The separation is artificial. A switch is a light without brightness support.

[balloob]

Can I just say that this discussion clearly shows that mixed group domains are a no? People try to push a very broad feature but in the end it shows that all people want is to have things show up as lights? 🤔

I'll close this as we have the group component and that does an ok enough job. Doing more would mean crazy mix of tracking all the different domains and their features and trying to somehow merge that. That's not what we want.

[balloob]

This is exactly what the existing group component provides.

[OttoWinter]

The group platform does supporting sending commands/calling services, but doesn't allow reporting states (apart from ON/OFF).

IMO, I think we should choose Option #.1 (only allow the exact same domain as the group platform) and tell users to use templates for more complicated use cases. Or even a mix of the two.

[cdce8p]

I'm not the certain that we should abandon the idea of mixed groups just jet.

It's right that we don't know with what somebody might come up with. But as you have said @balloob #13 (comment) the frontend group is more like a hack to this problem, currently. A dedicated group.switch platform could release some tension their and we would be able to control which domains we allow for it.

IMO, I think we should choose Option #.1 (only allow the exact same domain as the group platform) and tell users to use templates for more complicated use cases. Or even a mix of the two.

I don't think that this would be the best option. From a developing standpoint maybe, but should it be really be necessary to use template sensors to merge the functions of a switch and a remote?

We cover this for on / off type sensors, but maybe their are other cases where it might make sense, although I'm not aware of any at the moment.

[OttoWinter]

How about this: We stick with something similar to option #.1 for now and if we see several useful use-cases for the platform, we can still update the platforms accordingly? I mean as Paulus said, there are tons of (custom) ways users could want to use group platforms and it's simply impossible to support all of them.

After all, It's always easier to introduce a new feature than to break existing weird setups.

I do understand the input_boolean/etc thing, but could you give me a concrete use-case where this would be needed and overly difficult with templates?

[balloob]

remote and input_boolean can already be grouped today by the group component so I am a bit confused why we would need something else?

And yes, that component is a hack but it's not going away either. We will try to make it responsible for less use cases in the future but we wouldn't just drop it.

[cdce8p]

A switch group could be a step in this direction, but I admit it wouldn't add any new things that aren't already possible.

[psgcooldog]

Some input on this from a humble user, and a fairly new one at that. When I saw this new light group capability, I immediately tried it out. I've got a large house with (currently) 87 z-wave devices which are a mix of dimmers and switches. All except a couple of those switches are controlling lights.

My first attempt was to include those switches into the appropriate light groups. Of course, because of the decision made here, that didn't work. I then read about template lights, and set out to create templates for the 36 z-wave switches so that they'd appear as, and be controllable as what they actually were ... lights. It's an incredibly messy solution, that in the end, didn't work because of a type mismatch when a change to the switch state caused an update to the template light's state. IIRC, there was a comparison of 'brightness' to integer, which failed because 'brightness' had been set to "on" or "off".

In any case, even had I not stumbled over a bug in the template light code, the attempt to work around not allowing switches to be a part of a light group was incredibly ugly and laborious ... much worse (from the user's POV) than than dealing with the obvious limitations of including non-dimming light switches into a light group.

To me, the simplest solution is obvious: allow the switch domain to be over-ridden. When a switch is connected to a light, let the user tell HA that it IS a light. I don't see any downside to this; there are lights with many different capabilities already, so a light that is only on or off (0 or 100% brightness) should not be a problem.

Even if this capability has to be a special case, where only switches may be moved to only the light domain, it's most likely the best solution.

[OttoWinter]

@psgcooldog I think that ("let the user tell HA that it IS a light") should be done by the z-wave integration, not by the light group platform. I don't know anything about z-wave, so I don't know how it determines what component a device belongs to.

Doesn't something like this work for you?

- platform: template
  friendly_name: Light 1
  value_template: '{{ states("switch.switch_but_actually_light_1") }}'
  turn_on:
    service: switch.turn_on
    data:
      entity_id: switch.switch_but_actually_light_1
  turn_off:
    service: switch.turn_off
    data:
      entity_id: switch.switch_but_actually_light_1

(any further discussion about this template should be moved in the community forums)

Another option would be a "proxy" light platform, that can convert a switch to a light, but that might not be too useful to get into the core home assistant repo.

From an implementation perspective, there's a huge red-flag for me when it comes to supporting switches in light groups: Calling switch.turn_on with some parameters like "rgb_color": [255, 100, 100] will just fail, so the light platform would have to check each entity if it is a light or a switch, and so on - that's very far from "clean".

[cdce8p]

@OttoWinter Regarding your red flag: I agree that this wouldn't be the cleanest solution, but it's one that would work. Infact I already implemented something similar for the cover.group platform, since for covers it is necessary to actively check which ones supports which services.

There are certain cases where it might be useful. Apart from Z-Wave say you have a smart outlet for a light. The outlet would be a switch, but turns on / off a light. A template light certainly is a solution however it might be quite some unnecessary work for more the a few switches.

[OttoWinter]

Honestly, having the ability to set the component of an entity manually seems a whole lot like that ugly google_asisstant: type: hack all over again. I do understand that it's currently very difficult to have an entity look like another component (for example having a switch look like a light), but I don't think we should fix this in every single platform all over again.

TBH, I think this whole thing is a much bigger problem: We need to be able to "copy" an entity into another domain. Without complicated templates like the one mentioned above. Maybe another proxy or copy platform might be the solution:

light:
  - platform: proxy
    name: Kitchen Lights
    entity: switch.kitchen_lights_as_switch

It would make copy the state of switch into light.kitchen_lights. What do you guys think about that?

---

@cdce8p Yes I know your code, but you're only tracking the supported entities within the cover domain. If you start getting into supporting "switch", "input_boolean", "automation", and so on (there are lots of domains that are like switches) at some point you'll have to have tons of checks everywhere. As said, a proxy platform might be the clean solution.

[cdce8p]

@OttoWinter you're right, it would require some checks. However that way the group platform decides which domains to support and in which form.

A proxy platform would require that there is a complete representation as another domain possible which might not always be the case. If we start with that people may suddently want to combine a switch and a sensor and we end up creating a second template varient all together.

There certainly isn't a best solution here, but for the moment I would vote for the implementation in the individual group platforms.

[OttoWinter]

The problem with supporting entities from several domains has come up in several places already: google assistant, alexa, ... and now also group platforms. I don't think every single one of these integrations should do this supporting by themselves.

A proxy platform would require that there is a complete representation as another domain possible which might not always be the case. If we start with that people may suddently want to combine a switch and a sensor and we end up creating a second template varient all together.

Of course the proxy platform would only allow certain domains as entity_id input, somewhat how you're proposing the group platforms should do it. So of course the proxy platform wouldn't allow proxying a sensor into a light.

The benefit would then be that we'd have all this supporting in the same place and wouldn't have to reinvent the wheel for every single group platform and the aforementioned integrations.

---

If we have the code for the proxy platforms, we could then even go one step further and use this new proxy code for group platforms. For example, if a user adds a switch to a light group, we would automatically create a proxy entity for the switch in the back-end of the group. This would then be a much cleaner solution to the group platform problem.

[psgcooldog]

@OttoWinter That template is very close to what I tried. But imagine making 40 of them (and I'm not yet done installing all my switches!). Now THAT is ugly! The truth is @andrey-git is right, these ARE lights, they just don't dim.

As far as "switch.turn_on with some parameters like "rgb_color": [255, 100, 100] will just fail" how is that different from sendiing the same command to a light entity that is not color adjustable?

Allowing certain devices to be explicitly moved to a different domain would solve this grouping problem. It does not need to be totally general; although there may be other use cases than this one, this one is ridiculously common, and should be dealt with. I'm going to put this in as a feature request. Thanks for your time, guys.

[OttoWinter]

@psgcooldog FYI, I just created https://community.home-assistant.io/t/custom-proxy-platform-easily-convert-switches-to-lights/47565 as a test to see how users would react to this. It's basically the template I wrote above, but much easier to set up.

[psgcooldog]

@OttoWinter That was FAST! And it works for me. I'm going to try to make a minor modification to it to allow "hide_entity: true" to hide the original entity from the UI. It's time to add Python to the list of languages I've forgotten.