Illusion Posted June 26, 2011 Posted June 26, 2011 A couple of weeks ago I added an IR TX, 4 Syncrolincs, and 1 IOLinc to an essentially 100% reliable system. The system had been at this very high reliability for many many months. The changed did so much damage to the reliability of my system I do not have time to enumerate it all here, but after thousands of test commands I may have found one big culprit and I wanted to post it here because the only reliable repeatable symptom is so odd. Background: Dual band PLM 550 links used 2 Access points 3 T-stat adapters 1 Hardwired phase coupler 1 240v Dual band phase coupler/repeater devices (water heater) About 40 Insteon Devices. 4 of which are v.35 icon relay modules which do not appear to have the dreaded v.35 issues. (At least currently. Many thousands of test on this issue alone. See: viewtopic.php?p=22570#p22570) Neighbor's house on same transformer controlled by my ISY: 2 Access points 1 X-10 Dryer adapter hardwired phase coupler 2 Dual band lamplincs About 10 Insteon devices. So I have this IRLinc RX 2411. It works great. Has for like a year. I add the new devices and this IRLinc RX starts sending out multiple copies of received commands. Like if I hit the A on button on the credit card remote it may send one on command, or it may send as many as 5. It is pretty random, but repeatable. Here is a level 3 event viewer of it sending 5 commands in response to a single button press on the remote: Sun 06/26/2011 03:14:56 PM : [iNST-SRX ] 02 50 12.F5.69 00.00.01 CB 11 00 LTONRR (00) Sun 06/26/2011 03:14:56 PM : [standard-Group][12.F5.69-->Group=1] Max Hops=3, Hops Left=2 Sun 06/26/2011 03:14:56 PM : [ 12 F5 69 1] DON 0 Sun 06/26/2011 03:14:56 PM : [iNST-SRX ] 02 50 12.F5.69 00.00.01 CB 11 00 LTONRR (00) Sun 06/26/2011 03:14:56 PM : [standard-Group][12.F5.69-->Group=1] Max Hops=3, Hops Left=2 Sun 06/26/2011 03:14:56 PM : [ 12 F5 69 1] DON 0 Sun 06/26/2011 03:14:56 PM : [iNST-SRX ] 02 50 12.F5.69 00.00.01 CB 11 00 LTONRR (00) Sun 06/26/2011 03:14:56 PM : [standard-Group][12.F5.69-->Group=1] Max Hops=3, Hops Left=2 Sun 06/26/2011 03:14:56 PM : [ 12 F5 69 1] DON 0 Sun 06/26/2011 03:14:57 PM : [iNST-SRX ] 02 50 12.F5.69 00.00.01 CB 11 00 LTONRR (00) Sun 06/26/2011 03:14:57 PM : [standard-Group][12.F5.69-->Group=1] Max Hops=3, Hops Left=2 Sun 06/26/2011 03:14:57 PM : [ 12 F5 69 1] DON 0 Sun 06/26/2011 03:14:57 PM : [iNST-SRX ] 02 50 12.F5.69 00.00.01 CB 11 00 LTONRR (00) Sun 06/26/2011 03:14:57 PM : [standard-Group][12.F5.69-->Group=1] Max Hops=3, Hops Left=2 Sun 06/26/2011 03:14:57 PM : [ 12 F5 69 1] DON 0 Sun 06/26/2011 03:14:57 PM : [iNST-SRX ] 02 50 12.F5.69 13.24.AA 41 11 01 LTONRR (01) Sun 06/26/2011 03:14:57 PM : [standard-Cleanup][12.F5.69-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 This kinda creates havoc on the associated ISY program that now starts running 5 times. It took me forever to figure out the IRLinc was the core culprit. I spent hours trying to figure out what was wrong with my programs. I temporarily fixed it by isolating the IRLinc behind a filter and putting an access point with it to make it a RF devices in effect. It still sent multiple copies of the command, but the ISY would say Duplicate ignored I guess because it was now an RF command coming from the access point. Today I spent another few hours working on this and it currently appears to be the television. The TV as well as the entire entertainment system used to be behind filters, but I had to take them out because the Syncrolincs are all used on the system to allow ISY logic based control. I plugged a filter into the output of the Syncrolinc and the TV into that and currently it appears to have fixed this issue. I was not aware that an electronic devices could cause 5 copies of a command from an Insteon device to be created. Thought the community would like to know about this one. I have an ELK X-10 signal meter that I use to look for noise, and the TV shows none. I have had a myriad of other issues since this addition to my system, but none of those issues has been repeatable enough for me to develop a troubleshooting procedure to move forward on. Maybe the TV was the cause of all my problems. I will continue to try to come up with a next step. If I cannot I will be posting back here... Edited to change topic title as that did not fix all my issues.
Illusion Posted July 1, 2011 Author Posted July 1, 2011 The filter does appear to have fixed my issue with the IRLinc RX, but has not resolved all my other issues that were created by this addition to my system. I am a little stumped as to how to troubleshoot the problem and would like some suggestions for what to try next. In addition to the IRLinc issue, I have introduced some intermittent comm issues to other devices. The most consistent of which is that 2 of my KPLs do not adjust their LED back-lights at night and in the morning. (on different circuits, same phase as the PLM) This also worked flawlessly (100% for many many months) till I added all the new stuff. Now it fails every couple of days. I am having trouble coming up with a method to find the problem. I have put the two KPLs in a test scene with another Insteon device that is on the same circuit as problem KPL #1 so I could use scene test, but that does not seem to be any help as all devices always pass the scene test. I tried to just repeatably query the devices, but they stop responding to repeated quick queries and Michel told me that he has seen that before and is not an indication of a comm issue (if I am remembering correctly) I created a couple of mini back-light adjusting programs that just change the backlights in these two problem KPLs as opposed to the real ones that adjusts all the capable switches each night. Running these bright/dim mini test programs in succession does not seem to be much help either. It works most of the time with 2 hops remaining, but with no changes to the system it will just stop from one try to the next. Changing nothing in the system, just to get a baseline, I will make the back-lights bright and then dim repeatably trying to see how often they fail. It will work many times perfectly with 2 hops remaining, and then bam, one of the switches will fail to respond. Completely. Even with the ISY doing 3 retries. No comm to one of the problem switches. I will try to run the program again, or the other one, and the ISY will not even try to adjust that switch. The device tree shows pending updates for the devices and no further program runs will attempt to communicate with the device that failed. This condition will continue until I query the KPL which responds instantly usually. I have tried opening the event viewer and pressing buttons locally on the problem KPLs but nothing ever is missed. All the key presses are logged with 2 hops remaining. I do not know how to move forward as I do not seem to be able to design a testing protocol that tells me anything. Thoughts? Suggestions?
Illusion Posted July 1, 2011 Author Posted July 1, 2011 Here is an interesting data point: I played around with my mini test programs some more. Here is the level 3 event viewer with an anomaly. The recorded event starts with me running the mini test program to make the back-lights dim, but they are already dim, which I guess the ISY knows so it does not actually try to write to the devices. Then I run the test program to make the back-lights in these two problem switches bright and about halfway down you can see "RINPUT (08): Process Message: failed" from a device with the device ID of 12.3A.87. I have no such device. 1. What is RINPUT? 2. I thought the PLM would not respond to a device not in its link table. 3. I thought if the PLM link table does not contain a device, you cannot see it in the event viewer. Fri 07/01/2011 02:48:31 PM : [ Time] 14:48:33 10(0) Fri 07/01/2011 02:48:32 PM : [All ] Writing 1 bytes to devices Fri 07/01/2011 02:48:32 PM : [iNST-ACK ] 02 62 12.3A.85 0F 24 00 06 (00) Fri 07/01/2011 02:48:32 PM : [iNST-SRX ] 02 50 12.3A.85 13.24.AA 2B 24 00 (00) Fri 07/01/2011 02:48:32 PM : [standard-Direct Ack][12.3A.85-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 07/01/2011 02:48:32 PM : [12 3A 85 1 ] Memory : EPROM Refreshed Fri 07/01/2011 02:48:33 PM : [All ] Writing 1 bytes to devices Fri 07/01/2011 02:48:33 PM : [iNST-ACK ] 02 62 0F.C1.DE 0F 24 00 06 (00) Fri 07/01/2011 02:48:33 PM : [iNST-SRX ] 02 50 0F.C1.DE 13.24.AA 27 24 00 (00) Fri 07/01/2011 02:48:33 PM : [standard-Direct Ack][0F.C1.DE-->ISY/PLM Group=0] Max Hops=3, Hops Left=1 Fri 07/01/2011 02:48:33 PM : [F C1 DE 1 ] Memory : EPROM Refreshed Fri 07/01/2011 02:48:50 PM : [ Time] 14:48:52 10(0) Fri 07/01/2011 02:48:51 PM : [All ] Writing 2 bytes to devices Fri 07/01/2011 02:48:51 PM : [12 3A 85 1 ] Memory : Write dbAddr=0x0264 [7F] Fri 07/01/2011 02:48:51 PM : [12 3A 85 1 ] Using engine version i1 for 'Wake 3AM' Fri 07/01/2011 02:48:51 PM : [iNST-ACK ] 02 62 12.3A.85 0F 28 02 06 SET-MSB(02) Fri 07/01/2011 02:48:51 PM : [iNST-SRX ] 02 50 12.3A.85 13.24.AA 2B 28 02 SET-MSB(02) Fri 07/01/2011 02:48:51 PM : [standard-Direct Ack][12.3A.85-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 07/01/2011 02:48:51 PM : [iNST-ACK ] 02 62 12.3A.85 0F 2B 64 06 PEEK (64) Fri 07/01/2011 02:48:51 PM : [iNST-SRX ] 02 50 12.3A.85 13.24.AA 2B 2B 00 PEEK (00) Fri 07/01/2011 02:48:51 PM : [standard-Direct Ack][12.3A.85-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 07/01/2011 02:48:52 PM : [iNST-ACK ] 02 62 12.3A.85 0F 29 7F 06 POKE (7F) Fri 07/01/2011 02:48:52 PM : [iNST-SRX ] 02 50 12.3A.85 13.24.AA 2B 29 7F POKE (7F) Fri 07/01/2011 02:48:52 PM : [standard-Direct Ack][12.3A.85-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 07/01/2011 02:48:52 PM : [iNST-ACK ] 02 62 12.3A.85 0F 24 00 06 (00) Fri 07/01/2011 02:48:52 PM : [iNST-SRX ] 02 50 12.3A.85 13.24.AA 2B 24 00 (00) Fri 07/01/2011 02:48:53 PM : [standard-Direct Ack][12.3A.85-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 07/01/2011 02:48:53 PM : [12 3A 85 1 ] Memory : EPROM Refreshed Fri 07/01/2011 02:48:53 PM : [iNST-SRX ] 02 50 12.3A.87 13.24.AA 22 49 08 RINPUT (08) Fri 07/01/2011 02:48:53 PM : [standard-Direct Ack][12.3A.87-->ISY/PLM Group=0] Max Hops=2, Hops Left=0 Fri 07/01/2011 02:48:53 PM : [iNST-SRX ] 02 50 12.3A.87 13.24.AA 22 49 08 RINPUT (08): Process Message: failed Fri 07/01/2011 02:48:53 PM : [standard-Direct Ack][12.3A.87-->ISY/PLM Group=0] Max Hops=2, Hops Left=0 Fri 07/01/2011 02:48:53 PM : [All ] Writing 2 bytes to devices Fri 07/01/2011 02:48:53 PM : [F C1 DE 1 ] Memory : Write dbAddr=0x0264 [7F] Fri 07/01/2011 02:48:53 PM : [F C1 DE 1 ] Using engine version i1 for 'Front Porch KPL' Fri 07/01/2011 02:48:53 PM : [iNST-ACK ] 02 62 0F.C1.DE 0F 28 02 06 SET-MSB(02) Fri 07/01/2011 02:48:53 PM : [iNST-SRX ] 02 50 0F.C1.DE 13.24.AA 2B 28 02 SET-MSB(02) Fri 07/01/2011 02:48:53 PM : [standard-Direct Ack][0F.C1.DE-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 07/01/2011 02:48:54 PM : [iNST-ACK ] 02 62 0F.C1.DE 0F 2B 64 06 PEEK (64) Fri 07/01/2011 02:48:54 PM : [iNST-SRX ] 02 50 0F.C1.DE 13.24.AA 2B 2B 00 PEEK (00) Fri 07/01/2011 02:48:54 PM : [standard-Direct Ack][0F.C1.DE-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 07/01/2011 02:48:54 PM : [iNST-ACK ] 02 62 0F.C1.DE 0F 29 7F 06 POKE (7F) Fri 07/01/2011 02:48:54 PM : [iNST-SRX ] 02 50 0F.C1.DE 13.24.AA 2B 29 7F POKE (7F) Fri 07/01/2011 02:48:54 PM : [standard-Direct Ack][0F.C1.DE-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 07/01/2011 02:48:55 PM : [iNST-ACK ] 02 62 0F.C1.DE 0F 24 00 06 (00) Fri 07/01/2011 02:48:55 PM : [iNST-SRX ] 02 50 0F.C1.DE 13.24.AA 2B 24 00 (00) Fri 07/01/2011 02:48:55 PM : [standard-Direct Ack][0F.C1.DE-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 07/01/2011 02:48:55 PM : [F C1 DE 1 ] Memory : EPROM Refreshed
LeeG Posted July 1, 2011 Posted July 1, 2011 Illusion What is device 12.3A.87? That is the device that generated the inbound message to the PLM with a command code of 0x49 which is Read Input Port for Cat 07 devices such as an I/O Linc, EZIOxx devices. Fri 07/01/2011 02:48:53 PM : [iNST-SRX ] 02 50 12.3A.87 13.24.AA 22 49 08 RINPUT (08) Two of these messages were received which is why the second, which is a duplicate, is labeled Process message : failed Lee
LeeG Posted July 1, 2011 Posted July 1, 2011 Do a Show PLM Links Table to see if there is something residual.
LeeG Posted July 2, 2011 Posted July 2, 2011 I did not pay attention to the Flags. The RINPUT message is an ACK from a device which means a PLM link record is not in play.
Illusion Posted July 11, 2011 Author Posted July 11, 2011 Lee, I have been playing around with comparing link tables and I seem to have multiple communications from devices that are not in my system: Mon 07/11/2011 04:38:23 PM : [iNST-SRX ] 02 50 05.8D.3F 13.24.AA 20 E8 0F (0F) Mon 07/11/2011 04:38:23 PM : [standard-Direct Ack][05.8D.3F-->ISY/PLM Group=0] Max Hops=0, Hops Left=0 Mon 07/11/2011 04:38:23 PM : [iNST-SRX ] 02 50 05.8D.3F 13.24.AA 20 E8 0F (0F): Process Message: failed Mon 07/11/2011 04:38:23 PM : [standard-Direct Ack][05.8D.3F-->ISY/PLM Group=0] Max Hops=0, Hops Left=0 Mon 07/11/2011 04:38:23 PM : [iNST-ACK ] 02 62 05.8A.DF 0F 2B 9A 06 PEEK (9A) Mon 07/11/2011 04:38:23 PM : [iNST-SRX ] 02 50 05.8D.3F 13.24.AA 20 E8 0F (0F) Mon 07/11/2011 04:38:23 PM : [standard-Direct Ack][05.8D.3F-->ISY/PLM Group=0] Max Hops=0, Hops Left=0 Mon 07/11/2011 04:38:23 PM : [iNST-SRX ] 02 50 05.8D.3F 13.24.AA 20 E8 0F (0F): Process Message: failed Mon 07/11/2011 04:38:23 PM : [standard-Direct Ack][05.8D.3F-->ISY/PLM Group=0] Max Hops=0, Hops Left=0 Mon 07/11/2011 04:40:41 PM : [standard-Direct Ack][05.8A.DF-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Mon 07/11/2011 04:40:41 PM : [iNST-SRX ] 02 50 FA.7A.DF 13.24.AA 20 EB C4 (C4) Mon 07/11/2011 04:40:41 PM : [standard-Direct Ack][FA.7A.DF-->ISY/PLM Group=0] Max Hops=0, Hops Left=0 Mon 07/11/2011 04:40:41 PM : [iNST-SRX ] 02 50 FA.7A.DF 13.24.AA 20 EB C4 (C4): Process Message: failed Mon 07/11/2011 04:40:41 PM : [standard-Direct Ack][FA.7A.DF-->ISY/PLM Group=0] Max Hops=0, Hops Left=0 Mon 07/11/2011 04:40:41 PM : [iNST-ACK ] 02 62 05.8A.DF 0F 28 0F 06 SET-MSB(0F) Mon 07/11/2011 04:40:41 PM : [iNST-SRX ] 02 50 FA.7A.DF 13.24.AA 20 EB C4 (C4) Mon 07/11/2011 04:40:41 PM : [standard-Direct Ack][FA.7A.DF-->ISY/PLM Group=0] Max Hops=0, Hops Left=0 Mon 07/11/2011 04:40:41 PM : [iNST-SRX ] 02 50 FA.7A.DF 13.24.AA 20 EB C4 (C4): Process Message: failed Mon 07/11/2011 04:40:41 PM : [standard-Direct Ack][FA.7A.DF-->ISY/PLM Group=0] Max Hops=0, Hops Left=0 Mon 07/11/2011 04:40:41 PM : [iNST-SRX ] 02 50 05.8A.DF 13.24.AA 2B 28 0F SET-MSB(0F) Both of these occurred while I was getting the links from a KPL 05.8A.DF Once again contact from a device not in my system. I have no device with device ID of FA.7A.DF nor 05.8A.DF Could this be related to my intermittent complete inability to communicate with certain devices while having near perfect comms the rest of the time?
LeeG Posted July 11, 2011 Posted July 11, 2011 Illusion That is really intriguing information. The difference in 05.8D.3F (bad) and 05.8A.DF (good) could be a single bit position shifted one bit to the left across three bit cycles. The bit pattern for the last two bytes ... 1000 1101 0011 1111 (8D.3F) 1000 1010 1101 1111 (8A.DF) The right number of bits are present, just shifted so the CRC character would still match. This could all just be an odd coincidence but it is interesting to say the least. We all know that Insteon traffic is a series of pulses representing 0 and 1 bits sent serially. If there was a slight drift in the timing this might happen. Normally the CRC catches extra/lost bits but in this case the bit count is correct. Is your house power from an unusual source such as a very local generating plant or augmented from solar where the 60 cycle wave is generated by equipment in the house. It would be interesting to measure the line frequency to see if there is any variation from 60 cycles. The reality is that there is always a small drift in the 60 cycles from commercial power. Clocks which use the sine wave as timing often drift a little slow or a little fast but it averages out over time. Insteon is more than capable of handling this normal drift. Because every Insteon device is a repeater I guess it could be a single device that is repeating the Insteon message at slightly the wrong point or missing a cycle. Because Insteon uses the portion of the sine wave before zero cross timing is based on the previous cycle. Collectively you do have some very strange symptoms. This would be a very strange Zebra for sure. I do not know what to make of the other address. The bit pattern is close to 05.8D.3F in some areas but not in others. The xx.xA.DF matches but the first 12 bits are hard to imagine how they could come from the KPL address. I have to wonder if the KPL you are reading link records from is the source or some other device that is repeating the KPL traffic. The only thing I can think of at the moment is to move the KPL to an appliance cord and plug it in at the PLM plug point to eliminate repeaters. If the invalid addresses continue to appear when close the PLM then maybe KPL, maybe line frequency. This is really all far out stuff and very hard to really understand what is causing it. Lee
Brian H Posted July 12, 2011 Posted July 12, 2011 LeeG and others. You may find this interesting. There is going to be an experiment lasting about a year. Where the power grid is going to be allowed to drift further in frequency. http://www.theepochtimes.com/n2/united- ... 58156.html
ELA Posted July 12, 2011 Posted July 12, 2011 Brian, I had read about that along with various speculations as to what equipment will and will not be affected. Should be interesting. With Insteon communications you are more concerned with cycle to cycle zero cross times and I don't think the variances in timing from one cycle to the next will be allowed to vary that much. It would have more effect on Real time clocks that might be based on power line frequency. A drift over a much longer time? At least I hope so I am curious about the idea that bit shifts might occur in the data and not be detected. While I might be concerned about phase shifts corrupting messages I would get very concerned if the corrupted messages were allowed to be acted upon.
LeeG Posted July 12, 2011 Posted July 12, 2011 ELA I agree with concern over bit shifts not being detected. Normally the CRC will pick up bit level problems caused by noise or attenuated signals. In the first case the number of bits is correct so the CRC will come out correct I think. The problem is no documentation on exactly how the CRC is accumulated. I serviced 9 track tape drives which had such a sophisticated CRC process that it could and did correct for single bit errors on the fly. Of course Insteon does not require anything that sophisticated. Illusion has some very odd symptoms (beyond this one) that have no obvious cause. This is the first that involves an Insteon address that is known not to exist in the installation. Yet the address is actually very close to an existing device address that is actively processing commands. The old PLCs would output invalid addresses at times. Have never seen a PLM do that. Lee
ELA Posted July 12, 2011 Posted July 12, 2011 Lee, What is your experience with EEprom corruption and the possibility that "false" links get created? The links are stored in EEprom that has historically been corruptible by power sequences or code unintended memory overwrites in many electronic devices utilizing EEprom. EEprom protections have greatly improved but can still happen. More in some designs than in others I wonder if these could have been the result of an EEprom corruption that added some false addresses but left valid ones intact? A stretch perhaps but could'nt that happen as well? The EEprom is written to serially by the microcontroller and that is another point at which errors could possibly occur. In these PLMs they have an external EEprom mounted on the serial interface daughterbrd which means those signals must transverse across a connector leaving them more vulnerable? Some random thoughts but no direct experience here with the Insteon product.
Illusion Posted July 12, 2011 Author Posted July 12, 2011 Lee, I am turning in my homework... Per your suggestion I put the KPL with the PLM. No need to put an appliance cord on this as it was already in a table top enclosure. I put the PLM on a FilterLinc and Leviton 6288 in series with the KPL in parrallel with the PLM after the filters to create a really small isolated network (save the RF which I can do nothing about- dual band PLM). Repeated link table fetching netted no weird return addresses. But the 5th time I did it something interesting happened. The KPL seemed to refuse to respond. I got an error window but not the normal cannot communicate with device. Something about failed to write mark... 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?
Illusion Posted July 12, 2011 Author Posted July 12, 2011 I did a factory reset on this device and a full restore. I then requested its link record: Tue 07/12/2011 11:19:28 AM : [12 3A 85 1 ] Using engine version i1 for 'Wake 3AM' Tue 07/12/2011 11:19:28 AM : [iNST-ACK ] 02 62 12.3A.85 0F 28 0F 06 SET-MSB(0F) Tue 07/12/2011 11:19:37 AM : [iNST-ACK ] 02 62 12.3A.85 0F 28 0F 06 SET-MSB(0F) Tue 07/12/2011 11:19:46 AM : [iNST-ACK ] 02 62 12.3A.85 0F 28 0F 06 SET-MSB(0F) Tue 07/12/2011 11:19:50 AM : [All ] Writing 0 bytes to devices And got this error:. Then I did a query on the KPL: Tue 07/12/2011 11:20:28 AM : [iNST-ACK ] 02 62 12.3A.85 0F 19 00 06 LTSREQ (LIGHT) Tue 07/12/2011 11:20:36 AM : [iNST-ACK ] 02 62 12.3A.85 0F 19 00 06 LTSREQ (LIGHT) Tue 07/12/2011 11:20:45 AM : [iNST-ACK ] 02 62 12.3A.85 0F 19 00 06 LTSREQ (LIGHT) And got the standard "Cannot Communicate With Device" error. Looks to me like a cooked KPL. I will play some more. If that is all it is, I am going to be pissed. A device that works most of the time, but then sometimes just refused to talk.
LeeG Posted July 12, 2011 Posted July 12, 2011 The Event Trace is showing the 9 second gap between command retries that occurs when no response is received from the device. I would connect to an appliance cord and plug next to the PLM to be sure but it looks like the device is done. The ISY does not need to talk to the device being replaced so no harm in removing it from the circuit.
Illusion Posted July 12, 2011 Author Posted July 12, 2011 Lee, Read post before last. All test were with the KPL right with the PLM
Illusion Posted July 12, 2011 Author Posted July 12, 2011 Here is another errant device ID while trying to restore this KPL again: Tue 07/12/2011 11:41:46 AM : [iNST-ACK ] 02 62 12.3A.85 0F 28 0F 06 SET-MSB(0F) Tue 07/12/2011 11:41:46 AM : [iNST-SRX ] 02 50 12.3D.7F 13.24.AA 23 DB E9 (E9) Tue 07/12/2011 11:41:46 AM : [standard-Direct Ack][12.3D.7F-->ISY/PLM Group=0] Max Hops=3, Hops Left=0 Tue 07/12/2011 11:41:46 AM : [iNST-SRX ] 02 50 12.3D.7F 13.24.AA 23 DB E9 (E9): Process Message: failed Tue 07/12/2011 11:41:46 AM : [standard-Direct Ack][12.3D.7F-->ISY/PLM Group=0] Max Hops=3, Hops Left=0 Tue 07/12/2011 11:41:47 AM : [iNST-SRX ] 02 50 12.3A.85 13.24.AA 2B 28 0F SET-MSB(0F)
Illusion Posted July 13, 2011 Author Posted July 13, 2011 Lee, Thanks for all your help on this. I really appreciate it. I realize I never answered your question about my power. Suburb community. Stable power. No discernible frequency drift, no ancillary power source (solar, wind, etc). that is near me. I was thinking. Since this is far out stuff I have some concerns declaring the KPL bad after much consideration. While it would seem that with just the PLM and the KPL on their own little network a failure from the switch would make that switch bad but there may be two other possibilities. I have 2 KPLs at this version on two different circuits. Both show the intermittent problem of adjusting their backlights. These were essentially 100% reliable until the changes made referenced in the original post. These changes were also coincident with upgrading from 2.8.16 which killed my backlight control of a Switchlinc Relay. Even a new switch is not correcting that issue. These 2 KPLs only have a problem communicating around the backlight commands. -except the weird errant device ids, but that could be the fault of a repeater not the KPL- A command from either of these KPLs is never missed by the ISY. Also a command to turn on the connected load on the one KPL with a load is also never missed. So thought #1 Something has changed in the command sent by the ISY from the 2.8.16 image. Thought #2 We only see what the PLM thinks it is sending out. Not what is really being sent. If you asked the switch what it was sending when getting device links it would always report it was correct, but we know that that is not always what gets to the receiver. As proven by my errant device id traces. I wonder if maybe there is something wrong with my PLM.
IndyMike Posted July 13, 2011 Posted July 13, 2011 Hello Illusion, I've been watching quietly while you've worked through this one. Your note below struck a chord. The "V.35" phenomena has never been completely explained (to my satisfaction anyway). I know you've done a mountain of testing on your units...but, in light of recent events it may be time to try an airgap on these units. They could be the "repeaters" that are corrupting communication with your KPL's. Just a WAG on my part, I have no personal experience with V.35 units. Nonetheless, when all of the "probable" items have been eliminated, it's time to try the improbable. ... -except the weird errant device ids, but that could be the fault of a repeater not the KPL- A command from either of these KPLs is never missed by the ISY...
Illusion Posted July 13, 2011 Author Posted July 13, 2011 Hi IM! Always nice to hear from you. I continue to try to find a definitive failure caused by my 4 v.35 icon relays. I will admit I did not think of taking them out of the equation on the errant device id issue. As this has never caused a failure that I am aware of I did not do as extensive testing on this as I do on things that make lights fail to turn on. If we could link this to the switch refusing to communicate sometimes that would be something then. But I did sorta rule these v.35 devices out just by my procedure. I had the device return an errant id while trying to restore it ( viewtopic.php?p=50434#p50434 ). This restore was taking place on my mini isolated circuit so I do not know how the v.35 devices could be in play. Further, all comms while on the mini network showed 2 hops remaining so to me that means no repeats at all. Speaking of which, the first recorded case of this in this thread (while the KPL and the PLM were on the network at large-not isolated) the trace also show 2 hops remaining. Interesting. Now that being said, when these issues with the KPLs not responding arose I did extensive testing with my v.35 devices removed from the system. I continue to always try to find an issue I can pin on them. No luck so far with years of efforts. I have 2 breakers that have only those 4 (2 on each) Icon v.35 devices and 3 Switchlinc Relays v.28 on them. So not a perfectly sterile v.35 isolation, but it kinda does not matter because I am always able to experience the failure with or without these breakers closed. I would be happy to test the link records with and without the v.35 devices if you think it will provide any additional data. It would have to be a statical analysis I suppose as I did see one errant device id while the PLM and the KPL were behind the filters. The breakers for the v.35s were closed at this time and I guess it is possible that through RF some contamination of the signal could have occurred from them. I will not be able to test this for awhile as I am getting busy with work. Today was my last day to mess with this. I am probably just going to stop trying to adjust the backlights in these two KPLs till I figure out what I want to do next.
IndyMike Posted July 14, 2011 Posted July 14, 2011 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. I have never used the backlight feature on an active basis. After reading your post, I did test a number of my units using a repetitive program. No issues using V3.1.4 on the ISY (100 loops on 5 units). I did this using both the I1 and I2 protocol - nary a hiccup. Just to re-cap, are you able to control the backlight on any of your units? If not, we're looking for a common mode failure and it doesn't appear to be the ISY firmware. That would seem to point to the PLM, but I'm assuming that it is communicating with the rest of your units properly - correct? Lee's observation on the bit pattern also caught my attention. If I remember correctly, you have a passive coupler installed - correct? Have you noticed any correlation with communication issues and when the A/C or other large inductive loads are running? I've had problems in the past with X10 repeaters and 240V inductive loads in parallel. Sorry - lot's of questions and no suggestions, IM
Illusion Posted July 14, 2011 Author Posted July 14, 2011 I have never used the backlight feature on an active basis. After reading your post, I did test a number of my units using a repetitive program. No issues using V3.1.4 on the ISY (100 loops on 5 units). I did this using both the I1 and I2 protocol - nary a hiccup. So the back-light can be changed via I1 and I2 even for I2 based units. I am going to have to play with that. I asssume you did this with Link Management>Advanced Options>i1 Only? Just to re-cap, are you able to control the backlight on any of your units? If not, we're looking for a common mode failure and it doesn't appear to be the ISY firmware. That would seem to point to the PLM, but I'm assuming that it is communicating with the rest of your units properly - correct? Yes. No problem controlling: 2 (2486D) KeypadLinc Dimmer 8 Buttons v.36 1 (2486D) KeypadLinc Dimmer 6 Buttons v.36 2 (2476D) SwitchLinc Dimmer W/Beeper v.38 And I used to be able to control the backlight of: 1 (2476S) SwitchLinc Relay - Remote Control On/Off Switch v.3A Until recently. I have no remote control of this device's backlight any more. I can adjust it locally using the set button and fade adjust method. I think I lost ISY control when I upgraded from 2.8.16 but was not paying attention to this switch in all my other issues... And of course the main topic of discussion. I am now having intermittent trouble controlling: 1 (2486DWH8) KeypadLinc Dimmer 8 Button v.2D 1 (2486D) KeypadLinc Dimmer v.2D I change these every night and morning, and most of them are in places it really really stands out if they are full bright at night or completely dark during the day. All of these used to be just about 100% reliable. I do not recall any failure ever before. Now only the first group is reliable. Lee's observation on the bit pattern also caught my attention. If I remember correctly, you have a passive coupler installed - correct? Have you noticed any correlation with communication issues and when the A/C or other large inductive loads are running? I've had problems in the past with X10 repeaters and 240V inductive loads in parallel. Sorry - lot's of questions and no suggestions, IM Good memory. Yes passive coupler installed. Switched out the X-10 job for a Insteon tuned version some time ago. Lots of tests during this troubleshooting with and without the coupler. As far as correlation with loads. No. I have tried to find one for the past 40 days. But when I do repeated backlight changes on the problem KPL I will see great comms one second, and then a 3 attempt failure the next. As soon as the dialog box is dismissed a query of the device shows excellent comms again most times. I appreciate all the questions. I desperately needed some outside input just to keep me thinking of other tests. All this troubleshooting has made me really want 2 things. 1. Device names in the event viewer. At least in one line related to a communication. Like the one that says: Mon 07/11/2011 04:29:49 PM : [standard-Direct Ack][14.BF.AA-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 If just the device ID in this one line were the device name, but others were left as IDs it would be awesome. 2. A device that I can put at the receiving end of the equation so I know what is getting there. Like signal level, hop count, noise, and I guess now what it thought the message was. Thanks again all. I am glad to be part of this community.
TJF1960 Posted July 14, 2011 Posted July 14, 2011 Hi Illusion, I can verify the same results with the backlighting adjustment of SwitchLinc Relay's. I am running v 3.1.4 and just tested setting the backlighting on one of my SL relays (reported as 12.89.41 – (2476S Swithclinc Relay W/Sense v.37) thru the admin console. I know the adjust backlight in all of my SL relays in previous versions did work. I tested my SL dimmers and they do currently work. I dropped back to 2.8.16 and confirmed the backlight in the SL relays could be adjusted in the console. I then tested in v3.1.0 and the backlighting adjustment worked fine as well. I went to v3.1.1 and that appears t be when the backlight adjustment broke. Here are a couple of event traces in v2.8.16 in which the manual backlight worked setting to 1 then to 255: Thu 07/14/2011 04:54:49 AM : CLI-WBug: Connecting to datafeed.weatherbug.com Thu 07/14/2011 04:54:49 AM : CLI-WBug: Successfully Processed WBug Response Thu 07/14/2011 04:54:56 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 04:54:56 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [01] Thu 07/14/2011 04:54:56 AM : [iNST-ACK ] 02 62 12.89.41 1F 2E 00 01 03 01 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 04:54:56 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2E 00 (00) Thu 07/14/2011 04:55:07 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 04:55:07 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [FF] Thu 07/14/2011 04:55:07 AM : [iNST-ACK ] 02 62 12.89.41 1F 2E 00 01 03 FF 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 04:55:07 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2E 00 (00) Then I created a program loop setting backlighting to first 25%, wait 3 seconds then 50%, wait 3 seconds then 75%, wait 3 seconds then 100% in v2.8.16 and confirmed the backlighting was changing in v2.8.16: Thu 07/14/2011 04:55:28 AM : [ Time] 04:55:30 0(0) Thu 07/14/2011 04:55:28 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 04:55:28 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [3F] Thu 07/14/2011 04:55:29 AM : [iNST-ACK ] 02 62 12.89.41 1F 2E 00 01 03 3F 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 04:55:29 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2E 00 (00) Thu 07/14/2011 04:55:31 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 04:55:31 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [7F] Thu 07/14/2011 04:55:31 AM : [iNST-ACK ] 02 62 12.89.41 1F 2E 00 01 03 7F 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 04:55:32 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2E 00 (00) Thu 07/14/2011 04:55:35 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 04:55:35 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [bF] Thu 07/14/2011 04:55:35 AM : [iNST-ACK ] 02 62 12.89.41 1F 2E 00 01 03 BF 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 04:55:35 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2E 00 (00) Thu 07/14/2011 04:55:38 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 04:55:38 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [FF] Thu 07/14/2011 04:55:38 AM : [iNST-ACK ] 02 62 12.89.41 1F 2E 00 01 03 FF 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 04:55:38 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2E 00 (00) Thu 07/14/2011 04:55:38 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 04:55:38 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [3F] Thu 07/14/2011 04:55:38 AM : [iNST-ACK ] 02 62 12.89.41 1F 2E 00 01 03 3F 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 04:55:39 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2E 00 (00) Thu 07/14/2011 04:55:42 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 04:55:42 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [7F] Thu 07/14/2011 04:55:42 AM : [iNST-ACK ] 02 62 12.89.41 1F 2E 00 01 03 7F 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 04:55:42 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2E 00 (00) Thu 07/14/2011 04:55:44 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 04:55:44 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [bF] Thu 07/14/2011 04:55:44 AM : [iNST-ACK ] 02 62 12.89.41 1F 2E 00 01 03 BF 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 04:55:45 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2E 00 (00) Thu 07/14/2011 04:55:47 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 04:55:47 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [FF] Thu 07/14/2011 04:55:47 AM : [iNST-ACK ] 02 62 12.89.41 1F 2E 00 01 03 FF 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 04:55:48 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2E 00 (00) Thu 07/14/2011 04:55:49 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 04:55:49 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [3F] Thu 07/14/2011 04:55:49 AM : [iNST-ACK ] 02 62 12.89.41 1F 2E 00 01 03 3F 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 04:55:49 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2E 00 (00) Thu 07/14/2011 04:55:51 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 04:55:51 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [7F] Thu 07/14/2011 04:55:51 AM : [iNST-ACK ] 02 62 12.89.41 1F 2E 00 01 03 7F 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 04:55:52 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2E 00 (00) Thu 07/14/2011 04:55:52 AM : [ Time] 04:55:54 0(0) Here is the trace in v3.1.0 the backlight adjust still working, this is the manual adjust set to 1 then 255: Thu 07/14/2011 06:27:47 AM : [VAR 2 8 ] 1 Thu 07/14/2011 06:27:47 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 06:27:47 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [01] Thu 07/14/2011 06:28:01 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 06:28:01 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [FF] Here is the trace also in v3.1.0 of the program loop: Thu 07/14/2011 06:31:14 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 06:31:14 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [3F] Thu 07/14/2011 06:31:17 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 06:31:17 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [7F] Thu 07/14/2011 06:31:17 AM : [VAR 2 8 ] 0 Thu 07/14/2011 06:31:19 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 06:31:19 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [bF] Thu 07/14/2011 06:31:23 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 06:31:23 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [FF] Thu 07/14/2011 06:31:24 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 06:31:24 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [3F] Thu 07/14/2011 06:31:26 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 06:31:26 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [7F] Thu 07/14/2011 06:31:30 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 06:31:30 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [bF] Thu 07/14/2011 06:31:33 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 06:31:33 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [FF] Thu 07/14/2011 06:31:33 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 06:31:33 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [3F] Thu 07/14/2011 06:31:37 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 06:31:37 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [7F] Thu 07/14/2011 06:31:47 AM : [VAR 2 8 ] 1 Here are the traces for v3.1.1 when the backlight adjust didn’t work: Thu 07/14/2011 06:20:47 AM : [12 89 41 1 ] Using engine version i1 for 'WR Back Door Porch' Thu 07/14/2011 06:20:47 AM : [All ] Writing 2 bytes to devices Thu 07/14/2011 06:20:47 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [01] Thu 07/14/2011 06:20:47 AM : [12 89 41 1 ] Using engine version i1 for 'WR Back Door Porch' Thu 07/14/2011 06:20:47 AM : [12 89 41 1 ] Using engine version i1 for 'WR Back Door Porch' Thu 07/14/2011 06:20:47 AM : [iNST-ACK ] 02 62 12.89.41 0F 28 02 06 SET-MSB(02) Thu 07/14/2011 06:20:47 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 28 02 SET-MSB(02) Thu 07/14/2011 06:20:47 AM : [iNST-ACK ] 02 62 12.89.41 0F 2B 64 06 PEEK (64) Thu 07/14/2011 06:20:47 AM : [VAR 2 8 ] 1 Thu 07/14/2011 06:20:47 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2B FF PEEK (FF) Thu 07/14/2011 06:20:48 AM : [iNST-ACK ] 02 62 12.89.41 0F 29 01 06 POKE (01) Thu 07/14/2011 06:20:48 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 29 01 POKE (01) Thu 07/14/2011 06:20:48 AM : [iNST-ACK ] 02 62 12.89.41 0F 24 00 06 (00) Thu 07/14/2011 06:20:48 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 24 00 (00) Thu 07/14/2011 06:20:48 AM : [12 89 41 1 ] Memory : EPROM Refreshed Thu 07/14/2011 06:20:52 AM : [ Time] 06:20:52 0(0) Thu 07/14/2011 06:20:55 AM : [12 89 41 1 ] Using engine version i1 for 'WR Back Door Porch' Thu 07/14/2011 06:20:55 AM : [All ] Writing 2 bytes to devices Thu 07/14/2011 06:20:55 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [FF] Thu 07/14/2011 06:20:55 AM : [12 89 41 1 ] Using engine version i1 for 'WR Back Door Porch' Thu 07/14/2011 06:20:55 AM : [12 89 41 1 ] Using engine version i1 for 'WR Back Door Porch' Thu 07/14/2011 06:20:55 AM : [iNST-ACK ] 02 62 12.89.41 0F 28 02 06 SET-MSB(02) Thu 07/14/2011 06:20:55 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 28 02 SET-MSB(02) Thu 07/14/2011 06:20:55 AM : [iNST-ACK ] 02 62 12.89.41 0F 2B 64 06 PEEK (64) Thu 07/14/2011 06:20:55 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2B 01 PEEK (01) Thu 07/14/2011 06:20:56 AM : [iNST-ACK ] 02 62 12.89.41 0F 29 FF 06 POKE (FF) Thu 07/14/2011 06:20:56 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 29 FF POKE (FF) Thu 07/14/2011 06:20:56 AM : [iNST-ACK ] 02 62 12.89.41 0F 24 00 06 (00) Thu 07/14/2011 06:20:56 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 24 00 (00) Thu 07/14/2011 06:20:56 AM : [12 89 41 1 ] Memory : EPROM Refreshed Thu 07/14/2011 06:21:17 AM : [VAR 2 8 ] 0 And finally for what it is worth here is a trace from 3.1.4 trying to adjust to 1 then 255: Thu 07/14/2011 06:44:20 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 06:44:20 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [01] Thu 07/14/2011 06:44:20 AM : [iNST-ACK ] 02 62 12.89.41 1F 2E 00 00 07 01 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 06:44:21 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2E 00 (00) Thu 07/14/2011 06:44:33 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 06:44:33 AM : [12 89 41 1 ] Memory : Write dbAddr=0x0264 [FF] Thu 07/14/2011 06:44:33 AM : [iNST-ACK ] 02 62 12.89.41 1F 2E 00 00 07 FF 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 06:44:34 AM : [iNST-SRX ] 02 50 12.89.41 11.DD.F9 2B 2E 00 (00) Thu 07/14/2011 06:44:43 AM : CLI-WBug: Connecting to datafeed.weatherbug.com Thu 07/14/2011 06:44:43 AM : CLI-WBug: Successfully Processed WBug Response Thu 07/14/2011 06:44:48 AM : [VAR 2 8 ] 1 After all of this I just realized your original problems were with kpl’s which I had forgotten about. Your last post mentioned the SL relay problem which led me to check mine, which led to this long post. So I just tested one of my KPL’s and was able to successfully adjust the backlighting. This kpl was installed about a year ago (under what version I have no idea) so I hooked up a new kpl (15.63.66 – (2486S/WH6) KeypadLinc Relay v.36) and linked it to the isy (running v3.1.4) and tested the backlighting. It also worked fine. For what it is worth here is the trace: Thu 07/14/2011 07:18:44 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 07:18:44 AM : [15 63 66 1 ] Memory : Write dbAddr=0x0264 [00] Thu 07/14/2011 07:18:44 AM : [iNST-ACK ] 02 62 15.63.66 1F 2E 00 01 07 00 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 07:18:44 AM : [iNST-SRX ] 02 50 15.63.66 11.DD.F9 2B 2E 00 (00) Thu 07/14/2011 07:18:49 AM : [VAR 2 8 ] 1 Thu 07/14/2011 07:18:54 AM : [ Time] 07:18:54 0(0) Thu 07/14/2011 07:18:55 AM : [All ] Writing 1 bytes to devices Thu 07/14/2011 07:18:55 AM : [15 63 66 1 ] Memory : Write dbAddr=0x0264 [38] Thu 07/14/2011 07:18:55 AM : [iNST-ACK ] 02 62 15.63.66 1F 2E 00 01 07 38 00 00 00 00 00 00 00 00 00 00 00 06 (00) Thu 07/14/2011 07:18:56 AM : [iNST-SRX ] 02 50 15.63.66 11.DD.F9 2B 2E 00 (00) Anyway I hope this helps somebody figure it all out! Tim
Michel Kohanim Posted July 14, 2011 Posted July 14, 2011 Hi Tim, Thanks so very much! Can you send me the exact description on the title for those devices that worked in 3.1.0 and don't in 3.1.4? Thanks in advance and with kind regards, Michel
Recommended Posts
Archived
This topic is now archived and is closed to further replies.