Timing Issues with wait and repeat

[apostolakisl]

If
  - No Conditions - (To add one, press 'Schedule' or 'Condition')

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

Else
       Repeat 60 times
          Set 'Alexis Room / Alexis BR-Overhead L' 14 (Beep Duration)
          Wait  1 second

 

I would expect the else clause to run for 60 seconds and the switch to beep nice and steady once/sec. But it is not so. The beeps fluctuate greatly in timing and the entire 60 beeps takes more like 70 seconds.

 

Comments?

[LeeG]

I ran that test with good results. First beep was issued at 02:35:06, the 60th beep at 02:36:05. What other activity was running on the ISY during the 60 second period?

 

 

Fri 02/24/2012 02:35:06 PM : [iNST-ACK ] 02 62 15.9A.F9 0F 30 0E 06 BEEP (0E)

 

Fri 02/24/2012 02:35:06 PM : [iNST-SRX ] 02 50 15.9A.F9 19.70.06 2B 30 0E BEEP (0E)

 

Fri 02/24/2012 02:35:06 PM : [standard-Direct Ack][15.9A.F9-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

 

 

 

Fri 02/24/2012 02:36:05 PM : [iNST-ACK ] 02 62 15.9A.F9 0F 30 0E 06 BEEP (0E)

 

Fri 02/24/2012 02:36:05 PM : [iNST-SRX ] 02 50 15.9A.F9 19.70.06 2B 30 0E BEEP (0E)

 

Fri 02/24/2012 02:36:05 PM : [standard-Direct Ack][15.9A.F9-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

 

Else
       Repeat 60 times
          Set 'KPL Floor Dimmer 6 button' 14 (Beep Duration)

[apostolakisl]

One other program that was separately counting 60 seconds to turn the light off. I expected the two to end simultaneous, but the beeping continues for 5 or 10 seconds after the light turns off.

 

Plus, the beeping is not "like clockwork". Sometimes they are closer together (probably truly 1 sec) and other times more widely spaced (probably where the extra 5 or 10 seconds come from).

 

I ended up having the other program terminate this one so the beeping would stop at the same time the light went off.

[apostolakisl]

Based on your other comments to another post, I changed the program to

 

If
       Control 'Alexis Room / Alexis BR-Overhead L' is switched On
    Or Control 'Alexis Room / Alexis BR-Overhead L' is switched Fast On
    Or Control 'Alexis Room / Alexis BR-Overhead L' is switched Fade Up
    Or Status  'Alexis Room / Alexis BR-Overhead L' is not Off

Then
       Wait  29 minutes 
       Repeat 60 times
          Set 'Alexis Room / Alexis BR-Overhead L' 14 (Beep Duration)
          Wait  1 second
       Repeat 1 times
          Set 'Alexis Room / Alexis BR-Overhead L' Off

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

 

I was able to elliminate two programs and maybe not having that other timer running at the same time will fix things.

 

I have to ask, why is "repeat 0 times" an option??

[apostolakisl]

I checked my log this AM. My daughters light is programmed to turn on at 6:30am to wake her up. This triggers the above program which should shut the light off at 7:00am (29 minute wait plus 60 1 second waits).

 

The log shows the light turning on at 6:30:03 and then off at 7:01:03. That is a whole minute later than it should have gone off. I didn't have it on detail to know where it picked up the extra time, but something is running slow and I suspect it is the 60 wait 1 seconds.

 

Also, the program summary shows the light turning on program running at 6:30:00 and the above program last run at 7:01:03

[TJF1960]

I am wondering, is it possible that comm. to that SL is maybe not as good as other areas causing 2 or 3 hop counts to be used (assuming the beep command requires an ack return) which would delay the program from executing the next beep command? Or if there is a lot of other comm. going on at that same time so all the commands are being queued up causing the increase in execution times?

[LeeG]

The PLM can be over driven by the application so all applications (including the ISY) have a delay built in to insure the PLM is not driven faster than it can handle commands. Other Insteon activity during the 60 second once per second beep loop could slow the loop.

[apostolakisl]

So is the wait 1 second command not executed until after an ack is received on the beep command?

[LeeG]

Don't know if the Program holds on the Beep until the ACK is received or the next Beep is held until the ACK for the previous Beep is received. Either approach works. Probably others that don't immediately come to mind. The HouseLinc trace has a specific entry for waiting between events to throttle PLM commands.

[TJF1960]

I just ran a simple test program:

 

If
  - No Conditions - (To add one, press 'Schedule' or 'Condition')

Then
       Repeat 10 times
          Set 'Devices / WR1 KPL 1 Ceil Lite' 1 (Beep Duration)
          Wait  1 second
       Repeat 0 times
          Set 'Devices / WR2 KPL A Vent Fan' On

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

It takes 19-20 seconds from start to finish. I doubled the repeat to 20 times and reran. It took 39 seconds from start to finish. I ran both tests multiple times and the result was always the same. It would seem that about 1 second is used for sending/receiving the command then wait 1 second and repeat. The event viewer showed 2 hop counts left after each command was sent/received. Also the beeps seem to be about 2 seconds apart.

During one test I flooded the powerline by pushing another SL on and off for about 5 seconds during the program running which did extend the finish time by about 5 seconds, which shows any comm. during the program executing would also affect the finish time. Also during that time the beeps stopped then resumed after I stopped pushing the SL, the first couple of beeps were closely spaced then resumed to the every second or two normal speed.

 

As far as the Repeat “0†times I am thinking it is used to break out of the repeat without actually executing a command. In the above program the “Vent Fan†didn’t turn on but once I changed the repeat from 0 to 1 the vent fan turned on at the finish of the first repeat.

[apostolakisl]

If
  - No Conditions - (To add one, press 'Schedule' or 'Condition')

Then
       Repeat 10 times
          Wait  1 second

Else
     - no conditions

 

A run then on this program took 19 seconds to complete. So there is more to this than the plm or comm issues since this program is completely contained in the ISY.

 

If
  - No Conditions - (To add one, press 'Schedule' or 'Condition')

Then
       Wait  1 second
       Wait  1 second
       Wait  1 second
       Wait  1 second
       Wait  1 second
       Wait  1 second
       Wait  1 second
       Wait  1 second
       Wait  1 second
       Wait  1 second
       Wait  1 second
       Wait  1 second
       Wait  1 second
       Wait  1 second

Else
       Stop program 'Elk Temp'

 

This took 13 seconds

 

If
  - No Conditions - (To add one, press 'Schedule' or 'Condition')

Then
       Repeat 10 times

Else
     - no conditions

This took 0 seconds.

 

 

So combining repeat and wait seems to have a delay.

[TJF1960]

Yes, confirmed on this end as well. Interesting, I would not have thought that program would run with nothing after the wait….

 

And this program finishes in 9 to 10 seconds depending upon traffic:

 

If
  - No Conditions - (To add one, press 'Schedule' or 'Condition')

Then
       Repeat 10 times
          Wait  0 seconds
          Set 'Devices / WR1 KPL 1 Ceil Lite' 1 (Beep Duration)

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

And this program also finishes in 9 to 10 seconds:

 

If
  - No Conditions - (To add one, press 'Schedule' or 'Condition')

Then
       Repeat 10 times
          Set 'Devices / WR1 KPL 1 Ceil Lite' 1 (Beep Duration)

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

So it would appear that the repeat action by itself must consume about 1 second per run.

[LeeG]

These results are fascinating. I saved the Event log file from the 24th when I ran the test here which ran in exactly 60 seconds. Went back to the event file to confirm I had not miss calculated the time between the first and last beep, 60 seconds. Today it takes 120 seconds +/-.

 

Will try rebooting the ISY and power cycling the PLM to see if that makes any difference.

[TJF1960]

LeeG,

 

I meant to ask if that test was done on your test bed or house wide?

[LeeG]

It was run on the test bed. I now have two ISYs, one that manages the house and the other that runs the test bed. Although I have very little unexpected Insteon traffic from the house devices I found it easier to manage the test bed devices when they are on an ISY by themselves.

 

Power cycle of ISY made no difference. The Event trace is showing a clean 2 second cycle between Beeps. Thought it might have something to do with the If statement reevaluation but I deleted all If conditions with the same 2 second result. I’m right clicking on the Program and running the Then.

 

Very strange. Just need to think about what I have done in the last 3 days. Now that is a challenge.

[apostolakisl]

It would seem to me that there is a one second lag between execution of the commands after a repeat, and the restart of the repeat loop.

 

The following program took 10 seconds. Setting the variable to 0 should take less than a millisecond, so the looping back around seems to be a one second process.

 

If
  - No Conditions - (To add one, press 'Schedule' or 'Condition')

Then
       Repeat 10 times
          $itest  = 0

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

 

 

 

The following program I watched execute from the variable screen. The variables ticked up at exactly 1/second.

 

If
  - No Conditions - (To add one, press 'Schedule' or 'Condition')

Then
       Repeat 10 times
          $itest += 1

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

[IndyMike]

Hello Lee,

 

Your code from the 24th doesn't show a "wait" in the else statement (only the repeat). When I run this I get the same 60 second period.

 

If a 1 second "wait" is inserted, the period increases to 120 seconds.

 

I can confirm that the "Repeat" by itself is being scheduled. Other Insteon activity alters the timing as reported by Tim and Lou.

 

It appears that both the repeat and wait are interruptable (program re-evaluates and re-enters). The use of the repeat, by itself, appears to have 1 second of overhead.

 

These results are fascinating. I saved the Event log file from the 24th when I ran the test here which ran in exactly 60 seconds. Went back to the event file to confirm I had not miss calculated the time between the first and last beep, 60 seconds. Today it takes 120 seconds +/-.

 

Will try rebooting the ISY and power cycling the PLM to see if that makes any difference.

[LeeG]

IM

 

Great catch! Thanks. That is what I did wrong back on the 24th. I coded a different test Program for todays test which of course does have the Repeat and Wait. Explains why I see 120 seconds today. Really appreciate that find. I would have spent hours tonight trying to recreate a mistake.

 

Lee

[apostolakisl]

It would be great if Jahn or Michell could chime in.

 

I am suspecting that "repeat" has a 1 second delay built in for a reason. Perhaps it prevents a runaway loop from locking the system up?

[hoopty]

I wonder if you change the wait time to more than 1 second, if that would have any affect on it. Maybe you wouldn't see the one second going on behind the scenes, if the wait time were longer than the propagation time... just a thought.

[apostolakisl]

I wonder if you change the wait time to more than 1 second, if that would have any affect on it. Maybe you wouldn't see the one second going on behind the scenes, if the wait time were longer than the propagation time... just a thought.

 

 

Nope.

 

The following program counts up at exactly 3 second intervals. You can watch the variable screen and it shows the time the variable changes and it is right on at 3 seconds each time.

 

If
  - No Conditions - (To add one, press 'Schedule' or 'Condition')

Then
       Repeat 10 times
          $itest += 1
          Wait  2 seconds

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