IndyMike

@pwmcmaho, an easier way to look at the device links (and compare them): "right click" on the device in the admin tree. This should bring up a menu that includes "diagnostics" (1st graphic below). Select "Show Device Links Table" and the ISY will read the Link Table and present all of the stored Links (second graphic). At the bottom of the displayed table is a "Compare" button. Select this and the ISY will display a second table of what I believes "Should" be in the device. It will also highlight discrepancies. If you can post tables for a device, we should be able to determine whether they are configured correctly. The above is the process, However, the PLM table that you posted contains only 21 links. That's simply not enough links. Either something went south during the upgrade process, or you had a bad backup. Please re-try the PLM replace using the procedure that @Techman posted. If things still don't work, we'll assume that backup is bad and revert to an earlier backup.

Flashing Red is normally an indication that a controller can't communicate with a scene responder. Depending on the size of a scene, it can take significant time for the controller to send cleanup messages to each scene responder. If retries are required, the time grows longer still. Additional button presses while the controller is attempting to executing cleanup communication will likely result in the controller abandoning the activity. This could also result in the controller "flashing" an error.

I am using a Zooz ZAC38 (Z-waver) repeater to monitor a problem GFCI circuit for nuisance trips. The device has battery backup and informs my HomeAssistant install when AC power drops out. @Techman is using the same device on the EISY, so it is supported. https://forum.universal-devices.com/topic/44418-anybody-tried-the-new-zooz-zac38-repeater-with-power-outage-alerting/

@paulbates, thanks for the thought... After re-reading my post I clarified to point out that it's been a lean month AT HOME due to changes in phone carriers. Family members always have the right to disagree - and my family exercises that right often.

@CoolToys, are you saying that you have a Tesla Powerwall and an Inverter? If that is the case, take my suggestion of moving the PLM to the main panel with a grain of salt... As shown in the other threads, the Powerwall generates noise that appears to be close to the Insteon frequency. It MAY also generate noise near the 60Hz zero crossing - that's a double whammy. Given that the Powerwall is likely tied into your main panel (or sub), you want to put some distance between the Powerwall and the PLM. Line length = Inductance = noise attenuation.

@paulbates, thanks so much for getting back. It's been a rather lean month for me on the home front. Turns out switching phone carriers and devices isn't to everyone's liking. Very few "atta boys" and a number of the opposites to cancel them out (tough crowd). Glad to hear that something worked out.

I'm going to echo @Brian H's comments. I do not have a workaround. This has been requested in years past, and it's likely on a "to do" list somewhere. Unfortunately, it's a long list... As a test, I did try manually linking a 2456S3 Appliancelinc as a 2457D2 LampLinc. This would have allowed me to replace the existing LampLinc with the ApplianceLinc. In short - I lied to the ISY. The ISY994 correctly identified the ApplianceLinc and linked correctly for the device. In other words, the ISY outsmarted me. When the UDI team first came out with the Replace feature, it was a boon to the community. SmartLabs devices were having some teething issues with power supply and paddle switch failures that mandated early replacements. KPL power supply issues were particularly painful. Replacing an 8 button KPL could easily wind up being an all day affair depending on the number of scenes and programs involved. The ISY (ISY26 or ISY99??) paid for itself the 1st time I used the replace feature. While I'll admit that there have been times where an "unrestricted" replace might have been useful, these were few and far between. The UDI team has done many amazing things given their resources but, in the end, they are a small shop. Since the early Insteon days they have branched out to Z-wave, Zigbee, and now Matter. Focusing on new device definitions for the expanded protocols (likely) has much higher ROI.

Have a look at the Lutron white paper below. It goes into details on the types of powerline noise that can cause flicker in dimmers. One of the big offenders is noise at the zero crossing. Since Insteon communicates at the Zero crossing, noise at that point would absolutely detract from communication. In summary, the Inovelli devices you chose communicate well because to don't need the powerline (RF only). They don't flicker because they have a good powerline filter to provide consistent drive levels to the triac. https://assets.lutron.com/a/documents/power_quality.pdf

@CoolToys, It sounds like you have a lot of equipment that would be capable of absorbing/interfering with Insteon signals. My 1st suggestion would be to relocate the PLM as close as physically possible to the main panel. The panel is the Nexus of your electrical system and is (normally) the most stable/quite point. Even a temporary install can be extremely instructive. Edit: In addition to the PLM at the main panel -make sure you couple the phases at the panel... Place a dual band device (LL, APL, or range extender) on the opposite phase nearby the PLM. I would also be leery of installing the PLM on the same circuit as your A/V rack. Audio equipment incorporates very good powerline input filters. Unfortunately, many manufactures don't isolate the filters from the input - and they absorb powerline communication as a result. In other words, you may need filterlinc's (or something similar) to isolate your A/V equipment from the powerline.

