slcasner

@teken, I've done some searching for "four tap test" and "beacon test" in this forum and in the wiki but I did not find a reference for that test. Can you provide one?

Interestingly, that first reference includes this statement: "Likewise, certain models of GFCI outlets have also been reported to degrade INSTEON signals (this, however, is not true for all GFCIs)." So I guess my hypothesis was plausible.

Thanks for the replies. I expect that I do need to add a bridge between the A and B legs, but the reason I suspect the arc-fault breakers is that the system was working with only occasional communication problems that would probably be reduced by a bridge, then when the arc-fault breaker was installed on the circuit with the PLM, ISY lost communication with practically all the devices that depend on powerline communication. Moving to a different circuit without the arc-fault breaker restored the communication. I agree that if all arc-fault devices cause problems we should see reports in this forum. Perhaps the one I have is defective in some way. I'm hoping that the dual-function breakers I ordered don't exhibit this problem.

Has anyone had problems with the ISY being unable to communicate with Insteon devices when the PLM is plugged into a circuit protected by a circuit breaker with arc-fault interrupter function? This is a Square-D HOM115CAFI breaker. My branch circuits have all just been moved to a new subpanel as part of a solar PV system installation with whole-house backup. Initially all the breakers were ordinary, including those that were GFCI breakers in the old main panel. The Insteon devices were working, but then a CAFI breaker was installed on the circuit where the PLM is plugged in, and then the ISY failed communication with most of the Insteon devices. I used an extension cord to plug the PLM into a different circuit and then communication was restored. But all the outlets in the room where the ISY needs to be to access Ethernet are on the circuit that also has outlets outside and in a guest bath, so it needs GFCI protection. (Nevermind the fact that a CAFI breaker does not provide GFCI protection and the electrician says "that's what we use and it passes inspection". I've ordered a HOM115PDF breaker that includes both combination arc-fault and ground-fault functions to see if that works. The only HOM115PGFI without the arc-fault function that I could find was $260.)

@MrBillThanks, it seems to be behaving itself now. @smokegrubWhat you report is exactly what I saw. As I mentioned, if I dig down to the actual "ISY Launcher.app/Contents/MacOS/ISY Launcher" binary I can run that just fine. I looked at the app's Info.plist file and I see nothing there that would restrict to macOS 10.15, so I don't know how that restriction is imposed. I'm not a Mac guru. I have also used the start.jnlp file as you did, but that keeps putting an invalid alias on the desktop.

Thanks for your reply. I meant to state in my post that the lamp has a standard incandescent 3-way bulb installed. I have been using the ISY994 Administrative Console launcher 4.6.2 that I installed in 2017 even though I have updated the firmware since then. ("Why change something if it's not broke?") To access the ISY Launcher and the Dashboard I fetched the new start.jnlp which did start up the ISI Launcher and deposit an alias on my Desktop. However, that alias refuses to execute on my MacBook because I am still running macOS 10.14 as I have some 32-bit software that I need to run. I have verified that if I dig down to the actual ISY Launcher binary I can run that just fine. I looked at the Info.plist file and I see nothing there that would restrict to macOS 10.15, so I can't see how that restriction is imposed. This launcher is also less convenient because I have to select my ISY in the list of one and use the context menu to select Admin Console, whereas I can just click the 4.6.2 desktop icon and the Admin Console starts up, ready for me to log in. I already fetched https://isy.universal-devices.com/994i/4.9.0/admin.jnlp and when I ran it I did get version 4.9.0 of the UI, but it did not install a new alias on the desktop nor a new app in the Java cache. Perhaps that is because I disregarded the instruction to clear the Java cache since I did not want to lose the 4.6.2 version of the app that was working with a desktop alias.

I have a 2473 OutletLinc with a table lamp plugged in. The past two mornings I have discovered the lamp to be ON when I don't expect it to be. When I look at the status of that device in the ISY Administrative Console (v4.6.2, firmare v4.9.0) it shows the current status as OFF. The linked controller, a 6-button keypad, also did not have its button lit and the ISY indicated that the button was OFF. On the context menu for the 2473 device, I selected Diagnostics - Query Insteon Engine, but that did not correct the status. If I click the OFF button in the admin console the lamp turns off, and I can toggle the lamp on and off as much as I want. When I toggle it ON, then the current status is correctly displayed as ON. This problem arose after the circuit breaker for that device was off for 48 hours as part of testing my home solar PV system. Can Insteon devices lose some configuration in that period of time? I tried Restore Device from the context menu after I first discovered the problem yesterday, but then the lamp was on again this morning. I know about the Load Sensing feature of the 2473, but the load in this case is just a standard incandescent bulb which shouldn't do anything funny. And if the 2473 was sensing a load change and deciding to turn on, shouldn't the ISY see that and update the current state?

Just to close this out: I have purchased and installed the Smart Meter Module in my 2012 ISY994i and connection to the meter has been enabled by the utility. There are a few funny numbers that I'm trying to investigate with support on both sides, but it is basically working.

Thanks for confirming compatibility. Is there a User Guide for the Smart Meter Module that would tell me how I can use it (e.g., what methods are available to access the data).

I bought an isy994i in 2012 to control my INSTEON devices. I just heard about the Zigbee Smart Meter Module. Would my isy be compatible? I suppose there may have been some evolution over the past 9 years. Is there a User Guide for the Smart Meter Module? (I don't see a Documentation link on the website.) I would like to automatically pull meter readings for my records. I've been reading my meter visually on a daily basis for years, but it would be nice to do that automatically.

Sadly, I have to conclude that my capacitor replacement repair was not a complete success, but that may be because the problem with the PLM was not a failure of the power supply in the first place. This PLM never got into the state where the LED was red or dark. I replaced it with a new one in 2016 because programs were occasionally failing to do what they were supposed to do, that is, the ISY was sometimes unable to control some devices. Power cycling the PLM seemed to help for a while. Now, after replacing the capacitors in the unreliable PLM it seems to mostly work, but after a time the admin console was popping up error messages about being able to communicate with one or another device. When I swapped back in the newer PLM, it was able to communicate with all devices. Going back to the repaired one, it took multiple executions of the Restore Modem operation to get through to all the devices, and there still was one that it could not reach. I tried this with the PLM plugged into outlets in two different rooms (but not sure if they were on different halves of the panel) to try to make sure I could get through to all the devices so they would be linked to the PLM. So, even though this repaired PLM mostly worked in my system (all the timed lights still worked), it could not communicate as reliably as the newer one. Perhaps some component other than the capacitors has failed or degraded. Perhaps RF is not working well (I did put the antennas back into their original positions after the repair). I have more sets of capacitors, so if the newer unit fails I will try again.

I recently did the capacitor replacement repair on a PLM that had failed. It did not work initially because I just did the Restore Modem operation without having power cycled the ISY because I did not realize that was required. I have relied on the User's Guide document as my primary reference, but it provided no guidance. Finally I found this thread, then it worked. Why doesn't it describe the PLM replacement procedure? It doesn't even explain the Restore Modem command. Better yet, why doesn't Restore Modem cause the ISY to go read the PLM ID first?

Thanks for your help. You hit on the right answer, although I coincidentally found it myself earlier that day after searching the forum for information about PLM replacement. I had not powered off the ISY because I did not realize that was required (it has been a while since I replaced this PLM before). That is why the devices had the wrong PLM ID and why the Restore Modem operation finished at only 7% on the progress register. When I did the full recommended procedure (#1) then the Restore Modem operation took much longer to rewrite all the devices. I have relied on the User's Guide document as my primary reference. Why doesn't it describe the PLM replacement procedure? It doesn't even explain the Restore Modem command. Better yet, why doesn't Restore Modem cause the ISY to go read the PLM ID first? The repaired PLM has now been operating fine for a day, so it looks like the capacitor replacement was successful. I'll leave it in place to see if there are any indications of the instability that caused me to replace it before.

Hmmm, the suggestion to check the device like table is a good one, except that ISY can't read the device link table, either, which I guess is not surprising. After putting in the questionable PLM and doing Restore Modem, I get the following when trying to read the keypad's link table: Fri 02/02/2018 05:05:44 PM : [iNST-TX-I2CS] 02 62 1E 02 E7 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Fri 02/02/2018 05:05:44 PM : [iNST-ACK ] 02 62 1E.02.E7 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Fri 02/02/2018 05:05:45 PM : [iNST-SRX ] 02 50 1E.02.E7 1E.47.4F AB 2F FF (FF) Fri 02/02/2018 05:05:45 PM : [std-Direct Nack] 1E.02.E7-->1E.47.4F, Max Hops=3, Hops Left=2 Fri 02/02/2018 05:05:54 PM : [iNST-TX-I2CS] 02 62 1E 02 E7 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Fri 02/02/2018 05:05:54 PM : [iNST-ACK ] 02 62 1E.02.E7 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Fri 02/02/2018 05:05:54 PM : [iNST-SRX ] 02 50 1E.02.E7 1E.47.4F AB 2F FF (FF) Fri 02/02/2018 05:05:54 PM : [std-Direct Nack] 1E.02.E7-->1E.47.4F, Max Hops=3, Hops Left=2 Fri 02/02/2018 05:06:03 PM : [iNST-TX-I2CS] 02 62 1E 02 E7 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 Fri 02/02/2018 05:06:03 PM : [iNST-ACK ] 02 62 1E.02.E7 1F 2F 00 00 00 0F FF 01 00 00 00 00 00 00 00 00 C2 06 (00) Fri 02/02/2018 05:06:04 PM : [iNST-SRX ] 02 50 1E.02.E7 1E.47.4F AB 2F FF (FF) Fri 02/02/2018 05:06:04 PM : [std-Direct Nack] 1E.02.E7-->1E.47.4F, Max Hops=3, Hops Left=2 I should make clear that the problem is not just this keypad; there are several devices I can't control with the problem PLM. If I compare the event logs for the Restore Modem operations on the good and bad PLMs, they are identical. Is there some other step that is supposed to be done to tell all the modules about the new PLM?

I mentioned that the output of Show PLM Links Table was identical for the two PLMs. Is your suggestion to check the PLM's ID shows up in the Device Link Table for the devices that are failing to be controlled? Is there a reference to tell me how to interpret the logs in the Event Viewer and the Links Tables? BTW, I bought an inexpensive LCR tester that tells me the EKXM500ELL101MHB5D caps I bought for C7 and C13 are low ESR as claimed: 0.02 ohms. One of the two 10uF 35V originals that I removed shows an ESR of 41 ohms, but I don't know how much damage may have been caused by the desoldering process.

I have done my first PLM capacitor replacement repair, on a 2413S V1.7 1222 that wasn't communicating reliably but still showed a green LED, with mixed results. I ordered from DigiKey: Digi-Key PN Mfr Part Number Manufacturer Description 399-6538-ND ESG106M400AH4AA KEMET 10uf 400v replaces 6.8uf 250v 493-3276-ND UTT1E101MPD Nichicon 100uf 25v replaces 100uf 25v 565-1598-ND EKZM500ELL101MHB5D United Chemi-Con 100uf 50v replaces 10uf 35v 493-10390-1-ND UTT1C100MDD1TP Nichicon 10uf 16v replaces 10uf 16v The assembly process was relatively straightforward. The 10uF 400V cap is much larger than the original but actually fits the hole spacing on the PCB whereas the original cap's spacing was narrower. I put in the larger 100uF 50V caps lying down, as Smarthome does in the newer revs, but I observed that I needed to push C7 to be parallel to the bottom edge to avoid hitting the modular connector for the cable (photo below). I think these caps might fit better standing up. When I put this repaired PLM in place of the operational one to test, the green LED still lights. After doing Restore Modem I can control some devices but not others. In fact I got a "can't communicate" for one keypad that I tried; resetting the keypad restored communication, but I still could not control it. In the log I see: Mon 01/29/2018 01:35:17 PM : [iNST-TX-I1 ] 02 62 1E 02 E7 0F 11 FF Mon 01/29/2018 01:35:17 PM : [iNST-ACK ] 02 62 1E.02.E7 0F 11 FF 06 LTONRR (FF) Mon 01/29/2018 01:35:17 PM : [iNST-SRX ] 02 50 1E.02.E7 1E.47.4F AB 11 FF LTONRR (FF) Mon 01/29/2018 01:35:17 PM : [std-Direct Nack] 1E.02.E7-->1E.47.4F, Max Hops=3, Hops Left=2 This Nack is sent right away every time I try to command the keypad on or off, so it is not a timeout problem. What does this mean? When I did the Restore Modem operation I was concerned because the progress register advanced only to 6% before the popup disappeared. But when I switched back to the working PLM and did Restore Modem again, the behavior was similar (perhaps 7%). But the log of the restore operation is identical and the result of Show PLM Links Table was identical for the two PLMs. Since I can successfully control some devices and not others, perhaps the repaired PLM is only able to communicate with RF or powerline but not both, and the devices that I can't control were depending on the other mode? Is there a way to investigate that hypothesis? Other debugging suggestions welcome.

Brian, thanks for the advice. Here's a picture showing my old 1.7 and new 2.4.

I'm about to do this capacitor replacement on a 2413S V1.7 1222 that didn't fail all the way (the LED still goes green) but programs would fail to execute. Power cycling seemed to help, but the problems repeated. I replaced it with a spare in 2016. Not all of the original replacement capacitors are still available. Mouser shows the ESX106M400AH4AA 10uF 400V in stock, but KEMET does not show that as a current product (the ESX series does not go up to high voltages) so DigiKey does not have it and I can't find a datasheet to compare. (I prefer DigiKey because I have an account.) Is there a recommended alternative? DigiKey has KEMET's has ESU106M400AH4AA at 10000 hours for "electronic lighting and power" applications and ESG106M400AH4AA at 5000 hours for "electronic ballast, power supplies and long life" applications. Does either application suggest a preference? The ripple current at 120Hz is 90ma for the ESU and 100ma for ESG; the ESU has no ESR spec while ESG is 2.9ohms, while both specify and impedence ratio 5. The ESG is rated 350V / 400V surge rather than just 400V like ESU. The physical size for both is 10mm diameter, 20mm length, and 5mm lead spacing. This is 1mm longer than the ESX, but it looks like there is room. I see several posts upstream that cdragon chose the Nichicon UPW2G100MHD1TO from Mouser instead. Also, is it a good idea to replace the original 10uF C7 and C13 in an older 2413 with 100uF as in the newer revisions, and if so, is the recommended part still in the KY series (EKY-500ETD101MHB5D)? I wondered if there was any other component value change that would need to be coupled with the capacitor change. I just bought another spare 2413 (prompted by the 30% off offer from Smarthome) and I see it has the 100uF capacitors still mounted lying down on the board even though it looks like the board layout was changed to allow at least C7 to be installed standing up. I can't tell if the inductor is the same, though; it looks the same as in the old unit but there are no markings I can see on either one.

I have downloaded the american.zip file from the wiki that contains the american.isy file containing programs to import. These programs contain schedule conditions for some common American holidays for the next several years. I'd like to creates some similar program conditions using other programming tools to then import into the ISY. Is there an XML schema available to describe the format of a program import file?