It would be great if in a script/automation there was a way to wait for a previous action to complete before proceeding.
For example, imagine an automation that runs when a doorbell button is depressed. You’d like to make a noise, capture a video clip and then send the video file along with a notification. At present, you need to estimate how long it takes the camera to grab the video and write it to a file, insert some delay: step in the script ahead of the call to the notification service.
It would be great if you could, e.g., use an augmented version of the wait: scripting action to reference some previous service call and it’s completion. This probably requires services to publish some completion indication on the event bus that would be waited for… or something.
Having something like this would make it easier/possible to write reliable automations/scripts in an environment that’s highly asynchronous. Using delay: is an unreliable workaround since there’s not a synchronization mechanism available. Without some capability like that, you either end up having to wait too long or end up with broken notifications because some file that should be present hasn’t arrived yet.
In node red you have wait until node.
It kind of does this, but I agree that it would be better to have the action declare “I’m done” and the next would start.
But this would be something you could toggle or wrap around parts of scripts/automations
I think that you need some generalized support for service calls to reply when they’re done. Maybe some default behavior with an immediate response of some sort, with other services like camera.record providing its own signal when the longer operation is completed. And then something like the existing wait: operation that could block until some specified service call or other condition gets signalled. I don’t know enough about the nuts and bolts of the current implementation to offer a solution.
You can already do this with a wait template. It’s just that your specific niche case doesn’t have a flag that is set when the file is created. I suggest starting there with that integration.
If it’s a file saved to disk, you can use the folder integration to watch the number of files in the folder. When it increments, move forward. If that’s not good enough, you can write a template that searches the file_list attribute on the folder sensor for the file you just created.
or
Folder watcher even has an example of an automation that reacts to a newly created file. So you could just have the doorbell create the file, then a second automation that serves up each new file that is found.
Except creating the entire file is not an atomic operation. I’ve experienced truncated video files with a delay after the service call that wasn’t “long enough”.
Really, this seems like a another crude hack around a generic missing mechanism. What I have have more than one camera? Or it’s saving a still image and a short video clip? Perhaps the answer is that, in this use case, the camera entity should generate an event when it finishes writing a file, maybe with a parameter indicating the reason.
But if you’re going to expose this concurrency to end-users, there ought to be generalized tools to enable you to reliably use it. This is something that Dijkstra taught us (and computer science students) since the early 1960’s. My use-case illustrates what’s an architectural gap in the Home Assistant design which aggressively uses parallelism and concurrency to improve performance. The recent changes to scripts/automations is a solution to another version of this problem.
The problem is that not all devices return states, so not all services can know when they are done. It’s not a hack, you just have to tailor it for your device. All of your cases can be solved with a wait template with either folder or folder watcher. All you need to know is the filename(s).
So why were the changes made to the scripting/automation mechanism to control how to treat attempted simultaneous invocation? It seemed like there were a bunch of other workarounds people had been using previously to avoid those issues.
I agree that not all devices return status of their service calls. I suggested that perhaps some default behavior could be put in place for the 90% of the service calls that could be treated as synchronous, with specific support added for longer running asynchronous services.
And besides, I’m not sure how to use a folder watcher or similar, even when I know the file name, when I don’t know how long the file is, and when writing to it has been completed and the file is closed. This “solution” is more complex and still not reliable.
I can’t answer why the changes were made because I didn’t make them.
I can assure you that people would not like your default synchronous behavior because no one wants to wait 3 seconds for every light to turn on. The 95% use case here is asynchronous and the 5% use wait templates to make them synchronous.
That’s on your camera/integration. My cameras create the snips and place them locally as a full file. As a side note, you can use the file integration to look at the file size of a specific file. You have many options here.
The main reason I am refuting your WTH is because we already can do what you want. You just don’t like the solution that works for everyone else. The added complexity of waiting for things to finish (that could never finish) isn’t worth the time and effort when we already have something in place that works well. Not to mention most people don’t want entire action sequences to be synchronous, they’ll just want one or 2 actions to be synchronous. Which brings us full circle back to wait_templates. This is just my opinion and why I’m not voting for it. I am personally done discussing this because I don’t see us ever seeing eye to eye.