KNX Integration - Cover: Is traveling_time_up/down really used?

,
1

The early summer in Germany makes me use the blinds more often. My blinds are controlled by a KNX actuator and are integrated via KNX integration.

They also get position values (Position State) from the KNX bus. However, the status display fits neither in Homeassistant nor in HomeKit.

After approx. 24-25 seconds, it is displayed that the blinds are open or closed. Some blinds are actually only at 50%.

I therefore set the movement time manually with the following attribute. But no matter what I enter: Nothing changes.

travelling_time_down: 47
travelling_time_up: 47

Is the Travelling_Time or the Position state currently really used to represent positon of cover in HA or HomeKit?

Thx,
Sebastian

2

Hi :wave:!
Yes, it’s really used for KNX.
On movement the position is updated every second (I think) based on the configured time. However a received position state value has precedence and the calculation is restarted from that value. So when your actuators report wrong position states it will show wrongly in the HA entity too.

HomeKit has nothing to do with it - this is just the forwarded HA entity you see there.

3

Okay, thanks. But I watched the bus telegrams in group monitor and I can tell you - there is nothin wrong with it. The actuator starts at 100% when closed and counts down to 0 in a two second rhythm.

When I track the status in HomeKit, I can sometimes see two numbers. Once the values are counted from 0 to 100 within 25 seconds. Then the display switches to the real values sent by the actuator.

In my opinion, the behaviour is not correct.

4

🤷 I don’t know if HomeKit does something awkward with these values, but it doesn’t help to add an abstraction layer to find the source of the problem.
Just watch the HA entity in HA Ui and see if it behaves correctly.

How is the entity and the actuator configured?
Also logs of xknx.telegram and state_changed events would be helpful. KNX - Home Assistant

5

The position indicator of the HA entity shows the same behaviour. I goes from 100 to 0 within 25s and that it wents back to the real position (around 60%) and again down to 0.

The actuator is a MDT model, nothing special with it. I can control everything and position status is send in a 2s interval.

I can see the same faulty behaviour with my garage door, that is also configured as cover.

I would like to give you logs, but - as far I can see - there are no log files that I could easily upload. Logging in HA is some kind of complex thing - sorry, don’t have time for that currently.

It is not such a big problem to me - sorry.

6

This really seems like you have just not configured traveling times. It defaults to 25 seconds then.

7

The traveling time feature works perfectly fine for me and my covers.

8

May be the same issue as here: KNX cover position and status · Issue #71745 · home-assistant/core · GitHub
I can’t really test this on my installation as my actuators can only send position state when stopped, not continusly (eg. every second).

9

Yes, the issue shown in the first clip (reset of position state after 0) is exactly the same behavior.

If there is any fix I would test it.

10

Sure, but you’d need to have HA use an unreleased xknx version right now.
Otherwise just be sure to try the next beta release.

11

Hi!

I took a look into your changes at GitHub. I will report when 0.21.3 has been added to HA.

12

Beta is live. Time for testing :wink:

13

Hi! I downloaded and installed 2022.6.0 yesterday. Today I stripped down my configuration (no more unused travel-times) and started to move my garage door and my covers. So far an I can tell you: It is looking good!

Position state is displayed correctly and doesn’t jump anymore. Behavior in HomeKit is also correct! No more double state messages.

I think the solution is working fine. I will keep an eye on it!

Thank you!

14

Great. Travel time is not “unused”. It will always fall back to a default of 25 if not configured.

15

Ok, this is correct in terms of programming. In my case I say “unused” because actuators position states are primarily used.

16

Hi! I think found a weakness in the current implementation. If position_state_adress is set, and the actual position of a cover does not change after a position command (because of an error, misconfiguration, lock or whatever), the implementation does start to count for 25s and I looks like the cover is moving, while it is not.

I think the standard 25s travel time should be ignored, when position state address is available.

17

We couldn’t have opening and closing state anymore then.

18

Yes, I can confirm this problem as well.

It even doesnt work to stop the cover on the state like 50% by disabling the position_state_address.

19

I now changed the following:
before:
position_address: “1/3/82” [Adresse Position]
position_state_address: “1/3/83” [Adresse Position Feedback]

now
position_address: “1/3/83” [Adresse Position Feedback]
position_state_address: “1/3/82” [Adresse Position]

And now it seems to work better than before. But still not 100% correct. Btw, I’m using MDT Actors as well.

20

Could I please ask about the logic of the cover implementation?
If I want to move from fully open to 90% closed, which is KNX=90%, HA=10%.

How is this working if I provide in the yaml knx configuration of the cover only those infos:

  • only move_long_address & stop_address: it will have to calculate based on the default travelling time of 25s, right? so it will go 22.5s
  • only move_long_address & stop_address & travelling times: now it should be able to go to the accurate 10% position, correct? (There might be some issues however because it does not have the position_state_address → it can’t really know where it is… right?)
  • only move_long_address & stop_address & position_address & position_state_address: Now it doesn’t need the travelling times anymore, right? Because using the position_address it can just tell KNX to which position to move. Is this assumption correct? Or do I still need to provide travelling times? For what then?

It would be cool if you can share some best practices for this case.