ELA

Hello MarcArsenault, From your post it seemed as though you might be going on an assumption that the AFCI is your problem? While it is possible I have never read ay conclusive proof that AFCI breakers attenuate Insteon signals. Can you tell us more about the communications routes involved? Where is the transmitter that is trying to communicate with the outletlinc in relation to the outletlinc? How much distance between the two, on different phases (legs), different or same circuit? Is it possible that you have so much distance between the two that the signal is weak regardless of AFCI or not? Are there any other Insteon devices (repeaters) in-between the transmitter and the intended receiver? Any signal suckers on either circuit that may require a filterlinc? Without knowing how comfortable you are with electrical, a temporary replacement of the AFCI with a standard breaker could be telling. (only as a test, be sure to re-install the AFCI afterwards). Often times it is a total guessing game without signal strength measurements.

GFCI breakers and outlets have definitely improved over the years with respect to "nuisance tripping". A big question is ... is this Nuisance tripping? It may be worth a try but no guarantees. What brand is the current breaker? What is the wire length from the sub panel to the switch, then what length to the pool lights from there? As I said if you want to be thorough you need to monitor the leakage current to be sure that you are not always on the very edge of tripping without Insteon traffic.

Hello RichTJ99, You never want to exclude the possibility that a GFCI trip is a valid trip due to a current leakage issue that should be addressed. That being said; Yes GFCI circuits can trip due to Insteon Traffic. I have been able to produce this result on a GFCI outlet in my home, but then could not reproduce it afterwards. The occurrence happened when I plugged a PLM directly into that outlet during testing. Thus the amplitude of the signal at that point was very strong. That same circuit has never tripped for any other reason. This even though Insteon traffic does flow through that device all the time in route to some of my devices. I believe the signal level (amplitude) combined with message length have to be just right for this to occur. Some GFCI's are likely to be more sensitive than others. The fact that you have two sub panels may also contribute to the occurrence. That type of issue is not easy to diagnose and cure. If you seriously want to resolve it you can rent or purchase a current meter designed to measure small amplitude differential currents. Or hire an electrician who is familiar with the type of equipment required. That meter allows you to determine if the GFCI is experiencing some level of leakage all the time due to some other issue. These devices trip on a very small differential current of 5-6 milliamps. It is possible that you have some leakage all the time that is making this device then extra sensitive to Insteon traffic. It is also possible that you have some equipment, or long wire runs, that allows the Insteon signal to capacitively couple to ground at some point, rather than returning back to the GFCI on the other conductor. This can be a very complex issue to sort out. Best of luck

HI LeeG, I had to run some more testing to provide the info you requested. I ran several tries in a row that produced the same result 261 result while the house was empty and I could control the activity. I then purposely turned on lights during the PLM reads and got several "short stops" with less than 200 links. I finally caused one with 355 links and the same address I noted last night - that is not in my system. They were both A2 and E2 to the same address. A few were identical duplicates such as "E2 00 1B B0 FE 01 19 40" Based on your reply I am not worried and understand the errant reads can happen. I just wanted to provide you with this feedback since you asked.

Thanks for the information LeeG and Brian H. I realized that traffic might upset this process, even though it was via the serial cable and not over the power line. For that reason I thought I was avoiding purposely creating any traffic but perhaps "stuff happened" without me knowing it. Interesting information LeeG about link data base compression. This is a very new PLM that I ran a restore on when I installed it about 2 months ago. The strange addresses I saw were never in my system. Maybe I forgot to run a factory reset before the install? Or does that not clear memory either?

I had implemented reading the PLM's link records, over the power line, in my tester (ELAM) and all appeared to be working well (reading using the 0x2F) command. The ELAM reported 261 records. I then ran the get PLM links on the ISY for a confirmation that my code was working correctly. The ISY reported 327 records! I had the communications viewer open and could see a lot of records containing addresses that did not exist in my system! When I ran the same test in the ISY a second time it reported 261 records. I found this really strange since I would expect more likelihood of message corruptions when retrieving over the power line vs. the ISY reading the PLM's links directly over the serial cable using the 0x69, 0x6A commands. I will try more tests to see if this happens again when I can. Any explanations available, happen to anyone else? I am running ISY 3.2.4 I think.

Thanks LeeG, Somehow I knew there was an obvious answer that I was missing From what I have been able to attempt to understand about Illusions problem ... he thinks there is an errant link in the PLM, is that correct, or in the IRlink? If it were in the PLM, and the unwanted link had been identified, could a person use the "0x6F" - Manage All-link Record command and terminal program to remove the unwanted link? And then follow up with a backup of the PLM into the ISY? Or are there complications that would prevent doing that?

