What conditionals slow program speed down?

[gduprey]

Howdy,

 

Are there certain type of conditionals on programs that can lead to slowing down the time it takes the ISY to execute/respond to events?

 

I have an ISY with about 70 Insteon devices and about 90+ programs.  Most of the programs are not enabled as they are used as routines called by other events.  Probably about 40 enabled.

 

I've found that my "good night" action, it seems to take 10-15 seconds between when I press the Good night button on my keypad and when the lights go out.  I've manually executed every one of the few items in the goodnight program and they are all pretty much instantaneous in execution.

 

Because I bottle up the logic for "goodnight" separate from what invokes it, actually doing a "goodnight" involves about 4 programs to be called -- only the last one doing the actual initiating the "goodnight" insteon scene that shuts most lights off.  Manually executing any one of these programs from the console is very fast.

 

So the problem appears to be the time to execute the programs, not the content of the programs.  To test this, I copied and pasted all the logic from all 4 programs into a single program that is triggered by the keypad.  The result is about 1 second between pressing the button and the lights going off.  That seems to confirm it's not the actual logic for my "goodnight", but the chaining/running the 4 programs it's spread over.

 

I can't imagine running a program takes too long for the ISY to find and run.  So I got to thinking about whether certain conditions on programs were "slower" than other conditions and the ISY is just reacting slower because of those conditions.

 

For example, could using a 'status' condition (vs a control condition) slow down program execution?  Or anything else?

 

Debugging this took a long time, but I'm certain that the actual logic runs fast, so it leaves me asking this question.

 

Thanks!

 

Gerryt

[stusviews]

Post the four programs. Include descriptors and annotations.

[jerlands]

10-15 seconds is a long time.  I'd open Event Viewer to Level 3, press the "Goodnight button" and view the results (copy paste into message)

 

 

Jon...

[gduprey]

Well, mentioned that if I copy and pasted everything into a single program, it works very quickly (about 1 second from event to all actions complete). 

 

Other than the program that monitors the keypad, all the others have no "if" conditional and they aren't enabled, so doubt that it's really the 4 programs themselves.  Nor is it a comms issue -- there are no comms until the very last program and no delays.  The program is absolutely started within 1 second of the button press (you can see it start running in the admin console).

 

Its the fact (or related to) that I have to run multiple programs that seems to have some sort of overhead. 

[andyf0]

My "goodnight" program takes a little while to run also. It calls about 4 programs, one of which calls a couple more. But it doesn't bother me since I'm already in bed and pulling the covers up when I push the button. I think it's changing the settings on 2 Z-Wave thermostats that takes most of the time since I adjust mode, cool & heat set points on both. Lot's of Insteon and Z-Wave traffic going on which obviously has to get queued up.

[cam]

@Gerryt - I've seen similar behavior in my setup.  I have over 100+ Insteon light switches and an Elk M1 alarm panel with about 100 devices (e.g. door, window, motion, leak sensors) connected.  I tried to modularize my programs so that I could run them within other programs but there seems to be some overhead to that approach so I had to copy/paste similar functionality across programs (bad programming style but the programs execute much faster).

[jerlands]

The way I vaguely understand program execution..  occurs one program at a time and the program waits for the devices to ACK before it completes and goes on to the next program.

 

Then/Else statements don't wait for ACK from devices but just issue the command.

 

 

Jon...

[larryllix]

Typically it is not ISY program execution or logic processing that slows things down.

 

Years back I ran a similar system for X10 HA on a 40 MHz 80486 CPU and never saw any problems with loops or CPU bogging down. It was busy as it had an every second trigger that many programs used to do counting timers etc.

 

Now ISY comes along with a somewhere between a 600- 900 MHz (15 - 25 times) CPU and I am sure it doesn't sport an 8 bit bus either.

 

The slow down is the Insteon protocol.  While it is much faster than X10 and many others the time lags do add up.

 

When ISY sends out a command the targeted device has to acknowledge the command or ISY will send it again (Retry)

Before the targeted device can acknowledge it must wait for all devices to finish repeating the command with up to four hops and original send times.

