Insteon troubleshooting

[Techman]

This is a helpful article on troubleshooting Insteon signal problems.

 

http://www.elavenue.com/insteon_test_data.html

 

 

[paulbates]

Nice Techman. Very helpful.

That Elam is quite a tease, would love to rent one for a day or so...

[Techman]

I noticed that the are not building the device but will sell the plans. Maybe UDI should look into this.

[Teken]

I noticed that the are not building the device but will sell the plans. Maybe UDI should look into this.

 

The link you provided is from a ISY owner member: ELA, who is the creator of the ELAM.

[LeeG]

Now we know what has been keeping ELA off the forums for so long.

[Teken]

Now we know what has been keeping ELA off the forums for so long.

 

That link and his blog has been up for more than a year. As to why he hasn't been around its more than likely he's just living life and hasn't had a need to come to the UDI forums because all is well in Insteon land. 

[stusviews]

Or her device doesn't really work. Anyone try this one?

[Xathros]

Stu-

 

It may be worth reviewing the many posts by ELA during the time he was developing the ELAM.  He has provided this community with a great deal of valuable data on Insteon signaling, noise and attenuation.

 

See: http://forum.universal-devices.com/topic/5600-getting-serious-when-comm-issues-strike/?hl=elam

 

That KPL diagnostic tool is a joke in comparison.

 

-Xathros

Edited December 30, 2014 by Xathros

[Teken]

If anyone can shoot me a link to obtain the Busy Rat software that would be most helpful. I am still in the mist of trying to get my Insteon enabled Flood Stop to communicate with my network.

[oberkc]

My impression of the smarthome tool is that it will simply confirm that which is obvious from observation...that some devices are not communicating well, or at all. The ability to identify the source of the difficulty remains up to trial-and-error processes.

[Teken]

My impression of the smarthome tool is that it will simply confirm that which is obvious from observation...that some devices are not communicating well, or at all. The ability to identify the source of the difficulty remains up to trial-and-error processes.

 

The problem with the tool is that it only works for Insteon devices produced after March 2013. So, anyone with legacy devices in their home this diagnostic tool will not operate on.

 

Secondly, with the advent of the newer firmware v.43 in several devices. It appears the diagnostic aspect is being deployed with in each of the Insteon devices instead.

 

ie. The device will show same phase / opposite phase. The device will blink green if the receiver has ack the message. It will blink red if one or more devices do not ack the message. Rebroadcasting of messages, and message clean up as well.

 

With the Beacon test if you see the end devices blinking this tells you the sender message is arriving. When ICS3 protocol comes out I expect to see even more consistent and reliable COM's and feature sets.

 

I have been one of the first to throw Smarlabs under the bus when warranted. But, am also the first to Ack when I see progress and development in a product.

 

I believe some great products and features will be released in the not too distant future from Smartlabs and the engineers should be proud in pushing the Insteon protocol forward.

 

Now, they really need to get the e-docs straight and provide release notes that coincide with the product being sold and offered to the public. 

[Brian H]

BusyRats web site is gone and his domain is now listed on some of those domain selling sites.

Not sure if anyone has it archived on their web site.

I believe he released it to public domain with no support.

[Teken]

BusyRats web site is gone and his domain is now listed on some of those domain selling sites.

Not sure if anyone has it archived on their web site.

I believe he released it to public domain with no support.

 

Just my luck!

 

Well, here is a global plea to those who may have a copy and can fire it over to me. 

[oberkc]

The problem with the tool is that it only works for Insteon devices produced after March 2013. So, anyone with legacy devices in their home this diagnostic tool will not operate on.

 

Secondly, with the advent of the newer firmware v.43 in several devices. It appears the diagnostic aspect is being deployed with in each of the Insteon devices instead.

 

ie. The device will show same phase / opposite phase. The device will blink green if the receiver has ack the message. It will blink red if one or more devices do not ack the message. Rebroadcasting of messages, and message clean up as well.

 

With the Beacon test if you see the end devices blinking this tells you the sender message is arriving. When ICS3 protocol comes out I expect to see even more consistent and reliable COM's and feature sets.

 

I have been one of the first to throw Smarlabs under the bus when warranted. But, am also the first to Ack when I see progress and development in a product.

 

I believe some great products and features will be released in the not too distant future from Smartlabs and the engineers should be proud in pushing the Insteon protocol forward.

 

Now, they really need to get the e-docs straight and provide release notes that coincide with the product being sold and offered to the public.

 

Yes, clearly there is an attempt to develop tools to aid in diagnostics. But, in the end, knowing what phase one device is on relative another, knowing that a message has arrived, or knowing whether an acknowledgement has been received is not much new. I can already perform phase testing using access points. If a message has been received by a device, I can tell by observing the response. Many of my older devices already blink when there is a failure to receive acknowledgement.

 

Still, my bigger problem remains...how do I react to this knowledge. I am having trouble envisioning how this helps me identify the CAUSE of these problems. Perhaps I am missing something.

 

Part of the problem in my case may be that I have already been through the troubleshooting pain and now have a mature and reliable system. I do not much keep up with the additional capabilities of the newer devices. I certainly dont read the manuals for every iteration of every new device. If I want a new device here and there, I simply buy it, add it to my system using the methods I have already learned, and it works. Given this, I admit there may be more value here than I am able to recognize.

[Teken]

Yes, clearly there is an attempt to develop tools to aid in diagnostics. But, in the end, knowing what phase one device is on relative another, knowing that a message has arrived, or knowing whether an acknowledgement has been received is not much new. I can already perform phase testing using access points. If a message has been received by a device, I can tell by observing the response. Many of my older devices already blink when there is a failure to receive acknowledgement.

 

Still, my bigger problem remains...how do I react to this knowledge. I am having trouble envisioning how this helps me identify the CAUSE of these problems. Perhaps I am missing something.

 

Part of the problem in my case may be that I have already been through the troubleshooting pain and now have a mature and reliable system. I do not much keep up with the additional capabilities of the newer devices. I certainly dont read the manuals for every iteration of every new device. If I want a new device here and there, I simply buy it, add it to my system using the methods I have already learned, and it works. Given this, I admit there may be more value here than I am able to recognize.

 

I don't really think you missed anything at all.   

 

I do believe having more is always better for the collective as a whole. Sometimes keeping things simple is much better than using all the high tech gizmos abound. I am a firm believer in unplugging all electrical devices during a commission of a site then trial by fire.

 

It simply does not work and adds more time than it really saves by sitting and waiting to see if all is well. Even when using the breaker method its sometimes impractical to identify what is all on a circuit with out spending lots of time documenting each room, floor, zone, etc.

 

Adding back a single item while watching either HL2 software or the level 3 event log is one of the best methods to see bad COM's when they are present.

Edited December 30, 2014 by Teken