Coming from an Australian-english-as-a-first-language-entertainment-lighting-professional perspective, I would view a cover or blind like a mechanical dimmer inside a lighting fixture. They are both an opaque object that is progressively moved across an opening to control the amount of light passing through. Like an electronic dimmer, they are set to 100% for maximum light (open) and 0% for minimum light (closed).
3 Likes
Guys, please reconsider. This is NOT about valves our lights or dimmers. It is about covers. About blinds. About shutters.
Their job is to “destroy” the function of a window to let light in. Their job is to darken the room. They cover, blind, shut the holes in the walls. They do so gradually from 0% to 100%. When they are open you cannot tell that they are even there. 0%.
This is not about valves and engineers.
This is about my wife asking me if I need medication because I tell here to ask Alexa for “10%” when she actually wants to darken the room a lot.
5 Likes
Maybe also consider a marquee which would also be controlled by a HA cover entity.
Do you really want to set it to 0% to roll it out completely?
1 Like
I would say that covers are completely analogous to dampers. Dampers are just shutters (or blinds). They look similar, and have the same basic job to pass or block air or light from flowing through them.
I think the only difference is the perspective of what the percentage is meant to define, the device itself or it’s effect:
-
For the people that agree with this WTH, their perspective is that the 0-100% describes the device itself. Where the percentage is describing the device, not it’s effect. 0% means the device is doing nothing, and 100% means it’s doing all that it can do (to block light in this case).
-
For the people who think it’s correct as-is, their perspective is that 0-100% describes the devices effect on media that’s passing through the device (light in this case), and not the device itself. 0% means the device is not allowing any light to pass, and 100% is the device is allowing all of it to pass.
8 Likes
Language is not particularly logical, nor does is stay constant. I have learned to understand when people mean figuratively when they say literally, or that having a few bad apples is acceptable (despite spoiling the whole bunch). So I will adjust to people treating covers as openers.
What would be nice, though, is to give us a choice, as @anon43302295 was calling for. Just don’t call it ‘reverse’, otherwise we’re going to have this lovely conversation all over again 
2 Likes
Just let people inverse it as an option… don’t try to analyse why people think that way.
It’s clear that there are people who think 0 = open, 100 = closed and others who think 100 = open and 0 = closed. It doesn’t matter who is right, just that the software is counter-intuitive to a significant portion of its user base (and would still be if they flipped it).
Personally, I think a blind is 0% open and 100% closed - its function is to close, not open (i.e. the default of a window is to let in light, the blind’s function is to change amount the light transmission). I get people think the other way (i.e. 100% light, to 0% closed) but it’s not how I think. You won’t change the way I think, I won’t change the way you think.
But we can change the way the software operates.
9 Likes
Haven’t read all the posts, but with the variety of views I’d thought I’d add my solution - create an input_boolean.garage_door or input_boolean.blinds
then under entity_config for alexa, set the display category as “COVER”?
OR
create an 2 Alexa routines:
When you say “Alexa, open the blinds”
Then set cover to open or x%
When you say “Alexa, close the blinds”
Then set cover to close or y%
As has been repeated ad-infinitum, that is only one way of looking at it.
This should no longer about who’s opinion is right or wrong but about the option to choose the way the output is displayed. I’m sure if Jpsy added an a addendum to the original post to this effect it would gain more votes (from both sides).
3 Likes
For me it is a nightmare, too! My cover (Velux) returns 1 (not zero) in case the cover is closed! So what I*m talking about is that in some cases I need more flexability to define what closed mean.
I found this ambiguous at best.
It like saying I have 2 glasses, the first is 0% empty and the other is 100% empty - so you mean ‘full’ and ‘empty’ - no (you say) it’s 0% open (so it’s closed) and 100% closed (so it’s closed).
The problem is that people can’t be consistent, this is a relatively simple thing and they mix terminology and meaning. Further they can’t come up the an example that fits all cases (blinds vs awnings) - we did, but you’re not happy with that.
So let’s flip that and create a cover that is configurable.
- Dave : “I have a problem with my cover, I want it to go to 25% on this event trigger” (this is a ficticious help request example)
- Mike - “okay this bit of code will do that”
- Dave - “No that doesn’t work, it goes to 75% closed instead”
- Mike - “25 % open is 75% closed”
- Dave - “No, that’s not what I mean”
- Mike - “what do you mean ?”
- Dave - “Well I want to drive it 100% open when this happens, then I want to drive it 100% closed when that happens - but that doesn’t work either”
- Mike - which mode are you in ?
- Dave - what do you mean ?
- Mike - did you select reverse mode ? (or whatever you decide on)
- Dave - dunno, where would I check that ?
. - Another rabbit hole looms !
How about we change the terminology to ‘retracted’ so a blind is 100% retracted and an awning is 100% retracted and you draw your own conclusions from there ?
1 Like
I’m offended
Sorry about that Mike !
Well at least we can all agree on 50% open and 50% closed 
5 Likes
Set your tolerance sensor trip point to 100%.
1 Like
100% offended or 100% calm?
6 Likes
True, but I have a broken watch that is ‘dead right’ twice a day, that’s more than I can say about any working watch on the planet
1 Like
Not sure what part of my post indicated I invited your debate about the right way to refer to it. It’s pretty clear my opinion on that subject, it’s not changing terminology, it’s changing a frame of reference…
So I don’t care what you find ambiguous, at best.
So on a serious note, can this not be sorted out by using a template to invert the logic of the 0 and 100% ranges? I know it’s not as nice as simply having an option to choose, but perhaps as an interim solution until (if) we do get the option to invert?
1 Like
yes it can:
#https://www.home-assistant.io/integrations/cover.template/
cover:
- platform: template
covers:
raamverduistering_stookhok_inverted:
friendly_name: 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_template:
entity_id: cover.raamverduistering_stookhok
position: >
{{100 - position}}
7 Likes
Hmmm !
I find it best not to get personal on any forum as it tends to alienate people and harden their case against you.
@sparkydave 's suggestion above is a doable solution but involves a lot of logic behind it and this would be repeated for every ‘cover’ you wish to do this for.
But you do seem to have picked a confrontational approach and the people invested in your position may have some of the skills to do this for you, but you have literally (or is that figuratively (read up thread)) butted up to all most of the technically capable people on this topic. That’s not that someone may not assist as engineers like a good challenge, but they also don’t like to be ‘dissed’. (edit: see Marius’s post as an example of a template).
Having said that, I don’t think that’s what you want. (you have read two days)
I think you will want the standard component to be modified by the software devs who could do this, so that you can click a Box and ‘hey presto’.
This ‘convention’ about covers has been thought about long and hard by a lot of software engineers and there is a reason why they adopted this approach. And with the exception of the “Velux” (and perhaps a few others) example above (which could easily be solved with templating) every manufacturer seems to have gone the same route.
It’s at times like this I would start to question AITAH ?
Still, given that HA is striving to be ultra-user-friendly (especially to the non-technical) I’m sure the ‘configurable’ cover will be implemented.
Long live the GUI ! (I hope that was understood without flags etc.)