Best Way to Handle Wait Times within a Triggered Event

[kblagron]

Currently I have a couple of events, that when triggered, turn on things. I am currently setting a Pause() for 4 minutes, then turning them off. I have read where I could use the System:WaitTimer() or Timers driver, but from what I can tell, I would need to then have two events, one to turn on, and then one to turn off after a period of time. I have just been including the Pause() within one triggered event.

Is there any harm to having an event running for 4+ minutes, or would it be best to set it up so the event runs then stops, and then runs and stops again as it would with the countdown method?

[Dean Roddey]

The way to do that is to use the Devices::TimeFldChange() command. That lets you write one value to a field, and queue up another value to be written automatically after a given time. And, importantly, any other write to the field will cancel the queued up value, which is almost always what you want to happen.

[jkmonroe]

oohhh - can you run those sequentially in the same action?

for the wakeup routine we talked about some weeks ago - could i schedule an event, and in that event run a whole series of those timefldchanges back to back? so 30min ramp up from 0-60% would be 2% per minute, so 29 of those commands, all set for 1 min?

[Dean Roddey]

No, you can only have one per field. What you want to do is something better handled by other means, of which I've put a lot of thought into, but need the time to implement it.

[kblagron]

So I have value in my variables driver that I use for this - it is named FrontMotion.

So I could get my triggered event from the Elk when motion is detected, run the action that sets FrontMotion to true and turns on my TV's to the cameras, and then run the TimedFldChange for 4 minutes, and then set it back to false.

Does that mean I would need a second triggered event to turn everything off once it is set to false?

At least the way I have been reading it, that is the only way.

[Dean Roddey]

Yeh, if it's not just a field you want to write to, but you are using the field to kick off an action, then you would need a second triggered event to handle the off phase.

The down side of just blocking in the action is that there's nothing to prevent you from just stacking them up and up, unless you are taking measures to prevent multiple invocations. And it can't be stopped once it's started, where the timed field change can be. And it also eats up threads in the event server which are just blocked and not of use for other events.

[kblagron]

I was using that field and an If statement that allows it to just fall through the triggered event if it was already true. From that standpoint, it works very well as I can see in the log where if it is initiated, it just starts and stops almost immediately.

One thing that I noticed with the Pause() was that its wait time is very off from what I wanted - I have it cranked up to 800,000 millisecs, and I am getting a little over 2 minutes on the action. I am currently on 4.8.5.

[Dean Roddey]

I think there's a limit on it, for the specific reason that, if you accidentally put a really long time in, that it wouldn't just lock up a thread endlessly, which could happen over and over and bring the system down eventually. So it just clips really long times down to something more reasonable.

[bryanb]

Dean, how's the best way to handle this situation? I have a UPB switch that I turn on manually. In case I don't turn it off manually, I would like CQC to turn it off after it's been on for maybe 5-10 minutes. I currently have a triggered event that gets triggered when the switch is turned on. As above I have a 5 minute pause and then an off command but I never get the full 5 minutes. Thanks.

[Dean Roddey]

I'd use the timed field change for that as well. Even if the initial value you send is the value already set in the field, the delayed value still gets queued up and will run later.