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

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

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).

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.

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.

Hi!

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

Beta is live. Time for testing :wink:

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!

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

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

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.

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

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.

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.

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.

Your points 1 and 2 are correct. When you have a position address set up the times are still used to calculate intermediate positions.

Best practice is to configure everything you know about your cover. It may vary slightly on different manufacturers actuator implementations but generally it will try to do the right thing given any valid configuration.

1 Like

Hi @farmio, hi @ll,

I’ve read the thread and it might be already solved for others. Its more like two short question to be sure (I have MDT as well):

travelling_time_up/down will be ignored or not used if actuator provides the values?

I have configured them in HA as test case with 5 seconds each, but HA still uses the 23 secs configured in MDT actuator. Playing around with different values for up/down doesn’t changed the behavior, only MDT actuator values in ETS had an effect. So I’ve removed them from yaml, might this result in problems?

→ does HA try to write the calculated “position value” to the position_address?

If yes, who will win? HA or MDT actuator who’s also using it? Or will it be ignored from HA, cause actuator is using it?

Imo I should just use the integration without the traveling times, cause it looks like they aren’t used. (Version of actuator, ETS, HA, etc. is latest possible).

Thx a lot for your help

No. It is only written when you set a different target value.

If this would be correct with the 25 seconds, I would assume, that my 55 seconds KNX time for a specific cover should stop after 25 seconds, if travelling_time_ values aren’t configured, like they are at the moment (not configured).

But the cover closes as expected over HA without these values. Don’t get me wrong, I like it, but I wanna understand it.

If I tell HA to use it 5/5 seconds for up and down it ignores it. Only KNX values will be used. Is this correct or am I doing something “wrong”?

You said, you read the thread :upside_down_face: it is explained here.

So whenever a new position state is received, time based calculations are discarded / reset.

How a tiny little word (precedence) can be overlooked more than once :smiley:

Thx for the quick response and explanation. It works as expected for me without the time lines in yaml. Still great to have them in case you don’t have an actuator with this feature.

1 Like