My awning always reports state open as long as it is not fully expanded (when it reports closed). I’m using Dwain’s theme which shows all open covers.
My issue is, I’d like to see all awnings that are not fully retracted in order to see where I could have issues with wind. Of course it could be patched in the theme based on the attributes, but I was wondering whether covers or a subdevice class can be configured to have a state transition open -> partly_open -> closed. Is there a way to configure that or is this more like a feature request?
You’d have to make a template sensor. It’s not supported in covers. You may be able to template it with a template cover. But open or close functions may break when in the partly_open state. And that state won’t be translated into your native language.
Expanding on what Petro said, some people (whose devices support it) create sensors showing position.
I did a post on manual configuration of covers (I don’t have covers though), not too long ago. I’ll see if I can find it and post a link.
Edit: Found it.
Read the thread to find out what your cover supports, there are sample sensors and automations included
You could then automate closing covers if open by more than 40% and windspeed greater than 6.9 m/s (use your own thresholds)
My cover (awning) does support the position and yes I could create a specific template sensor, so thanks a lot @petro, @Mutt for the hints and tips. I will do this, but I was just wondering in a more abstract/generalized way:
Obviously it was decided to have 100%-1% mapped to open and 0% to closed. This totally makes sense to me for window shutters as the safe state I would say is closed, e.g. to avoid burglary.
For awnings I would more think of 100% is open and 99% to 0% is closed as an awning has it’s default state fully retracted (for safety, e.g. wind reasons).
So wouldn’t a differentiation based on the device class (or an device option to invert the mapping) help more people, e.g. avoiding template sensors?
Please note that the feature request will not get a lot of traction.
Covers operate under a single device model integration and all operate the same (at the basic level) Trying to change this will cause ‘some disruption’ code for standard solutions will not be transferable and the result will be chaos.
The best thing to do, if you can not live with this, is do as petro suggests and template the cover.
This leaves the back end the same and just displays it the way you want in the front end.
I’ll do a template cover and close this topic. @Mutt thanks for the insights, it still sounds a bit unnatural to me (why there are these device classes although they are all the same) but I trust your opinion.
I discovered that doing a cover template would still require me to fix the view, so I decided to patch the view. That way it works nice and there is no need to adapt the core home assistant. Thanks a lot for all the input!
