"Err 1" During KPL Restore

[TJF1960]

I am attempting to restore a number of kpl's (v.36). I have been watching the event viewer (level 3) and all hops left = 2 out of 3. So it would seem comm. is fine. Problem is I have had 4 or so that ended the restore process with Err 1 and the unable to communicate window pops up. Looking thru the logs all hops left = 2. After querying I can restart the process and sometimes it will end in error again, sometimes it finishes fine the second time, occasionally it takes 3 times to finish successfully.

 

I have disabled all programs and have been very careful not to create any insteon traffic during the restore process. The plm is 2413S v.99 with 994ir pro.

 

Is this more than likely maybe accidental insteon traffic (from another device being activated) causing the error or an intermittent comm issue or other?

 

Thanks,

Tim

[LeeG]

Need to see an event trace at level 3 to evaluate what err is occurring.

 

Other Insteon traffic would not normally create an issue unless the powerline was flooded.

[TJF1960]

Sorry Lee, I was in a hurry and forgot....

 

Tue 12/11/2012 09:56:47 AM : [std-Direct Ack] 16.71.CD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 12/11/2012 09:56:47 AM : [iNST-TX-I1  ] 02 62 16 71 CD 0F 2B 3B

Tue 12/11/2012 09:56:47 AM : [iNST-ACK    ] 02 62 16.71.CD 0F 2B 3B 06          PEEK   (3B)

Tue 12/11/2012 09:56:47 AM : [iNST-SRX    ] 02 50 16.71.CD 19.84.0E 2B 2B 00    PEEK   (00)

Tue 12/11/2012 09:56:47 AM : [std-Direct Ack] 16.71.CD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 12/11/2012 09:56:47 AM : [iNST-TX-I1  ] 02 62 16 71 CD 0F 29 84

Tue 12/11/2012 09:56:48 AM : [iNST-ACK    ] 02 62 16.71.CD 0F 29 84 06          POKE   (84)

Tue 12/11/2012 09:56:48 AM : [iNST-SRX    ] 02 50 16.71.CD 19.84.0E 2B 29 84    POKE   (84)

Tue 12/11/2012 09:56:48 AM : [std-Direct Ack] 16.71.CD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 12/11/2012 09:56:48 AM : [iNST-TX-I1  ] 02 62 16 71 CD 0F 2B 3C

Tue 12/11/2012 09:56:57 AM : [iNST-TX-I1  ] 02 62 16 71 CD 0F 28 0F

Tue 12/11/2012 09:57:06 AM : [iNST-TX-I1  ] 02 62 16 71 CD 0F 28 0F

Tue 12/11/2012 09:57:06 AM : [iNST-ACK    ] 02 62 16.71.0F 3C 29 84 15 02 62 16 71 CD 0F 28 0F 06 02 62 16 71 CD POKE   (84)

Tue 12/11/2012 09:57:07 AM : [iNST-SRX    ] 02 50 16.71.CD 19.84.0E 2B 28 0F    SET-MSB(0F)

Tue 12/11/2012 09:57:07 AM : [std-Direct Ack] 16.71.CD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Tue 12/11/2012 09:57:11 AM : [  16 71 CD 1]      ERR   1

[LeeG]

The message flow is fine to start with

 

Tue 12/11/2012 09:56:47 AM : [iNST-TX-I1 ] 02 62 16 71 CD 0F 29 84

 

Tue 12/11/2012 09:56:48 AM : [iNST-ACK ] 02 62 16.71.CD 0F 29 84 06 POKE (84)

 

Tue 12/11/2012 09:56:48 AM : [iNST-SRX ] 02 50 16.71.CD 19.84.0E 2B 29 84 POKE (84)

 

Tue 12/11/2012 09:56:48 AM : [std-Direct Ack] 16.71.CD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

 

At this point the PLM stopped responding. Serial commands are sent to the PLM but nothing comes back, not even the Echo of the issued Serial command which should always happen

 

Tue 12/11/2012 09:56:48 AM : [iNST-TX-I1 ] 02 62 16 71 CD 0F 2B 3C

 

Tue 12/11/2012 09:56:57 AM : [iNST-TX-I1 ] 02 62 16 71 CD 0F 28 0F

 

Tue 12/11/2012 09:57:06 AM : [iNST-TX-I1 ] 02 62 16 71 CD 0F 28 0F

 

