Need help with troubleshooting protocol

[TJF1960]

Hi Michel,

 

I tested 4 of 2476S SwitchLinc Relay W/Sense v.37, all backlight changes worked in 3.1.0 not in 3.1.1 and newer.

 

I also tested 2 of 2476S SwitchLinc Relay - Remote Control On/Off Switch v.3A, again all backlight changes worked in 3.1.0 but not 3.1.1 and newer.

 

Also all SL Relay models I have do have beep.

 

Tim

[Michel Kohanim]

Hi Tim,

 

Thanks so very much. There should be a fix in the next drop.

 

With kind regards,

Michel

[Illusion]

Hi Tim,

 

Thanks a bunch for the assist. That was some great and definitive detective work. I greatly appreciate the time you put in with all that version switching and testing.

[TJF1960]

Hi Illusion,

 

No problem, I was curious and hoping to be of some help.

 

By the way 3.1.5 fixed all of my SL Relay Led brightness issues, hoping it fixes your SL and KPL backlight troubles as well.

 

Michel, Thank you as always!!!

 

Tim

[Michel Kohanim]

Hi Tim,

 

My pleasure. Would you be kind enough to ensure that 3.1.5 passes the TFT? We had rather comprehensive changes to the network library (mostly impacting SSL) ... if we pass the TFT, then everything is fine!

 

 

With kind regards,

Michel

[Illusion]

I need some help. I am hoping someone out there has a (2486D) KeypadLinc Dimmer v.2D that they can test for me in their system. While doing my homework from IndyMike I began to wonder if many of my issues are just an anomaly of this specific firmware, kinda like the inconsistent problems caused by v.35 devices.

 

If you have any (2486D) KeypadLinc Dimmer v.2Ds please do these couple of test, all with maximum event viewer resolution open:

 

1. Build a program to turn the load on and off every 2s with a 2s delay between on and off. Run that in a loop for a few minutes. Look for any errors like listed in this post.

 

2. Repeatably query the devices. See if they just refuse to respond all of a sudden.

 

3. If you have the time, make a back-light adjusting loop program and run that for a few minutes as well looking for errors.

 

Thanks all.

 

IM, LeeG,

 

Hours of testing today with very frustrating results. I got the device link tables 12 times today. 6 times from each of my problem KPL. Both with and without v.35 devices in system. The first test was to get the device link tables from each device 3 times so I could do some statistical analysis if the v.35s were interacting negatively in earlier tests even though the mini network was isolated behind filters. This time both KPLs are in system and the whole system is the same as always except the circuits with v.35s were opened. This kills 4 v.35s and 4 other modules plus my hardwired coupler. Low and behold, in 3 tests on each switch not a single errant device ID was returned!

 

I think to myself, finally definitive proof that my v.35s negatively impact my system. I do 3 link table fetches on each device with the 4 v.35s and the 4 other modules back on line but without the coupler installed. And damn!!! Not a single errant device ID returned. Could it be the coupler. I put it back in and do three more fetches with not a single errant device ID returned.

 

The last time I did this I could not get a single link table without errant IDs and now, with the system the same I cannot get a single error. I like fetching the device link tables because it is lots of commands with little interaction from me, but boy they take a long time with heavily linked KPLs. This is why I did not ask others to do this test. It really can kill a day and appears to not be consistent even in my troubled case.

 

I set up two other tests.

 

First I turned the loads on these two on and off at 2s intervals with device direct commands in a program. I did get an anomaly:

 

Mon 07/18/2011 01:23:48 PM : [iNST-ACK    ] 02 62 0F.C1.DE 0F 11 FF 06          LTONRR (FF)

Mon 07/18/2011 01:23:48 PM : [iNST-ACK    ] 02 62 0F.C1.DE 0F 11 FF 06          LTONRR (FF):  Received an ACK for a different device 

Mon 07/18/2011 01:23:48 PM : CLI-WBug: Successfully Processed WBug Response

Mon 07/18/2011 01:23:48 PM : [MOD  2  2  1  1] 972000.000000  Weather - Temperature = 97.2 °F