In an attempt to learn more from this thread I retrieved my IRlinc- links ( below). 1b,fd,23 being the PLM. When I compare them to Illusions I am now a bit confused? Illusions show to be responder links whereas mine are controllers. I found the same associated (22) links in the PLM but as responder links. This arrangement seems to make sense to me since I send IR commands from my remote to the IRlinc device and it then sends control commands to various loads. The PLM never controls the IRlinc? So what am I missing? Why are Illusions responder links with the PLM address in them? Please be gentle, I am rookie and learning e2 1 1b fd 23 ff 1f 1 e2 18 1b fd 23 ff 1f 18 e2 19 1b fd 23 ff 1f 19 e2 1a 1b fd 23 ff 1f 1a e2 1b 1b fd 23 ff 1f 1b e2 26 1b fd 23 ff 1f 26 e2 27 1b fd 23 ff 1f 27 e2 1c 1b fd 23 ff 1f 1c e2 1d 1b fd 23 ff 1f 1d e2 20 1b fd 23 ff 1f 20 e2 1e 1b fd 23 ff 1f 1e e2 1f 1b fd 23 ff 1f 1f e2 21 1b fd 23 ff 1f 21 e2 28 1b fd 23 ff 1f 28 e2 29 1b fd 23 ff 1f 29 e2 2a 1b fd 23 ff 1f 2a e2 2b 1b fd 23 ff 1f 2b e2 2c 1b fd 23 ff 1f 2c e2 2d 1b fd 23 ff 1f 2d e2 23 1b fd 23 ff 1f 23 e2 24 1b fd 23 ff 1f 24 e2 25 1b fd 23 ff 1f 25

Michel, I do not want to belabor this too far but one more question please. I understand if UDI preferred to output the file in XML for your purposes, however I did not understand the comment that the XML output was to reduce file size? Last night I saved a file that contained 51 link records. That XML file is 6.5K in size. On the surface that seems like room for 127 bytes per link. If there are 8 (hex) bytes per link record that leaves about 15 characters to define each byte in a record? Couldn't a straight hex output (as ascii) be that size or smaller? This is of course not important at all, just makes me curious.

Thanks LeeG, I did do a search before I posted but missed that discussion, sorry for being redundant. The answer is unfortunate, if not intended for human use then the save option must be only for ISY programmers?? While I do know how to convert decimal to hex it would be way to laborious for the 50+ link records I viewed on screen and would now like to parse further off-line. I was reading my IRlinc link-records in an attempt to help further understand another posters issues with the IRlink and to learn more myself. I will have to do it next time I am in front of the ISY, or use the ELAM since I have just completed adding that ability to it. Thanks Michel, I unfortunately I am not a java guy.

I have been trying to review some link records both on the ISY screen and then later in a saved file. I understand the command on screen but find the xml format that is a saved file representation of that information frustrating to view and with my limited knowledge somewhat useless. Why does the ISY show it on screen as hex characters and then save it as XML? Is there an easy method to convert the XML output back to hex? I have heard the term REST command used a few times ? Is REST helpful for converting back and if so how. I read the wiki but it appeared to be for other things? I am interested in converting the output file back to hex ( off-line when I do not have the the ISY running in front of me). Or if there is another method to output the link record file while in front of the ISY direct to hex characters?

LeeG, Understood that there are "20+ link records (IR codes) that are responding to ISY Scene number 91 (0x5B)". My question revolved around identifying which one of those corresponded to the IPOD play? Perhaps that would not be helpful.

Hi LeeG, I probably worded my question poorly. Yes I meant an index byte to one of the 128 possible IR transmission codes. I did not mean the IR code itself. So if you knew what index to look for wouldn't that be helpful in evaluating which link in the ISY was in question?

Hello Illusion , LeeG, I have recently been working with link commands and learning. Reading this thread I am curious if the last byte of the link records shown ( data 3 byte) are the IRlink IR code number? If so could a person identify which IR code # (data 3 byte) in the IRlink commands the IPOD play ( via the ISY) and then use that information to assist in identifying which link in the ISY could be the errant one? (assuming there is an errant link?)

