IndyMike

@Algorithm, Ive been bitten by this a number of times in the past. Typically occurred after a power outage. I don't have a solution for the button being re-enabled. What I can offer is an easy method for updating motion sensors (actually this is all UDI). Some time back UDI gave us the ability to write updates to sensors when they detect motion - BSMT Sensor Program - [ID 004A][Parent 0066] If 'Motion/RF / BSMT-Sensor' is switched On Or 'Motion/RF / BSMT-Sensor' is switched Off Then Set 'Motion/RF / BSMT-Sensor' Write Changes Else - No Actions - (To add one, press 'Action') Works like a charm. I normally keep the program(s) disabled and re-enable when I notice a pending write... I also keep the automatic writes to battery devices disabled (until they reset).

This works for Insteon motion sensors. Does it apply to Zigbee/Z-wave?

Months of troubleshooting would wear anyone down. Hope that glow of success lasts you a good long time.

No worries - the EA record is an artifact of the I2CS protocol. Your device is fine. https://forum.universal-devices.com/topic/15336-device-links-table-corrupteds/

Tracking down communication issues using the breaker method was far easier in the X10 days. With the repeating capability + RF of Insteon devices, there is normally not a single offending device. Instead it's a combination of signal absorbers + noise that causes issues. One rule that normally applies: If you are having problems with a few devices - inspect the circuit. If you have having problems with many devices, inspect the PLM circuit or the PLM itself. Moving that PLM to the breaker panel is optimal. The panel will normally be the lowest noise point with best electrical access to all points of your system. A RF coupling device installed on the opposite phase near the panel is also highly advisable (or passive coupler). Using a program to test communication is valid as long as you are not turning on/off scenes (which you obviously are not doing). The ISY does not test the status of devices in a scene on/off command. You can use a program to query a scene. You can also query scenes from the Admin Console by right clicking the scene. Your poor RF performance is interesting. Have not seen that reported previously. Is it possible that you had a 900Mhz interference device nearby? If this is true, your problems may have stemmed from the fact that you were not coupling the phases due to poor RF performance. You could retry linking a RF device with the PLM near the panel to confirm. If the poor RF persists (and there are no obvious interference sources) I would consider replacing (returning if possible). There are workarounds, but you really do want your PLM to communicate/couple via RF.

@paulbates - My apologies, I misunderstood your comment. The program that @Michaelv posted was already using scenes. From his comments my understanding was that the program was not triggering correctly for some reason.

75 devices in a scene is not a problem. Your "My Lighting" is essentially a scene. Your ISY queries it every night at 3:00 AM using the Schedule 1 program (unless you have modified it). Schedule 1 - [ID 0005][Parent 0002] If From 3:00:00AM For 10 minutes Then Set 'My Lighting' Query Else - No Actions - (To add one, press 'Action') Alternatively, I would not create a large scene and assign a Device as a controller. The device (switchlinc, KPL, Etc) will execute the Scene ON command that I posted above, but will then perform "group cleanup commands" to every device in the scene. For a large scene, this can take quite a long time. When your device flashes red, it is trying to tell you that it was unsuccessful in communicating with a scene member. A device can only be a controller for 1 scene (except for the PLM). A device may be a responder to many scenes.

I'm sorry, but I respectfully disagree... The ISY uses a rather specialized method of controlling scenes - it does not perform "group cleanup commands". In order words, it does not request scene devices respond to the scene command. The ISY ASSUMES that the scene command was properly received and acted upon. The following is a copy of the event viewer when I turned off my basement scene (group 00.00.27). There are 17 devices in the scene. NO status or confirmation is requested from any of the devices. Sat 07/06/2024 09:37:22 AM : [INST-TX-I1 ] 02 62 00 00 27 CF 14 00 ISY Command to PLM Sat 07/06/2024 09:37:22 AM : [INST-ACK ] 02 62 00.00.27 CF 14 00 06 LTOFF-F(00) PLM Acknowledge I could just as easily have replaced group 00.00.27 with 00.00.FF and turned on every device in the house. As a result, there should not be an issue with "chaining" multiple scene commands together. There is no return traffic that would create a collision. Device Direct commands do request a status. As a result, there is a possibility of a collision. Older discussion of scenes and retries: https://forum.universal-devices.com/topic/11690-understanding-retries-in-isy/

