Scene test questions

[gfridland]

Does the number of devices in a scene affect the reliability of the scene test funtion?

 

I have a large scene where all devices in my installation are responders (all on/off group). Currently, there are approximately 70 devices in this scene. When I run a test scene on this group, I get a significant amount of devices report as "failed" (greater than 70%)!!!

 

When I run scene test for all the individual scenes, I generally (99%) see "successful".

 

In some cases, individual scenes have 20 devices and do not fail...

 

Is this a result of the quantity of insteon traffic from such a large scene? Is this significant? Should I break the scene into smaller subsets?

[oberkc]

I have, personally, not noticed any relationship between scene size and test results. However, the larger scene size increases the possibility that one of your devices is triggering a program (which can corrupt scene test results). Is this a possibility for you?

[gfridland]

Interesting...haven't thought of programs causing test corruption...I will check it out!

[LeeG]

There is no relation to the number of devices in a Scene versus reliability as far as Insteon is concerned. However, Insteon will not allow multiple Scenes to run at the same time, cancelling one if another is started, So if something else introduces traffic while that large Scene is running it could result in that large Scene failing to complete. Controlling every installed load essentially simultaneously may generate some interference from an electrical perspective.

 

An All Device test is the extreme test of the Insteon network reliability. With sufficient work to locate and filter problem appliances/devices it should be possible to run that test with good reliability. I’m not at all sure that effort is worth the gain if everything else is working.

 

I would split the All Device Scene into multiple Scenes to reduce the total number of devices that are reacting at the same time.

 

EDIT: oberkc point of Programs interferring is a great point. It could be a logical interference (Program generated traffic) rather than electrical.

[oberkc]

Interesting...haven't thought of programs causing test corruption...I will check it out!

 

A scene test can, I understand, trigger programs. These programs can change device status and otherwise cause problems with scene test results. My suggestion is to temporarily disable any program which has a condition based on a device within the tested scene.

[gfridland]

Thanks Guys!!

 

I verified that there are no program related triggers that cause devices to react to a change in status due to the scene test, however, I do have programs that re-evaluate based on status change...these programs remain false and do should not send insteon signals into the network. Would a program re-evaluation cause a scene test issue?

 

I disabled the programs which are re-evaluated and the result was better...I had 2 consecutive 100% "successfull" results, followed by 2 with >70% "failed".

 

I have never seen a misfire when I call this large scene in practice...all devices turn on or off as intended but it concerns me if there is unknown weakness in this approach.

 

I'm not sure if it makes sense to split the scene into smaller groups to pass the scene test if all works ok???

[oberkc]

I find that the scene test is simply a single tool in a larger toolkit of troubleshooting methods. My experience is that if I get a significant number of successes, then I cease worrying about it. In your case, half the tests passed. I would take this to be a good indication that I can expect reliable operation of my system.

 

Furthermore, I don't even worry about scene tests if my system is otherwise working fine. When I begin to see operational failures, I would double-check with a scene test. If I then see consistent failures with the scene test I would begin trial-and-error (based on educated guesses, hopefully) removal of potential interference generating devices, using the scene test as a rough indication of improved communication, or no impact. Rarely do I ever see scene tests pass multiple times in a row, but so long that I see a good portion pass, I call it success, waiting for further operational indication of failure.

 

Another thing I watch, simultaneously with the scene test, is the event viewer, set to a high level of detail. With a little practice and experience, once can begin to sense a tempo with communication events. I find that a consistent and speedy tempo to be a good indication of robust communication. If the event viewer gets hung up at some point, I take this as a potential problem. Often times, the event viewer provides additional clues about the problem device(s).