I'll give that a try eventually but for now I just dug out an older version ApplianceLinc and used it from the same location with no issues at all. Hi Upstatemike, I had a lot of trouble adding a version 4.6 Appliancelinc to the ISY under ISY V3.2.x . I suspected it was the i2CS changes initially. Later I found that that particular module had a hardware issue wherein its transmitter was very weak. It was only transmitting at a level of 1/4 that of what my PLM puts out. In addition its output would vary from time to time. Initially it was nearly 3 Vp-p and later fell to 1 Vp-p. I could occasionally see its output drop to less than 100 mv p-p. This sort of defect is not easy to identify if you do not have access to test equipment. My point is that my issue was due to a not immediately obvious hardware issue. I returned that module for a replacement last week. Your situation may be totally different but I wanted to relate another person experience with the same rev Insteon hardware.

Installed a new Switchlinc (hardware R5.6, V40 firmware) under ISY V3.2.2 that went flawless using auto-discover. Unfortunately I forgot to save the log when ISY Rebooted after doing a "replace operation". Later using the Query Engine the new device showed a "01" or i2 device. Did not appear to be I2CS.

Thanks for your help LeeG, I had kept a log of one of the failed attempts. One where it hung up "appearing to" attempt communicating with an MS (PIR)Sensor. I reviewed the log to the best of my understanding and it appears that linking mode was established , The ISY tried to begin linking but that it did not happen. A little while later the garage PIR sensor times out with an off command ( from a previous On 10 minutes earlier when I had tripped it ). I guess this is why its address appeared in the window? Thu 04/05/2012 06:57:20 PM : ---- Initializing the linked devices ---- Thu 04/05/2012 06:57:20 PM : ---- All Linked Devices are now initialized ---- Thu 04/05/2012 06:57:20 PM : ---- Add remaining devices ---- Thu 04/05/2012 06:57:20 PM : [iNST-TX-I1 ] 02 62 1C F3 17 0F 0D 00 Thu 04/05/2012 06:57:20 PM : [iNST-ACK ] 02 62 1C.F3.17 0F 0D 00 06 (00) Thu 04/05/2012 06:57:21 PM : [iNST-SRX ] 02 50 1C.F3.17 1B.FD.23 2B 0D FF (FF) Thu 04/05/2012 06:57:21 PM : [standard-Direct Ack][1C.F3.17-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Thu 04/05/2012 06:57:21 PM : [iNST-TX-I2CS] 02 62 1C F3 17 1F 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 F6 Thu 04/05/2012 06:57:21 PM : [iNST-ACK ] 02 62 1C.F3.17 1F 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 F6 06 LNK-ON (01) Thu 04/05/2012 06:57:22 PM : [iNST-SRX ] 02 50 1C.F3.17 1B.FD.23 2B 09 01 LNK-ON (01) Thu 04/05/2012 06:57:22 PM : [standard-Direct Ack][1C.F3.17-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Thu 04/05/2012 06:57:22 PM : [LNK-BGN ] 02 64 01 00 06 // Garage PIR sensor , turning off Thu 04/05/2012 06:58:16 PM : [iNST-SRX ] 02 50 14.71.EE 00.00.02 CB 13 02 LTOFFRR(02) Thu 04/05/2012 06:58:16 PM : [standard-Group][14.71.EE-->Group=2] Max Hops=3, Hops Left=2 Thu 04/05/2012 06:58:16 PM : [ 14 71 EE 2] DOF 2 Thu 04/05/2012 06:58:16 PM : [ 14 71 EE 2] ST 0 Thu 04/05/2012 06:58:16 PM : [iNST-SRX ] 02 50 14.71.EE 00.00.02 CB 13 02 LTOFFRR(02) Thu 04/05/2012 06:58:16 PM : [standard-Group][14.71.EE-->Group=2] Max Hops=3, Hops Left=2 Thu 04/05/2012 06:58:16 PM : [iNST-SRX ] 02 50 14.71.EE 00.00.02 CB 13 02 LTOFFRR(02): Process Message: Ignored Thu 04/05/2012 06:58:16 PM : [standard-Group][14.71.EE-->Group=2] Max Hops=3, Hops Left=2 Thu 04/05/2012 06:58:17 PM : [iNST-SRX ] 02 50 14.71.EE 1B.FD.23 41 13 02 LTOFFRR(02) Thu 04/05/2012 06:58:17 PM : [standard-Cleanup][14.71.EE-->ISY/PLM Group=2] Max Hops=1, Hops Left=0 Thu 04/05/2012 06:58:17 PM : [iNST-SRX ] 02 50 14.71.EE 1B.FD.23 41 13 02 LTOFFRR(02): Process Message: Ignored Thu 04/05/2012 06:58:17 PM : [standard-Cleanup][14.71.EE-->ISY/PLM Group=2] Max Hops=1, Hops Left=0

I performed a factory reset on the new I2CS Appliancelinc prior to a third attempt to Auto-Discover and this attempt went flawless. A forth attempt (just for test purposes) resulted in the ISY hanging once again. This might be due to operator error on my part? Q1) I believe the best way to remove a device is to delete it from the ISY prior to factory resetting of the device, is that correct? This being to to remove all links on both ends? Q2) If you factory reset a device first, then delete it from the ISY, does this fail to remove the links in the ISY -PLM? I was surely seeing some strange behavior in the ISY and wonder if at least part of that was partial links not removed. I was seeing the ISY lock-up and never time out (> 10 minutes) which seems very strange. I would expect it to time out no matter what, unless the code was hung. This appeared to be the case because I had to power reset it 2-3 times in this testing process to get it to stop presenting the "Initializing System Window". The last time this happened I saw that it was hung attempting to work with an address shown on the screen that belonged to a MS(PIR) sensor ? The new Appliancelinc was not added to any scenes, and why would it hang up on the forth attempt but not the third? I then had a successful 5th auto-discover linking and am leaving it as is. I am up and running fine now so no need to pursue this any further. I am just reporting this back in case is not all due to errors on my part. I do have a new Switchlinc Dimmer (V5.6, suspected I2CS) to install on Sunday so I will see how that one goes. That will be a replacement of an existing older switchlinc dimmer (non I2CS).

