DynamicGroupController and attributes

[therealdb]

Hey @toggledbits I'm back to trying to optimize a couple of things based on dynamic group.

First of all, I think I found a typo in the doc:

          primary_attribute: "binary_sensor.state"
          primary_attribute_value: |
            d = false;
            each id in members: d = getEntity(id)?.attributes?.power_switch?.state or d,
            d

I think the correct code snippet is d = false,

All that said, my use case for dynamic groups is to group 3 different climate devices, so I could easily command them at the same time. Commands are good, but sometimes I want to check if any of the devices are on, and that's easily done with a similar snippet as the one you have in the docs. But this is limited to the primary attribute, while I want to have any of the attributes in the group to be driven by a similar logic (while all are null in the group). ie, access hvac_control.mode and see if any of the unit is set to cool, or heat. Is that possible, without re-defining an expression in each of my rules? Thanks!

[toggledbits]

@therealdb said in DynamicGroupController and attributes:

I think the correct code snippet is d = false,

The grammar allows semicolon (;) to end a subexpression, so in that context, the two should be interchangeable.

@therealdb said in DynamicGroupController and attributes:

But this is limited to the primary attribute, while I want to have any of the attributes in the group to be driven by a similar logic

I understand. Nice. I will look at this in greater depth over the weekend.

[therealdb]

Oh, wow. Is ; universally accepted in code blocks too?

Thanks for considering the request!

[toggledbits]

Yes!

Question on your feature request... generally, a capability has to be defined on an entity to assign an attribute within that capability. A Group is a subclass of Entity that normally has a limited set of capabilities and attributes that don't vary from group to group (i.e. the sys_group capability is pretty much it).

I can see adding attributes to a Group two ways:

1. Like with actions, the capabilities the Group allows follows the superset of capabilities of the Group's members, so the group would inherit those capabilities and you would be allowed to set attributes (via expressions in config) for them, or...
2. In config, you set what capability you want to assign and set attributes for, and then supply the logic (expression) to drive the attribute. In this scenario, the only additional capabilities that are assigned to the Group are those you explicitly name in config.

Thoughts?