@MrEstateManager, I looked though the PLM record file you provided hoping to understand what happened. I am no smarter as a result. I imported your XLM table to Excel (left side) and then converted to HEX (right side) below What I did learn - You have 65 link records - they are all to unique devices. All of the records are for group 0, with the PLM as the controller (flag E2). There are no devices listed as a controller for the PLM (flag A2) and no scenes listed. The device that you showed above as non-responsive (Entry cans @40.CF.51) is included in the table. This is likely a I2CS device that is missing the PLM link and refuses to respond as a result (security reasons). Because you have no scenes listed in your PLM, you will not be able to control them. Because you have no devices listed as controller for the PLM (flag A2), no devices will be able to control the PLM (can't fire programs with a button press, device initiated on/off tracking won't work). In short - that's a very messed up PLM. The second set of figures shows my plm with various groups (scenes) and control records from different devices. If I had to guess, I'd say that you had a partial PLM restore and possibly an erroneous backup. You could go back through your older backups and try to find a good one to restore from (ISY Restore). You may need to restore your PLM after the ISY Restore. https://forum.universal-devices.com/topic/3999-how-do-i-replace-my-isyplm/?do=findComment&comment=30953 In any event, the most expedient route would be to follow @hart2hart's advice and create a support ticket.

Sorry, I thought you were looking at the Aqara FP1 which uses Zigbee. The RPI 5 + Sonoff Zigbee bundle looks nice for that. The Aqara FP2 is WiFi based. Home Assistant can integrate WiFi without any additional hardware. You could choose any of of the bundles (RPI 5 or ODROID). I personally do not use WiFi for automation devices. That's why assumed you were referring to the Zigbee model.

@vbPhil, There are some nice turn-key options on that site. I actually like the RPI 5 with Sonoff Zigbee since it would give @Blackbird a working Zigbee solution out of the box. I'm assuming that Ameridroid integrates the Zigbee dongle - that would be a good question for them. A SSD could be added at a later date. Unfortunately - the RPI 5 is out of stock.

I started with a PI 3 (adequate). Currently running a Canakit PI 4: https://www.amazon.com/gp/product/B08956GVXN/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&th=1 I do not have experience with the PI 5. It does appear to have some nice SSD support features. You will want a SSD at some point. You can add a USB SSD to the PI 4 but it's not natively supported. Don't spend a lot of money on a kit with a fancy case and a large SD card as the SSD will obsolete both (most Kit cases will not support a SSD). Downside is that support for the PI 5 is as of Feb '24. There will undoubtedly be growing pains and hardware support issues. https://www.home-assistant.io/blog/2024/02/26/home-assistant-os-12-support-for-raspberry-pi-5/

It looks like the Aqara FP1 is Zigbee. You can certainly set up Zigbee on Home Assistant but there is a learning curve. You'll be watching YouTube videos and reading forum posts for a while. I am currently running: Universal Devices ISY/IOX Integration - very easy installation. I linked to instructions above. ZWaveJS2MQTT Integration - next step up on the learning curve. I've been using the Zooz 700 series devices and USB controller. Pretty decent support on the Zooz site. ZWave_JS integration Zigbee2MQTT Integration - I found this setup difficult. Using a Sonoff USB stick + Aqara Temperature sensors and Power monitoring devices. Very cryptic setup of the Sonoff USB stick was probably complicated by the fact that the Stick and the Zigbee2MQTT integration were rather new when I was attempting it. Things are a bit better now. https://www.zigbee2mqtt.io/guide/getting-started/ You will be able to use the Aqara sensor to trigger programs to turn on/off Insteon devices (individuals) or Scenes. For either Z-Wave or Zigbee you will need enough devices to form a reliable mesh. I can't tell you how many devices that will be. One additional consideration is the fact that Zigbee can interfere with Wi-Fi. I spent a fair amount if time changing the channel of my USB stick (to channel 24) to find a less crowded range of operation. I also moved most of my WIFI devices up to the 5GHz range. As I'm writing this, I just realized that I have a Zooz motion sensor that is triggering an Insteon On/Off module. Probably not to dissimilar to what you are visualizing with the presence detector. The program itself is stupid simple. It's the journey that can be interesting. Zigbee Device network Z-Wave Device Network