At this point the PLM returns a string of data that looks like multiple responses all strung together. A serial command Echo shows command rejected (NAKed) , the next is an Echo of an accepted serial command, followed by a device response.

 

Tue 12/11/2012 09:57:06 AM : [iNST-ACK ] 02 62 16.71.0F 3C 29 84 15 02 62 16 71 CD 0F 28 0F 06 02 62 16 71 CD POKE (84)

 

Tue 12/11/2012 09:57:07 AM : [iNST-SRX ] 02 50 16.71.CD 19.84.0E 2B 28 0F SET-MSB(0F)

 

Tue 12/11/2012 09:57:07 AM : [std-Direct Ack] 16.71.CD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

 

Tue 12/11/2012 09:57:11 AM : [ 16 71 CD 1] ERR 1

 

I would take this as a PLM issue for now. What does PLM Info/Status show for the PLM firmware level?

[TJF1960]

PLM is 2413S v.99

 

Out of 9 kpl's restored this morning 5 failed the first time, 3 failed the 2nd time and succeeded the 3rd time. No problems restoring Switchlincs, just the kpl's.

 

Thanks Lee,

Tim

[LeeG]

Have to look at the commands issued for a SwitchLinc Restore Device. The v.36 KeypadLincs are using the old Peek/Poke method for writing link records. SwitchLincs might be I2CS which would use extended commands for writing link records. Trace a SwitchLinc Restore Device or trace a Query Insteon Engine to see if they are I2CS. There is something besides general device type difference that is affecting PLM operation.

 

EDIT: there are also inherently more link records in a KeypadLinc to cover all the buttons than would be expected in a SwitchLinc.

[ELA]

I had looked at this earlier this afternoon but did not want to respond before LeeG, just to confirm If I was on the correct track

 

I came to the same conclusions. The PLM seems to have went away for a while. Is it failing, was it busy due to unreported traffic?

Are there some fine points to peek/poke command timing or protocol not being met? May seem trivial but is the connection from ISY to PLM confirmed secure?

 

Two things stood out to me at the point that things went haywire:

1) Why did the ISY go ahead and send the "28 0F' set MSB command when it has not gotten a response to the previous "2B 3C" peek?

 

2) Did you notice that when the PLM did once again wake up ( recover from confused state?) that the first response contained an incorrect address "16.71.0F " and other bytes seeming to be out of sync?

[TJF1960]

Thanks for your response ELA. Good catch on the incorrect address, I can confirm that I do not have a device with that address.

As far as the connection between the ISY and PLM...its the new cable which came with the ISY from earlier this year. Say the word and I can change it out with another and restore a couple of kpl's in the morning.

 

