How does one control the order programs run in ISY?

[IT Solutions]

Good Morning Forum Members,

I have been programming computers for almost 50 years (I started in grade school), and have worked with a variety of different languages from Basic to Machine Code.  ISY is not like anything I have worked with in the past.  I showed it to a friend that does imbedded work it wasn't like anything he had worked with either.

ISY is very powerful, but takes some getting used to.  In a traditional programming language what ISY calls a "Program" would be called a statement.  Statements in a program run in the order they appear in the program (this is very over simplified).

I am working on adding programs to ISY to track the high and low temperature for the day by poling the outside temperature probe every XX minutes, then updating the high and low for the day (if needed). To do this, I need to make sure the poling of the outside temperature happens right before the updates to the high and low.

One way to do this would be to have the program that poles for the temperature set a state variable to 1 at the end of the program, then have the next program trigger on the state variable being 1, then it would change it to 2, then the next program triggers on 2, etc.,

Is there a better way to do this?

Thank you.

 

[DennisC]

11 minutes ago, IT Solutions said:

Good Morning Forum Members,

I have been programming computers for almost 50 years (I started in grade school), and have worked with a variety of different languages from Basic to Machine Code.  ISY is not like anything I have worked with in the past.  I showed it to a friend that does imbedded work it wasn't like anything he had worked with either.

ISY is very powerful, but takes some getting used to.  In a traditional programming language what ISY calls a "Program" would be called a statement.  Statements in a program run in the order they appear in the program (this is very over simplified).

I am working on adding programs to ISY to track the high and low temperature for the day by poling the outside temperature probe every XX minutes, then updating the high and low for the day (if needed). To do this, I need to make sure the poling of the outside temperature happens right before the updates to the high and low.

One way to do this would be to have the program that poles for the temperature set a state variable to 1 at the end of the program, then have the next program trigger on the state variable being 1, then it would change it to 2, then the next program triggers on 2, etc.,

Is there a better way to do this?

Thank you.

 

Take a look at the document in the link below. It might help you the precedence and execution order of programs.

https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Scope,_Precedence_and_Execution_Order

 

[IT Solutions]

@DennisC Thank you for the link.  What I am seeing here references execution within a program.  Since there does not appear to be away to have and If Then If in a single program, we need to use multiple programs.  For this we need to make sure they execute in the correct order.  If Program #2 starts before Program #1 is completed, the values Program #2 is using may not be correct.

Does this make sense?

[DennisC]

Just now, IT Solutions said:

@DennisC Thank you for the link.  What I am seeing here references execution within a program.  Since there does not appear to be away to have and If Then If in a single program, we need to use multiple programs.  For this we need to make sure they execute in the correct order.  If Program #2 starts before Program #1 is completed, the values Program #2 is using may not be correct.

Does this make sense?

Disable program 2 and run it from program 1.

[Michel Kohanim]

@IT Solutions,

ISY is not procedural. ISY is event based. And, the events are handled in FIFO manner. So, if A happens before B, then the program that depends on A is evaluated before the program that depends on B. 

With kind regards,
Michel

[IT Solutions]

@Michel Kohanim

1 minute ago, Michel Kohanim said:

@IT Solutions,

ISY is not procedural. ISY is event based. And, the events are handled in FIFO manner. So, if A happens before B, then the program that depends on A is evaluated before the program that depends on B. 

With kind regards,
Michel

Yes, I understand that, but if a single event means Programs A & B need to run, and we need A to run before B, then we need a way to control that.

 

3 minutes ago, DennisC said:

Disable program 2 and run it from program 1.

@DennisCI think this will work, thank you. In traditional programming, Program 2 would be referred to as a subroutine, but since it does not return back to program 1 when completed, it is more similar to a GOTO statement in Basic. Wow, that brings back some really old memories.

[Michel Kohanim]