Mon 07/18/2011 01:23:48 PM : [iNST-SRX    ] 02 50 12.3A.85 13.24.AA 27 13 00    LTOFFRR(00)

Mon 07/18/2011 01:23:48 PM : [standard-Direct Ack][12.3A.85-->ISY/PLM Group=0] Max Hops=3, Hops Left=1

Mon 07/18/2011 01:23:48 PM : [  12 3A 85 1]       ST   0

Mon 07/18/2011 01:23:48 PM : [iNST-ACK    ] 02 62 12.3A.85 0F 11 FF 06          LTONRR (FF)

 

"Received an ACK for a different device" Is this the same monster as I was seeing before. It seems to me to be coming from the PLM, not another device as it is an ACK not a SRX. What are your thoughts LeeG?

 

And here is the same issue regarding the other KPL:

 

Mon 07/18/2011 01:24:04 PM : [iNST-ACK    ] 02 62 0F.C1.DE 0F 11 FF 06          LTONRR (FF)

Mon 07/18/2011 01:24:05 PM : [iNST-ACK    ] 02 62 12.3A.85 0F 11 FF 06          LTONRR (FF)

Mon 07/18/2011 01:24:05 PM : [iNST-ACK    ] 02 62 12.3A.85 0F 11 FF 06          LTONRR (FF):  Received an ACK for a different device 

Mon 07/18/2011 01:24:05 PM : [iNST-SRX    ] 02 50 0F.C1.DE 13.24.AA 23 11 FF    LTONRR (FF)

Mon 07/18/2011 01:24:05 PM : [standard-Direct Ack][0F.C1.DE-->ISY/PLM Group=0] Max Hops=3, Hops Left=0

Mon 07/18/2011 01:24:05 PM : [   F C1 DE 1]       ST 255

Mon 07/18/2011 01:24:06 PM : [iNST-SRX    ] 02 50 12.3A.85 13.24.AA 27 11 FF    LTONRR (FF)

Mon 07/18/2011 01:24:06 PM : [standard-Direct Ack][12.3A.85-->ISY/PLM Group=0] Max Hops=3, Hops Left=1

Mon 07/18/2011 01:24:06 PM : [  12 3A 85 1]       ST 255

 

 

IM,

I did this test for 3m with those breakers open and closed each. There was a statical difference here. There were 4 errors like this with those breakers open and 12 errors with them closed. I am not sure that is very definitive though based on my other inconsistencies. I have read other posts expressing concern about the timing of simulcasting and concerns that more devices cause as many problems as they cure and I sure can buttress that with anecdotal experience. This increase in errors could be because of something else changing in the line while doing tests, or it could be because I added 8 more repeaters to my system by closing those breakers. The hardwired coupler was out for both conditions.

 

The last test I did was a looping back-light changing program for just these two KPLs. Bright and then dim. 2s delay between bright and dim. Not a single error, or failure to communicate in the 3m test with or without v.35 devices in system. No coupler for both conditions.

 

And this would be my source of frustration. I sit down to do some work on this today, and everything works whereas the last time I put time into this it would not work at all. I know of no changes to my environment between the tests. At least none I can control.

[LeeG]

The issue with the v.35 SwitchLincs was believed to be a firmware problem rather than a hardware problem. It may be necessary for those devices to be powered on and running for some period of time before the interference surfaces (if they are causing a problem). Once the symptom appears turn the devices off and see if that resolves the problem rather than turning them on.

[Illusion]

LeeG,

 

I will add that to the test docket. What are your thoughts on the most recent errors. Am I right that they are from the PLM and not a remote device?

[LeeG]

Illusion

 

You are right on in that the messages are initiated by the PLM not a device. It is difficult to tell from those messages what the issue is. When a serial message is sent to the PLM the PLM echo’s the message back to the application with a 06 (ACK) or 15 (NAK) appended to the original message indicating acceptance or rejection of the message. The ISY does not trace the message sent to the PLM. Normally the message sent and the echo are duplicates with an 06 on the end of the echo so tracing the sent message would be redundant.

 

