Shutter/cover: Implement trigger (up/down/stop) from bus side

[twistermcneal]

Implement trigger (up/down/stop) from bus side

[rklueber]

Hi guys and girls,

I have 5 covers which do not have a position_state object. When suing HA everything works fine and the (virtual) state objects gets updated.

However, if you use the KNX bus to steer the cover the position state is out of sync.

Say in the morning I steer it up manually via KNX. The bus thinks it is still down. The automation started in the evening thinks its still down and does not send the signal on the bus.

Super anoying. WAF goes down dramatically atm for the whole solution. I need help or advise how to fix it.

It seems that BUS signals are not used to update the position state object.

Regards
Ralf

[rklueber]

Dear friends, this is still open. Since 2016. If one uses the KNX buttons to drive the cover XKNX will not see/react. This is true for knx Hardware which does not have a position state object. This renders the covers useless.

Situation is as follows:

• HA runs cover down at Sunset
• next morning someone uses knx buttons to get the cover up. HA does not know as it only listens to the non existing position state object. The actual HA entity is no longer representing the real status. HA still thinks the cover is down
• next sunset the cover will not go down bc HA thinks it’s already down

Am I missing something? How can I overcome this problem? Replacing the old knx devices with new ones is one which sets 5x70€ aside. A lot of bucks.

If none of the devs is willing to jump in here, please advise where to look. I can try to fix it, but now I have not enough experience to make this happen.

Please ...

[farmio]

As a workaround you can always use any logic to fake the position state address. Just send 100% to a new GA when 1bit DOWN and 0% when 1bit UP signal is received. Positions in between are a bit problematic then, but maybe you don't even use them.
This could also be implemented in xknx of course - if you want to do it, I'm happy to review a PR.

[rklueber]

@farmio, actually this was very helpful. Thank you. I document the workaround here for further reference and fellow HAs who come accross the same problem.

I must admit for a PR I am not skilled enough. Please accept my sincere apologies.

add to your knx: section these lines to get the knx event fired to the hA event bus:

knx:
  ...
  fire_event: true
  fire_event_filter:
    - "1/3/1-6" # Rolladen Ergeschoss Lang/Kurz Objekte
    - "2/3/1-6" # Rolladen Obergeschoss Lang/Kurz Objekte

create the following automation

- alias: "fake position arbeiten down"
  trigger:
    platform: event
    event_type: knx_event
    event_data:
      address: '1/3/2'
      data: 1
  action:
    - service: knx.send
      data:
        address: '1/3/7'
        payload:
          - 255

- alias: "fake position arbeiten down"
  trigger:
    platform: event
    event_type: knx_event
    event_data:
      address: '1/3/2'
      data: 0
  action:
    - service: knx.send
      data:
        address: '1/3/7'
        payload:
          - 0

I will see if I work on an appdaemon python script to do this more intelligent and derive the positions in between as well. I will keep you posted.

[farmio]

You can also combine regular switches with a cover template. https://www.home-assistant.io/integrations/cover.template/#garage-door

[farmio]

Maybe the problem is that the xknx device currently doesn't process a write to the move_long and move_short addresses. Thus the travel calculator isn't triggered and won't return a new position. We could check if position_address is initialized - if not start the travel calculator to 0 or 100% depending on the binary value.

xknx/xknx/devices/cover.py

Line 237 in c22e394

async def process_group_write(self, telegram):

If you need help implementing this join us on discord.