I would be nice if we can invert the open and close functionality for the cover entities. I’m coming from domoticz where this was possible. For some entities it’s unlogical, for example:
We have some roller shutters in our house. No I need to “open” them for the window to be 100% covered. For us its more logical to “close” them.
But for our folding arm sunshade it’s more logical to “open” it and shield us from the sun on our patio. (This is now the default in home-assistant)
I’m all for this one.
I found it strange when building a blind cover in esphome yaml and controlling it in HA or pressing the hard buttons - watching my blind go up (opening) and the cover position move towards 100 (filling the bar) and vice versa, closing and the pos moving towards 0 - just feels wrong
I’ve attempted to compensate this in lambda code but it seems HA has a tie into the cover position and open closed states, the HA button (open / close) controls dont seem to function correctly when i did this. (Reverted my code now)
I would also love to see additional flexibility with the Cover template.
However, I may be wrong but I think that it’s quite complicated. I don’t think that the problems would be completely solved by being able to invert the 0% and 100%. The way that the front end interprets 0 and 100 needs to be flexible too.
At the moment there is a link between: (a) the concepts of “open/closed” and “up/down”; and (b) the concept of being “not closed” and being “active”.
Apologies if I’ve got this slightly wrong but it goes something like this:
In the back end:
In the front end
These semantics make perfect sense for blinds/shades. Not so much for projector screens or awnings where opening is downward and closing is upward.
Also, as it stands, reversing the meaning of 0 and 100 can break the semantics front end. E.g. no up/down button when you need one.
I raised this on Discord last year and they suggested that I raise the topic in the architecture forum but it really didn’t get any attention at all. FYI, here is my post. Maybe some upvotes there may get this some attention?
In the post I suggest that device class could be used to define the semantic mapping of the back end to the front end. However, for full flexibility, I think that there needs to be some way to map the “extension” of the cover (whether it be 0 to 100 or 100 to 0) to the concepts of “up/down” and “open/closed”, “active/inactive” (or “on”/“off”) in the back end, removing all logic from the front end.
Obviously I’d be happy if alternative, better suggestions were to come out of this too.
Thinking about it, I remember why I was suggesting additional device classes. A cover only has one state in the back end so device class sees like the best way to tell the front end how to interpret it.
I’m surprised to find that this doesn’t exist yet, as the need seems common enough to warrant the feature. I would love to see this at least in the customize section of configuration.yaml if not also in the entity config UI.
A workaround exists to make template entities to invert the behavior of position and open/closed, however that’s adding a lot more complexity to config and has proven to be problematic for average users to accomplish, or even discover the workaround. In my case of 8 blinds I want to invert, that’s doubling my blind entities, adding more yaml to manage, and adding confusion when I need to reference them in scripts, automations and dashboards.
Adding a simple toggle to invert the behavior would be a great improvement.
Any news about this?
Just to be sure, only workaround is using cover template right? Or am i missing a HACS repo
I’m adding here since my request was closed as a duplicate. I don’t feel that a simple inverting of open and close is sufficient. Blinds are closed both downward and upward therefore 0 should be closed down, 50 fully open horizontal and 100 closed upwards. This shouldn’t be difficult as this is exactly how the new SwitchBot blind tilt motors work. Currently if I use HA to simply close an open blind, I have no way of knowing if it will close upwards or downwards. It seems like this addition would better differentiate blinds from shades which are currently the same thing and function the same way.
I would also really love to see this feature. I have a lot of covers that work inverted. One simple solution would be just to have custom icons on the cover card (it’s a workaround, true cover customization would be better).
I would love to see this feature as well! Even just for the simple fact that seeing my dashboard and having my [mushroom] cover cards’ bar being shown as “full” when the blinds are open is misleading to my own brain. In my head, the bar should be “empty” when open and “full” when closed.
I would love to see this feature as well. It is not the first visualization solution I’m using, but the first that gets this basic wrong.
Fully support this request. To make this more concrete, I put together what I’d consider as requirements to get this flexibility implemented - as basis for further discussion:
(0) Starting point: Physical/Raw Position
What all covers have in common, is the ability to move “something” linearly between two end positions A and B. This movement is represented by a position value between 0 and 100. Let’s call this raw_position, which is controlled via commands
raw_open → move towards raw_position = 0
raw_close → move towards raw_position = 100
(1) Configurable Display Position
We want to be able to invert the interpretation how position 0 and 100 maps to the physical end positions A and B. Let’s define a setting
invert_position: (false)
which defines how the actual position value relates to raw_positions:
position equals raw_position if invert_position == false
position equals 100-raw_position if invert_position == true
(2) Configurable open/close directions
Allow inverting the direction of open/close command via new setting
invert_open_close: (false)
open performs raw_open and close performs raw_close if invert_open_close == false
open performs raw_close and close performs raw_open if invert_open_close == true
(3) Configurable States / Tristate
The usual opened and closed states represent end positions. And additional intermediate state is suggested, which is assumed whenever the cover is no fully opened or closed.
The relation between state and position is defined via new settings
opened_upper_bound: 0
opened_lower_bound: 0
closed_upper_bound: 100
closed_lower_bound: 1
i.e. the state opened is assumed when position is between opened_lower_bound and opened_upper_bound, analogously for position closed. The state intermediate is assumed in all other cases. (see notes 1 and 2)
(4) Configurable Active State
Add a setting that allows to define which of above states is considered ‘active’ (–> e.g. causing the icon to be colored yellow in the standard UI representation)
active_opened: (true)
active_intermediate: (false)
active_closed: (false)
Summarizing:
Above logic adds a flexibility layer between the cover entity as defined in home assistant and the physical cover. With the given default values, the behavior is unchanged to the current way, but the new settings allow hopefully most other interpretations that have been discussed in this and related threads.
In analogy to above, tilt_position should be handled in exactly the same way, to add this flexibility also to tilting covers.
How to implement?
I am trying to contribute as much as possible with above ‘specification’, but unfortunately, my development skills are limited, and I won’t be able to implement that myself. I’m hoping for someone knowledgeable to discuss my proposal and get this converted into usable code…
Note 1: With the given (default) values, the current behaviour is reproduced, to avoid breaking changes.
Note 2: I know that from a mathematical point of view, there should be a possibility to distinguish between “less than” and “less than or equal” for the bounds, as position is continuous and should be a float. With above default values, in fact, the state would be intermediate for the case 0 < position < 1 (e.g. position = 0.1), but I’m not even sure whether the current implementation allows float values here or is limited to discrete integer position values.