larryllix Posted February 17, 2019 Posted February 17, 2019 (edited) 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, 2019 by larryllix 2
TrojanHorse Posted February 18, 2019 Posted February 18, 2019 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
larryllix Posted February 18, 2019 Author Posted February 18, 2019 (edited) 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, 2019 by larryllix 1
Hurting2Ride Posted February 18, 2019 Posted February 18, 2019 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.
larryllix Posted February 18, 2019 Author Posted February 18, 2019 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.
TrojanHorse Posted February 19, 2019 Posted February 19, 2019 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
larryllix Posted February 19, 2019 Author Posted February 19, 2019 (edited) 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, 2019 by larryllix 1
Recommended Posts