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.
In my opinion, “inverting” of an entity should be a default feature for most entities / Device Classes…
That would make life so much easier in some cases 
This is indeed a great summary of specifications, and to me look pretty exaustive…
+1 for this.
I’m using a shelly to control my motorised projection screen, but it shows as “open” when raised and “closed” when lowered, which in my mind should be the opposite. I can use “lower” and “raise” in my voice commands but having the option to invert the “open/closed” states would definitely be a welcome addition.
yes, and failing to have spotted this FR before, I believe it might be a good thing to post that template here, especially since I am not aware the feature will be implemented any time soon, if at all…
this is what I used:
cover:
- platform: template
covers:
raamverduistering_stookhok_inverted:
device_class: shade
position_template: >
{{100 - (state_attr('cover.raamverduistering_stookhok','current_position')|int)}}
set_cover_position:
service: cover.set_cover_position
data:
entity_id: cover.raamverduistering_stookhok
position: >
{{100 - position}}
Having stumbled on this issue today with matterbridge-home-assistant, I learned that the matter spec v1.3 uses 0% for open and 100% for closed. As matter is more widely adopted it seems this issue will become increasingly more relevant:
Command({
name: "UpOrOpen", id: 0x0, access: "O", conformance: "M", direction: "request", response: "status",
details: "Upon receipt of this command, the window covering will adjust its position so the physical " +
"lift/slide and tilt is at the maximum open/up position. This will happen as fast as possible. The " +
"server attributes shall be updated as follows:" +
"\n" +
"if the PositionAware feature is supported:" +
"\n" +
" • TargetPositionLiftPercent100ths attribute shall be set to 0.00%."
Hi,
for me it would also be nice, if I could change/invert the display of the state.
I think, a rollershutter is 100% closed and not 0% open.
My consent for this request.
Your answer is exactly how I fixed this! Thank you!! I hope you don’t mind, but I went ahead and summarized the issue and how your solution
resolves it for any other poor souls that stumble in here looking for a solution:
If you’ve integrated your shades (covers) with Home Assistant and exposed them to HomeKit, you might encounter an issue where the shades operate in reverse when controlled via HomeKit. This happens because Home Assistant and HomeKit interpret the shade positions differently:
This mismatch causes the shades to move in the opposite direction when commands are sent from HomeKit. Below is a generic solution to fix this issue by inverting the position values within your Home Assistant configuration.
Solution:
By adjusting the position_template and set_cover_position in your template cover configuration, you can invert the position values to align with HomeKit’s expectations.
Steps:
Create or Modify a Template Cover:
Use the template platform in your configuration.yaml (or included YAML files) to define a cover that inverts the position values.
Invert the Position in position_template:
Subtract the actual current_position from 100 to invert it. This way, when Home Assistant reports the position, it aligns with HomeKit’s interpretation.
Invert the Position in set_cover_position:
When setting a new position from HomeKit, invert the position before sending the command to the actual cover entity.
Generic Example Configuration:
cover:
- platform: template
covers:
my_shade:
device_class: shade
friendly_name: "My Shade"
# Invert the reported position
position_template: "{{ 100 - (state_attr('cover.my_actual_shade', 'current_position') | int) }}"
# Reflect the open/closed state
value_template: "{{ is_state('cover.my_actual_shade', 'open') }}"
# Open the shade
open_cover:
- service: cover.open_cover
data:
entity_id: cover.my_actual_shade
# Close the shade
close_cover:
- service: cover.close_cover
data:
entity_id: cover.my_actual_shade
# Set the shade to a specific position
set_cover_position:
- service: cover.set_cover_position
data:
entity_id: cover.my_actual_shade
# Invert the position here
position: "{{ 100 - position }}"
optimistic: false
Explanation:
cover.my_actual_shade: Replace this with the actual entity ID of your shade.position_template: Inverts the current position value.position_template: "{{ 100 - (state_attr('cover.my_actual_shade', 'current_position') | int) }}"
value_template: Reflects whether the shade is open or closed based on the actual state.set_cover_position: Inverts the desired position before sending it to the actual shade.position: "{{ 100 - position }}"
How It Works:
position variable receives this value.set_cover_position inverts this value (100 - position), so Home Assistant sends the correct position (e.g., 70%) to the actual shade.position_template ensures that the reported position back to HomeKit is also inverted, keeping both systems in sync.