@IT Solutions, why would have two programs anyway? Choices a) what @DennisC suggested and b) use  high > temp or low < temp (this way, both are handled by the same program regardless of which one comes first.

With kind regards,
Michel

[MrBill]

1 hour ago, IT Solutions said:

Good Morning Forum Members,

I have been programming computers for almost 50 years (I started in grade school), and have worked with a variety of different languages from Basic to Machine Code.  ISY is not like anything I have worked with in the past.  I showed it to a friend that does imbedded work it wasn't like anything he had worked with either.

ISY is very powerful, but takes some getting used to.  In a traditional programming language what ISY calls a "Program" would be called a statement.  Statements in a program run in the order they appear in the program (this is very over simplified).

I am working on adding programs to ISY to track the high and low temperature for the day by poling the outside temperature probe every XX minutes, then updating the high and low for the day (if needed). To do this, I need to make sure the poling of the outside temperature happens right before the updates to the high and low.

One way to do this would be to have the program that poles for the temperature set a state variable to 1 at the end of the program, then have the next program trigger on the state variable being 1, then it would change it to 2, then the next program triggers on 2, etc.,

Is there a better way to do this?

Thank you.

 

High and low temps for the day aren't hard at all, unless you want to know the exact time it occurred.  If $sCurrentTemp is a state variable any program using that variable as the IF will run ANYTIME the value changes.

If

   $sCurrentTemp > $iHighTempToday

then

   $iHighTempToday = $sCurrentTemp

else

   (nothing)

 

IF

 $sCurrentTemp < $iLowTempToday

then

   $iLowTempToday = $sCurrentTemp

else

   (nothing)

 

 

 

EDIT TO ADD:  of course you need to have something set up to run at some time like 11:59 PM that does something with the values  $iHighTempToday  and $iHighTempToday (Save them or report them) and then reset the values to the opposing i.e. $iHighTempToday = -999 and $iHighTempToday  = 999 which will be immediately replaced the next time the state variable updates as we begin working on the new days High and Low.

[dbuss]

On 2/23/2021 at 9:20 AM, MrBill said:

High and low temps for the day aren't hard at all, unless you want to know the exact time it occurred.

I used your high/low programs and discovered that the UD Mobile app does show the time that the variable was changed. I added the high and low and the times changed changed to my favorites in the UD Mobile app. 

[palayman]

On 2/23/2021 at 10:07 AM, Michel Kohanim said:

@IT Solutions,

ISY is not procedural. ISY is event based. And, the events are handled in FIFO manner. So, if A happens before B, then the program that depends on A is evaluated before the program that depends on B. 

With kind regards,
Michel

@Michel Kohanim

So if I have two different programs, say one that runs from sunset to 11 and another that runs from sunset to sunrise, do they get cued in the FIFO randomly or perhaps in the order they were created? Maybe I've missed some documentation on this.

Cheers,

Paul

[MrBill]

48 minutes ago, dbuss said:

I used your high/low programs and discovered that the UD Mobile app does show the time that the variable was changed. I added the high and low and the times changed changed to my favorites in the UD Mobile app. 

cool... I don't have the UD mobile app yet because I'm on the "other side" and missed the post about the iOS beta group until after it was already full.

18 minutes ago, palayman said:

@Michel Kohanim

So if I have two different programs, say one that runs from sunset to 11 and another that runs from sunset to sunrise, do they get cued in the FIFO randomly or perhaps in the order they were created? Maybe I've missed some documentation on this.

Cheers,

Paul

Programs don't run From... To...

In your example, from sunset to 11: will run the THEN body at Sunset and the Else body at 11, and its considered TRUE from Sunset to 11 and FALSE otherwise.   "repeats" and "waits" may keep programs running longer, but the only times that they "start" in your example is Sunset for THEN and 11 for ELSE.

As for two programs that both "Start" at Sunset, you can't predict which will run first, if order matter to you add a "wait" or run one at Sunset +a few seconds.

[IT Solutions]

Things don't always run exactly in order.  For example, see the program below. The first wait 10 seconds was added because another program that turned on the floor heat output to trigger this program also sends an email that includes $I.FH.ON.or.OFF.  Sometimes the value in the email would be wrong because the next line in this program would change it before the email was created.

The second wait ten seconds was added for the same reason.  The Send Notification right before that sends $S.Foor.Heat.Run.Timer and it was sending 0 even though we know it was not 0.  Adding the wait allowed the email to get sent with the correct value before resetting it to zero.

We also have programs that run on startup that need to run in order.  The first 6 need to run (does not matter what order), then after they are done, the 7th needs to run.  For the first 6 we add one to a Integer Variable in each program, then trigger the last program to run when the integer changes to 6 so it runs after the first 6 are done.

Floor Heat ON/OFF Actions and Timer - [ID 0011][Parent 0015]

If
        Elk Output 'Floor Heat Contr' is On
    And Elk Output 'Floor Heat Contr' is not Off
 
Then
        Wait  10 seconds
        $I.FH.ON.or.OFF  = 1
        $I.FH.Daily.Cycle.Count += 1
        $I.FH.Daily.Cycle.Count Init To $I.FH.Daily.Cycle.Count
        Send Notification to 'ELk Logs' content 'Floor Heat ON'
        Wait  10 seconds
        $S.Floor.Heat.Run.Timer  = 0
        Wait  40 seconds
        Repeat Every  1 minute 
           $S.Floor.Heat.Run.Timer += 1
           $I.FH.Daily.Run.Time += 1
           
        // // Only Save This Program When it is NOT Running //
 
 
Else
        $I.FH.ON.or.OFF  = 0
        Send Notification to 'ELk Logs' content 'Floor Heat OFF'
 
 

[MrBill]

1 hour ago, IT Solutions said:

Things don't always run exactly in order.  For example, see the program below. The first wait 10 seconds was added because another program that turned on the floor heat output to trigger this program also sends an email that includes $I.FH.ON.or.OFF.  Sometimes the value in the email would be wrong because the next line in this program would change it before the email was created.

The second wait ten seconds was added for the same reason.  The Send Notification right before that sends $S.Foor.Heat.Run.Timer and it was sending 0 even though we know it was not 0.  Adding the wait allowed the email to get sent with the correct value before resetting it to zero.

We also have programs that run on startup that need to run in order.  The first 6 need to run (does not matter what order), then after they are done, the 7th needs to run.  For the first 6 we add one to a Integer Variable in each program, then trigger the last program to run when the integer changes to 6 so it runs after the first 6 are done.

Floor Heat ON/OFF Actions and Timer - [ID 0011][Parent 0015]

If
        Elk Output 'Floor Heat Contr' is On
    And Elk Output 'Floor Heat Contr' is not Off
 
Then
        Wait  10 seconds
        $I.FH.ON.or.OFF  = 1
        $I.FH.Daily.Cycle.Count += 1
        $I.FH.Daily.Cycle.Count Init To $I.FH.Daily.Cycle.Count
        Send Notification to 'ELk Logs' content 'Floor Heat ON'
        Wait  10 seconds
        $S.Floor.Heat.Run.Timer  = 0
        Wait  40 seconds
        Repeat Every  1 minute 
           $S.Floor.Heat.Run.Timer += 1
           $I.FH.Daily.Run.Time += 1
           
        // // Only Save This Program When it is NOT Running //
 
 
Else
        $I.FH.ON.or.OFF  = 0
        Send Notification to 'ELk Logs' content 'Floor Heat OFF'
 
 

You're correct on both counts...  you need at least 1 second delay to send an email that includes a variable value that change.

Also programs that "run at the same time" it's impossible to predict what order they will run in, it doesn't matter if its "run at start up",  "run at sunset", or "Run at 11:00am" multiple programs with the same trigger run "all at once" and you can't guess which one will execute which first.... if order matters you have to control the order manually.

Personally for "run at startup" I only have ONE program that runs at startup.  When it's finished (which takes 10 minutes, mostly waiting, to finish) it runs the Then branch of another program that starts some heartbeat and does some other things and includes actually includes a couple short waits between some of the things it starts up.

Why 10 minutes for my run at startup program?  I have a really large insteon installation one of the things happening at startup is a 'query all' insteon... that needs to finish first, which actually happens mostly in about 4 minutes... the other part of the 10 minute value insures that in a WORST CASE SCENARIO (i.e. I'm on vacation in another part of the world and a major power outage caused even the UPS to run dry) the rest of the network (cable mode/LTE modem and router) will come up before the ISY starts trying to send me notifications.   10 minutes might be a little longer than it needs to be but I restart the ISY so rarely it doesn't matter to me.

[IT Solutions]

In my case I need the first 6 programs to run as quickly as possible, then the 7th to run immediately after them, before other values have a chance to change.  Thus the count up to 6 and go with #7.  I figure the first six are done in around a second.

Different needs require different solutions.

[MrBill]

15 minutes ago, IT Solutions said:

In my case I need the first 6 programs to run as quickly as possible, then the 7th to run immediately after them, before other values have a chance to change.  Thus the count up to 6 and go with #7.  I figure the first six are done in around a second.

Different needs require different solutions.

the important thing to keep in mind.... rebooting only happens months apart in most cases... it definitely not an everyday or even every week thing..  Generally the only time I reboot is firmware update.

[larryllix]

I would have each program increment a counter at termination and a 6 value trigger the last program dependent on the others, and clear the counter.

[IT Solutions]

@larryllix  That is what we do, except we don't clear the counter as that is our confirmation that all 6 ran.  The counter clears at reboot.

[IT Solutions]

8 minutes ago, MrBill said:

the important thing to keep in mind.... rebooting only happens months apart in most cases... it definitely not an everyday or even every week thing..  Generally the only time I reboot is firmware update.

Yes, but every time there is a change to programs that run at startup, a reboot should be done to test them.  We have a hard rule, "If you haven't tested it; it doesn't work."

[larryllix]

1 hour ago, IT Solutions said:

@larryllix  That is what we do, except we don't clear the counter as that is our confirmation that all 6 ran.  The counter clears at reboot.

....or two ran and the second ran 5 times.

[MrBill]

57 minutes ago, larryllix said:

....or two ran and the second ran 5 times.

then have one program add +1, the next add +2, the next add +4, the next add +8, the next add + 16, the last adds +32 when the total is 63 they all ran once....

oh... but that doesn't solve the problem if one of them can run 5 times ??

[Ross]

11 hours ago, MrBill said:

cool... I don't have the UD mobile app yet because I'm on the "other side" and missed the post about the iOS beta group until after it was already full.

Programs don't run From... To...

In your example, from sunset to 11: will run the THEN body at Sunset and the Else body at 11, and its considered TRUE from Sunset to 11 and FALSE otherwise.   "repeats" and "waits" may keep programs running longer, but the only times that they "start" in your example is Sunset for THEN and 11 for ELSE.

As for two programs that both "Start" at Sunset, you can't predict which will run first, if order matter to you add a "wait" or run one at Sunset +a few seconds.

MrBill,

I'd like to understand your sentence "In your example..." as I'm confused by the From... To...

I believe what your saying is that my program below would only run the Then at 8am and the Else at 2pm.  However, as long as it's between 8-2, the fans will turn on when the temp hits 75 - could be 9am or 11:30am.  I'm missing something but I don't know what.  Will you please explain what is happening?

Thank you,

Ross

[larryllix]

13 hours ago, MrBill said:

then have one program add +1, the next add +2, the next add +4, the next add +8, the next add + 16, the last adds +32 when the total is 63 they all ran once....

oh... but that doesn't solve the problem if one of them can run 5 times ??

The best way is to OR in distinct binary bits into the resultant flag variable. ie: OR in 1, 2, 4, 8, 16, & 32 from each program, so when the resultant bit accumulation == 2^6 - 1 then they have all ran and no multiple program runs can fool it.  Let's assume the power never fails.  

....The Bools

[MrBill]

8 hours ago, Ross said:

MrBill,

I'd like to understand your sentence "In your example..." as I'm confused by the From... To...

I believe what your saying is that my program below would only run the Then at 8am and the Else at 2pm.  However, as long as it's between 8-2, the fans will turn on when the temp hits 75 - could be 9am or 11:30am.  I'm missing something but I don't know what.  Will you please explain what is happening?

Thank you,

Ross

This program has more triggers.  specifically 3 state variables and a nodeserver data point, anytime ANY of those change the IF will be re-evaluted, during the time Range it is true.   This is different that the example present above which was two programs with time ranges only, the first was 'sunset' in both and the question was which sunset will run first... the answer to that question is that its not predictable.

[MrBill]

1 hour ago, larryllix said:

The best way is to OR in distinct binary bits into the resultant flag variable. ie: OR in 1, 2, 4, 8, 16, & 32 from each program, so when the resultant bit accumulation == 2^6 - 1 then they have all ran and no multiple program runs can fool it.  Let's assume the power never fails.  

....The Bools

yea... in ISY math functions we do actually have operators bitwise OR |= and bitwise AND &= meaning we can set or clear variables bitwise.

Unfortunately IF statement conditions don't include XOR or any other bitwise operators so there's no easy way to use it.  I wish there was actually.

[larryllix]

28 minutes ago, MrBill said:

yea... in ISY math functions we do actually have operators bitwise OR |= and bitwise AND &= meaning we can set or clear variables bitwise.

Unfortunately IF statement conditions don't include XOR or any other bitwise operators so there's no easy way to use it.  I wish there was actually.

The total value 2^6-1 (63) can trigger a program. Wouldn't need any boolishness on the right side of the logical trigger.
If
     $sBitTotal = 63
Then
    ....