I am using the ISY994 with Home Assistant. When initialized, Home Assistant "Receives" node information from the ISY. Nodes are typically presented as "cards" in Home Assistant (example below). You can control nodes (and scenes) directly from the "card" or you can write programs to turn on devices within the ISY994. I am not sure that it's possible to control Home Assistant devices from the ISY. You can write Home Assistant programs to respond to ISY actions. Clear as mud right? Documentation: ISY Integration on Home Assistant

So you posted a program and logs from actions that you knew WOULD NOT WORK. Thanks for including that little detail in your post. Have a nice life.

Your program is written to trigger on "FAST ON". You are executing a standard "ON" at the switch.

Both of the previous responses are correct - you can reset the devices and manually link them. That is the safe method. There may be another method. Whether it's easier or not depends on your installation. The old ISY994 had a option to "delete modem" (file\delete modem). This purportedly removed the PLM links from all your installed devices. I have never tried it. I am also not sure this still exists in the EISY. IF you try this, you will still need to plan out your removal process. Since you will be removing some devices, you'll want to make sure they are not part of the scene that your N-way devices are controlling. You would need to remove these devices from any scenes that include your N-way devices. Again, the safe method would be to delete these devices from the ISY entirely. Once you have the system operating correctly with ONLY the N-way devices and the PLM, then you can try the "delete modem". If it works, it should leave your "N-ways" intact with no connection to the PLM. ...if it doesn't work you'll need to factory reset and link manually. The one thing I would NOT do is leave the PLM. It's an unnecessary piece of hardware that has a higher failure rate than the devices themselves. If it dies, gets removed, or just has poor communication, you are right back to the "flashing red" N-Way. Last thought - are you sure that you will be able to communicate between your N-Way devices when you remove ALL YOUR OTHER INSTEON devices? My answer for my own home would be NO.

@matapan, The best Insteon diagnostics that I have seen over the years were provided by SmartLabs Houselinc. There was a signalling diagnostics feature that would allow you to repetitively test your devices. Houselinc is no longer supported but can still be downloaded and works with 2412S, 2413U and 2413S PLM's. Words of caution - Houselinc must be setup on a SEPARATE PLM from your ISY setup. You will need to link devices to Houselinc and it's PLM in order to test them. This will produce link table mismatches for the ISY. It may (on I2CS devices) render the device unreachable by the ISY. Restore can be used to repair link table mismatches. A re-link is required for the devices that can't communicate. Some devices may not be configured in Houselinc (I3 devices definitely not). Houselinc Download Signaling Diagnostics PDF The following shows an example of the testing that can be performed. I was attempting to demonstrate the importance of PLM placement. The test shown was setup to resemble a typical SCENE command as the ISY would perform it. PLM installed near my desktop computer 6 devices tested - 100 reads on each Start Hops set to 3 PLM retry OFF (similar to scene command). As shown in the Success% column, 3 devices showed "poor" communication with success rates in the 60% range. The summary table shows the results of changing the HOPs, PLM retries, Message Retries, and PLM Location. Conclusion - the PLM location was the largest determining factor in the communication success rate. It's not AI, but it's the best tool that I've seen for Insteon.

@John Chen, the simple answer is "NO". In my opinion, there is nothing better than the ISY for managing Insteon devices. Like you, I use the ISY994. When I get to the point where I need to replace it, I'll upgrade to the current Universal Devices product (likely the EISY). I use Home Assistant for managing my Z-Wave and Zigbee devices. I would not suggest using Home Assistant to replace the ISY for Insteon. From what I understand, you will loose a lot in terms of scene management. I have no doubt that Universal Devices will be able to solve your issue - they really are quite good.