From the annotation it suggests the echo received does not match the device address of the message sent. Seems an odd thing for the PLM to do since it normally just rejects the next command with an echo of 15 if it cannot accept the next message. Without the sent message and echo traced together it is hard to know just what is happening.

 

It is likely that the serial message sent and the echo response are on different ISY threads. That might lead to a situation where something on the send thread has gotten ahead of the receive thread. Might be the PLM echoed the wrong device address. Just cannot tell from the echo trace messages alone. Whatever the situation these are all questions dealing the PLM. The echo response has nothing to do with an individual device response. In fact my experience is the echo occurs before the message is actually sent on the powerline.

 

Lee

[Illusion]

Thanks LeeG. So different issue altogether. Good to know. As I expected but you are the resident expert on event traces.

 

Confirming 3.1.5 did fix my Switchlinc Relay 100% back-light failure rate, as I expected it would. I have always thought that was a different issue than my KPL problems.

 

That is all the testing and upgrading I can do for awhile. I will report back with any new developments in the future.

[IndyMike]

Hello Illusion,

 

The good news is that I do have a couple of V.2D KPL's.

 

The not so good news is that I tested these using a looping backlight routine back when you were initially having problems with (ISY V3.1.4). I did not see any issues. I did not perform anywhere near the amount of testing that you have put in (not exhaustive). Over 20 bright/dim cycles, I received no errors and the backlight's operated faithfully. I tried this at a number of times during the day without a problem.

 

I apologize for not reporting this earlier, but my tests are far from conclusive and I was worried that the results might lead you toward replacing hardware (I do not think this is a hardware problem).

 

If there are additional tests that you would like me to perform on the V.2D's, let me know.

[Illusion]

Thanks IM,

 

If you would not mind occasionally doing repeated queries to see if they refuse that that could be good. Also, the most consistent failure I get is refusal to communicate when doing a fetch of the device links. I suspect this is because of so much traffic generated by the fetch.

 

So if you have time to kill I would love an occasional attempt to get the device link tables and look for errors, both device ID errors and comm errors. I have noticed that my hop counts are all over the place when I do this. Many comms at 2 hops remaining, and then degradation through the process down to 0 hops remaining and even occasional retries of transmissions.

[ELA]

Illusion,

Have you ever communicated directly with your questionable PLM using a terminal program (as a diagnostic tool)?

That way you can monitor all the responses of the PLM.

[Illusion]

ELA

 

I think you have just lost me. I am always interested in learning, but I do not think I have even a basic knowledge of what you are talking about.

[LeeG]

Illusion

 

After looking over the last trace I think it is just a timing question with no lost communication. Both the 0F.C1.DE and 12.3A.85 devices actually ACKed (device ACK) the outbound commands so the PLM accepted and executed the commands. Both devices received their respective commands and ACKed them. Best guess is the outbound activity is happening so fast that the preparation for the next outbound command (to 12.3A.85) has happened faster than the echoes are coming back.

 

ELAs thought about driving the PLM commands with a test environment independent of the ISY might show that. Would require moving the ISY PLM to a Serial port on the PC/MAC. Then send repeated On commands to 0F.C1.DE and 12.3A.85 watching the responses. I really think this is unrelated to the other symptoms and do not think getting a definitive answer to this will help resolve the other symptoms.

 

Lee

[ELA]

Hi Illusion,

Sorry about that.

As LeeG mentioned you use a PLM connected to a serial port direct to the computer rather than the ISY99.

 

This does require you to be familiar with Terminal programs such as Hyperterminal or better yet is a free program called Docklight.

 

You load and send your own messages through the terminal program and the screen shows you what the responses are.

 

The EZBridge Manual for the (2412S) is very helpful at explaining the procedure. Others here probably can also help if you want to try that method.

I do not own Houselinc but I have heard it is pretty flexible as another possible option?

 

It is a little laborious but you seem like you are determined

[Brian H]

