KNX Cover: No update on bus signals (no position object)

svenihoney · June 26, 2019, 11:33am

Hello community,

I am aware of the thread #80421 ([solved] KNX Cover - State updater not working (lights & switch do though)), but my problem is a little different.

My KNX device (Busch Jaeger Powernet cover actor) does not have a position_address(_state)? object, therefore the position is based on travelling time, which works perfectly if controlled by HA. But if the move group address objects are sent via KNX, the UI does not update. Is there a limitation that the automatic UI update does only work if there is a position_address_state group address available?

Thanks,
Sven

Joca · June 30, 2019, 6:55pm

For the UI to update the state, the actuator has to send the current state position.
Are you sure the actuator does not have the position state object? In some actuators it is necessary to activate the position state in the parameters.

rak · January 18, 2020, 8:50pm

Hello,

I have the same problem. The actor has no state position object. What about assuming if we have received a down on move_short_adressat all the cover position gets immediately set to 0 and when we receive an up its immediatly set to 100%.

Because as how it is now its not really usable for me. The cover does not update when triggered directly within KNX. Its always closed. All rules/automations dont really work, because the cover is so “clever” that it does not send UP when the cover is already open.

Doesnt help with no state position object for me the KNX cover is not usable.

Am I missing something?

Regards
Ralf

kammmuschel · January 30, 2020, 7:56pm

I am having exactly the same problem. I got everything working (more or less) via Home Assistant, but no status change when controlling the cover via the physical buttons. Can this not be fixed somehow in the code? The component should listen to the addresses move_long_address and move_short_address and start/stop changing position in HA accordingly.

One thought: Could an alternative be a template cover and a lot of knx_event actions for up, down, stop. It is quite ugly, but I will try it out tomorrow.

rak · January 31, 2020, 5:49am

I was thinking of writing an app with python which does that. Listen to the long/short state objects and maintains a virtual position.

Let me see when I get time to delve into the AppDaemon ecosystem.

I had that within Mr. House written in Perl. Anybody here remembering the Mr. House solution 10 years ago?

http://misterhouse.sourceforge.net/

Another solution might be to set the position value to unkown during startup. It seems the service cover.set_position is only accepting 0-100 values.

Is there a way to set an entity to „unkown“?

farmio · January 31, 2020, 6:53am

@rak You may have a look at the Knx implementation. The virtual position calculator is already there. You may just trigger it from the binary GAs.

github.com

XKNX/xknx/blob/ef18a0fa4795655e275721a08ffc5605d4095b02/xknx/devices/cover.py

"""
Module for managing a cover via KNX.

It provides functionality for

* moving cover up/down or to a specific position
* reading the current state from KNX bus.
* Cover will also predict the current position.
"""
from xknx.remote_value import (
    RemoteValueScaling, RemoteValueStep, RemoteValueUpDown)

from .device import Device
from .travelcalculator import TravelCalculator


class Cover(Device):
    """Class for managing a cover."""

    # pylint: disable=too-many-instance-attributes

This file has been truncated. show original

You can return None to current_cover_position() for unknown state.

kammmuschel · January 31, 2020, 11:52am

Here is my solution now. Ugly, but working fine.

KNX Cover: down_living_screen
Template Cover: down_living_screen_ctrl used in HA UI to control the cover. On OPEN/CLOSE/STOP it always first sets a input_boolean to ON, then moves the actual KNX cover.
Below automation will listen to the KNX bus. If message is received, check the input_boolean mentioned above. If ON nothing happens as the message was triggered by HA, so all is fine. The input boolean is turned OFF again. If the input_boolean is OFF, then the KNX bus message was triggered from elsewhere, so the OPEN/CLOSE/STOP functions of the Template Cover are called. (Unsolved problem is that this will trigger a second message to the KNX bus, but as it is the same message as received, it doesnt really matter.)

KNX Cover:

 - platform: knx
   name: down_living_screen
   move_long_address: 3/3/225  
   move_short_address: 3/3/226
   travelling_time_down: 19
   travelling_time_up: 19
   invert_position: true

Template Cover:

- platform: template
  covers:
    down_living_screen_ctrl:
      open_cover:
        - service: input_boolean.turn_on
          data:
            entity_id: input_boolean.cover_screen_ignore
        - service: cover.open_cover
          data:
            entity_id: cover.down_living_screen
      close_cover:
        - service: input_boolean.turn_on
          data:
            entity_id: input_boolean.cover_screen_ignore
        - service: cover.close_cover
          data:
            entity_id: cover.down_living_screen
      stop_cover:
        - service: input_boolean.turn_on
          data:
            entity_id: input_boolean.cover_screen_ignore
        - service: cover.stop_cover
          data:
            entity_id: cover.down_living_screen