One thing I should mention. A couple of days ago I tried restoring a 4 of the kpl's and it was taking FOR EVER and I was in a hurry. So I switched to Device Reported and ran a restore on the kpl's (I know I shouldn't have, but I was in a hurry). Man... Lightning fast and they were done and seemed to work fine (also no errors). But decided since I had a bit more time today and had to restore a few more that I would do it the right way and restore them with Automatic selected.

 

LeeG, I will run a restore of a switchlinc and post the log in the A.M., how much of the log do you want to see? Just the tail end snippit like the one above or the whole thing?

 

Thanks guys,

Tim

[LeeG]

Assuming no errors only enough to see if the SwitchLinc is using extended commands or Peek/Poke. Even if the SwitchLinc is using Peek/Poke the smaller number of commands to restore the SwitchLinc could be the differentiation. Nothing but guess work at this point. More failure traces may lead to different conclusions.

 

This combined response from the PLM after not responding to some serial commands is interesting. The first of three messages in the string has much of the last successful command Echo which is a Poke

 

Tue 12/11/2012 09:56:48 AM : [iNST-ACK ] 02 62 16.71.CD 0F 29 84 06 POKE (84)

Tue 12/11/2012 09:57:06 AM : [iNST-ACK ] 02 62 16.71.0F 3C 29 84 15 02 62 16 71 CD 0F 28 0F 06 02 62 16 71 CD POKE (84)

 

I've highlighted the differences in Red. The 06 in the good echo is an ACK, the 15 in the combined string is a NAK. I first considered the ISY might have gotten into a loop and just not read the PLM response string but that would not have scrambled the string nor resulted in a NAK. I do not rule out some issue with interference (RF or powerline) that caused the PLM to stop processing serial commands for a few seconds or the PLM just got hung up for some reason within itself.

 

ELA

 

The ISY did its normal recovery when the Peek command failed to get a response. The ISY recovery is to start over with a Set MSB to reestablish the high order memory address for a retry of the Peek sequence.

[ELA]

Thanks for your clarification of the recovery sequence for me LeeG.

This is a very interesting issue.

 

I had seen a fair amount of corrupted messages when developing my tester firmware.

At one point I included a "corrupted message" counter to report them.

 

I also saw a few instances where a device (PLM) responded with multiple messages quicker than what my firmware was set up to respond to, which resulted in a larger than expected message ( multiple responses together). As I am sure you know messages direct from the PLM can be returned much faster than those from a remote device that involves PL comms.

 

Looking forward to learning from the resolution to this.

[LeeG]

ELA

 

It is not uncommon for multiple messages or even partial messages to be returned on any given serial read. It can be a challenge insuring a complete message is received particularly for the 02 62 because the length is not known until the flag byte is checked for Standard versus Extended message.

 

In this case there are several seconds where nothing was received and nothing for more than one issued serial command. Really interesting symptom.

[TJF1960]

I started out this morning attempting to restore one of the devices which ended in an err1 yesterday in order to make sure I could duplicate the problem before moving forward. Well, it looks like the gremlin has left the building. I ended up restoring 5 kpl’s this morning and all five restored perfectly. Not one error.

 

Yesterday, for other reasons, I power cycled both the ISY and PLM after working on the system. At this point it looks like whatever was causing the problem was cleared up during power cycling.

 

I apologize to both of you, I have been around long enough to know I should have tried power cycling after the first couple of errors showed up just to rule it out. I still would like to know why this occurred and will keep an eye out for similar occurrences.

 

Thank you both,

Tim

[LeeG]

Thanks for the update Tim. Likely the PLM power cycle but one never knows for sure. Do post back any additional errors. Don't remember seeing that particular sequence before in any ISY trace. I think there is a later PLM firmware release but v.99 has been stable.

[Xathros]

LeeG, ELA-

 

For what it's worth, I had a PLM lockup bad yesterday for the first time ever. I did the 3.3.5 upgrade on Monday afternoon. Everything seemed to be OK after the upgrade. Tuesday morning I noticed some backlight adjustments didn't happen as scheduled and by lunchtime, nothing that required the ISY was working. I could not even log into the admin console. I rebooted the ISY via telnet (Remotely) and lost all access at that point. When I got home from work I found the 994 with Pwr, TX,RX all lit solid. Powered down/Up the 994 which resulted in Pwr,TX,RX solid and Blinking ERR. Powered down/up the PLM several times with no improvement. Had to factory reset the PLM to get back online then did a restore modem. System has been stable since but I'm keeping a close eye on it.

 

I can't say if this had anything to do with 3.3.5 or not. Other than this incident, all seems fine.

 

-Xathros

 

EDIT: PLM is an older 2412S v.85

[TJF1960]

Lee, ELA,

 

I just have had 4 errors in restoring 4 different devices. All occured at least 75% into restoring. Looking over the log I see just a couple hops left=1 and 1 or 2 hops left=0 in the tracesbut all the rest are hops left=2. But they (hops left=0 or 1) are well before the error. It seem the longer time I spend restoring devices the faster the errors are occuring.

Here are the trail end of the 4.

 

Wed 12/12/2012 10:12:43 AM : [std-Direct Ack] 15.64.C6-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 10:12:43 AM : [iNST-TX-I1  ] 02 62 15 64 C6 0F 2B 90

Wed 12/12/2012 10:12:43 AM : [iNST-ACK    ] 02 62 15.64.C6 0F 2B 90 06          PEEK   (90)

Wed 12/12/2012 10:12:44 AM : [iNST-SRX    ] 02 50 15.64.C6 19.84.0E 2B 2B E2    PEEK   (E2)

Wed 12/12/2012 10:12:44 AM : [std-Direct Ack] 15.64.C6-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 10:12:44 AM : [iNST-TX-I1  ] 02 62 15 64 C6 0F 28 0E

Wed 12/12/2012 10:12:44 AM : [iNST-ACK    ] 02 62 15.64.C6 0F 28 0E 06          SET-MSB(0E)

Wed 12/12/2012 10:12:44 AM : [iNST-SRX    ] 02 50 15.64.C6 19.84.0E 2B 28 0E    SET-MSB(0E)

Wed 12/12/2012 10:12:44 AM : [std-Direct Ack] 15.64.C6-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 10:12:44 AM : [iNST-TX-I1  ] 02 62 15 64 C6 0F 2B 91

Wed 12/12/2012 10:12:53 AM : [iNST-TX-I1  ] 02 62 15 64 C6 0F 28 0E

Wed 12/12/2012 10:13:02 AM : [iNST-TX-I1  ] 02 62 15 64 C6 0F 28 0E

Wed 12/12/2012 10:13:02 AM : [iNST-ACK    ] 02 62 15.64.C6 91 2B 0E 02 62 15 64 C6 0F 28 0E 06 02 62 15 64 C6 0F PEEK   (0E)

Wed 12/12/2012 10:13:03 AM : [iNST-SRX    ] 02 50 15.64.C6 19.84.0E 27 28 0E    SET-MSB(0E)

Wed 12/12/2012 10:13:03 AM : [std-Direct Ack] 15.64.C6-->ISY/PLM Group=0, Max Hops=3, Hops Left=1

Wed 12/12/2012 10:13:07 AM : [  15 64 C6 1]      ERR   1

Wed 12/12/2012 10:27:03 AM : [std-Direct Ack] 16.78.87-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 10:27:03 AM : [iNST-TX-I1  ] 02 62 16 78 87 0F 2B B1

Wed 12/12/2012 10:27:03 AM : [iNST-ACK    ] 02 62 16.78.87 0F 2B B1 06          PEEK   (B1)

Wed 12/12/2012 10:27:03 AM : [iNST-SRX    ] 02 50 16.78.87 19.84.0E 2B 2B 01    PEEK   (01)

Wed 12/12/2012 10:27:03 AM : [std-Direct Ack] 16.78.87-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 10:27:03 AM : [iNST-TX-I1  ] 02 62 16 78 87 0F 28 0F

Wed 12/12/2012 10:27:03 AM : [iNST-ACK    ] 02 62 16.78.87 0F 28 0F 06          SET-MSB(0F)

Wed 12/12/2012 10:27:04 AM : [iNST-SRX    ] 02 50 16.78.87 19.84.0E 2B 28 0F    SET-MSB(0F)

Wed 12/12/2012 10:27:04 AM : [std-Direct Ack] 16.78.87-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 10:27:04 AM : [iNST-TX-I1  ] 02 62 16 78 87 0F 2B B2

Wed 12/12/2012 10:27:13 AM : [iNST-TX-I1  ] 02 62 16 78 87 0F 28 0F

Wed 12/12/2012 10:27:22 AM : [iNST-TX-I1  ] 02 62 16 78 87 0F 28 0F

Wed 12/12/2012 10:27:22 AM : [iNST-ACK    ] 02 62 87.0F.2B B2 28 0F 02 62 16 78 87 0F 28 0F 06 02 62 16 78 87 0F SET-MSB(0F)

Wed 12/12/2012 10:27:22 AM : [iNST-SRX    ] 02 50 16.78.87 19.84.0E 2B 28 0F    SET-MSB(0F)

Wed 12/12/2012 10:27:22 AM : [std-Direct Ack] 16.78.87-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 10:27:26 AM : [  16 78 87 1]      ERR   1

Wed 12/12/2012 12:08:37 PM : [std-Direct Ack] 12.C4.D6-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 12:08:37 PM : [iNST-TX-I1  ] 02 62 12 C4 D6 0F 2B 93

Wed 12/12/2012 12:08:37 PM : [iNST-ACK    ] 02 62 12.C4.D6 0F 2B 93 06          PEEK   (93)

Wed 12/12/2012 12:08:37 PM : [iNST-SRX    ] 02 50 12.C4.D6 19.84.0E 2B 2B 71    PEEK   (71)

Wed 12/12/2012 12:08:37 PM : [std-Direct Ack] 12.C4.D6-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 12:08:37 PM : [iNST-TX-I1  ] 02 62 12 C4 D6 0F 28 0F

Wed 12/12/2012 12:08:37 PM : [iNST-ACK    ] 02 62 12.C4.D6 0F 28 0F 06          SET-MSB(0F)

Wed 12/12/2012 12:08:38 PM : [iNST-SRX    ] 02 50 12.C4.D6 19.84.0E 2B 28 0F    SET-MSB(0F)

Wed 12/12/2012 12:08:38 PM : [std-Direct Ack] 12.C4.D6-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 12:08:38 PM : [iNST-TX-I1  ] 02 62 12 C4 D6 0F 2B 94

Wed 12/12/2012 12:08:47 PM : [iNST-TX-I1  ] 02 62 12 C4 D6 0F 28 0F

Wed 12/12/2012 12:08:56 PM : [iNST-TX-I1  ] 02 62 12 C4 D6 0F 28 0F

Wed 12/12/2012 12:08:56 PM : [iNST-ACK    ] 02 62 12.C4.D6 94 28 0F 02 62 12 C4 D6 0F 28 0F 06 02 62 12 C4 D6 0F SET-MSB(0F)

Wed 12/12/2012 12:08:56 PM : [iNST-ACK    ] 02 62 12.C4.D6 94 28 0F 02 62 12 C4 D6 0F 28 0F 06 02 62 12 C4 D6 0F SET-MSB(0F):  Duplicate or ACK for a different device 

Wed 12/12/2012 12:08:56 PM : [iNST-SRX    ] 02 50 12.C4.D6 19.84.0E 2B 28 0F    SET-MSB(0F)

Wed 12/12/2012 12:08:56 PM : [std-Direct Ack] 12.C4.D6-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 12:09:00 PM : [  12 C4 D6 1]      ERR   1

Wed 12/12/2012 12:25:47 PM : [std-Direct Ack] 16.71.CD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 12:25:47 PM : [iNST-TX-I1  ] 02 62 16 71 CD 0F 2B FD

Wed 12/12/2012 12:25:48 PM : [iNST-ACK    ] 02 62 16.71.CD 0F 2B FD 06          PEEK   (FD)

Wed 12/12/2012 12:25:48 PM : [iNST-SRX    ] 02 50 16.71.CD 19.84.0E 2B 2B FF    PEEK   (FF)

Wed 12/12/2012 12:25:48 PM : [std-Direct Ack] 16.71.CD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 12:25:48 PM : [iNST-TX-I1  ] 02 62 16 71 CD 0F 28 0E

Wed 12/12/2012 12:25:48 PM : [iNST-ACK    ] 02 62 16.71.CD 0F 28 0E 06          SET-MSB(0E)

Wed 12/12/2012 12:25:48 PM : [iNST-SRX    ] 02 50 16.71.CD 19.84.0E 2B 28 0E    SET-MSB(0E)

Wed 12/12/2012 12:25:48 PM : [std-Direct Ack] 16.71.CD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 12:25:48 PM : [iNST-TX-I1  ] 02 62 16 71 CD 0F 2B FE

Wed 12/12/2012 12:25:58 PM : [iNST-TX-I1  ] 02 62 16 71 CD 0F 28 0E

Wed 12/12/2012 12:26:07 PM : [iNST-TX-I1  ] 02 62 16 71 CD 0F 28 0E

Wed 12/12/2012 12:26:07 PM : [iNST-ACK    ] 02 62 16.71.CD FE 2B 0E 02 62 16 71 CD 0F 28 0E 06 02 62 16 71 CD 0F PEEK   (0E)

Wed 12/12/2012 12:26:07 PM : [iNST-ACK    ] 02 62 16.71.CD FE 2B 0E 02 62 16 71 CD 0F 28 0E 06 02 62 16 71 CD 0F PEEK   (0E):  Duplicate or ACK for a different device 

Wed 12/12/2012 12:26:07 PM : [iNST-SRX    ] 02 50 16.71.CD 19.84.0E 2B 28 0E    SET-MSB(0E)

Wed 12/12/2012 12:26:07 PM : [std-Direct Ack] 16.71.CD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Wed 12/12/2012 12:26:11 PM : [  16 71 CD 1]      ERR   1

Note this last error occured 3 times in a row and it looked to be in about the same spot. I factory reset the kpl and tried restore again, this time succeeding.

 

Thanks,

Tim

[LeeG]

The string coming back from the PLM is not the same in each case but the sequence that starts it is. A command to read a byte of data (address is different in each case) fails to get any PLM response. The first response should be a simple echo back from the PLM with the issued serial command which has not even been sent to the device at that point. The first command in the recovery process is issued 9 seconds later (normal time ISY waits for response before giving up) which also fails to get any response, followed by another command 9 seconds later which gets a garbage response.

 

With these occurring on multiple devices I rule out any specific KPL. I suspect the SwitchLincs do not show this either because extended commands are used or the SwitchLinc has far fewer links thus far fewer standard commands.

 

Insteon is generally a matter of trial and error in trouble shooting so there are no guarantees but it looks to me like I PLM failure.

 

I will do a series of KPL Restore Devices here to see if there is any chance this is ISY related but I really don't think so. Cannot see how the ISY could cause this result. However, that is why we test looking for the impossible.

[LeeG]

I've done 12 consecutive Restore Device operations to a v.36 KPL. No err conditions occurred or logged. Of course this testing is trying to verify a negative so how many passes does it take to verify a negative. I'll continue run more restores to the various KPLs I have but I'm still of the belief this is a PLM issue.

[TJF1960]

Thanks Lee. Looking back at today’s experience I am leaning towards the plm as well. I didn’t start getting errors today until I restored probably about 5 or 6 kpl’s and the errors do seem to occur at least 75% into the restore. It doesn’t have any trouble restoring switchlincs all of which are using peek/poke. It does seem to be caused by the length of time it takes to do the restore. Most of my kpl’s have a boat load of links. None of the kpl’s which have just a few links failed, it was all the heavy linked kpl’s.

[ELA]

Tjf1960,

 

It is never a bad thing to have a spare PLM if you should elect to order to new one.

 

On the theory that the PLM is failing after running long peek/poke sessions.

A PLM does heat up internally more when doing a lot of communications as it must drive the power line with a pretty good amount of current ( depending upon where it is installed).

Externally applied heat can also aggravate an intermittent failure condition.

 

Is your PLM located in an area that might experience some temperature variation? Cooler in the morning by any chance?

 

Some things you could try if you wanted to:

1) Run repeated restores to the switchlincs that have up until now worked fine. Do a lot of them one right after the other without pausing very long between in an attempt to duplicate the approximate amount of time it took the KPLs to fail.

 