Now the Acknowledge goes through the same process with up to four hops before anybody is allowed to talk again without signal collisions.

 

This all adds up to not too many commands, echoes, and acknowledges, with their hops/echoes per second.

 

The trick is to use scenes where only one command gets sent out and everybody involved does their thing at the same time.

 

One other trick is to space out your device commands with wait lines in your programs.

 

I use an ALL OFF scene and also an All OFF program with waits between 40-50 devices. They both have their uses.

[jerlands]

The trick is to use scenes where only one command gets sent out and everybody involved does their thing at the same time.

 

I agree.. scenes cut down a lot of ISY business.

 

 

Jon...

[gduprey]

I'm fairly certain it's not my Insteon traffic -- at least the traffic I'm initiating.  The 4 programs I run only set state variables (each handling different areas of state setting).  Only the last one I have actually runs an Insteon command and that one single command is to execute an Insteon scene that turns all the lights off.

 

Again -- if I paste all the combined 4 programs logic directly into a single program, the whole thing executes in about 1 second.  The only difference between the whole "all pasted together" and 4 seperate programs is that they are 4 seperate programs with RUN program commands to execute.

 

It appears the delay is creeping in between each RUN program and thats what makes me think that perhaps some sorts of conditionals in a program (likely not even the programs I'm running in my 4-program chain) slow down whatever main "loop" the ISY has over these things. 

 

Gerry

[oberkc]

Hey jerry,

 

While I have never noticed programs, themselves, causing much delay, it seems to me your exeriments are petty conclusive. But...15 seconds!? Wow. It is almost hard for me to imagine that separating programs would introduce this kind of a delay.

[oberkc]

Further thoughts....is it possible that other program or insteon activity is happening between the separated programs? Might this activity delay the response of the subsequent programs? Have you ever opened an event viewer while executing the goodnight action?

[gduprey]

I've watched the event viewer at least twice during this and see nothing Insteon or ZWave happening during that execution (it's usually a quiet time at night).    

 

The 15 seconds is a "worst case" and it varies between about 9 seconds and 15 with an average around 11.

 

I'll be honest, I have my suspicions on this.  While I have not yet been able to do much testing on it, something in the back of my head is telling me the more programs that use the 'Status of X is Y' conditionals, the slower this seems to have gotten.  That could easily be a incorrect suspicion and I know the 'Status' conditional isn't polling the devices (which, of course, would slow it down even more), but I have two ISYs that share a lot of common code (including the goodnight stuff) and one runs the same 4 programs a lot faster (still 3-5 seconds, but) and one difference is that the faster one has only 1 Status conditional (then again, the faster one has less devices and programs, so it could easily be a red herring).

 

I was hoping a UDI person could step in with any insight about things that put extra burden on the program loop logic and such.  

 

I'm away today until next week, so won't get to test this further (i.e. disable all Status conditional programs) until then. 

 

Gerry

[Michel Kohanim]

Hi Gerry,

 

Something definitely wrong unless the queue is filled up with events:

 

1. Programs run based on events that are in the queue

2. Events are pulled off from the queue on a first come first serve basis

3. Programs that work on Z-Wave/Insteon, wait for its completion

4. If programs create more events, then they will go on a queue to be processed

 

So, the main question is: what are these separate programs doing?

 

With kind regards,

Michel

[gduprey]

Thanks -- thats good to know!

 

Is there any priority to the queue?  If I have a run program and then an insteon command, they'll be in the queue and executed in order, correct?

 

I mentioned earlier, but basically, except for testing state variable values and setting state variable values, they are not doing anything that should take any time until the end of the very last one (that one is the only one that activates an Insteon scene that then turns all lights off).

 

Program 1 (enabled)

If Control 'Bedroom Keypad' is switched Fast Off

Then

  Run Program "Set Goodnight (if)"

 

Program 2 - "Set Goodnight" - (disabled)

<no If>

$Time_of_day = 40

$Entertaining_mode = 0

$Cleaner_Present = 0

Run Program "Set Goodnight Home/Away"

Run Program "Lights: Goodnight"

 

Program 3 - "Set Goodnight Home/Away" (disabled)

If $Occupancy_Mode is 0

