ISY program response time

[kclark]

First of all I want to start out by saying I love my ISY and UDI’s development and support is second to none. It’s the reason I’m still having fun with home automation and I haven’t ripped out all my Insteon switches.

 

That said, I’ve always had a “feeling†that the response speed from the ISY programs isn’t what it should be. I used to use HomeSeer with a PLC and my dim recollection is that Event based actions used to respond faster.

 

Anyhow, I converted my lighting control over to the ISY but still use HomeSeer for functions that haven’t been developed in the ISY (yet). If HomeSeer needs to control a light it does so through the ISY via bpwwer’s ISY plugin.

 

So last night I set up the following test.

 

I added a simple program in ISY to turn on a SWL when another SWL was turned on.

 

If
       Control 'Sun Room: Ceiling 1.4' is switched On
Then
       Set 'Sun Room: Ceiling 1.2' On
Else
  - No Actions - (To add one, press 'Action')

I also set up a similar event in HomeSeer to turn on a different SWL when the same SWL button is turned on. So it’s a race.

 

I didn’t expect what I found. Switch the SWL and about a second later the HomeSeer Event turns on it’s SWL. A second to a second and a half AFTER that, the ISY controlled SWL turns on.

 

I just stood there turning the lights on and off. Never did the ISY’s light turn on before the HomeSeer controlled light.

 

Remember now, the ISY has to receive the SWL on message and send the status change to the HomeSeer plugin. HomeSeer then has to evaluate the Event and send a control command back to the ISY. Then the ISY sends the Insteon command on behalf of HomeSeer. All this happens a second before the ISY program interpreter can evaluate the same button press and respond by turning it’s light on. I get the fact that once ISY starts to send the HomeSeer command to the SWL the power line will be tied up with that communication and that may add to the ISY response time in this test. The question is why can HomeSeer initiate its response before ISY can evaluate its program and respond? The ISY after all has the button press information before HomeSeer.

 

After seeing the above I swapped which SWL the ISY and Homeseer was controlling. Same results.

 

Then I took HomeSeer completely out of the picture – turned off the HS pc. I didn’t see any appreciable improvement in the response time of the ISY controlled SWL. I wish I had a more precise way to measure the time between actions/events. I pretty much have to rely on watching the sweep second hand on my watch as the lights come on. It would even help if the Event Viewer time stamp was more granular when in say level 2 or 3.

 

Unless someone can shoot holes in my testing methodology, there is something that needs to be looked at in the ISY’s program evaluation algorithms. My background includes years of software development for embedded processor systems and I am confident that the hardware and software the ISY uses is capable of MUCH better performance.

 

Some further info and comments:

ISY 99i Pro (1040) running version 2.7.0 (I have since installed beta 2.7.2 and repeated all the tests – same results.)

14 enabled programs in the ISY

102 Insteon devices installed and added to ISY

32 Scenes

389 PLM links

HomeSeer is running on a not to swift Celeron 1.7 GHz machine.

100Mb network

 

If anyone has a way to run a similar test I would appreciate either corroboration or just tell me I’m nuts – that’s happened before.

 

Ken

[Michel Kohanim]

Hello Ken,

 

First of all, thanks so very much for the detailed explanation and benchmarking. With that said, the reasons that your HomeSeer responds more quickly are:

The program task has a lower priority than

a. The HTTP task - accepts HTTP requests from your plugin

b. The Updater task - updates the plugin with status

c. The number of programs that have to be evaluated

 

Now, with a task oriented OS such as ours, the program task will not get to run till the Updater (send event to HS) and the HTTP (respond to HS) tasks are completed. These priorities were chosen based on many factors including start up times, client responsiveness, and the feelings that programs are programs (events) which do not have to be instantaneous (we have scenes for those) and 1 to 5 second response times are permissible depending on the context.

 

With kind regards,

Michel

 

Withk

[kclark]

Thanks for the explanation Michel.

I understand and agree with the task priority you outlined. And there are other tasks running that probably have higher priority than program evaluation too. I was just not able to see how they could affect program evaluation time to this extent.

 

As a further test, I disabled all of my programs, save for the test program. No change in results.

 

Unfortunately, up to 5 second response to a key press or motion is not permissible for me (WAF among other things). That just means I'll move the timing sensitive event driven programs from the ISY to HomeSeer. I had been planning to phase out HomeSeer as new capabilities were added to the ISY. That way I wouldn't have to run a computer 24/7. I'll have to make other arrangements.

 

ISY is a great tool. I just have to find out where its limits are in my automation scheme. "Not every tool can be a screw driver... But every tool CAN be a hammer."

 

Ken

[bpwwer]

Michel,

 

Thanks for that explanation. I didn't realize that's how the ISY prioritized tasks. While I like the idea that plug-ins get a higher priority, is this something that could be made user configurable in a future version?

 

