Trouble With Some Programs After Going from 99 to 994

[grtaylor]

I have some programs to keep KeypadLinc LED's in sync (got the principles from other posts here), and with my 99 they worked perfectly. Since upgrading to 994 (did a backup/restore) they are very intermittent. Nothing else has changed. Any ideas where to start troubleshooting?

 

Example of the two programs I use to keep an LED on a KeypadLinc in sync with a light

 

Program - Test Master Bath Hall Light On

If

Status 'Master Bedroom / Master Bath Hall Dimmer' is not Off

 

Then

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

 

Else

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

 

Program - Set Master Bath Hall LED

If

Program 'Test Master Bath Light On' is True

 

Then

Wait 2 seconds

Set Scene 'Master Bedroom / Master Bathroom Hallway LED' On

 

Else

Wait 2 seconds

Set Scene 'Master Bedroom / Master Bathroom Hallway LED' Off

 

Scene "'Master Bedroom / Master Bathroom Hallway LED" has the button on the KeypadLinc I want to control as a responder.

 

As I say, it used to work perfectly. Now it's random. I have a bunch of these programs, and they all work some of the time. But not consistently.

 

Thanks

Greg

[LeeG]

If a Program is a necessary follow-up to keep two devices in sync (assuming both are controllers of the same ISY Scene) there is an Insteon Mesh Network issue to begin with. No reason to think the network issue would not affect the activity of the Program as well.

 

Has there been activity to fix the Insteon network problem? Until that is resolved device communication involving these devices can be unreliable regardless of whether device or PLM initiated. A simple test is to run Tools | Diagnostics | Event Viewer with LEVEL 3. Use the Admin Console to turn the switch and the KPL load On and Off several times looking at the Hops Left=x count. If the counts move around or is Hops Left=0 it indicates a track-able issue that can be used to show when the problem has been corrected.

[grtaylor]

Sorry for the slow reply. So I am seeing Hops Left = 0 a lot. Is there a troubleshooting guide or suggesting you can make to help me find out why?

[grtaylor]

The Hops Left = 0 are mainly showing in the [std-Cleanup] lines if that is an indication of something else.

 

I see a ton of posts in the comms issue forum. I'll take a look, but if you have any tips I'd appreciate the pointer.

[LeeG]

Sorry, I should have been more clear. A message with Max Hops=1 Hops Left=0 is great. It means the device message made it from the device to the PLM on the first attempt. A message with Max Hops=3 Hops Left=0 is bad. Also situations where Max Hops=3 and Hops Left=x count is varying from message to message is an indication of problems.

 

Finding Insteon comm problems is a challenge. I always suggest starting at the beginning. Be sure the PLM is plugged into an outlet, not a surge/noise suppression power strip. Other electronics powered from the same circuit (PC, UPS, etc) as the PLM should be isolated with a FilterLinc.

 

Then start analyzing communication with various devices around the Insteon network. Using the Admin Console with the Event Viewer running at LEVEL 3, turn various devices On and Off and watch the Hops Left=x counts. Messages from the PLM will have Max Hops=3 so Hops Left=2 is the best, Hops Left=1 is okay if the count remains consistent over several command executions, Hops Left=0 does not leave any room for additional sporadic noise or signal absorption. As mentioned before if Hops Left=x count is changing from command execution to command execution to the same device, that indicates problems even if some have Hops Left=2. It is common to have some change in Hops Left=x count if enough commands are sent.

 

By analyzing what devices have good comm and what devices have marginal/bad comm a pattern may evolve. All the marginal devices are on one circuit for example would require looking at what is powered from the circuit. It can be useful to unplug (not turn Off) appliances/devices to see if that improves comm on a particular circuit. Some cell phone chargers have been known to destroy comm in the area where they are plugged. Other devices can cause the same type of problem.

 

The first thing is determine how well comm is working around the structure and then evaluate what is causing problem areas. Not a particularly fun project and time consuming but there are no good Insteon based devices for Insteon network analysis. Some of the X10 tools can be used to measure the noise level. Insteon is on a different frequency and Insteon messages start earlier in the AC cycle but I have used an X10 Monterey Powerline Signal Analyzer to successfully locate noise. It is an expensive tool from my attempts to get X10 to run many years ago. Only if you already have something like that. I would not suggest getting one for Insteon.