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.)
I had to google it to even understand it so I think you’re probably safe but who knows these days…
1 Like
I will give my two cents. And as I write this I have a smile on my face and I write it in this lifted positive mood.
You are all wrong!!!
Explanation.
All my blinds are Venetian blinds.
0% is closed
100% is closed
50% is open
But 20% open/closed and 80% open/closed is not the same. In one position the sun light can come in from the top but it is difficult to look in. I use this when I am not home but want to give my plants some sun light. And 20% or so is used when I do not want to be blinded by the sun but I want a little light to come in.
In my daily life I have simply setup a Zigbee remote which can do short, long, and double press and I have defined long and double press to go to pre-defined values and then I do not see or think about %. Or I can short press to step up and down.
I defined my Covers in MQTT like this
- platform: mqtt
name: "Workshop Blinds"
command_topic: "workshop-blinds/set"
state_topic: "workshop-blinds/position"
position_topic: "workshop-blinds/position"
set_position_topic: "workshop-blinds/set"
retain: false
payload_open: "50"
payload_close: "0"
payload_stop: "85"
state_open: "50"
state_closed: "0"
optimistic: false
device_class: blind
And that works with my voice control. I can say Alexa Open the blinds or Alexa Close the blinds. That sets them to 0% or 50%.
The fun come when I want to close the blinds in the other end to 100%.
I say Alexa - Set the blinds to 100%. And then something somewhere interpret that command to Open and the blinds go to 50%. So when I use voice I have to say - Alexa, set the blinds to 99%.
The important message of all this is
- Not all covers are equal. Some are open in a middle value.
- Please ensure that the implementation of covers in Home Assistant allows the flexibility to define open as a value mid range. Or as many suggests swap 0 and 100. In my case, I can define my 0 and 100 to whatever I want as I have written my own ESP8266 code controlling the stepper motors. Important for me is that I can continue to define open as 50% which means the venetians are 90 degrees to horizontal.
6 Likes
Then make a template cover to account for that in the meantime. And long term, write up an issue against that integration.
You can. You just need to define it properly.
cover:
- platform: template
covers:
garage_door:
device_class: garage
friendly_name: "Garage Door"
value_template: "{{ state_attr('cover.xxx', 'position') | int == 100 }}"
open_cover:
service: cover.open_cover
entity_id: cover.xxx
close_cover:
service: cover.close_cover
entity_id: cover.xxx
stop_cover:
service: cover.stop_cover
position_template: "{{ 100 - state_attr('cover.xxx', 'position') | int }}"
set_cover_position:
service: cover.set_cover_position
data_template:
entity_id: cover.xxx
position: "{{ 100 - position }}"
Seems overly complicated???
1 Like
A VERY good point.
I have no motorised venetian blinds but…
I think I’d template them, so maybe 0 was horizontal and the two extremes would be - 50% and +50% for inside lip down and inside lip up respectively.
Getting a voice assistant to interpret that would be a nightmare though.
This is the point of these discussions, to get these use cases and try to interpret a ‘method’ to control your devices
To extend your analogy further, maximum light (on the sun ward side of your house would be related to the sun’s angle, whilst on the shade side it would just be horizontal.
Privacy depends on if your peeping Tom hides in the bushes or uses a step ladder, still, as I have no mirrors on the ceilings, I think I’d prefer him to be admiring the ceilings.
Edit: given this, I’d make my life easier and template it to open == 100% == horizontal and closed == 0% == inner lip up, dunno.
Except for the funny thing that setting to 100% with Alexa is interpreted to 50% everything works great as it is. At least for the MQTT type cover
I just warn against someone changing the current flexibility so that you cannot define open to anything else than 100 or 0 %
1 Like
Thanks to all of you for your dedicated input. I did obviously express a rather controversial demand.
As a result of the intense discussion I have now update the original posting of this WTH.
I honestly hope the new text meets the bottom line of what has been said here.
This is the new title and tenor:
WHY THE HECK can’t we freely configure a Cover to interpret its percentage value as “percentage open” or “percentage closed”?
5 Likes
It’s not about templating, but flexibility in configuration for people who are new to HA - introducing that type of friction is off-putting to new users - and telling them to think differently is not the solution.
It’s not personal, you responded to and quoted part of my post. You chose to tell me I was wrong because the way I think about something is not the way you do…
I don’t require your technical support, I’m quite capable of forking the integration and invert the covers if I choose to. The point isn’t about what I can or can’t do, or that I can template, it’s about what is the best approach for everyone when considering users of all experience levels.
1 Like
No, I didn’t
All I said was your statement was ambiguous. (there were others things I could ascribe it to but I chose ambiguous)
I then went on to try to explain where the industry norm ‘may’ have come from (as we see so many examples following the same vein), supported by a great many on this thread with examples from their experience.
I also tried to give a conceptual interpretation that would perhaps allow people who are less inclined to think as people who control stuff for a living, get a handle on things.
I quoted you, as you gave the most recent (to the time I posted) example of the ‘conflicted’ opinion.
You further went on to use ambiguous language in explaining your point (which is kinda my point about a consise description about the operation of these covers).
If you are capable of forking the integration then you are capable of writing up the pull request to get that fork re-integrated (though it would have to pass the PR process)
I genuinely wish you luck with that.
And if it passes muster, and provides a functionality that I feel is useful and well implemented then I would be happy to use it myself.
I actually know where you are coming from, as many people think the same as you. But my other point is - “who cares ?” once the automations are written and tested the ‘value’ should be irrelevant to the user because the interface (ie the bit that I’m responsible for) hides the ‘nitty gritty’ from the user. Refer to Marius’s example, even if you have to translate from Dutch.
I was going to cite an example about lock conventions too, but again, who cares as long as the user can lock/unlock it.
Edit: home automation is about home automation, not turning your computer into a big remote control. If I have to pick up a device to control something, I think I’ve failed (not quite perfected it yet)
1 Like
Where can I vote for this feature? The logic is driving me crazy as well… I’m coming from the KNX world. In KNX 100% is also closed. Best regards
1 Like
You can vote for it last month.
1 Like
Scroll up all the way to the top. The vote button is there.
Hello, could we start discussion how this feature could be implemented?
As you see in my name, I’m using in most cases KNX components. In KNX open is cleary defined as 0%. All my KNX devices are showing 0% as open. Therefore it’s not nice that Home Assistant is doing this in the other way.
Most important question: Would the Home Assistant guys be willing to add this feature? This feature would have influence at a lot of places in the code.
If I understand it correctly an additional property woud be required for the cover entity, e.g. invert_position
Next question is what invert_position will do:
- Basically it could tell Home Assistant that the raw data of an integration are inverted. However, this would cause all integrations to be adapted. Don’t think this make sense.
- Another option is to keep the logic between Home Assistant and integration as it is. Then the paramater would ‘just’ tell lovelace and all the services to handle the entity inverted.
Looking forward for your comments.
1 Like
This property already exists for the KNX cover entities. But it is meant for KNX actors with inverted logic. It will not invert the logic in HA itself.
For me the 100% == open logic is still very disturbing. And I found it interesting how much the feelings towards it differ in this thread. I also do not see any context that seems to define groups here. We have Americans and British here which support both sides. We have engineers who claim that HA supports the right view but the simple fact that KNX with all its engineering history chose the opposite paradigm proves them wrong. Very strange.
But I also have concerns about introducing such an inversion flag in HA. It would affect an incredible amount of code. And @farmio already had his fair share of struggle with the inversion setting in the KNX integration alone. I realize that a generic new inversion feature would probably lead to a cascade of bugs and many integrations that would need months or even longer to get fixed. So personally I have buried this hope.
2 Likes
@Jpsy, I don’t wont to bury this hope 
!! That’s the reason why I want to discuss this here again. Nobody will change the KNX standard, therefore my switches will always show 100% as closed.
I think the problem is, that KNX is used mainly in Europe, but it is coming more and more, especially in the private sector.
I completely agree that changing the interface between integrations and home assistant core should not be changed (too many dependencies, not only to KNX integration). But what about a home assistant internal property to invert the behaviour…?