@Kevin Connolly - The direct answer to your question is the PLM transmits on the powerline @131.65 KHz I have not personally used Insteon alongside Powerline Networking. The DHP-P701AV that @vbPhil posted appears to use Homeplug AV2. It's rather high frequency. Wikipedia indicates that Homeplug has carriers from 2Mhz to 30 Mhz. The AV2 version is higher still. Being a minimum of 15x higher in frequency, the AV2 should not interfere. https://en.wikipedia.org/wiki/HomePlug Interestingly, Homeplug transmits on the neutral connector. That means there should be no issues with communicating with devices on both electrical phases (they share the common neutral). It also means that if you do encounter an issue, traditional filters will not work. A quick google does not show issues between the two: https://forums.homeseer.com/forum/homeseer-products-services/general-discussion-area/65338-insteon-powerline-av-homeplug

@Jimbo.Automates, Your issue sounds suspiciously similar to one encountered by @John Chen - https://forum.universal-devices.com/topic/43645-is-my-isy994-done/ Do you happen to use Google Home as described in John's post?

@John Chen, I do not use the web portal or google Home. I can't troubleshoot this from my end. Your description definitely points to a problem with the google home connectivity. I did not realize that affected links in hardware devices. I have been seeing an increase in the number of posts about devices that mysteriously become unavailable and require re-linking. You may have uncovered the cause. My apologies for the short hand. UDI = Universal Devices Inc. You can submit a support ticket here : https://www.universal-devices.com/contact-us/. Please do make sure to inform Universal Devices of this issue. It likely affects many others.

@John Chen, the following is an example of what I believe is happening in your system. The link table shown is from one of my newer Switchlinc dimmers (similar vintage to your device). These are I2CS devices that must be "INITIALIZED" during the linking process. If they are not initialized, they will respond with the NACK that you are seeing. The highlighted row is the "GROUP 0" responder link back to my PLM. Without this link, the device will refuse to respond to "Device Direct" Commands from the Admin Console (On/OFF/Fast ON/Fast OFF etc). The remaining links are to scenes that the device is assigned to. I believe that your Group 0 link is being overwritten for some reason. That would produce the NACK that you are seeing and would prevent the device from responding to "Direct Commands" from the admin console. Re-linking with the "set button" could restore this link. Assuming the other link records are intact, your device would still be able to respond to scenes and communicate manual kepreses back to the PLM. This would explain why you could control the device through scenes, but not directly from the Admin Console. The device would not respond to a "Restore" since the Group 0 record is missing or corrupt. Unfortunately, I do not understand HOW this is happening. I am assuming that this is happening on multiple devices. That means it's not an isolated device failure. The communication in your current location also appears good, so a failing PLM does not fit. Do you have another Insteon controller in your system (houselinc or Insteon Hub) that might be writing to these devices? If you don't have a second controller in your system, I would suggest that you open a ticket with the UDI team. What you are seeing is not at all normal.

@John Chen, the NACK is the device indicating that it is no longer linked correctly to the PLM. I am not well versed on the "Google home linking". It appears that this linking process "broke" the link table in your device. The following looks good with good communication (hops left 2 or greater) The following has good communication (good hops remaining), but the device is returning a NACK. That's an indication that the PLM is no longer a valid controller for group 0. Did you "link google home" prior to this? Same as previous. Good communication, but NACK indicating PLM isn't a valid controller. Hopefully someone else can help with the Google Home Linking issue. It seems that it is corrupting your devices. I would also strongly suggest that you investigate the circuit where your PLM was originally installed. There is still a strong noise source or signal absorber on this circuit. Moving your PLM improved things, but the offending device is still degrading your system.

@Jimbo.Automates, the "NACK" in your event viewer is a dead giveaway. You apparently have an I2CS device and the link record listing the PLM as a controller is missing or corrupt. It's interesting that your device still responds to and controls scenes. That means that some/most of the link table was still intact. The highlighted entry below is the responder link in one of my KPL's. This was apparently missing from your KPL. Without the entry, the KPL will refuse to accept writes from the PLM. A description of the link table entries was provided by LeeG here : https://forum.universal-devices.com/topic/9525-how-to-read-a-link-table/ If this occurs frequently on this device, you may have a failing device power supply. If this occurs frequently on multiple devices, you have have a failing PLM or SD card.