How often are programs run?

[RichK52]

How often are programs run?  For example, once all of the programs are run, does the ISY944i immediately restart running through the programs again to check if any are scheduled or if their 'If' condition(s) indicate that the respective 'Then' or 'Else' statements should be run.  It would see the cycle time is a function of how many programs exist and the larger the number of programs, the slower the cycle time would be.

One of the reasons for the question is the sample program in the appendix which has an 'If' condition with a time between sunset and 10pm.  During this window, the outside lights would be turned on, and outside of this time window, the lights would be commanded off.  This program would appear to continuously be transmitting either continuous ON or OFF commands 24 hours a day. 

Thanks

[lilyoyo1]

It runs when the conditions for a program are met. 

Using your example if time is from sunset to 10pm

The isy will run the then at sunset turning on the light and at 10pm it will run the or else and turn off the light. 

[RichK52]

Very strange.  Coming from a computer background, I expect the 'If' condition would be continuous evaluated as being TRUE, and thus the program below would be sending out "ON' commands between sunset and 10pm.

Does the ISY994i have some type of look ahead feature that identifies at what time a given program is scheduled to run?  I have a program that is to run at sunrise every day, and in looking at the program summary screen, it identifies that the next time the program is scheduled to run is at sunrise tomorrow (which is the IF condition I am checking for).

If
    Time is Sunrise
Then
    Set 'House / Front Door Outside Lights' Off
Else
   No Actions - (To add one, press 'Action')
 

 

 

[lilyoyo1]

5 minutes ago, Kloemri said:

Very strange.  Coming from a computer background, I expect the 'If' condition would be continuous evaluated as being TRUE, and thus the program below would be sending out "ON' commands between sunset and 10pm.

Does the ISY994i have some type of look ahead feature that identifies at what time a given program is scheduled to run?  I have a program that is to run at sunrise every day, and in looking at the program summary screen, it identifies that the next time the program is scheduled to run is at sunrise tomorrow (which is the IF condition I am checking for).

If
    Time is Sunrise
Then
    Set 'House / Front Door Outside Lights' Off
Else
   No Actions - (To add one, press 'Action')
 

 

 

There are ways to have something be continuously evaluated between certain hrs if that is what you are attempting to do. Simply add the status to your if command. The isy will then turn on the light should the status of the light is ever off during that time.

If time is from sunset to 10pm and status of light is off. Then turn on or else turn off

 

[larryllix]

Very strange.  Coming from a computer background, I expect the 'If' condition would be continuous evaluated as being TRUE, and thus the program below would be sending out "ON' commands between sunset and 10pm. Does the ISY994i have some type of look ahead feature that identifies at what time a given program is scheduled to run?  I have a program that is to run at sunrise every day, and in looking at the program summary screen, it identifies that the next time the program is scheduled to run is at sunrise tomorrow (which is the IF condition I am checking for).

If

    Time is Sunrise

Then

    Set 'House / Front Door Outside Lights' Off

Else

   No Actions - (To add one, press 'Action')

 

 

 

 

ISY is an almost totally trigger event based processing.If you have experience with VB or other MS Visual products is is very similar. This causes seasoned online programmers a lot of grief until the concept sinks in.

 

The ISY engine doesn't scan unlike some other realtime event triggered software.

 

All the best.

 

Sent using Tapatalk

 

 

 

 

 

[MrBill]

I think I might be the only one that does this, but it's easier for me for testing purposes.  I have exactly one program that evaluates Sunset and Sunrise, it sets the state variable DARK, then any program that needs to know if it's day or night uses "If $DARK= 0" or "if $DARK >= 1".  The reason I do this is because at for example now at 2:24 in the afternoon I can just manually set the value of DARK to 1 and see everything that happans, conversely setting DARK back to zero makes it "sunrise".  

isDark? - [ID 0008][Parent 0001]

If
        From    Sunset
        To      Sunrise (next day)
 
