Help on understanding how to do an automatic override of some active automation

Hi all,
sorry in advance if I make a “basic” question.
I describe my situation.

I’ve an old awning driven by a RF remote controller that I domotized by adding a second remote where buttons are “pushed” by an ESP32 via ESPhome.
Then I created a cover and three single buttons in HA that makes me possible to performs all the operations. Everything works fine including my automations.

My problem: I want that when the user presses the Lovelace UI button or interacts with cover opening/closing percentage there’s an automatic override of all the cover automations for a configurable time. This means that the user wants to bypass cover automations by acting to the UI.

My Idea is to use a binary flag state that is active when at leas one automation is triggered AND the driven action is completed.

How to reset the flag state considering that the opening/closing of the awning is completed after the automation action?

What would you use in my case?

Thanks for the patience.

I don’t get what you want to do here, sorry. Disable another automation? How do I imagine that?

Anyway, what I understand from your post, you’re looking for a way to “wait” for something in your automation?

That would be a typical case for these:

If you use a wait trigger (any of the available) you can “delay” your script for as long as it deems necessary. In other words: your automation shouldn’t be over when there’s still something to do. Wait or delay the automation until there’s nothing left to do.

EDIT: I totally forgot, welcome to the forum, and please describe what you want to achive. :slight_smile:

Thanks for the reply.
I simply want a way to dynamically disable one or more cover automation if the user presses the buttons of the user interface.

Think about a cover automation that, at every azimuth change, forces a cover position. Now suppose that the user doesn’t wont that position set by automation, so he changes it by user interface.
So I would like to have a bypass of the automation for a certain amount of time in order that the automation will no force the position at the next azimuth trigger.

OK, I see! :slight_smile:

My first question would be, why does the automation doesn’t handle a manual override already? If the automation is already monitoring the state of the cover(s), it should know, that someone has taken over control. :wink: That’s why I’m asking. :slight_smile:

Btw. for exactly this use case we do have a fantastic integration and a blueprint here in this very forum. There already is a “manual override” included! :wink: Take a look in this thread:

It started as a blueprint, which is still available, and ended in an integration, that is really amazing! Just saying, but there was already someone who invented that wheel. :laughing: I’d recommend to take a look at least at the blueprint, it might give you some ideas.

But that won’t solve your initial question, so let’s go on with that. If it where me, I’d work with an adjustable timer. You could start it with a button press in the frontend, ideally you would change the already existing automation to check for that timer.

But if that automation is “not changeable”, you could also write an automation, that reacts on the timer running. With the beginning of that timer, the automation would disable the other automation and enable it back after the timer finishes. But I wouldn’t go that route tbh, it’s not really a good idea to enable/disable automations from within other automations. Better to change existing automations to react on different states.

But that’s all theory, let me know, which way you want to go, integration, blueprint or own automations, and we can figure out how to solve this. :slight_smile:

If it were me, I’d try the integration first, than the blueprint, and then the change of the existing automation. If all that doesn’t work like I want it to, I’d take a seperate automation, but really only as a last resort. :slight_smile:

I had a quick look at your suggestion about “Adaptive cover”, seems interesting but I don’t see the possibility to manage the weather.

Meanwhile I did a solution before you suggested me to use timer and I did the same! :slight_smile:
I’ve an automation that when the user pushes the button on the UI or changes the percentage of opening then an override timer is started. In all the automations I’ve done the condition check of the override timer and seems working.

Thanks a lot for now.

Update: I added a binary switch that is based on some OpenWeather sensors strategy that, in case of bad weather like overcloud, rain etc. will go off. An automation based on this switch opens the awning.

Great you got it working! :slight_smile: I think that sounds like a solid solution.