Extend Inverse Helper to support cover entity type as well?

[olympia]

Would it be possible by any chance to extend to inverse helper feature to support cover entity type as well?
This discussion is popping up from time to time, one of the better threads about the topic is here: https://community.home-assistant.io/t/cover-entities-that-are-0-open-and-100-closed/581979

In summary, it would be more than helpful for many of us to see an inverse logical interpretation of “open” and “closed” for a cover, meaning 0% = open and 100% = closed.

[frenck]

That won't work. As cover considers 1-99% open and 100% closed, flipping that, will result in 1-99% closed and 100% to be open. That behavior is odd.

[olympia]

What I am currently experiencing (Somfy shutters using Velux GW integrated with HA via Homekit) is this:
0% = closed
1-100% = open
I think this is close to what you considered as odd. I and many others consider this as odd too if you read the linked thread. There are many other forum threads in HA forums discussing the same and trying half baked workarounds.

This is not the same what you say how this should be (1-99% open and 100% closed), however this logic also seems to be odd for many of us. What state 0% should be then if only 1-99% should be referred as open? And if a cover is lowered by 30%, then why it should be open 30% and not closed 30%?

Considering we're dealing with cover entities, the position should correspond to the state of the cover. Thus, when the cover isn't covering the window, it should be at 0%, indicating an open state. Conversely, when the cover is fully closed and covering the window, it should be at 100%, indicating a closed state.

What I and many many others would like to achieve is:
0% = open
1-100% = closed

The confusion might also come from the likelihood that different vendors and integrations might employ weird logic and that's why we should have options and tools in our hands to revert the rebel behavior.

At the end you are also saying yourself in the Spook documentation for the invert feature that: This can be helpful if you use a switch or binary sensor in a non-standard way, or when the manufacturer of a device has decided to use the opposite logic for the switch or binary sensor (Yeah... they exist...)

[frenck]

I'm happy to access a pull request that add working inverse logic for covers, don't get me wrong.

I know this has been attempted to implement in Home Assistant core itself as well, which was cancelled, as no one has been able to figure out a working implementation.

../Frenck

[olympia]

Unfortunately this is not something I can code myself, otherwise, I would have surely already submitted a PR. :(

I know this is going outside of the scope of spook, but while I have your attention:
As a starter, would it not be feasible to allow the configuration of value_template and position_template within a template cover independently from each other? Or are they that much tight together logic and code wise?
...because this would at least allow us to workaround the issue.

Currently we can make the position inverted by adjusting the position_template, but since it's not possible to flip the states via value_template when position_template is being used, it will end up in the wrong interpreation by HA:

[frenck]

As a starter, would it not be feasible to allow the configuration of value_template and position_template within a template cover independently from each other? Or are they that much tight together logic and code wise?

Then just use the templates already available? 🤷

../Frenck

[olympia]

What I am trying to say is that currently it is not possible with the templates what we want to achieve, because value_template and position_template doesn't allow independent configuration. Hence my question if this would be feasible to change.

Currently we can make the position inverted using the position_template, but it's not possible at the same time to flip the states via value_template, because position_template is being used:

[jorismocka]

Hi Frenck,

for me it would be useful too. Just invert 100 to 0 and 0 to 100. Means - for the command "open cover livingroom", currently it will close because they are false mounted but I cannot get an electrician to fix it - that is the reason why I like to inverse them.

The original cover entity still exists where I can work with percentage. Just the "virtual" inversed cover will close or open inversed.

[meiser79]

Hi, may I kindly ask to continue the discussion here? I'm also interested in inverting the open/close logic for my awning. Thanks!

[olympia]

Hi Frenck, hope you're well! With @meiser79 bringing this up again, I thought it might be worth a quick recap.

Just a small note on your earlier reply. You mentioned "1-99% open and 100% closed," but the dev docs and user experience actually define it as 0% = closed and 1-100% = open (referring to how open is the window). Wanted to clarify in case that changes how you see the feasibility.

What many of us would love: An inverse helper for covers that flips the position (0 and 100) and correctly maps the open/closed state accordingly. So that we'd get: 0% = open (window is not covered) and 1-100% = closed (window is covered or partially covered).

The existing template cover workaround could also help, but unfortunately falls short, because value_template and position_template can't be set independently. Inverting position causes HA to derive the wrong state.

This has been a long-standing wish across the community (the 2020 WTH thread, 10+ forum posts, affecting KNX, Z-Wave, Somfy, MQTT, Tuya, ESPHome users and more). Interestingly, the WTH thread also revealed that opinions split along cultural and professional lines: engineers and native English speakers tend to read 100% as "100% open" (like a valve), while many European users read it as "100% covered." Neither side is wrong, which is exactly why a configurable inversion is the only fair solution.

Spook's inverse helper feels like it could be the most elegant path forward in the absence of a HA core solution. Thank you for all the amazing work on Spook and HA! 🙏

[olympia]

Hi @frenck,

I noticed that #1327 (Add inverse cover helper support) was closed today without being merged, and I wanted to follow up here rather than on the PR itself, since this thread is where the request originally came from.

I'll be honest, I was quietly hopeful when that PR appeared back in June. From the outside it looked like it did exactly what this thread has been asking for since 2024: inverted position, a correctly derived open/closed state, and the commands mapped accordingly. It also seemed to line up with your earlier reply here, where you said you'd be happy to accept a PR that adds working inverse logic for covers.

Of course it's your project and entirely your call what goes in, and I fully respect that. But if you have a moment, would you mind sharing what the blocker was? Whether it was the semantics, the maintenance burden, edge cases like tilt, covers without position support or stop behaviour, or simply that this isn't a direction you want Spook to go in. Even a single line would genuinely help, because this is still one of the most requested ideas in the repo and people keep landing here looking for an answer.

If it's more a question of validation than direction, I'm very happy to test the branch on my own setup (Somfy shutters via the VELUX gateway and HomeKit, plus Zigbee covers) and report back with real-world results. And if the honest answer is that it's not going to happen, that's completely fine too. Knowing it would at least let those of us following this thread stop waiting and invest in our own workarounds instead.

Either way, thank you for everything you do for Spook and for Home Assistant. 🙏

[frenck]

No panic. That was an experiment with an AI agent.

It is still on my list to explore, but I've closed up that generated slop specifically :D

../Frenck

                       

Blogging my personal ramblings at frenck.dev

[olympia]

Thanks for clearing that up 😄

One thing worth knowing before you spend time on it, from trying to build this for myself...

I was able to make the backend helper half working: inverting position, deriving closed from the helper's own position (0% = open, 1-100% = closed), leaving the commands alone. A fully lowered shutter then reads 100% and closed.

However, I wasn't able to solve the visual half: ha-state-control-cover-position feeds current_position into ha-control-slider with no inverted, and in vertical end mode the bar is anchored at the top and slides up as the value grows. So the helper at 0% draws a fully lowered shutter labelled Open, and at 100% a retracted one labelled Closed. Numbers right, graphic upside down. Please see the screenshot as a reference. ha-control-slider does support inverted, but nothing ever sets it, and #17687 asked for the same thing on the tile feature and was closed on UX grounds.

So: is the slider direction settled for good, or is there a path? That one answer decides whether the visual side is worth anyone's time, or stays a custom card forever.