For people that want the ISY to be the primary controller it might make sense if the priority could be switched to make programs more responsive.

[MikeB]

For the record, I have a lot of triggers that run based on switch presses (double-tap OFFs, etc.). It's extremely rare when I have a program that takes more than 1 - 1.5 seconds to respond to a switch press.

[Michel Kohanim]

Hi Ken,

 

We continuously improve on performance. As Mike suggested, it's very rate that programs take longer than 1 to 2 seconds. I just tested my ISY with many programs and the response time was almost immediate.

 

Bob, we could possibly make this user configurable but, without detailed analysis of how much more performance is gained (see above), the side effects (deadlock), it would not be a good idea.

 

With kind regards,

Michel

[fitzpatri8]

Any chance a communications issue is causing the delay? Have you looked at the log to see how many hops commands are taking when communicating with the members of that program? Also, have you set it up so that the program executes a scene vs. commands each member device individually?

[ergodic]

Just my two cents:

 

Anything that could be done to improve (on my side or yours) the latency of programs' execution would be most appreciated IMHO. The delays are generally not huge, but there is a frustrating variability in the delays. And as the poster mentioned program response is in general noticeably slower and more variable than HS2.

 

There are a great many things I'd prefer to do with programs - if it were possible I'd just get rid of linked scenes completely (other than for simple multiway switches). But the problematic and variable latencies in program execution really seem restrict their useability.

 

If it is a matter of raw CPU horsepower or memory I for one would be happy to pay the extra cost for a higher-end unit. This thing totally rocks.

[Michel Kohanim]

Hello ergodic,

 

We will surely investigate this feasibility. The problem is not necessarily horse power but priorities: the client update task has a higher priority than the programs. The main question is: do you wish for your clients (such as Admin Console, InterfaceGo, IES touchscreen, HS) to be updated first or the programs?

 

With kind regards,

Michel

 

Just my two cents:

 

Anything that could be done to improve (on my side or yours) the latency of programs' execution would be most appreciated IMHO. The delays are generally not huge, but there is a frustrating variability in the delays. And as the poster mentioned program response is in general noticeably slower and more variable than HS2.

 

There are a great many things I'd prefer to do with programs - if it were possible I'd just get rid of linked scenes completely (other than for simple multiway switches). But the problematic and variable latencies in program execution really seem restrict their useability.

 

If it is a matter of raw CPU horsepower or memory I for one would be happy to pay the extra cost for a higher-end unit. This thing totally rocks.

[Michel Kohanim]

Hi all,

 

Based on the feedback, we changed some of the behaviors and task priorities in 2.7.3. Although we could not make drastic changes, but we managed to make program execution just a little more responsive by changing some of the priorities. Please do be kind enough to test 2.7.3 when it comes out and let me know how it feels. Also, please do make sure to check for deadlock or unresponsive system.

 

2.7.3 should be out very soon.

 

Thanks and with kind regards,

Michel

[Davonavo]

I don't have my ISY yet, (waiting for rebate) but I have been closely following what you all have to say. After many years trying to make HA systems work properly by improving my knowledge and requesting help from the manufacturers, I am impressed with the response from UDI to input from it's owner base. I realize all things requested are not possible, but this is always explained in a way that leaves the customer with the feeling he is not just being patronized. This is stellar performance in todays world. I look forward to getting my system started, so I can come here and say Help!

[ergodic]

Thanks for doing what you can.

 

To answer your question, I'd much, much rather have faster program execution at the expense of IF update speed. I only use the ISY interface when configuring, programming or troubleshooting.

 

People with touchscreens may have a different opinion. At the moment I have no touchscreen interfaces. I'm waiting for a better selection of touchscreen netbooks and then I'll probably try InterfaceGo on one.

 

Possibly it would be possible to make the prioritization a config option in the ISY? I realize you don't want to get too 'config-heavy', but this seems like one of those places where different people may have very different needs.

[Michel Kohanim]

Hi ergodic,

 

You will see just a little bit of improvement in 2.7.3. Still, if you have many things queued up to be sent on the wire, then you will experience delays till all our sent out (500 m.s. per message).

 

The configuration option is very tempting but the main issue is changing task priorities is always a very risky business. As such, please do be kind enough to test 2.7.3 to make sure you are not having system hangs.

 

With kind regards,

Michel

 

Thanks for doing what you can.

 

To answer your question, I'd much, much rather have faster program execution at the expense of IF update speed. I only use the ISY interface when configuring, programming or troubleshooting.

 

People with touchscreens may have a different opinion. At the moment I have no touchscreen interfaces. I'm waiting for a better selection of touchscreen netbooks and then I'll probably try InterfaceGo on one.

 

Possibly it would be possible to make the prioritization a config option in the ISY? I realize you don't want to get too 'config-heavy', but this seems like one of those places where different people may have very different needs.