Add group feature to knx integration

Feature Requests
,
1

In a knx project, we can configure multiple actors to trigger for the same group adress sent on the bus.

This can be used to turn_on multiple switch synchronously or close multiple cover synchronously.

Currently, to configure such an ability, I had to write this kind of configuration. See the problems in the comments:

knx:
    cover:
      - name: "Kitchen left shutter"
        move_long_address: "21/0/1"
        stop_address: "21/1/1"
        position_address: "21/2/1"
        position_state_address: "21/2/101"
        
        travelling_time_up: 18
        travelling_time_down: 18

      - name: "Kitchen left shutter"
        move_long_address: "21/0/2"
        stop_address: "21/1/2"
        position_address: "21/2/2"
        position_state_address: "21/2/102"
        
        travelling_time_up: 18
        travelling_time_down: 18
        
template:
  - cover:
      - name: "Kitchen x2"
        open_cover: { data: { address: "20/0/20", payload: 0 }, action: "knx.send" }
        close_cover: { data: { address: "20/0/20", payload: 1 }, action: "knx.send" }
        stop_cover: { data: { address: "20/1/20", payload: 1 }, action: "knx.send" }
        
        set_cover_position: { data: { address: "20/2/20", type: percent, payload: "{{ 100 - position }}" }, action: "knx.send" } # postion conversion must be implemented from the user
        
        state: "{{ get_cover_group_state(this.entities) }}" # custom template must be implemented from the user
        position: "{{ get_group_mean_state_attr(this.entities, 'current_position') }}" # custom template must be implemented from the user

homeassistant:
    customize:
        cover.kitchen_x2:
            entities:
              - cover.kitchen_left_shutter # has to be predicted according to knx configuration (slugify(name))
              - cover.kitchen_right_shutter # has to be predicted according to knx configuration (slugify(name))

It would be nice to implement groups, like in the Group integration, merging the features of “group” and knx integration.

The knx configuration for it, could looks like :

knx:
    cover_group:
      - name: "Kitchen x2"
        move_long_address: "20/0/20"
        stop_address: "20/1/20"
        position_address: "20/2/20"
            entities:
              - cover.kitchen_left_shutter
              - cover.kitchen_right_shutter
2

Hi :wave:!

Why not just use HA groups? I don’t think there would be any noticeable delay by triggering a reasonable amount of covers sequentially.

Or, if you have some kind of combined states (from external logic or whatever), you can just configure an additional cover.

3

I agree. It is basically cosmetic. And since knx allows it, I like to use such common group adress for synchornised actions.

I have an edge case where it is needed :

  • 3x “Velux SML” shutter, actored with an unofficial solution (knx switch with common power supply)
  • Moving the 3 shutter synchronously with the same address works
  • If there is a delay, when a shutter start moving, the others stops

But now I think this kind of feature is easier and more usefull to be added in the group integration. (Extend integration, to be able to override each default group action with own script. Then calling knx.send service or somehting else more generaly).

4

Do you know of any other integrations providing “groups” of things? I’m not not sure if there even is any API for that.

Creating a normal cover entity with this address should work well then. Not sure how things like voice assistants handle would handle that, though as there is no semantic about the one entity being a group of those 3 others.

5

I don’t know if there are other integrations providing grouped actions.

Yes configure the 3 covers as a unique cover work, but the _state addresses are returned separately on the bus from the 3 entities. The group state should also update when the shutter are moved individually, and by initialization: there is no group address which can respond to a Read telegram for the group state.

Currently I can only mix the ‘group’ and ‘knx cover’ behaviour with the logic at the first post (Template partially reimplementing ‘group’ features),

or Template managing 2x hidden helper entities: knx cover for actions & group cover for updating state from children.

6

For an implementation, I guess that wouldn’t be easy to solve. If one is 0%, one 50% and one 100% - what’s the state of the group then. Or one is opening, another closing. There is no right or wrong answer to this…

For your specific situation I see 3 options

  • template providing the state as you think it fits. Expose to Knx → readable by Knx entity
  • Knx Cover without position addresses (will calculate position - might not be desired)
  • Template cover with Knx.send actions (maybe assumed state or templated from multiple other entity states)
7

Group integration seems to define a group position according to children positions.

For my project I will continue to use option 3, so I can customize the group state like I want it.
For me, it is solved, I can do it with templates.

As feature, it would be nice to expose override options in the group integration config :

# Example configuration.yaml entry
cover:
  - platform: group
    name: "Window Covers"
    entities:
      - cover.hall_window
      - cover.living_room_window
    cover_open:  { data: { address: "20/0/20", payload: 0 }, action: "knx.send" } # if key exist, run action, if not => default group behaviour
    position_template: # if key exist, use this template to get position, if not => default group behaviour

An other pro is: You can implement your own logic to combine states.

1 Like
8

Hue, and it’s dumb (IMO). Now you get individual devices and groups.