Posts: 341
Threads: 53
Joined: Nov 2018
I loaded the Run Timer driver and I don't think that's what I'm looking for.... of course I don't know really....
I'm looking for an interuptable wait or timer. Set the count down or wait to a specified amount of time and be able to interupt and restart it from something else happening.
If door opens -> start timer
if door re-opens -> reset timer from beginning
timer ends (finally) -> do something
Posts: 341
Threads: 53
Joined: Nov 2018
I think.. maybe I got it working with Timer and the ResetCD in the command. I'll have to test it out and verify that it resets the timer on each trigger which by logic it "should" but what do I know I'm learning this beast.
Posts: 1,507
Threads: 143
Joined: May 2007
(01-06-2020, 01:50 PM)Dean Roddey Wrote: You are probably using my simple counter driver, He's probably using the third party one (called RunTimer I think) which has more options. Look for that.
I am using the CQC Timer driver. In the initial configuration, you set up how many Count Down Timers and How Many Count Up Timers you want. In order to get the timer to reset, you are correct, the ResetCD that will reset the countdown.
RunTimer2 (which I use also) is really more of a driver to keep track of how long or how many things are on or off.
Posts: 341
Threads: 53
Joined: Nov 2018
(01-06-2020, 11:29 PM)kblagron Wrote: (01-06-2020, 01:50 PM)Dean Roddey Wrote: You are probably using my simple counter driver, He's probably using the third party one (called RunTimer I think) which has more options. Look for that.
I am using the CQC Timer driver. In the initial configuration, you set up how many Count Down Timers and How Many Count Up Timers you want. In order to get the timer to reset, you are correct, the ResetCD that will reset the countdown.
RunTimer2 (which I use also) is really more of a driver to keep track of how long or how many things are on or off.
I have successfully gotten the timer to work with the exception of the re-triggering/reset of the timer upon multiple entries to an area/room.
door close
cmd -> turn on fan and set timer
door open
cmd -> invokeCmd ResetCD 1 Minutes 2
timer ends
cmd -> turn off fan
This is working perfectly. What I need to add to this is if the door closes again while the timer is running to pause the existing timer so the 'timer ends' doesn't run after the 2 minutes of the first timer. Then when the door opens again to perform the timer reset.
I don't see a pause or anything in the docs to stop a CDTimer only the Reset. Ideas?
Posts: 1,507
Threads: 143
Joined: May 2007
I would look at using a variable driver Boolean field that keeps track of that - then if you have this occurrence you could pass over the reset command.
Posts: 341
Threads: 53
Joined: Nov 2018
(01-07-2020, 11:21 PM)kblagron Wrote: I would look at using a variable driver Boolean field that keeps track of that - then if you have this occurrence you could pass over the reset command.
I'll look at that. Sounds like the direction to go in. Just for sanity as there are local vars, global vars and the variable driver. I should use the variable driver for this? So it's available across events right? Or should this be a global var? The local var are only for that exec within that event is my understanding.
Posts: 40,483
Threads: 491
Joined: Aug 2002
The variable driver, being a driver, provides basically 'variables' system wide. The naming was probably unfortunate but it's too late to change that now. It's unrelated to global variables, which are only available within a program (and the locals which are only only within the action that's running.) Any things that run inside the same application can share global variables, though that's not common. The event server is mostly the only place where there are multiple user actions potentially going on. So the event server has a single global variables space that lets events share info if they want, though you have to be careful there as well since they are often running on separate threads. You can 'serialize' a particular event so that it will only ever run one instance of it at a time, and use a global variable to pass on info to the next instance and so forth.
Otherwise it's really all separate. Each IV (or WebRIVA instance) has its own global variables. Each trigger driver does. Global actions use the global variables of whatever other action they are invoked from within.
Dean Roddey
Explorans limites defectum
Posts: 341
Threads: 53
Joined: Nov 2018
Thanks for the details and information. You mention "same application". Does that mean that each "Scope" would be an application in terms of events so a local variable is available among members of that scope but then Global are available to all events in all scopes? Or are local vars only available within that one single event.
Just wanting to make sure I understand the terminology and actual use of "scope" and local/global vars in this context.
I did install the Variables driver and I like that I can use it for a variety of arbitrary values which is good.
Posts: 40,483
Threads: 491
Joined: Aug 2002
Local variations are thrown away when the action dies (that means the action that started at the beginning, if it runs global actions they will share the originating action's locals.) That allows you to just create them and not worry about cleaning them up since they are tossed. For anyone familiar with programming languages, they would be 'local variables' that go away when the current function/method call exits.
Globals are around as long as the thing that created that global variable context exists. So the event server has one global variables context that lives until the event server cycles. Each IV has one. In the action trace you can see any global variables that have been created and not cleaned up. So, if you bring up the action trace in the IV, every time you run an action, it'll show all of the global variables for that IV that current exist (and hence could be used by the action being invoked.)
IVs and WebRIVA clients need their own globals because they know nothing of each other and shouldn't have to worry about another IV/WebRIVA client changing or deleting their global variables. They are used to store info for subsequent actions in that client. So a button may set a variable saying, I'm not operating on Zone 1, and all other audio zone actions will look at that and affect that zone, etc...
The same for trigger drivers. Each one assumes he exists alone, and shouldn't have to worry about other trigger drivers interfering with him. He just wants to be able to (if needed) store info for subsequent incoming triggers to use.
Dean Roddey
Explorans limites defectum