#Variables in parallel sequences aren't isolated...?

1 messages · Page 1 of 1 (latest)

surreal skiff
#

I'm working on an automation to take timelapses on multiple cameras, but I specifically want the snapshots to wait for a frame with (or without) activity. To do this, I'm triggering on the hour and then in parallel waiting for the camera to report activity before snapping a photo. If I explicitly write out the camera name it works fine, but I figured adding more cameras would be easier if I could put the camera name in a variable to avoid errors when duplicating actions. Unfortunately, it seems like the "variables" action applies to all the parallel sequences. Is this a bug? Is there a workaround to do something similar?

Attached is my current automation. My "no motion" sequences are without variables and run great. The "motion" ones use variables and resulted in all four sequences working with the variable set in the 4th motion sequence. I've attached the trace too.

tribal flint
#

Variables used to have a scope per sequence, but this is changed a while ago. There is only one variable scope now. So your cam variables will overwrite each other

surreal skiff
#

That's unfortunate. Oh well, thanks for the info.

tribal flint
#

but why not just trigger on state changes of these sensors instead of a time pattern based automation

surreal skiff
#

I'm taking a timelapse with exactly one shot per hour. I'm just shifting the time slightly to account for motion/no-motion, ie. I want one hourly timelapse that looks like there is never anything moving in the frame, and one hourly timelapse that looks like there is pretty much always something moving in the frame.

tribal flint
#

ah okay

surreal skiff
#

I could make a bunch of separate automations that are hourly triggered, but felt like making it one automation for some reason (sometimes it is nice to keep related things together).

#

Maybe I could make a script that is called with each variable option, but I've got the thing adapted to hard coded values now and probably won't mess with it.

tribal flint
#

A script could work as well indeed

wooden tusk
#

Or a blueprint.

#

Then you already have the code, flip in a couple of inputs to replace some entities, and call it as many times as you need to.