venetian blinds with terrasse door

[fireeater112]

Hello,
In our house we have, among other things, three Venetian blinds on the ground floor with full-height windows.
One of these windows also serves as our terrace door to the garden.
To avoid adaptive pro Automation (big thanks again to the developers for this excellent integration) locking us out of the house and preventing us from using the terrace door because the blind decided to lower itself just now, I’d like to suspend it.
The idea would be to use a window sensor on the terrace door. If the sensor is "open", then the automation would "override" until the sensor is back to "closed" – or something similar.
How could this be implemented sensibly with adaptive pro? Best regards
fireeater

[Nickduino]

Create an automation?

When door is open -> turn automatic control off

[jrhubott]

Thanks for the question — that's a thoughtful use case. Nickduino's suggestion to toggle automatic control OFF via an automation is exactly right.

The cleanest pattern is:

• When terrace door opens → turn off the integration's automatic control switch
• When terrace door closes → turn on automatic control again

This way the cover won't respond to the sun while the door is open, and you won't get locked out. The integration will pick back up as soon as the door closes. It's one automation with a simple binary sensor trigger, so very low overhead.

If you want the cover to stay at its current position while the door is open (rather than just stopping new commands), manual override would also work — any manual position change registers as an override and blocks new automatic commands until the override expires. But the toggle approach is simpler.

Hope that helps! Let me know if you have follow-up questions.

[Nickduino]

@jrhubott You could also make some of the settings available as entities.
For instance, there could be a number.adaptive_store_i_minimum_position entity and @fireeater112 could set it to 60% when the door is open (to keep some shade but not be locked out) and 0% when it's closed (if the cover is on the side that doesn't open, of course).

There are plenty of other use cases (minimum at 60% in the morning, 20% in the afternoon. Or switches to activate the 2D anti-glare zones: an automation would switch the "TV anti-glare zone" on if the TV is on, off the rest of the time, ...)

[jrhubott]

That'''s a great suggestion — I'''ve been thinking along similar lines. I'''ve opened #221 to track exactly this: exposing services that let automations update configuration values at runtime (min_position, custom positions, force override position, sunset position, etc.).

The proposal covers the scenarios you'''re describing. Rather than adding per-field entity pickers throughout the options flow, the idea is a single services surface so any configuration option can be driven by any automation trigger. Your examples fit neatly:

• Set min_position to 60% when the door is open, 0% when it closes
• Adjust min_position by time of day via a time-based automation
• Toggle custom positions on/off (e.g. a "TV glare zone" when the TV is on)

Nothing to install yet, but if you want to weigh in on the approach (generic setter vs. field-specific services, persistence behavior, etc.) the issue is the right place. Happy to hear what would work best for your setup.