Then
        $DARK  = 1
        $DARK Init To 1


Else
        $DARK  = 0
        $DARK Init To 0

You might have also noticed above that I tested for  "if DARK >= 1"  instead of just equals.   That's because actually at "bedtime" DARK goes to 2 so that outdoor and kitchen lighting can change.  (Bedtime is handled differently if AWAY mode is on... but you get the idea). 

So in my scenarious $DARK can have 3 possible values:

0 = daytime (sunrise to sunset)

1 = Early evening (Sunset to "bedtime")

2 = Late Night ("bedtime" to Sunrise)

"bedtime" is an arbitrary time triggered when specific scene is turned off,  or If away mode is set "a random number of minutes 1-90 after 9:43PM"

 

I like this set up because $DARK can be used in many programs and you can test anytime by simply manually changing it's value.

 

[HABit]

It is evaluated as True, but as Larryllix said, the ISY is an event engine, and so since the event has triggered once (when the time is Sunset), it will trigger a False event when the time is no longer equal to Sunrise, running the Else part of the Program (if there is anything to be evaluated in the Else).

Don’t think of the ISY as having a Computer programming language, think more like it’s a programmable Controller, equivalent to a Honeywell/Bailey, etc., running some machine. It has its unique characteristics in the control language. Best way to understand is to read the ISY Cookbook on the Wiki, and ask questions on the Forum. Folks here are usually very helpful to get you pointed in the right direction.

[BamBamF16]

4 hours ago, SeeGreen said:

It is evaluated as True, but as Larryllix said, the ISY is an event engine, and so since the event has triggered once (when the time is Sunset), it will trigger a False event when the time is no longer equal to Sunrise, running the Else part of the Program (if there is anything to be evaluated in the Else). 

I don't think this is correct.  It will fire true once (at sunset), run the then clause and do nothing else at any other time.  To get anything else done, there would need to be another event trigger to evaluate.  Or conversely, if there was from Time A to Time B and nothing else in the if it would run the Then clause at Time A and the Else clause at Time B.

4 hours ago, SeeGreen said:

Don’t think of the ISY as having a Computer programming language, think more like it’s a programmable Controller, equivalent to a Honeywell/Bailey, etc., running some machine. It has its unique characteristics in the control language. Best way to understand is to read the ISY Cookbook on the Wiki, and ask questions on the Forum. Folks here are usually very helpful to get you pointed in the right direction.

 

[HABit]

@bambamf16Yes my bad, I neglected to mention the duration part of the IF requirement to get an Else trigger. What I get for drive-by commenting.

My point was to direct @Kloemri to the Wiki to understand how the ISY evaluates. I understand what he's saying: the ISY is not equivalent to a computer programming environment, the reason being that the hypothesis (IF) is evaluated only on a change/event. This is how conditional evaluation works in Controllers - i.e. the box hits a limit switch, etc., otherwise the controller is happy to sit by doing nothing. Folks coming from a traditional Computer Programming environment don't immediately make that connection so can experience different results in their programs than expected.

Thanks for corrected my rambling.

[RichK52]

Thank you to everyone who replied.  I am getting my head wrapped around event style programming when I come from a procedural programming background.  I had expected that when I created an "IF' condition that combined a scheduled time (ie, sunrise or sunset) AND status of Front Door Light' = Off,  that the 'THEN' statements would run when the 'AND 'IF' condition was TRUE, otherwise the 'ELSE statements would run.  I expected that the program would run only at the specified time (ie, sunset).  I did not expect that when the Front Door Light was manually turned off at 2pm, that the ELSE statements would run.  In reviewing the logic, I finally realized that because the manual turning off of Front Door Light created an event, that the program would run, which would result in the 'IF' condition to be FALSE, which then triggered the ELSE statements to run!  Not what I wanted.   

