[Cover] Cover Integration. Missing Functionality (Locking, Rain-, Wind-, Frost-alarm)

Hello together,
first I want to say, that I really like the KNX integration to Home Assistant :smile:

Currently I implemented a “full” feature KNX Blind.
This Blind i wanted to integrate into Home Assistant and the following features (“group adresses”)
were missing.

1. Locking the Blind

  • for example if the balcony door is open to not lock your self when automation wants to close the Blinds
  • current implementation just keeps continuously updating the percentages etc. even if the blinds stop because they are locked
  • Feature requested: it would be nice to have the option to set a locking_address in the cover configuration, whitch then locks the control from Home Assistant and shows (for example) a lock symbol in the UI

2. End Positions (Top and Bottom)

  • Feature requested: it would be nice to be able to set the End Positions Address within the config (top_end_stop_address; bottom_end_stop_address). Maybe there could be also a indication in the UI.

2. Rain-; Wind- and Frost-alarm

  • my current blind control unit can also handle some alarms (mentioned above), where it automaticly drives the blinds if a certain alarm was set (open or closed; can be configured).
  • Feature requested: also there it would be nice to have the option to set the rain_alarm_address … in the config. The UI should then also show some icon to indicate that the alarm got triggered.

I would love to try to implement it myself, but unfortunately I don’t currently have the time or the knowledge to dig into it in detail :smiley: .
Thank you all in advance.

Hi :wave:!

Integrations can’t really add features not available in the Entity model. So I think your feature requests should target HA as a whole instead of the KNX integration. (Also the KNX aware audience here is not very big).

For 1) I opened an architecture issue a while ago (which was then converted to a discussin): Add locked state to Cover · Discussion #545 · home-assistant/architecture · GitHub
Rain/Wind/Frost Alarm is more or less the same. A cover in a state where it can’t be operated.

For 2) there is position_state_address. 0% in KNX means the cover is at open end position. 100% at closed end position. I don’t think it is necessary to add the complexity of 2 address configurations replicating this state as binary state. If a cover doesn’t support %-position its always possible to create an automation converting it - but these should be the least nowadays.

Hi back :wave: !
thank you for the quick response.
I was not sure where and how to address this Request, but thank you for the short introduction :slight_smile:

To 1) I think that this feature is really missing and would be great if it finds its way into the official release.

If I understood the Discussion correctly the Rain- Wind and Frost-Alarm will or might be the “same” as locking the cover and restarting it if the alarm is no longer active.
Currently I’m playing around with the KNX Cover and there you can select what should happen when the Alarm is active (drive to the top/bottom; stay still; …). In addition you can not drive the cover away from its selected position as long as the alarm is active.
Do you think that this would be some interesting point for the discussion, because would introduce some additional complexity :smiley: ?

To 2) I am totally on your side. I might just have copied the features from my KNX-parameters in here without thinking :sweat_smile:.

You hit the right place - architecture repo isn’t meant for feature requests.

I think the behavior at the beginning of an alarm / lock can always be reflected by current_cover_position property from the actuator.
Behavior after the alarm / lock state is cleared should be the actuators job / configuration. (in german: “Nachführen”)
But I come from a Knx point of view where this option is commonly available. (One can always create an HA automation for this if it is not available). No idea how more commonly used integrations handle this.

Im sorry to ask, but its my first interaction with the forum and HomeAssistant feature request.
What is or what would be the next steps for the feature request?
Sorry if its a dumb question :sweat_smile:

Well if you ask me I’d remove the “KNX” reference in the topic and the first post and rephrase it as a general HA feature request - or open a new one. I’d guess 99% of forum users aren’t familiar with KNX / haven’t heard of it at all (0,6% of HA analytics users use the KNX integration) so they will not look into this.
As stated earlier, there is nothing the KNX integration can do as long as the HA entity model doesn’t support it - believe me, we tried Adds locked attribute to KNX covers by marvin-w · Pull Request #48990 · home-assistant/core · GitHub :man_shrugging:

That said, I think you have 3 options:

  • find someone who is willing to implement your idea
  • implement it yourself
  • watch this thread disperse in the noise of the forum

On the other hand, I’m no expert… I have 3 open feature requests here and only 1 got a vote :no_mouth:

This is unfortunate to hear. Also you write like you have tried multiple times :sweat_smile: .
Anyway I would follow your suggestion and write another Feature request and will link all the informatons you have sent me, If its OK for you?
Maybe we could get the “critical mass” at some point in time :smiley:

1 Like

Sure, go ahead!

I have added another Feature Request. This one will be closed.
If someone comes around here please refer to this Request :smiley:.