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.