I have used Busy Rats PLM Test program to send and receive the hex codes through a PLM.

http://busyrat.com/plmtest/

 

I have also used DockLight as it is what the present Insteon SDK Kits use.

http://www.docklight.de/

 

Both I believe are Windows programs and I have not kept up on the latest Mac OS running Windows programs.

[IndyMike]

Hello Illusion,

 

I've been exercising my V.2D KPL over the past week. My particular unit is a 6 button and contains 87 links. I've been comparing the response of this unit with my other older and newer KPL's and can't honestly see a difference. That does not mean that I have not seen problems at times.

 

I've been dumping the event viewer contents to Excel and performing a post-mortem on the link scan. My intent was to statistically measure changes in my system. In this I failed, but I did learn a number of things about my system.

 

The following is a section of the event viewer and the items that I was tabulating. All of the commands/responses were tested for addresses (only communications to/from the specific address were tabulated).

 

[A E5 EC 1 ] Using engine version i1 for 'Foyer KPL 1 - Bar Lamp'

[iNST-ACK ] 02 62 0A.E5.EC 0F 28 0F 06 SET-MSB(0F) (ACK SET-MSB - PLM ACK of ISY Command)

[iNST-SRX ] 02 50 0A.E5.EC 13.22.F9 2B 28 0F SET-MSB(0F) (SRX SET-MSB - KPL ACK of SET-MSB Communication)

