I’m running 0.111.4 and using roller blinds that don’t report position (RF using a Broadink Pro). If I stop the shade before it reaches the limit in either direction, I can’t continue in that direction until I move the shade in the opposite direction, stop it, and then can move it in the intended direction. This is purely a Lovelace UI thing as the direction can move however I need from service calls, automations, etc.
Perhaps my search-foo is weak, but the only thing I found was this GitHub bug report that listed it as fixed a while back: https://github.com/nervetattoo/banner-card/issues/31 and I’m not totally sure this is the correct component as it is for a “Banner Card” although I did comment there just to be safe…
It would seem as though this should be configurable. It’s quite annoying as-is and I have the opportunity to hear just how annoying my wife thinks it is every time she tries to manually adjust the blind opening.
Here’s an example from the entity card she uses a lot. Currently the shade is at a mid-point position but she can’t raise it higher until she does the lower-stop-raise sequence.
Anyone else seen this behavior, or is it that it’s just so noobish nobody cares to respond? I’m surprised I’m the only one seeing it… Or the only one not knowing the solution to prevent it…
I found the solution, even though it seems a little counter-intuitive. Posting here in case others trip up on this:
cover.mbr:
assumed_state: true
Placed in the customize.yaml. I was tripping up on the true/false. Logic says that I don’t want HA to assume the state of the blinds (thus disabling buttons) so I should set “assumed_state” to false. I tried it in the Lovelace entities card config (which did nothing), I tried it in configuration.yaml (which generated an error), and I tried it in customize.yaml (which did nothing). Finally I cleared everything tried, restarted and used the GUI customize panel that presented me with a checkbox that was unchecked by default. I checked it, saved and then checked customize.yaml - assumed_state was now set to true, and I have the desired behavior in the cover controls.
I guess when I read “assumed_state: true” I should interpret it as “override_assumed_state: true” to make the logic correct.
Thank you ! not exactly intuitive, not sure I would ever have worked that one out,
but Yes it now allows my RF-controlled Blinds to be operated the way I need and not get locked out of being able to raise them.
I had to use a door sensor on my awning pivot arm to track the state accurately.
In the template, I had to use position instead of value, so I could set it to 99 (or any value other than 100 and 0) to allow me to continue deploying when it stopped midway
- platform: template
covers:
second_balcony_awning_with_state:
friendly_name: "Second Balcony Awning With State"
unique_id: "second_balcony_awning_with_state"
icon_template: "mdi:storefront-outline"
device_class: awning
# value_template: >
# {% if is_state('binary_sensor.second_balcony_awning_position', 'on') %}
# opening
# {% elif is_state('binary_sensor.second_balcony_awning_position', 'off') %}
# closed
# {% else %}
# unknown
# {% endif %}
# Use position and set max to 99 so that it allows to continue deploying the awning when it's not fully deployed
position_template: >
{% if is_state('binary_sensor.second_balcony_awning_position', 'on') %}
99
{% elif is_state('binary_sensor.second_balcony_awning_position', 'off') %}
0
{% else %}
unknown
{% endif %}
open_cover:
service: cover.open_cover
data:
entity_id: cover.second_bedroom_balcony_awning
close_cover:
service: cover.close_cover
data:
entity_id: cover.second_bedroom_balcony_awning
stop_cover:
service: cover.stop_cover
data:
entity_id: cover.second_bedroom_balcony_awning
).