2) You could also apply a small amount of external heat to the PLM using a heat gun / hair dryer. This is something I do regularly in my work but you do have to be very careful not to apply too much heat. Just enough to raise the temperature around the PLM a few degrees.

Again I was hesitant to mention this so please do be careful if you try it. Using a temperature gauge located on the device you are heating is best but I have used my hand as a gauge as to how far away to hold the gun in the past as well.

 

Very curious issue and I will be interested to hear of your resolution. Best of luck

[TJF1960]

Thanks for the suggestions ELA.

 

I will select 5 to 10 switchlinc devices to restore at one time (I have the pro) and look for errors.

 

The PLM and ISY are in the garage right next to the AC Mains panel...temp is mid 50F in the morning, maybe low 60F in the afternoon. I too use a heat gun for my work and will give that a shot.

 

I will also try swapping the data cable between plm and ISY.

 

Lastly I will swap the plm for a new spare I have (ordered 1 earlier this year just in case).

 

Thanks again,

Tim

[LeeG]

I've run another dozen or so Restore Device functions, this time using KPLs with more link records than the v.36. No error messages and a scan of the saved event logs show no err.

[TJF1960]

LeeG, thanks so much for all of the time you have spent in testing and confirming!

 

Tim

[TJF1960]

I selected 10 Switchlinc's to restore. All 10 restored without errors.

 

I selected 4 kpl's to restore (restored 1 at a time) 2 failed with err.

 

Heating the plm up didn't seem to affect the comm. data, in other words it didn't seem to make it any worse.

 

Replaced plm cable. Restoredx 4 kpl's 1 ended with err this time.

 

Replaced and restored plm. Restored 6 kpl's all finished with no err.

 

So it looks like the plm is defective.

 

Thanks LeeG and ELA,

Tim

[Michel Kohanim]

Hi Tim,

 

May I ask what's your PLM firmware version?

 

With kind regards,

Michel

[TJF1960]

Hi Michel, old and new are both v.99 (rev 1.6 printed on plm).