Automation:

- alias: down_living_screen_bus
  trigger:
    - platform: event
      event_type: knx_event
      event_data:
        address: 3/3/225
    - platform: event
      event_type: knx_event
      event_data:
        address: 3/3/226
  condition:
    - condition: state
      entity_id: input_boolean.cover_screen_ignore
      state: 'off'
  action:
    - service_template: >
        {% if trigger.event.data.address == "3/3/226" %}
          cover.stop_cover
        {% elif trigger.event.data.data == 0 %}
          cover.open_cover
        {% else %}
          cover.close_cover
        {% endif %}
      entity_id: cover.down_living_screen_ctrl

- alias: down_living_screen_skip
  trigger:
    - platform: event
      event_type: knx_event
      event_data:
        address: 3/3/225
    - platform: event
      event_type: knx_event
      event_data:
        address: 3/3/226
  condition:
    - condition: state
      entity_id: input_boolean.cover_screen_ignore
      state: 'on'
  action:
    - service: input_boolean.turn_off
      data:
        entity_id: input_boolean.cover_screen_ignore

In config.yaml:

knx:
  fire_event: true
  fire_event_filter: [3/3/225,3/3/226]
  ...

rak · January 31, 2020, 2:11pm

@farmio, not sure if I get you right. You saying that virtual pos calculation is already in the standard KNX integration?

I have the problem that my KNX actors do not provide have a position state.

When I start HA it assumes all covers are down. Typically I code during a day so they are up. When the first automation kicks in it wants to send them down. Nothing happens.

I believe the system thinks they are down, so why send them down again.

Anyhow. Its anoying. I will try to set the position state to none on HA Start. That might work.

Will keep you posted.

svenihoney · January 31, 2020, 4:11pm

Hi @rak,

I already had a look at it, but no time to “fix” it. The position “calculation” is indeed done in the xknx module. But this is only done if the start and stop command has been initiated by xnkx, not by the commands on the bus. So this would be the place to look at, I did not have the python skills to find out where to lay my hands on.

Regards, Sven

kammmuschel · January 31, 2020, 5:12pm

It would be really great if someone could fix it. I had exactly the same problem like @rak with stating position after HA restart. My workaround is the template cover. To be exact:

In KNX Cover invert_position: true: This will make that it starts at position 0%, but the UP/DOWN buttons are inverted (=wrong)
Template Cover wrapping the KNX Cover. Template.open_cover calls KNX.close_cover etc. This corrects the open/close functionality. Issue: When the template cover is at 0%, the arrow down is disabled in UI. Therefore:
position_template returning 1 if position is 0 and 99 if position is 100. This makes sure that both arrows are always displayed, which I think is good.

Code:

- platform: template
  covers:
    down_living_screen_ctrl:
      open_cover:
        - service: input_boolean.turn_on
          data:
            entity_id: input_boolean.cover_screen_ignore
        - service: cover.close_cover
          data:
            entity_id: cover.down_living_screen
      close_cover:
        - service: input_boolean.turn_on
          data:
            entity_id: input_boolean.cover_screen_ignore
        - service: cover.open_cover
          data:
            entity_id: cover.down_living_screen
      stop_cover:
        - service: input_boolean.turn_on
          data:
            entity_id: input_boolean.cover_screen_ignore
        - service: cover.stop_cover
          data:
            entity_id: cover.down_living_screen
      set_cover_position:
        service: cover.set_cover_position
        data_template:  
          entity_id: cover.down_living_screen
          position: "{{position}}"
      position_template: >-
        {% if state_attr('cover.down_living_screen', 'current_position')|int == 0 %}
          1
        {% elif state_attr('cover.down_living_screen', 'current_position')|int == 100 %}
          99
        {% else %}
          {{state_attr('cover.down_living_screen', 'current_position')|int}}
        {% endif %}

rak · January 31, 2020, 5:27pm

Short idea. Cant test it right now. Should we expose the cover items back to knx?

rak · February 18, 2020, 3:54pm

Update here in this round. I cant make this work. Really a pitty. My cover automations will just fail always bc of this. Situation is as follows:

my actors dont have a position signal
they can be operated perfectly from with in HA
if I operate them from the knx hardware/switch the state does not get updated in HA at all.

rak · March 7, 2020, 7:24pm

WAF is going down significantly. Any help on the horizon? Otherwise I need look into this appdaemon thing. Learning a full new tool and programming language just to have blinds go up and down seems a pitty.

There is a ticket already for the KNX component already

UPDATE:

Heureka, I got a tip from one of the xnkx developers and created a workaround.

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.

There is a follow up discussion going on here for a better solution which also creates positions between 0 and 100%.