larryllix Posted November 17, 2022 Share Posted November 17, 2022 (edited) This may be of interest to some involved with seasonal lighting, using programs that are year independent. In the past we had to change our date triggers due to the year portion being static. Here is how I accomplish this task using my favourite little engine that could....ISY The Date Variables First we use the system variables to create a variable indicating the month and date of the month. I shift the resultant two decimal points so it looks nice to the user and can be used to create filters that will respond for 1, 2,3, 10 days or the whole month by eliminating the comparison decimals and only using a whole number representing the month. This requires creation of several state variables containing two decimals of precision as well as several Integer variables for calculation usage. These are necessary so that programs triggered by state variables are not triggered erroneously every time an intermediary calculation result is obtained. Only the resultant is actually transferred into the State variable. State variables are prefixed with '$s' in my system $sSys.MM.DD contains the month and day, both using two decimal numbers 01.01 to 12.31 $sSys.hh.mm contains the hour and minute, both using two decimal numbers 00.00 to 23.59 $sSys.hh.5mm contains the hour and minute, both using two decimal numbers, except it only updates every 5 minutes 00.05 to 23.55 This variable can be used to trigger cyclic programs that you only want updated on a 5 minute basis in order to not flood ISY with unnecessary processing or excess traffic on your device protocol Eg: excess Insteon traffic when you slowly dim lighting in the evening. clock.sync - [ID 0003][Parent 0002][Run At Startup] If // Run at Startup enabled Time is 12:00:10AM Or Time is 6:00:10AM Or Time is 12:00:10PM Or Time is 6:00:10PM Then // update $sSys.MM.DD $Clock.scratch = [Current Day of Month] $Clock.scratch /= 100 $Clock.scratch += [Current Month (Jan=1, Feb=2, etc.)] $sSys.MM.DD = $Clock.scratch $sSys.MM.DD Init To $Clock.scratch // update $sSys.hh.mm Repeat Every 20 seconds $Clock.scratch = [Current Minute] $Clock.scratch /= 100 $Clock.scratch += [Current Hour] $sSys.hh.mm = $Clock.scratch // update $sSys.hh.5mm $Clock.scratch.noFrac = [Current Minute] $Clock.scratch.noFrac /= 5 $Clock.scratch.noFrac *= 5 $Clock.scratch = $Clock.scratch.noFrac $Clock.scratch /= 100 $Clock.scratch += [Current Hour] $sSys.hh.5mm = $Clock.scratch Repeat 1 times Else // Run at startup will evaluate False Run Program 'clock.sync' (Then Path) Program Usage Now we use these variables in programs like this Christmas lighting one. Note the multiple times and multiple date combinations in use. Also my lighting scenes are driven off State variables that trigger banks of lighting scenes. I find not directly operating lighting scenes offers much more control and simplicity of programming the end user logic. Making later changes becomes a snap. A special note should be given to date ranges that include the end of the year. The range dates need to use "OR" logic, not "AND". IOW: we are saying after Nov.15 or before Jan. 07 since contiguous numeric dates stop at 12.31 and start again at 01.01 without any break in the calendar dates. XmasTree.onOff.inititiate - [ID 00D8][Parent 00D7] If // Vocal input also ( Time is Sunset - 15 minutes And ( $sSys.MM.DD >= 11.15 Or $sSys.MM.DD <= 1.07 ) ) Or ( Time is 5:00:00AM And $sSys.MM.DD >= 12.24 And $sSys.MM.DD <= 12.26 ) Then Set 'Dining Room / Christmas Tree' On Wait 7 hours Run Program 'XmasTree.onOff.inititiate' (Else Path) Else Set 'Dining Room / Christmas Tree' Off Simpler Usage Eaxmple Here is another example of using this system. This is a theme setter for Independence day. Note the usage of the ISY native time trigger ANDed with the $sSys.MM.DD variable to achieve this. Festive.set.USA - [ID 0083][Parent 007D] If Time is 12:10:00AM And $sSys.MM.DD is 7.04 Then $Festive.theme = $cMODE.USA $Festive.theme Init To $Festive.theme Else - No Actions - (To add one, press 'Action') Canada Day Date Range Program Example Festive.set.CanadaDay - [ID 007B][Parent 007D] If Time is 12:10:00AM And ( $sSys.MM.DD >= 6.25 And $sSys.MM.DD <= 7.02 ) Then $Festive.theme = $cMODE.CANADA $Festive.theme Init To $Festive.theme Else - No Actions - (To add one, press 'Action') Christmas Date Range Except New Years Day Example Note the combination of IS native time trigger ANDed with a date range and the New Years Day exclusion logic. Festive.set.Xmas - [ID 0081][Parent 007D] If Time is 12:10:00AM And ( $sSys.MM.DD >= 12.01 Or $sSys.MM.DD <= 1.15 ) And $sSys.MM.DD is not 1.01 Then $Festive.theme = $cMODE.XMAS $Festive.theme Init To $Festive.theme Else - No Actions - (To add one, press 'Action') Hope this inspires other programmers to be more creative with their ISYs. They are as powerful as your imagination. The cloud is the limit!! Edited November 18, 2022 by larryllix 1 Link to comment
lilyoyo1 Posted November 18, 2022 Share Posted November 18, 2022 I wish they would add an annual button to the Isy so it wouldn't take this amount of program. Just set the date range like normal and click. Then every year it triggers Link to comment
asbril Posted November 18, 2022 Share Posted November 18, 2022 34 minutes ago, lilyoyo1 said: I wish they would add an annual button to the Isy so it wouldn't take this amount of program. Just set the date range like normal and click. Then every year it triggers I have not used the Time-Date Node server for quite a while, but would it not solve the issue ? Link to comment
lilyoyo1 Posted November 18, 2022 Share Posted November 18, 2022 (edited) 54 minutes ago, asbril said: I have not used the Time-Date Node server for quite a while, but would it not solve the issue ? It's not a problem for me. The Node server potentially could. However, I'm referring to the built in controls that the isy has already Edited November 18, 2022 by lilyoyo1 Link to comment
kclenden Posted November 18, 2022 Share Posted November 18, 2022 (edited) 3 hours ago, larryllix said: This requires creation of several state variables containing two decimals of precision as well as several Integer variables for calculation usage. These are necessary so that programs triggered by state variables are triggered erroneously every time an intermediary calculation result is obtained. Only the resultant is actually transferred into the State variable. I think you mean to say "are not triggered". 3 hours ago, larryllix said: $sSys.MM.DD contains the month and day, both using two decimal numbers 01.01 to 12.31 A question and an observation: Why do you perform "$sSys.MM.DD Init To $Clock.scratch" when the program is set to run at startup anyway? Shifting the results two decimal places to the left makes it look nice except when you're comparing to a day of the month that is 10, 20, or 30. When you enter something like "1.10" into the Number field of the Condition, the ISY strips off the trailing "0" making the Then look something like this: If $sSys.MM.DD <= 1.1 Then Else Not a deal breaker, but at first glance it may not be clear whether you're checking for Jan 1st, or Jan 10th. Edited November 18, 2022 by kclenden Link to comment
larryllix Posted November 18, 2022 Author Share Posted November 18, 2022 9 hours ago, kclenden said: I think you mean to say "are not triggered". A question and an observation: Why do you perform "$sSys.MM.DD Init To $Clock.scratch" when the program is set to run at startup anyway? Shifting the results two decimal places to the left makes it look nice except when you're comparing to a day of the month that is 10, 20, or 30. When you enter something like "1.10" into the Number field of the Condition, the ISY strips off the trailing "0" making the Then look something like this: If $sSys.MM.DD <= 1.1 Then Else Not a deal breaker, but at first glance it may not be clear whether you're checking for Jan 1st, or Jan 10th. Thanks. OP corrected to include "Not triggered" The truncating of superfluous decimal is a problem for appearances for sure. We want floating point...usually. $sSys.MM.DD init to $Clock.scratch? IIRC there were cases where the variables were not initialised before programs attempted to use them. It may have been a quirk in the system time parameters. Only more recently, did I discover you can [Run at startup] and redirect the action back into the Then section after the [Run at startup] typically evaluates to False and runs Else. Also, IIRC there may have been an intermediary version where the startup process did not evaluate in proper order? It may have become redundant now. Very observant! Link to comment
larryllix Posted November 18, 2022 Author Share Posted November 18, 2022 12 hours ago, asbril said: I have not used the Time-Date Node server for quite a while, but would it not solve the issue ? Possibly it could but I have avoided NSs mostly as they were residing in another box at the end of a cable and via switches and routers. I prefer sources of data as reliable as possible. On power up how long would it take for a NS to have accurate data available? My guess would be about 30-60 seconds after other programs have already done things based on time 00:00. Link to comment
asbril Posted November 18, 2022 Share Posted November 18, 2022 2 hours ago, larryllix said: Possibly it could but I have avoided NSs mostly as they were residing in another box at the end of a cable and via switches and routers. I prefer sources of data as reliable as possible. On power up how long would it take for a NS to have accurate data available? My guess would be about 30-60 seconds after other programs have already done things based on time 00:00. I don't contest @lilyoyo1 in that an option (for annual) in IoP would be the best solution, but I may disagree with you on the use of node servers. I use several and rarely have problems. In fact, I have never seen a time-lag issue with a Node server. The only time-sensitive Node server that I use (Holydays Google) correctly changes status at midnight. I used to have some issues with this in the past, but no longer. Link to comment
Recommended Posts