@jkraus, I don't have a Powerwall but I've used the Zooz Zen77 dimmers (Z-wave) in a number of problem installs where flickering was an issue. They are rather inexpensive compared to Insteon and can be used with mechanical switches in 3-way configurations (no need for slave switches). Since this appears to be an overall "power quality" issue affecting dimmers in general, Lutron would be another option (smart or otherwise). If shopping for Lutron, look for devices that incorporate RTISS (Real Time Illumination Stability System) https://assets.lutron.com/a/documents/power_quality.pdf

@CoolToys, sorry to hear you still have some gremlins running around. Your failed scene is rather curious. The 2476D dimmer is likely powerline only. Surprising that it's the one that responded. The KPL's (V.43 and V.45) are dual band. Would have expected those to have responded. The difference between the 2476D that responded, and the KPL's that didn't, is the path that your scene command took from the PLM to the devices. The path to the 2476d is from your PLM, to the panel, and then to the 2476D circuit. The path from to the KPL's is complicated since it uses RF. It should be better due to the dual band capability. Unfortunately, this isn't perfect. I've seen dual band devices Ignore RF communication due to a low level (below noise level) insteon signal on the powerline. My advice would be to investigate the circuit the KPL's are on for signal absorbers/noise. Beyond that, you can use the "scene test" to determine whether "verification" would help here. The scene test uses the Insteon standard method of activating a scene/interrogating the responders. The PLM will poll each device to determine if it responded correctly. If it does not, it will re-try up to 5x. In my experience, the "scene test" shows failures that do not exist with standard ISY scenes. Beyond that, we may need to understand your "house" configuration (plm placement, home sq footage, #' panels, number of devices, other "problem devices") to go forward.

@JJJ, you are correct. While there is a "feature" in the ISY programming to allow you to set a scene to a specific level, it doesn't work. Turning the scene on to any level above 0% will simply execute the scene command at the stored device on levels. Turning the scene on @0% will turn the scene off. Insteon protocol does allow for scenes to be turned on to a level. This feature may have been removed previously when other devices (Z-Wave) started to be included in scenes. https://forum.universal-devices.com/topic/25805-is-set-scene-on-possible/

Device level retries as explained be LeeG: Understanding Retries in ISY

I'm thinking you may have mis-stated things here. You can't activate a scene by turning one a Controller from the Admin Console. That will activate the controller by itself. You have to activate the "Scene" from the admin console tree (or a program). If this was the case, we need to start looking for noise/signal absorbers on the responder circuits.

Are these scenes locally activated (device) or activated from the ISY? Very different scenarios. Device activated scenes will attempt to determine the status of the responders. The ISY will not.

Right click on the program and "Export" to a file, or "Export to Clipboard". You resulting file is a jumbled mess. You can manually insert carriage returns using clipboard, or find a quick XLM viewer on the web.

I'm sorry, I'm not being clear... The following is my guess based on my recent experience with the ISY994 - Your program is not triggering properly because it is not saved properly. Said differently, the program that you posted is not what is saved in XML. It was corrupted some time back and "updating/re-saving" is not changing/fixing the corruption. I saved and copied my program several times to no avail. The XML was still wrong. When you re-save, you are resetting the "last run" status and the state (true/false) of the program. It's possible that is allowing the program to trigger once. Can't tell you why without seeing the XML. I don't understand what I did to screw up my program. It was an isolated case. I had been editing the program frequently throughout the day. The program is very long with numerous embedded waits. Suddenly it began to execute things that I couldn't explain. That's what drove me to look at the XML code.

@dbwarner5, another possibility is that your program became corrupted. I ran into this a week ago and had a difficult time finding/fixing the problem. My program is shown below next to the actual XML that my ISY994 was running. They didn't match. The RED scene control is incorrect in the XML. What I saw in the program editor was correct and no number of saves, copy to a new program and saving, etc would correct it. I corrected the program by deleting the "Set Basement/ SC Basement On" statement, saving the program, and then adding the statement back. My example dealt with a "then" action that was incorrect. I could SEE that the program was turning on the wrong scene. You may have a corrupt "IF statement". That would be much more difficult to determine. You could export the program XML and inspect it for errors (somewhat painful), or simply rewrite the program. Program Program XML If <if><and /> '19.21.5C.1' is switched Off <control id="DOF" node="19 21 5C 1" op="IS"></control></if> Then <then> $FirstDining.On = 1 <var id="11" type="2"><op>EQ</op><val prec="0">1</val></var> Wait 5 seconds <wait><seconds>5</seconds></wait> Set 'Basement / SC Basement' On <cmd id="DON" node="46453"></cmd> Wait 23 seconds <wait><seconds>23</seconds></wait> $FirstDining.On = 2 <var id="11" type="2"><op>EQ</op><val prec="0">2</val></var> Set 'Basement / BSMT Back Room' Off <cmd id="DOF" node="B B7 F8 1"></cmd> Set 'Basement / BSMT Back Room Load' Off <cmd id="DOF" node="16 5C BF 1"></cmd>

@DerekL, happy to hear that your earlier backup is working better. That rules out a hardware or (current) firmware problem with your EISY. I would still encourage you to submit a ticket. It's possible that your more current backup could be recovered. It is also possible that the backup was saved under a firmware version that had an issue - this would be a new item. In either case we (as a community) and UD learn when documented issues like this arise.

@DerekL, I went through your Event Log and agree with your assessment (thanks for posting) - things appeared to go rather well during the update. You have good communication, and the two devices that experienced NACK errors were corrected by the ISY. Unfortunately, that's not the end of the story. The link table shown below is what I pulled from one of my device that is linked to the PLM ONLY. No scenes whatsoever. As such, it has the Minimum number of links for any Insteon device. Link 0 @0FF8 is a responder link to the PLM @53.BC.3A. This is group 0. Link 1 @0FF0 is a controller link to the PLM @53.BC.3A. This is group 1. When I activate the device manually, this link is used to communicate back to the PLM. In going through your event log, I found many devices that had only 1 responder link to your NEW PLM. The result would be exactly what you are observing - you can control the device, but the device isn't communicating changes back to the PLM. This should not happen. The following devices are a few that show this error (there are many). If you perform a link table read on these devices they should show only 1 record (or 2 if you count the last 00 record). Furthermore, a compare should show that the ISY believes the link table is correct. If this is the case, the only thing I can think of is that you restored the EISY from a bad backup. Restoring again from a different backup would hopefully correct things. The alternative would be to factory reset/re-link all affected devices (a rather large task). If you believe that your backup is valid, I would encourage you to open a ticket with UD. They may be able to look at your backup file and determine where things are going awry. Minimum Device Link Table Edit: After reviewing your log a bit more I've realized that the EISY did not write Any controller links to Any of the 65 devices in your installation. That's rather bizarre. None of your devices can control anything else. At this point any recommendation I might have would be a SWAG and a waste of your time - please open a ticket with UD.

@tporada, if you are using Zwave and Zigbee dongles, conventional wisdom is to use a USB extender to put some distance between the dongle and the Hub. My experience is with a Raspberry PI, but I would think the same would apply to the EISY unless it's shielded. A second comment in regard to Zigbee - it can be challenging to use in a WIFI environment. Zigbee frequencies overlap many of the WIFI 2.4 GHz channels. There are a number of sites that give instructions on how to change the Zigbee channel to avoid crowded WIFI channels. I do not know how to do this with the EISY. There are also apps that you can download to your phone to identify what channels are in use in your vicinity (I use WIFI analyzer). Best advice is to move as many things to 5Ghz as possible to avoid interference, then change 2.4GHz zigbee/WIFI channels as necessary.

I own the same mirror. Daughter #2 is an hour down the road. We know the area well and regularly bike the parks there as well as the Kal-Haven trail. Daughter #1 is truly in the great white north. I've spent a little time in Houghton in my youth. Have not been to Marquette. Given the proximity, I'd guess it's white and cold this time of year. Don't go out without snowshoes and heated whatever-you-can-get. Best of luck.

Let me know how things work out. Curious if it will meet the DAF (Daughter Approval ...). My automation suggestions for my Daughter have been about 50% successful. In retrospect, that's probably better than my WAF%. February is a tough month for visiting the great white north (UP?). I wake up every morning ~ 300 yards South of the MI line. Very good to have indoor projects. Thankfully the IN State line deflects all the bad weather back to the North.

@someguy, as @paulbates indicated the ISY provides a Option box for enabling the Blink on Tx for most devices. @MrBill had a nice post on the subject here: https://forum.universal-devices.com/topic/35258-blink-on-insteon-traffic-setting/#elControls_330388_menu The option has been around since at least 2015. From what I can see, it's available on all of my V.45 and newer KPL's, SWL's, and plug in devices. Earlier devices are hit and miss. As it turns out, Blink on TX is the same as Blink on Traffic since all modules repeat Insteon traffic. In looking at your original post, I noticed that a number of your problem items were named "Malibu" and all seemed to be associated with outdoor devices. I tend to associate Malibu with low voltage lighting (maybe incorrectly). Is it possible these are low voltage applications on outdoor GFCI circuits? Any photocells on fixtures? The presence of GFCI's, LV transformers, and/or photocells can send troubleshooting in different directions (boosting vs filtering vs isolating). Would you mind describing your problem circuits a bit more (indoor/outdoor, load type, GFCI, fixture type)?

@paulbates, I have just enough Google Home knowledge to be considered dangerous. I'm thinking that it's natively a WIFI based system (that can interface with other bridges). If that is the case, you may want to look at something like the following: Linkind Remote Bulb Kit. It's inexpensive and interfaces with Google Home. The battery remote is not my cup of tea, but I've learned that my daughters taste in these things differs somewhat from mine. Not sure how you are planning on routing power to the ceiling, but that's another item...