Configurable COVER entities to invert close/open

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:

    • 100 means not covered, open
    • 0 means covered, closed
    • an increasing value means “opening”
    • a decreasing value means “closing”
  • In the front end

    • “opening” means upwards
    • “closing” means downwards
    • “open” means that the “down” button is inactive
    • “closed” means that the “up” button is inactive
    • not “closed” means “active” means yellow icons
    • “closed” means default icons

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.

2 Likes

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.

1 Like

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.

9 Likes

Any news about this?

1 Like

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.

3 Likes

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.

6 Likes

Any news on this feature request ?

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 :wink:

1 Like

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}}
2 Likes

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%."
1 Like

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:

  • In Home Assistant, a position of 0% typically means the shade is fully open (rolled up), and 100% means it’s fully closed (rolled down).
  • In HomeKit, it’s the opposite: 0% is fully closed, and 100% is fully open.

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:

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

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

  3. 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:

  • When HomeKit sends a command to set the shade to a certain position (e.g., 30%), the position variable receives this value.
  • The set_cover_position inverts this value (100 - position), so Home Assistant sends the correct position (e.g., 70%) to the actual shade.
  • The position_template ensures that the reported position back to HomeKit is also inverted, keeping both systems in sync.

Would love to know why this isnt a thing?? All of my 23 external shutters work correctly… but display in reversed in HA. A simple config setting to tell HA the inverse the display would be great.

2 Likes

Same here… since years hacking around to get my shade displayed as it makes sense to me. Last solution was vertical stacked mushroom template card for the icon and state inverted together with a mushroom cover card only for the buttons to control the shade, all with a ton of card_mod styles to look good.
Currently using a cover template for inverting state/position and service calls to open close and using tile card with “Custom Features for Home Assistant Cards” from HACS to actuall paint 3 buttons with the correct service calls and style template to disable them if it doesn’t make sense…
Waiting for the next change in HA or any of the used features which forces me to fix it again somehow

Would love to have this fixed once for all with a simple setting to invert positions, actions or states. At least thee actions would be nice, because I can fix the state/position with a cover template, but the buttons are then wrong.