Yes LeeG the ELAM issues the 0x0D command. I will attempt the auto-discover again this evening. here is the beginning of the log from my third attempt last night, using manual linking. Wed 04/04/2012 10:29:55 PM : ---- Initializing the linked devices ---- Wed 04/04/2012 10:29:55 PM : ---- All Linked Devices are now initialized ---- Wed 04/04/2012 10:29:55 PM : ---- Add remaining devices ---- // Flags .. get engine Wed 04/04/2012 10:29:55 PM : [iNST-TX-I1 ] 02 62 1C F3 17 0F 0D 00 Wed 04/04/2012 10:29:55 PM : [iNST-ACK ] 02 62 1C.F3.17 0F 0D 00 06 (00) // I2CS = 02 Wed 04/04/2012 10:29:57 PM : [iNST-SRX ] 02 50 1C.F3.17 1B.FD.23 2B 0D 02 (02) Wed 04/04/2012 10:29:57 PM : [standard-Direct Ack][1C.F3.17-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Wed 04/04/2012 10:29:57 PM : [1C F3 17 0 ] Calibrating engine version Wed 04/04/2012 10:29:57 PM : [ 1C F3 17 1] Adding device to ISY t=02.0C.0000 Wed 04/04/2012 10:29:57 PM : [1C F3 17 1 ] Start : Adding device to ISY Wed 04/04/2012 10:29:57 PM : [1C F3 17 1 ] Finish : Adding device to ISY was Successful No nak bit and a valid "0x02" response. This makes me think that the appliance link must have been "aware" or at least partially linked from the previous 2 attempts? I will do a factory reset before any further attempts tonight.

LeeG, I do not know if my Fanlinc was I2CS. I do not think it was but I will check on that. I never attempted to add it to my ISY prior to upgrading to 3.2.2 , ... knowing that I needed that version. I did power cycle both the PLM and ISY before my second failed attempt last night. I had some time so I tried communicating to the new Appliancelinc with my ELAM (isolated bench test). As expected it gets response messages (to a direct msg send) but they are not acted on since the ELAM is not in the I2CS devices link data base. When I added the ELAM to its (appliancelinc) link record then the direct commands were accepted and acted on. What this allowed me to see is that if the device is not in the link record the response sets the MSB of the flags (broadcast/NAK bit), Flag byte =0xA1. It also puts a 0xFF in the Cmd 2 byte. So what is very interesting is when compared to my original failed log, ... The I2CS appliancelinc returned the 0xFF in cmd2 but it DID NOT set the NAK bit ??? This seems to be an inconsistency?

Hi LeeG, I do not think this would be an network communication reliability issue. When I linked it manually all the comm was very good and the process completed very fast. If it would not have linked manually I would have put the device right next to the PLM just to be sure, but manual link worked great ( as best as I can tell). I was short on time as it was bed time last night and I expected the process to only take 5 minutes.. I will delete it and try auto-Discover once again tonight. I am unsure of firmware level but I just replaced the PLM a few weeks ago. I believe it is V99 firmware. Now you have me thinking... As we introduce I2CS devices how does that work without upgrading the PLM to be I2CS compatible? When I have time I am reviewing the successful manual link log. It looks like the get engine request returned an "0x02" in cmd2. Guess this must indicate I2CS device? I just looked at the failed attempt and the get engine returned 0xFF in cmd2?