In order to do what I wanted, I had to create 2 programs and nest them.  Program1 has the 'IF' scheduled time of 'Sunset'.  The Program1 'THEN' statement then RUNS Program2 (which is manually disabled) where I then have an 'IF' condition which checks if the status of an (Insteon) device is TRUE.   This is the only way that I can think of creating a program that will only run at a certain time and then run either the THEN or ELSE statements and at no other time of day be triggered by an event.

 

[larryllix]

1 hour ago, Kloemri said:

Thank you to everyone who replied.  I am getting my head wrapped around event style programming when I come from a procedural programming background.  I had expected that when I created an "IF' condition that combined a scheduled time (ie, sunrise or sunset) AND status of Front Door Light' = Off,  that the 'THEN' statements would run when the 'AND 'IF' condition was TRUE, otherwise the 'ELSE statements would run.  I expected that the program would run only at the specified time (ie, sunset).  I did not expect that when the Front Door Light was manually turned off at 2pm, that the ELSE statements would run.  In reviewing the logic, I finally realized that because the manual turning off of Front Door Light created an event, that the program would run, which would result in the 'IF' condition to be FALSE, which then triggered the ELSE statements to run!  Not what I wanted.   

In order to do what I wanted, I had to create 2 programs and nest them.  Program1 has the 'IF' scheduled time of 'Sunset'.  The Program1 'THEN' statement then RUNS Program2 (which is manually disabled) where I then have an 'IF' condition which checks if the status of an (Insteon) device is TRUE.   This is the only way that I can think of creating a program that will only run at a certain time and then run either the THEN or ELSE statements and at no other time of day be triggered by an event.

 

Some other tips and gottchas.

• Any program can be disabled. This disables the triggers only and allows programs to be used as subroutines and filters.
• Control Switched condition lines are only true when the device triggers them and are always false otherwise. With two control switched condition lines in a single If section whichever ones triggers the evaluation, the other line will always be false. Only one trigger draws the attention of the engine to the If section at any time.
• Times can be time frames. From x ...to Y time. They can now be used as time frame filters for other triggers but the From time will trigger as a True statement and the TO time will always trigger as a False logic at it's time.....unless the program triggers are disabled. Two programs are often needed to use it as a filter.
• In ISY V5 a Repeat While X=Y line can be used as an inline IF condition.
• LInes in Then/Else sections are atomic and execute together. WAIT and REPEAT lines give up their time slice to the ISY engine and other/or same programs can be evaluated, I/O can run etc.. during those WAIT times.
• Calling another program does not wait until the subroutine completes. They may run simultaneously. No guarantees of execution order.
• A program called with an empty If section is assumed to be true and runs Then.
•  

 

[RichK52]

Here is a very strange problem that I have been having relating to intermittent issues I have been experiencing with the ISY994i and Insteon switches/dimmers. 

I do not use scenes in my programs and instead have individual programs to turn on and off Insteon devices at preprogrammed times. I have 4 programs that run at sunrise and 4 other programs that run at sunset.  Each program turns on or off only one Insteon device.  The issue that I noticed I was having that at lease one of the devices would fail in either accepting a command or sending an acknowledgment back to the ISY994i.  I wrote some additional programs to test the status of a switch/dimmer and ran them one minute after the respective program. The only thing all 8 programs had in common was that they were triggered via being scheduled at sunset (4) or at sunrise(4).

In trying to identify why I was getting these intermittent issues, I modified the programs so that the group of 4 programs were not scheduled a the same time (ie, sunset or sunrise).  I modified the programs so that Program1 runs at sunset, Program2 runs at sunset +5 sec, Program3 runs at sunset + 10 sec, & Program4 runs at sunset + 15 sec. After making these changes, the intermittent issues vanished and the system has run without an issue for 4 days now.  

I would not have expected that the ISY994i with it's multi-tasking OS, or the resulting powerline/RFcommunications would get scrambled or lost if multiple programs were scheduled to run at the same time. The fix is not pretty, but it works.   

Has anyone else seen this behavior or have any insight into it?

Thanks

