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.