Can you use auto-detect to link new I2CS modules in V3.2.2? I updated my ISY99 to 3.2.2 last Sunday. All went well. I added an existing Fanlinc, created a couple of scenes and all went well. Confirmed Running 3.2.2 in both listings in "about". I did not log into the ISY until last night again. I had a lot of trouble even getting the ISY up and running. Only initial white screen (no 2nd Blue screen) would come up. Authentication input would fail to work. I will not expound on that for now but wanted to mention it. I eventually got it running after reloading Java (perhaps just the cache needed emptying? ... I had emptied cache after the install on Sunday). Now all seemed to be running as it should. Did a few queries to be sure of comm. I then tried to link a new Appliancelinc (2456S3, V 4.6). I used auto-detect. A few intial commands were sent and the Appliancelinc went into link mode (fast blinking white LED). The ISY then hung in a loop "initializing system". It timed 0-100% on that screen 3 times (over 10 minutes) and I could not exit. Rebooted computer. As soon as I entered the ISY again it was still hung in that loop. I rebooted the ISY. Now I could not get a query to work. Exited and reentered ISY. Now all is fine. Tried a second attempt at Auto-detect linking and it failed in the same manner. Had to reboot the ISY and reenter program twice to get query working again. On my third attempt I did not use auto-detect and instead picked the 2456S3 device. I also manually put the appliancelinc into link mode using the set button. This time it linked fine. What I expected to take 5 minutes took over an hour. All I really wanted to accomplish was getting a log of the new device link to confirm it was I2CS. I think there may have been a few things going wrong at once and I did not want to focus on all of them. Just the question of auto-detect for I2CS? Here is the log from the very first attempt that failed and hung: Wed 04/04/2012 09:48:53 PM : ---- Initializing the linked devices ---- Wed 04/04/2012 09:48:53 PM : ---- All Linked Devices are now initialized ---- Wed 04/04/2012 09:48:53 PM : ---- Add remaining devices ---- Wed 04/04/2012 09:48:53 PM : [iNST-TX-I1 ] 02 62 1C F3 17 0F 0D 00 Wed 04/04/2012 09:48:53 PM : [iNST-ACK ] 02 62 1C.F3.17 0F 0D 00 06 (00) Wed 04/04/2012 09:48:54 PM : [iNST-SRX ] 02 50 1C.F3.17 1B.FD.23 2B 0D FF (FF) Wed 04/04/2012 09:48:54 PM : [standard-Direct Ack][1C.F3.17-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Wed 04/04/2012 09:48:54 PM : [iNST-TX-I2CS] 02 62 1C F3 17 1F 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 F6 Wed 04/04/2012 09:48:54 PM : [iNST-ACK ] 02 62 1C.F3.17 1F 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 F6 06 LNK-ON (01) Wed 04/04/2012 09:48:54 PM : [iNST-SRX ] 02 50 1C.F3.17 1B.FD.23 2B 09 01 LNK-ON (01) Wed 04/04/2012 09:48:54 PM : [standard-Direct Ack][1C.F3.17-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Wed 04/04/2012 09:48:54 PM : [LNK-BGN ] 02 64 01 00 06 Wed 04/04/2012 09:49:26 PM : [ Time] 21:49:26 0(0)

While it might seem unlikely I have had the same thing happen to a dimmer in the kitchen. I am guessing the someone hit the paddle very near the bottom and also engaged the air-gap at the same time. This has happened twice on a dimmer in my home. I do not know of a way to disable it.

Thank you much LeeG, I hope to experiment with this when I have time. As it is now I use hardware jumper config in my MS's. If I could easily update the configuration without having to access the PIRs I would then use the firmware configurations option. Thank you UDI for making my PLM restore so easy in terms of automating the process. Very gracefully handled! Quite the test of ones communications reliability I imagine in some cases. I located one low battery when restore to that device failed. It was as big of a trouble as I suspected up and down the ladder though for the RF devices. It would be a very nice feature to be able to update the PIRs via a motion activation if it could be added at some point in the future?

Thanks LeeG, Now you have peaked my interest . It sounds as though you are saying that it is possible to write a link record ( or configuration updates?) to a PIR device within some window of opportunity after motion detection then? Any specifics you could possibly offer? If it is not too complicated I would like to experiment with it in my custom tester.