WHY THE HECK can't we freely configure a Cover to interpret its percentage value as "percentage open" or "percentage closed"?

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

yeah, some people need more detail than open/closed…


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???

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.

:rofl:

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.

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

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.

1 Like

@Jpsy, I don’t wont to bury this hope :slight_smile: !! 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…?

For me the current behaviour is also not correct.

Roller shutter completely open should be 0
Roller shutter completely closed should be 100.

I hope that this will changed so that moving the slider to the right will close the cover and not open it.

This works for the slider (now slider to the left means open, slider to the right means close).

But the Up and Down buttons are now wrong. How can I invert those buttons as well?

Not possible. I have investigated several hours / days to find a solution. The only chance is a change in home assistant, but who knows if this ever will happen.

Best regards

Okay…yes I hope that they will change this soon. It should be a very easy modification I think.

The issue here is that value_template and position_template cannot been set concurrently in a template cover, so HA assumed the cover is open, when position is 100 and cover is closed when position is 0.

I found a “solution” which fits my needs, using two rows in an entities-card, except than just one. The first row uses the original entity, to control the cover with the buttons, the second row shows a slider and uses the template reverse entity, like the one you have:
image

  - type: entities
    entities:
      - entity: cover.rollladen_arbeitszimmer
        name: Rollladen
      - entity: cover.revers_rolladen_arbeitszimmer
        type: custom:slider-entity-row
        full_row: true
        hide_state: false

For the slider I use the custom slider-entity-row:

There is another custom card I use, which looks a bit different, but works for me too:

Maybe this helps you to find a solution, that fits your needs :wink:

1 Like