Understanding problem with groups

[HorizonKane]

Hi all,

as said before, I came here from OpenHAB and I am very happy with my choice to switch. What took me weeks in OpenHAB is done in HA in an afternoon, everything is very straight forward.

However I am very confused on the groups implementation.

In OpenHAB, when I create a group of lights, thermostats etc, I can do what I would expect: send a temperature to the thermostats group and all thermostats in the group get set to that temperature.

Same for lights, covers, etc. This is extremely important to create automations without listing each single device and having to change that X times when I get a new device or move one… (so essentially all the reasons why you use groups anywhere in IT).

But when I created a group of thermostats in HA, it was not available to the thermostat card as it was not belonging to the climate domain. I also found no wy to put it in the climate domain.

Instead I found a script from somebody here in the community that does exactly that. However it is only working partial, changing the thermeostats mode fails.

Now my question: Is the group concept in HA really imited like this? Or am I missing something? Or is it just not finished yet and I only need to be patient? In consider this as a very basic and important feature.

Kind regards,
Thomas

[tom_l]

I don’t think you are missing anything. They can be limited.

For example there is a dedicated light group you can use to group lights and treat them as one entity.

Also see this bizarreness about specifying group actions for climate objects:

Climate group and automation action

Interesting! Yes, what you posted does work, and if I use this format with groups, it also works! For example, the following will correctly change the temperature for the 3 thermostats in the group_basement_living_thermostats defined in my original post: - id: 'temp_weekday_morning_basement_living' alias: Temperature Weekday Morning Basement Living trigger: - platform: time at: '05:30:00' condition: - condition: time weekday: - mon - tue - wed - thu …

in short, this does not adjust any members of the group:

  action:
  - service: climate.set_temperature
    data :
      entity_id: group.group_basement_living_thermostats
      temperature: 22

Where as apparently this works for all members of the group:

  action:
  - service: climate.set_temperature
    data : 
      entity_id:
         - group.group_basement_living_thermostats
      temperature: 22

This is rather odd. Both should be equivalent. A group as a single entity or a list containing one group.

[123 (Taras)]

@tom_l

This is rather odd. Both should be equivalent.

I just used a YAML to JSON converter to see the difference (if any) between the two formats. Apparently, there is a difference.

This format in YAML:

entity_id: group.whatever

converts to this:

{ "entity_id": "group.whatever" }

whereas this format:

entity_id: 
  - group.whatever

converts to this:

{ "entity_id": ["group.whatever"] }

Based on that, this would work:

  action:
  - service: climate.set_temperature
    data_template: 
      entity_id: "{{ expand('group.group_basement_living_thermostats') | list }}"
      temperature: 22

However, it’s simpler (and neater) to just use the second format.

[petro]

@123

{{ expand(‘group.group_basement_living_thermostats’) | list }}

Are you sure that will work? That will add brackets into the string. I would assume that this is what would be needed. I haven’t tested, just curious (as I don’t use automations).

  action:
  - service: climate.set_temperature
    data_template: 
      entity_id: "{{ expand('group.group_basement_living_thermostats') | list | join(',') }}"
      temperature: 22

[123 (Taras)]

Honestly, no, not sure.

Without join it returns ["group.whatever"] which is what the second YAML format produces. EXCEPT you’ve reminded me that Jinja2 will deliver it as a string so that’s not good.

In contrast, with join the output appears to be identical to the first YAML format which reportedly doesn’t work in this particular application.

Beats me!

[petro]

I’ve noticed that some entity_id fields in data templates don’t accept the 'item, item' notation. I think it would be advantageous to find out all the fields that don’t allow it and make an issue to get it corrected.

[pickerin (Rob Pickering)]

FWIW, the difference is in treating the group as a single entity:

entity_id: group.whatever

versus treating is as a single element of an array:

entity_id: 
  - group.whatever

While they should both operate the same from an execution standpoint, because you’re sending commands and want to operate on each element of the group, I can see why the second works (hey here’s a group of elements in an array) and the first doesn’t (hey here’s a single element).

[HorizonKane]

Crazy!

At least I now know that I can set the temperature of a group of thermostats in an automation, better than nothing.

However I really think that it should be possible to create a group of any type and then send collective commands to all members as if it was a single item.

Kind regards,
Thomas

[petro]

That’s yaml and it depends on the validation on the element. entity_id accepts lists or a single item. Some services allow entity_id to contain 1 element that is a comma separated list (Like light.turn_on). Apparently, climate.set_temperature does not allow this.