[standard-Direct Ack][0A.E5.EC-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 (Hop Count- ISY decoding of SRX response)

[iNST-ACK ] 02 62 0A.E5.EC 0F 2B F8 06 PEEK (F8) (ACK Peek - PLM ACK of ISY Command)

[iNST-SRX ] 02 50 0A.E5.EC 13.22.F9 2B 2B A2 PEEK (A2) (SRX Peek - KPL ACK of Peek communication)

[standard-Direct Ack][0A.E5.EC-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

 

The above communications are tabulated below for a number of configurations of my system. As I stated above, my KPL contains 87 link records with 8 bytes per records. It takes two communications (1 SET MSB and 1 PEEK) to read each byte. In a perfect world, it would take a total of 1392 communications to read the entire table ( 696 Set MSB comms and 696 Peek comms). Test #4 below is an example of a "perfect" link read with 696 set-msb comms and Peeks. There were no 0 hop responses, and the number of 2 hop responses is above 90%. Not bad...

 

 

So, why did I say I failed? There is a lot going on in these logs and it can't be accounted for with a simple statistical method. To do this properly, intelligence is required to interpret the order of commands and responses. In other words, I need a post processing program to apply the insteon protocol and look for inconsistencies in the responses (or lack thereof).

 

Problem 1:

Referring back to my "Perfect" run #4 - there were a number of Extended communications logged with my KPL address. The communication itself appears to be garbage as the hop count is whacked and the data does not correlate to anything in my KPL. Not sure if this is a repeater mis-interpreting the data or the PLM. Regardless, the KPL did respond with the correct data immediately afterward.

 

Tue 07/19/2011 05:17:56 PM : [standard-Direct Ack][0A.E5.EC-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Tue 07/19/2011 05:17:56 PM : [iNST-ACK ] 02 62 0A.E5.EC 0F 28 0F 06 SET-MSB(0F)

Tue 07/19/2011 05:17:56 PM : [iNST-SRX ] 02 50 0A.E5.EC 13.22.F9 2B 28 0F SET-MSB(0F)

Tue 07/19/2011 05:17:56 PM : [standard-Direct Ack][0A.E5.EC-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Tue 07/19/2011 05:17:56 PM : [iNST-ACK ] 02 62 0A.E5.EC 0F 2B B2 06 PEEK (B2)

Tue 07/19/2011 05:17:57 PM : [iNST-ERX ] 02 51 0A E5 EC 13 22 F9 14 D7 CF 13 35 6F 4F 6B EC 39 31 18 63 29 B5 4C E4

Tue 07/19/2011 05:17:57 PM : [Extended-Direct][0A.E5.EC-->ISY/PLM Group=0] Max Hops=0, Hops Left=1

Tue 07/19/2011 05:17:57 PM : [iNST-SRX ] 02 50 0A.E5.EC 13.22.F9 2B 2B 13 PEEK (13)

Tue 07/19/2011 05:17:57 PM : [standard-Direct Ack][0A.E5.EC-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

 

Problem 2:

 

Between 7 and 7:30 PM each day, my system hits a brick wall. At best, hop counts degrade significantly. Normally, it would simply "error out" on device retries (total loss of communication). I have nothing in particular scheduled at this time that would explain additional noise or excessive communication.

 

The following shows the performance during this "Problem Period". Runs 1 and 20 are good. Everything in between shows degradation. Runs 10 and 11 stopped early due to no response after 3 re-tries.

 

The above lead me to canvass the house looking for possible problems -

1) Several devices with "orphaned" links - reprogrammed.

2) Burned contactor on my A/C compressor (causing voltage drop on start-up).

3) Waterlogged tank on my Grundfos variable speed well causing surging (motor speed variation).

 

To date - nothing I have done has touched the above phenomena. I would love to start pulling breakers when this occurs, but unfortunately, this is "Prime Time" in the household. My family barely tolerates my activities as it is.

 

My latest hunch is that I (or my neighbor) has a photo-cell that is experiencing problems. The time frame in question is about right for "shadows" developing in the area. I'm thinking that the photo-cell may be oscillating in the "twilight" prior to total darkness. I've disabled my post-light. If that doesn't work, it may be time to visit my neighbor (with a couple of cold beverages of course).

[IndyMike]

Hi Illusion,

 

I'm going backward through your posts trying to correlate observations. I have roughly 35 KPL scans saved over a period of days. Some of your observations I can confirm, some I cannot.

 

If you would not mind occasionally doing repeated queries to see if they refuse that that could be good. Also, the most consistent failure I get is refusal to communicate when doing a fetch of the device links. I suspect this is because of so much traffic generated by the fetch.

 

So if you have time to kill I would love an occasional attempt to get the device link tables and look for errors, both device ID errors and comm errors. I have noticed that my hop counts are all over the place when I do this. Many comms at 2 hops remaining, and then degradation through the process down to 0 hops remaining and even occasional retries of transmissions.

 

I also see an "ebb and flow" of hop counts during a KPL scan. The scans on my V.2D KPL take roughly 15 minutes to complete. There is a lot of communication going on during that time frame, and a lot of other things being activated.

 

Observations:

• [*:28t426y2]During the early morning hours hop counts are consistently good. The A/C and well pump are not in use and the refrigerator/freezers have not been opened.
  [*:28t426y2]During the day heavy loads are frequently activated. During load start-up I do see a decrease in Hop count, which then quickly recovers as the load stabilizes. The most obvious is my A/C compressor. On start-up, it's not uncommon to get a re-try during a link scan. I actually made things worst when I replaced the 240V contactor. The old contactor was likely producing a low voltage condition on start-up and the compressor was struggling. With the new contactor in place, the compressor is starting nicely, but is likely producing a much higher inrush current and upsetting communications for a few reads.[*:28t426y2]My "brick wall" noise event came early today. We're having storms pass through and it's quite dark outside. I failed 3 successive attempts to read my KPL link table (failed on retries). Then applied some electrical tape to the post lamp photo cell (constant on) and passed 3 successive reads. This becomes more interesting in light of my current setup - I have my PLM and the KPL on two separate filtered circuits (RF couple only). I'm guessing this is low frequency noise that is making it past the filterlincs and affecting the AGC on one of the devices.

 

In summary, I would view Hop count variation and retries as a fact of life. This is the Insteon protocol at work adapting to the changing noise environment within the home. Heavy load startup will affect powerline communication due to inrush current and wild variations in the powerline impedance. Insteon combats this through the use of multiple repeaters and retries.

 

First I turned the loads on these two on and off at 2s intervals with device direct commands in a program. I did get an anomaly:

 

Mon 07/18/2011 01:23:48 PM : [iNST-ACK    ] 02 62 0F.C1.DE 0F 11 FF 06          LTONRR (FF)

Mon 07/18/2011 01:23:48 PM : [iNST-ACK    ] 02 62 0F.C1.DE 0F 11 FF 06          LTONRR (FF):  Received an ACK for a different device 

Mon 07/18/2011 01:23:48 PM : CLI-WBug: Successfully Processed WBug Response

Mon 07/18/2011 01:23:48 PM : [MOD  2  2  1  1] 972000.000000  Weather - Temperature = 97.2 °F

Mon 07/18/2011 01:23:48 PM : [iNST-SRX    ] 02 50 12.3A.85 13.24.AA 27 13 00    LTOFFRR(00)

Mon 07/18/2011 01:23:48 PM : [standard-Direct Ack][12.3A.85-->ISY/PLM Group=0] Max Hops=3, Hops Left=1

Mon 07/18/2011 01:23:48 PM : [  12 3A 85 1]       ST   0

Mon 07/18/2011 01:23:48 PM : [iNST-ACK    ] 02 62 12.3A.85 0F 11 FF 06          LTONRR (FF)

 

"Received an ACK for a different device" Is this the same monster as I was seeing before. It seems to me to be coming from the PLM, not another device as it is an ACK not a SRX. What are your thoughts LeeG?

 

The above "ACK for a different device" is something I have not seen. I can search my entire workbook of 35 runs, and this error does not show up. I have tried to trip the ISY/PLM up by activating programs, initiating RF events, even writing to the device being scanned - to no avail. The ISY seems to handle all of these events with aplomb - Congrats to the UDI team on a robust interface.

 

But this gave me an idea. As long as I have my KPL isolated with the PLM, I would try to run a test program to change its backlight repeatedly. That way I would know it was some problem with the network at large that was causing the intermittent failure of the backlight changing.

 

I changed the backlight to dim, and then back to bright. I was shocked to find the failure on the second attempt to change the backlight:

 

Tue 07/12/2011 10:57:23 AM : [        Time] 10:57:23 1(0)

Tue 07/12/2011 10:57:23 AM : [All         ] Writing 2 bytes to devices

Tue 07/12/2011 10:57:23 AM : [12 3A 85 1  ] Memory : Write dbAddr=0x0264 [00]

Tue 07/12/2011 10:57:23 AM : [12 3A 85 1  ] Using engine version i1 for 'Wake 3AM'

Tue 07/12/2011 10:57:23 AM : [iNST-ACK    ] 02 62 12.3A.85 0F 28 02 06          SET-MSB(02)

Tue 07/12/2011 10:57:24 AM : [iNST-SRX    ] 02 50 12.3A.85 13.24.AA 2B 28 02    SET-MSB(02)

Tue 07/12/2011 10:57:24 AM : [standard-Direct Ack][12.3A.85-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Tue 07/12/2011 10:57:24 AM : [iNST-ACK    ] 02 62 12.3A.85 0F 2B 64 06          PEEK   (64)

Tue 07/12/2011 10:57:24 AM : [iNST-SRX    ] 02 50 12.3A.85 13.24.AA 2B 2B 7F    PEEK   (7F)

Tue 07/12/2011 10:57:24 AM : [standard-Direct Ack][12.3A.85-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Tue 07/12/2011 10:57:24 AM : [iNST-ACK    ] 02 62 12.3A.85 0F 29 00 06          POKE   (00)

Tue 07/12/2011 10:57:25 AM : [iNST-SRX    ] 02 50 12.3A.85 13.24.AA 2B 29 00    POKE   (00)

Tue 07/12/2011 10:57:25 AM : [standard-Direct Ack][12.3A.85-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Tue 07/12/2011 10:57:25 AM : [iNST-ACK    ] 02 62 12.3A.85 0F 24 00 06                 (00)

Tue 07/12/2011 10:57:25 AM : [iNST-SRX    ] 02 50 12.3A.85 13.24.AA 2B 24 00           (00)

Tue 07/12/2011 10:57:26 AM : [standard-Direct Ack][12.3A.85-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Tue 07/12/2011 10:57:26 AM : [12 3A 85 1  ] Memory : EPROM Refreshed

Tue 07/12/2011 10:57:44 AM : [        Time] 10:57:44 1(0)

Tue 07/12/2011 10:57:44 AM : [All         ] Writing 2 bytes to devices

Tue 07/12/2011 10:57:44 AM : [12 3A 85 1  ] Memory : Write dbAddr=0x0264 [7F]

Tue 07/12/2011 10:57:44 AM : [12 3A 85 1  ] Using engine version i1 for 'Wake 3AM'

Tue 07/12/2011 10:57:44 AM : [iNST-ACK    ] 02 62 12.3A.85 0F 28 02 06          SET-MSB(02)

Tue 07/12/2011 10:57:53 AM : [iNST-ACK    ] 02 62 12.3A.85 0F 28 02 06          SET-MSB(02)

Tue 07/12/2011 10:58:02 AM : [iNST-ACK    ] 02 62 12.3A.85 0F 28 02 06          SET-MSB(02)

Tue 07/12/2011 10:58:06 AM : [12 3A 85 1  ] Memory : Write dbAddr=0x0264 [7F] - Failed

 

So it appears that sometimes this switch just refuses to respond. I cannot imagine a more definitive test result than this in a heavily isolated network...

 

Thoughts?

 

My only thought on the above is that "Isolated" is a relative term. If memory serves, you have a 6288 Filter. This has a much wider filtering range than the filterlinc (better low frequency) but it simply may not be enough. Low frequency noise will propagate much further through your electrical system (less attenuation) and the filters may be ineffective. If the low freuqency noise activates the PLM/KPL AGC, they will become less sensitive to incoming transmissions.

 

Can you move this setup to a different area (gain some distance from a possible noise source)?

 

As a side note, if you can save/send me on of your Event Viewer outputs from the KPL scan (TXT file), I can load it into the spreadsheet and show you the statistics.

[Illusion]

IM,

 

Wow! That was a lot of work. As far as isolation, I had my mini network behind a 6288 and a filterlinc in series.

 

You said you did not see a noticeable difference between the v2d KPLs and your others. You also said during your brick wall period sometimes the command timed out on three retires. Did you ever experience this with other KPLs as well? It seems to me 3 retries and failure is a pretty significant event.

 

I do not know what to say about the PLM ACK errors. Weird that you did not see any of them. I do not know what to make of this.

 

I will send you my files. I think that is cool. Questions for logs:

1. Am I doing this on my mini isolated network or in system? In system I can do 2 KPLs, mini network I can do 1.

2. Do I send you a seperate txt file for each read?

3. Method of delivery. Is private message with attached files okay?

[IndyMike]

Illusion,

 

I did not see a statistical difference between the V.2D units and my other KPL's. When my post lamp photo cell began producing noise, it affected everything in the Installation. I plan on yanking the photo cell and setting it up on the bench so I can monitor the noise with my oscilloscope.

 

Answers to your questions:

1) Your choice on the unit configuration - whichever you would like to see.

2) A separate .TXT file is easiest. I'll load it into a spreadsheet with whatever configuration notes you can provide. This way you can compare from device to device and across different system configurations.

3) A PM with the attached text file would be fine. It takes all of about 3 minutes to load the data to the spreadsheet and configure the device address.

 

Send me a couple of test runs. I send you the completed spreadsheet with instructions on how to load future runs.

[ELA]

I need some help. I am hoping someone out there has a (2486D) KeypadLinc Dimmer v.2D that they can test for me in their system.

If you have any (2486D) KeypadLinc Dimmer v.2Ds please do these couple of test, all with maximum event viewer resolution open:

 

1. Build a program to turn the load on and off every 2s with a 2s delay between on and off. Run that in a loop for a few minutes. Look for any errors like listed in this post.

 

Hi Illusion,

I held off running a test as my older keypadlinc is v.29 and I did not know if it would be of any help.

I have in the past had problems with this device responding to my ISY99. Then a few minutes later it would be fine.

Over time it has not caused any real headaches and I have improved my network communications so I ignored it. I might consider updating it some day though as I have never had a great deal of confidence in it.

 

I ran a test from my test PLM to the Keypadlinc with on/off cycles separated by 4 seconds for 100 cycles. I did this twice and got a 100% success rate allowing only 1 hop.

 

I also ran this test on another newer keypadlinc (v.36) with the same results.

 

What was interesting is that I tried the same test using extended messages and found that the older keypadlinc would not respond at all.

Apparently it is before the support of the extended messages was introduced. I could not find at exactly which version I2 support was introduced.

I wonder, is there an Insteon release history log that would show this?

[Brian H]

This is a list of devices as found by users and not an Official Smartlabs list.

http://www.madreporite.com/insteon/Inst ... e_list.htm

[ELA]

Thanks Brian,

I had seen that list and it lists the v.2D as a i1 device?

 

I was unsure if that was consistent with the tests run in this thread?

[Illusion]

Hello Illusion,

 

I should have guessed that you would have already ruled out the V.35 phenomena. I'd call shutting off the breaker rather definitive... another swing and a miss on my part.

IM

 

You know, IM, you have used that phrase several times when trying to help me with my weird comm issues. And yes, often it has been a swing and a miss. But maybe that is because you are always going for the home run. You do not bunt. Even when you miss wildly you give me ideas when I am stumped; however, you may have hit the home run on this topic...

 

Lets say the link table read anomalies are not directly related to the specific issue that interferes with my ability to adjust the back-lights of these two KPLs. (This is the only outstanding problem I have left).

 

I have built loop programs that I run frequently turning the back-lights bright and then dim for testing. Through literately thousands of cycles I have not found a consistent issue I could deal with. So after you gave me the results of the 18 link table reads I sent to you, I kinda gave up. I did read them with great interest, but again I could not link what I was seeing to any specific issue with any kind of certainty.

 

I just let the program try to adjust the back-lights of these switches as it is supposed to at night and again in the morning. After repeated failures I got frustrated. I ran another couple of hundred loops to these two switches and got 100% success on back-light changing. Damn. Back to leaving it alone.

 

So frustrating because I have another KPL and two Swithlincs on the same circuit as one of the problem KPL that never exhibit the problem. They are less than 6 feet from the problem KPL physically and probably not much more than that in wire distance.

 

So I added two new KPLs to my Smarthome wish list along with replacements for my 4 v.35 devices.

 

Then something hit me. You talked about issues with your photocell on your lamppost. How you found out that was a problem is beyond me. I ran lots of test trying to cause a consistent failure by varying the amount of light hitting the one photocell I have in my system. Seems like a good candidate for a problem if you have an issue with yours. In my case especially since it is on the same phase as one of the problem KPLs and on the same phase and circuit for the other.

 

No good. No conclusive test. No visible noise on my trusty ELK meter. No consistent failure of back-light adjustment.

 

But I could not let it go. So I killed power to the photocell and its load for a week. Not a single failure of the back-lights to adjust since then. Not conclusive yet, but looking good.

 

It kinda makes sense. If some certain intensity of light that I did not create in my testing causes some kind of issue with this device it would explain why I cannot get a failure when testing all this time. As it is on the same circuit as one of the test devices it would not get cut out on the extensive breaker shutdown testing done. Further, if it is full bright out, or maybe full dark, there is no issue but right around the time the ISY is trying to make the back-lights dim is exactly the time when this could be an issue.

 

Maybe the other KPL and Switchlincs near it are just more sensitive as they are several versions newer; otherwise, I do not have an explanation for why they never experience the comms problem.

 

I intend to re-institute the photo cell and its load for a week tabulating results. Like testing-but in slow motion.

 

Results to follow. Thanks for the suggestions all.