[Michel Kohanim]

@Kloemri,

This has nothing to do with ISY. This is related to signal or noise from the load on one of your devices. Please try moving the PLM to a different outlet and one which is not shared with other transformers and power supplies. We have more troubleshooting tips here. But, ultimately, if things don't work you will have to contact SmartHome tech support.

With kind regards,

Michel

[lilyoyo1]

2 hours ago, Kloemri said:

Here is a very strange problem that I have been having relating to intermittent issues I have been experiencing with the ISY994i and Insteon switches/dimmers. 

I do not use scenes in my programs and instead have individual programs to turn on and off Insteon devices at preprogrammed times. I have 4 programs that run at sunrise and 4 other programs that run at sunset.  Each program turns on or off only one Insteon device.  The issue that I noticed I was having that at lease one of the devices would fail in either accepting a command or sending an acknowledgment back to the ISY994i.  I wrote some additional programs to test the status of a switch/dimmer and ran them one minute after the respective program. The only thing all 8 programs had in common was that they were triggered via being scheduled at sunset (4) or at sunrise(4).

In trying to identify why I was getting these intermittent issues, I modified the programs so that the group of 4 programs were not scheduled a the same time (ie, sunset or sunrise).  I modified the programs so that Program1 runs at sunset, Program2 runs at sunset +5 sec, Program3 runs at sunset + 10 sec, & Program4 runs at sunset + 15 sec. After making these changes, the intermittent issues vanished and the system has run without an issue for 4 days now.  

I would not have expected that the ISY994i with it's multi-tasking OS, or the resulting powerline/RFcommunications would get scrambled or lost if multiple programs were scheduled to run at the same time. The fix is not pretty, but it works.   

Has anyone else seen this behavior or have any insight into it?

Thanks

The problem isn't with the Isy. It's how you've set up your system. Your setup isn't optimized for how insteon works. By using individual devices at the same time, the plm has to send out and accept acknowledgements from each one. This can lead to signals being missed. It's the reason why insteon and other people recommend a single scene when you want stuff to happen all together. This lessens the chances of what you are experiencing from happening. 

If you don't want to use scenes, you're still better off using 1 single program with a 1 second wait between each device turning on. 

With that said, you can also have noise issues interfering with your communication as well. 

[larryllix]

2 hours ago, Kloemri said:

Here is a very strange problem that I have been having relating to intermittent issues I have been experiencing with the ISY994i and Insteon switches/dimmers. 

I do not use scenes in my programs and instead have individual programs to turn on and off Insteon devices at preprogrammed times. I have 4 programs that run at sunrise and 4 other programs that run at sunset.  Each program turns on or off only one Insteon device.  The issue that I noticed I was having that at lease one of the devices would fail in either accepting a command or sending an acknowledgment back to the ISY994i.  I wrote some additional programs to test the status of a switch/dimmer and ran them one minute after the respective program. The only thing all 8 programs had in common was that they were triggered via being scheduled at sunset (4) or at sunrise(4).

In trying to identify why I was getting these intermittent issues, I modified the programs so that the group of 4 programs were not scheduled a the same time (ie, sunset or sunrise).  I modified the programs so that Program1 runs at sunset, Program2 runs at sunset +5 sec, Program3 runs at sunset + 10 sec, & Program4 runs at sunset + 15 sec. After making these changes, the intermittent issues vanished and the system has run without an issue for 4 days now.  

I would not have expected that the ISY994i with it's multi-tasking OS, or the resulting powerline/RFcommunications would get scrambled or lost if multiple programs were scheduled to run at the same time. The fix is not pretty, but it works.   

Has anyone else seen this behavior or have any insight into it?

Thanks

In addition to the above comments Insteon has a small stacking cache to eliminate this from happening. However battery operated devices can cause some packet collisions because battery Insteon devices don't seem to know about playing nice with other devices. Additionally they will repeat send their signals multiple times to ensure they  gets heard.