For this example I will use my occupancy timer system. 

Initiator methods
Starting the timer process can be done from any program by simply saving the number of minutes you want the timer to timeout into a single state variable.
Each device involved sets my occupancy timer to an appropriate time based on the location and probability another MS will reset the timer variable again before the timer time out. I have at least 12 MS devices as well as other devices that initiate this.

Motion.Libr - [ID 0019][Parent 000B]
If
        'Library / Motion.Libr' is switched On   <---- MS trigger
Then
        $sMS.Motion.room  = $cROOM.LIBRARY   <--------------- all rooms are defined by preset constant numbers (not relavent here)
        Wait  2 seconds         <-------- this is so the admin console shows the colour change for debugging (not relavent here)
        $sHouse.occupied.timer  = 120   <-------------------------- initiates programable timer
Else
   - No Actions - (To add one, press 'Action')
 

 

This is an example using my security system. Note 1 minute is used so the programs will trigger properly to set the occupancy flag to False.

Occupied Cancel by arming - [ID 0018][Parent 000B]
If
        $sHouse.armed is $cTRUE
Then
        $sHouse.occupied.timer  = 1
Else
   - No Actions - (To add one, press 'Action')
 

 

Timer Program
This program is Enabled at Startup so that it continues after a power cycle.
I have allowed for sleeping times when no motion may be detected but we are still home. Timer countdown continues in the morning.
This program is automatically triggered by the program examples above.

Occupied.countdowner - [ID 0167][Parent 000B][Run At Startup]
If
        $sHouse.occupied.timer > 0
    And From     7:00:00AM
        To      11:00:00PM (same day)
Then
        Wait  1 minute 
        $sHouse.occupied.timer -= 1
Else
   - No Actions - (To add one, press 'Action')
 
Self retriggering timer.
Enabled to run at startup!
-If startup occurs ouside wake timeframe, will self start at beginning of timeframe.
-If timeframe commences while .timer is 0, first new occupied.timer value will start again.

 

Using the Timer Counter
In my case I set and reset a variable to True or False, as other programs throughout my system expect these values. Others may want to turn on lights, or other indicators system, run programs or lighting scenes directly from this program, instead.

Occupied.flagger - [ID 0168][Parent 000B]
If
        $sHouse.occupied.timer > 0
Then
        $sHouse.occupied  = $cTRUE   <---- preset constant (integer) variables for convenience and clarity
Else
        $sHouse.occupied  = $cFALSE
 
Power up assumes home unoccupied! Shouldn't be long to correct that.
Program cannot be combined into "Occupied countdowner" program as it's timeframe end would zero occupied.timer

 

 

 

Edited February 17, 20196 yr by larryllix

Larry,

Thanks for posting this as I’m sure many will find it useful. I didn’t study in detail, but I’m curious why you decided not to include an Init command for the variables for a restart? Perhaps worst case the ISY will only think the house is occupied for a bit longer than may actually be the case?


Sent from my iPhone using Tapatalk

39 minutes ago, TrojanHorse said:

Larry,

Thanks for posting this as I’m sure many will find it useful. I didn’t study in detail, but I’m curious why you decided not to include an Init command for the variables for a restart? Perhaps worst case the ISY will only think the house is occupied for a bit longer than may actually be the case?


Sent from my iPhone using Tapatalk

Been awhile, but I figured I wouldn't need them to be 'init to'ed. I had those lines installed for one but figured out I wouldn't need it and would avoid wear and tear o the eprom memory.

However, just looking at it again, despite startup running the program, the counter would be 0, and Occupied would be set False until some event happened again.
A function of this importance may warrant the 'wear and tear'. I need to re-exam this. Thanks for the nudge.

Edited February 18, 20196 yr by larryllix

5 hours ago, larryllix said:

t figured out I wouldn't need it and would avoid wear and tear o the eprom memory.

Is this something of concern with the ISY in particular?  or just a general concern you keep in mind?  I had a ISY 99i for a long time with multiple state variables being set/reset every 1 to 60 seconds.  I never experienced (or remember seeing) any issue w/ the ISY & memory.   Thx.

5 hours ago, Hurting2Ride said:

Is this something of concern with the ISY in particular?  or just a general concern you keep in mind?  I had a ISY 99i for a long time with multiple state variables being set/reset every 1 to 60 seconds.  I never experienced (or remember seeing) any issue w/ the ISY & memory.   Thx.

It is not ISY in particlar. I know eprom manufacturers have worked to avoid this problem and technology has advanced. I still hear conflicting reports about this over the years. I try to avoid it when unnecessary.

Been awhile, but I figured I wouldn't need them to be 'init to'ed. I had those lines installed for one but figured out I wouldn't need it and would avoid wear and tear o the eprom memory.
However, just looking at it again, despite startup running the program, the counter would be 0, and Occupied would be set False until some event happened again.
A function of this importance may warrant the 'wear and tear'. I need to re-exam this. Thanks for the nudge.

I never considered that. I suppose if you are concerned about this you could limit the Init to lines to only run for 120 and 0 (maybe 60 as well) and not everything in between. Maybe an additional program that does only this.


Sent from my iPhone using Tapatalk

At some point I must have had a change of heart and used the "init to" for the variables.

Here is another system I use to run my HRV from different triggers. It uses an extra technique, writing a time in minutes to a variable that will "request" the HRV ventilation system to run for that many minutes.

Initiating a request
It is initiated in this example trigger program.
Note that two STATE variables are used in this system to trigger automatic program running.

HRV.purge.bedtime - [ID 0173][Parent 011E]
If
        Time is 11:00:05PM 
Then
        $sHRV.run.minsRequest  = 15   <----ask to run HRV ventilator for 15 minutes
Else
   - No Actions - (To add one, press 'Action')
 

Handling the Request
The time request is considered, and if a longer time than what is currently left  running, uses the new time requested instead.
The requested time variable is cleared after,  due to similar requests would not trigger the request handler program. A change must be detected.
Variables are saved into permanent memory for self-continuation after a power disruption

HRV.cycle.requestHandler - [ID 0111][Parent 011E]
If
        $sHRV.run.minsRequest > 0
    And $sHRV.run.minsRequest > $sHRV.run.minsLeft
Then
        $sHRV.run.minsLeft  = $sHRV.run.minsRequest
        $sHRV.run.minsLeft Init To $sHRV.run.minsLeft
        $sHRV.run.minsRequest  = 0
Else
        $sHRV.run.minsRequest  = 0
Self retriggering timer.

The Timer
Note this is a self retriggering timer program and enabled to Run at Startup for continuation after a power failure.
This program turns the actual HRV fan device on and off

HRV.cycle.timer - [ID 0110][Parent 011E][Run At Startup]
If
        $sHRV.run.minsLeft > 0
Then
        Set 'HVAC / HRV Fan.control' On
        Wait  1 minute 
        $sHRV.run.minsLeft -= 1
        $sHRV.run.minsLeft Init To $sHRV.run.minsLeft
Else
        Set 'HVAC / HRV Fan.control' Off
 
Self retriggering timer.

 

 

Edited February 19, 20196 yr by larryllix