Then

  <nothing>

Else

  Run Program 'Set Away Patrol'

 

Program 4: 'Lights: Goodnight" (disabled)

<no If>

Set Scene 'Lighting Scenes / Goodnight' On

Run Program 'Secure House'

 

If I take the 'Set Scene' from Program 4 and paste it into Program 1, everything works in 1-2 seconds.  That's why I keep feeling it's the chaining between programs that seems to be introducing the delays.  The 'Secure House' after the scene sends Zwave command to the locks and 2 Insteon commands to insure the garage doors are closed.  But the perceived time delay is when the lights go out -- the "Set Scene" command.

 

Gerry

 

 

[Michel Kohanim]

Thanks Gerry.

 

Quick comments:

1. What happens if you remove the following from Program 2:

$Time_of_day = 40

$Entertaining_mode = 0

$Cleaner_Present = 0

2. What happens if you remove the following from Program 3:

Run Program 'Set Away Patrol'

 

With kind regards,

Michel

[Xathros]

Gerry,

 

I'd be interested to know if removing the very last line (Run Program 'Secure House') makes any difference in when you see the lights respond.

 

-Xathros

[gduprey]

Long time after followup - it was ZWave!

Well, sort of.  The order of my goodnight program was to send an Insteon Set Scene command (to which about 70 devices are programmed to respond) and immediately after, I send a series of ZWave commands to insure the doors are all locked for the evening.  While debugging something else recently, I noticed (with the event viewer open and set to Device Communications Level) that when I ran my "Goodnight" program, even though the Insteon command was first, all I saw was a bunch of ZWave commands and then later, the Insteon traffic.  

Testing the idea that a later ZWave command has priority over an earlier Insteon command, I added a 'Wait 10 seconds' after the Insteon Set Scene command and before the ZWave commands.  Bang! Seemingly instant response to my "Goodnight" button.

Of course, overall, the total runtime is still about the same, but the WAIT allows the Insteon to do it's thing instantly and provide instant feedback/gratification to the family (door locks just need to happen, but can wait a little).

I would be curious if anyone knows why the ZWave command preempt the Insteon command.  My program (posted earlier) summarized (with no sneaky intermediate steps excepted) is

Run Program "Set Goodnight Lights" -> "Set Scene "Lighting Scenes/Goodnight" On
Run Program "Secure House" -> "Set 'Front Door' Lock (followed by 3 other ZWave Lock commands)

so given that, I do not understand why the Insteon Set Scene command "loses" to subsequent ZWave commands -- shouldn't they all execute (or at least queue up) in the order the related command is executed?

Gerry

[oberkc]

Interesting.  I have an end-of-day program that has always seemed to run slower than I would expect, and in different order.  Of course, there is zwave involved, so that may explain things.  In my case, it is not a big deal, so I have never bothered to try to figure it out, but that could be it.

[Wagood]

found some amazingly useful information here so thanks all for sharing, this is extremely useful for me. been wondering if i may ask you questions in case i would have some? thanks because i'm new here so i'm not sure how everything's going around. but so far, thanks!

[kclenden]

On 2/18/2018 at 12:19 PM, gduprey said:

Long time after followup - it was ZWave!

Wow!  Almost two years, and you still wrote a followup.  I wish everyone would do that.

From my reading of the forum over the years, it seems that there are no guarantees about the order statements execute within a program unless you use overt WAIT instructions.  Especially if you're launching programs right after each other.  It also seems to be true when it comes to setting variables and evaluating those same variables (you have to guard against race conditions).

Edit: To be more precise, it's not that lines in a program aren't executed sequentially, it's that some of them are not atomic (i.e. the line that runs another program completes when the other program is queued to run, not when the other program actually starts running).  So if two non-atomic commands execute one after the other, there's no guarantee which will actually get to complete first.

One more edit to add a link to a discussion about the atomic nature of the THEN clause in which apostolakisl talks about having done experiments with math equations dependent on order of execution and not always getting the same results:

https://forum.universal-devices.com/topic/22557-are-a-series-of-statments-within-a-then-clause-still-atomic/?tab=comments#comment-220515