IndyMike

Hey Someguy, The 48.15.F2 device is absolutely being turned on by a Rest command. An external device is instructing your EISY to turn on the device. Where the command originated from I can't tell you. @kclenden posted a method above on how to interrogate the Error log file to find the IP address of the sender. Aside from that, all of the commands that I've seen posted are device direct commands. In other words the commands are targeting specific device addresses (no scenes). I am not a Alexa user. I am not sure whether that information helps.

Correct - this was intended as a stopgap/troubleshooting step until you resolved the root cause. It allows programs and schedules to run on the EISY while preventing Rest commands. I would not call the RJ45 network connection fragile, but agree you would not want to disconnect/re-connect as a long term solution. If you are concerned about this, most routers allow you to "pause" a network connection to specific devices. Either way, it's far better than continuously performing power cycles on the EISY.

@someguy, please do post any event viewer info that appears pertinent. Unfortunately, I am not knowledgeable on the Alexa control/integration. I am simply reading the event viewer logs and interpreting what the EISY is receiving. @Geddy had earlier posted a link pertaining to the Amazon Integration.

@jlloyd_UD, Resetting your switches will not help. Base on your event viewer, they are responding to valid communications from the PLM/EISY. The EISY is, in turn, responding to a valid REST command instructing it to turn ON/OFF an Insteon device. Your latest Event Log doesn't offer any new insight (at least for me). You have 3 reset "profile" commands that I can't identify. At 11:07:00 AM the EISY receives a valid Rest command to turn OFF device 40.16.5C (highlighted RED) The Violet Entries are the ISY/PLM/Device communicating the OFF command sequence. The green entry is the ISY summarizing the OFF command communication. Good news is that you have very good communication to this device. When I suggested disconnecting the EISY, I was proposing disconnecting it from your network (RJ45 network connector) not the PLM. This was intended to be easier then powering down the EISY completely. It would allow your programs and other EISY events to run while eliminating Rest commands. un 10/12/2025 11:00:42 AM : Create REST U7 [/rest/profiles/ns/0/connection] Sun 10/12/2025 11:05:32 AM : Create REST U7 [/rest/profiles/ns/0/connection] Sun 10/12/2025 11:05:44 AM : Create REST U7 [/rest/profiles/ns/0/connection] Sun 10/12/2025 11:07:00 AM : Create REST U7 [/rest/nodes/40%2016%205C%201/cmd/DOF] Sun 10/12/2025 11:07:00 AM : U7 Rest: submitCmd([40 16 5C 1],[DOF],[<NULL>]) Sun 10/12/2025 11:07:00 AM : [INST-TX-I1 ] 02 62 40 16 5C 0F 13 00 Sun 10/12/2025 11:07:00 AM : [INST-ACK ] 02 62 40.16.5C 0F 13 00 06 LTOFFRR(00) Sun 10/12/2025 11:07:00 AM : [INST-SRX ] 02 50 40.16.5C 48.EC.F5 2F 13 00 LTOFFRR(00) Sun 10/12/2025 11:07:00 AM : [Std-Direct Ack] 40.16.5C-->ISY/PLM Group=0, Max Hops=3, Hops Left=3

Your earlier "Event Viewer" post showed that the EISY was receiving REST commands instructing it to turn on/off device 60.41.6B. That is the EISY simply responding to an external command. Not a fault of the EISY or the PLM. It's a valid command that is being received through the network interface. I don't use Alexa or PG3 so I am not much help in troubleshooting. I suppose you could try eliminating specific device links (60.41.6b) from Alexa to see if that corrects the behavior for that specific device. You can also disconnect the EISY from your network during the night (rather than unplugging it). Without a network connection, the Rest interface should not be operative.

That appears to be rather damning. Not sure what device 60.41.6b.1 is, but it is absolutely being turned on by a rest command (Alexa?). I had seen other posts from users of the Eisy that showed "Rest" commands in the event viewer and was hoping yours would show the same. My ISY994 does NOT indicate Rest commands. Not a solution, but now you know where the command is originating from. Hopefully you can drive to a solution with the help from others on the forum. [comment: the following are the steps that initiated a random turn on of a light thru I3 switch 60.41.6B.1 ] Wed 10/08/2025 03:56:57 PM : U7 Rest: submitCmd([60 41 6B 1],[DOF],[<NULL>]) Wed 10/08/2025 04:04:15 PM : U7 Rest: submitCmd([60 41 6B 1],[DON],[<NULL>]) Wed 10/08/2025 04:04:24 PM : [60 41 6B 1 ] ST 255 (uom=100 prec=0) [comment: I initiated a "shut off light" command using Alexa plus spoken] Wed 10/08/2025 04:05:07 PM : U7 Rest: submitCmd([60 41 6B 1],[DOF],[<NULL>]) Wed 10/08/2025 04:05:07 PM : U7 Rest: submitCmd([60 41 6B 1],[DOF],[<NULL>]) Wed 10/08/2025 04:05:07 PM : [60 41 6B 1 ] ST 0 (uom=100 prec=0)

You seem to have established that unplugging either the PLM or (more importantly) the EISY eliminates the random on problem. In my mind that eliminates noise, absorption, corrupted link tables and a host of other items. Re-winding to your very 1st post, you had mentioned the Alexa plug in. This and other plug-ins (Elk) are absolutely capable of activating various devices through the EISY/PLM. Can you try capturing a "Event Viewer" transmission when one of the random lights activates? You'll need to have the viewer on Level 3 to see the transmission. I understand that this may be difficult because of the randomness of the events. The following is an event where my Home Assistant install instructs the ISY to turn off a basement light (using the Rest interface). It's indistinguishable from a normal ISY command (I'm using a ISY994). I'm hoping you have something similar going on - not noise, bad links, or a failing PLM. If you can't seem to capture one of the events, you could try disabling your various plug-ins. I really don't use them on my ISY994, so others will have to assist here.

.

Got it. Hope you're able to find someone to write a Plug-in.

Assuming that your screen and window frame are aluminum, your should be able to make the magnetic reed switch work over a 1/2" distance. You may need to tune the magnet (increase strength, stack, etc) to get things to trigger reliably. There is nothing magic about the magnets included in the sensor kits. You can replace with stronger versions and stack them to increase flux strength/close distances. Neodymium Magnet The Insteon sensor is easy since you have the ISY, but the battery life isn't the greatest. That could be an issue with skylights. The Yolink has good range and battery life, but you'll need a hub and a plugin. The garage door tilt sensor is elegant, but you probably don't have enough range of motion on your skylights. I use Zooz tilt sensors on my garage doors and they work well. They are not tunable (most are not) and require ~ 60 degrees of motion to trigger reliably. I have played with some Tuya Zigbee tilt sensors (ZG-103Z) that report X,Y, and Z axes tilt angles. These would require a Zigbee interface/mesh and probably are not supported by the EISY (requires Home Assistant). Not sure if there are other devices available that report actual angles rather than just Open/closed.

@smorgasboard, thanks for posting back with your findings. Sounds like you have found a path for controlling some of your skylights. My understanding is that Velux/Somfy use a closed RF protocol to interface their skylights/shades. The KLF-200 can speak this protocol and connect to MANY (200?) motors. You are correct that the KLF-200 is limited in the number of switch INPUTs that can be used to control the skylights. The value of the KLF interface is it's ability to communicate with other controllers (HA/EISY) that can operate the skylight(s) through it's API. That's my understanding anyway. If it's incorrect, please post back. https://community.home-assistant.io/t/velux-klf-200-pairing-with-somfy-io-motors-and-remotes/248075/14

No experience with Velux or the interfaces. However, a post on the HA forum indicates that the KLF 200 can handle far more than 5 devices. I'd say clarification from the manufacturer would be in order: VELUX America LLC 1-800-88-VELUX https://community.home-assistant.io/t/how-to-control-io-homecontrol-velux-devices-blinds-somfy/88917/3 Please do post back with anything you learn. Others will have the same questions.

Sorry, I'm not going to try to re-quote 10+ years of history. Search the forum's

To the best of my knowledge, Smartlabs HAS NOT removed the all-on command from current PLM's. They are still capable of sending the command (it is a valid command). Smartlabs HAS removed the all-on command from some of the newer Insteon modules. To the best of my knowledge, the IOLinc is STILL SUSCEPTIBLE to the all-on command. The ISY can still send an all-on command if you wish to test your devices. Navigate to the "My Lighting" item in the Admin Console Tree and you will see the all on at the bottom of the window. This will execute the group all on command. Devices that do not respond have been "fixed" or can't hear the communication. Devices that do respond are susceptible. Most of the issues with all on events seem to involve motion sensors, keypads, or devices that trigger programs that talk beck to the same device. I'm not aware of any specific Alexa issues (but then i don't use Alexa). The wiki mitigation posted above works reasonably well. There are Many posts on the forum. Try searching "site:"forum.universal-devices.com" all-on event" Best of luck.

Any error lights on the 994? You may want to remove and check your Sdcard (plug it into a windows machine and check for errors). If you find errors, I would highly recommend replacing the card. You can try a "repair" via windows, but I'd consider that a stopgap. Procedure for replacement is in appendix 😄 of the ISY994 users guide: https://docs.universal-devices.com/production/ISY User Guide 4.2.8.pdf

Sorry, thought you were still using the ISY994. I don't know what format the SSD uses. There are posts on how to re-flash the SSD: https://forum.universal-devices.com/topic/42174-polisy-ssd-image-restore-process-for-a-corrupt-ssd/. I also don't know if the EISY can read the information on the SSD. I would try a mSata to USB adapter and a PC first to see if it registers.

@apostolakisl, that's rough. Sorry to hear. My only comment(s) would be - check the power supply to see if it fried, and check the SDcard for corruption. Two easy ways to recover your configuration.

You can view the programs in a backup. Identifying a specific program and restoring it is rather painful. Copy one of your backups to a separate directory in case things go bad. The 1st screenshot below is the result of an UnZip of one of my backups. Use 7Zip or something similar to open your backup .Zip. Windows explorer will NOT work. You will see the file "uuid.xx.xx.xx.xx.xx.xx.zip". Unzip this to your directory. Open the "uuid.xx.xx.xx.xx.xx.xx.zip" file in 7Zip as well. Extract the CONF folder. Within the CONF folder you will find a D2D folder. This contains your program files. The "*.PGM" files are in XML format. Your challenge will be to identify which file you want to restore (not easy). You can export your current programs to try to determine the program numbering (ID) and what is missing. Beware that Exporting the entire "My Programs Folder" produces an XML file that can't be interrogated by any XML viewer that I have found (format error). I have been successful in exporting individual program folders (non-nested). I'm quite sure this is not the answer you were hoping for. Unfortunately, it's all I can offer. Directory showing Backup Zip, UUID Zip, and CONF file folder CONF Folder contents: D2D Folder Containing Program Files 000A.PGM Contents

As indicated above, the Zen32 does not send ON/OFF commands. Instead it sends "keypressed" events. The ISY appears to be interpreting the "keypressed" event as an "ON" event. Said differently, the ZEN32 will not send an OFF as interpreted by the ISY. You can still use programs and variable to interpret the successive "ON" events: {on program} if 'ZEND32 Button 2' is switched on and $ivar = 0 {0 = off} then {turn devices on} set $ivar = 1 {1 = on} {Off program} if 'ZEND32 Button 2' is switched on and $ivar = 1 {1 = on} then {turn devices off} set $ivar = 0 {0 = off}

@Techowl, I'm in agreement with @Brian H. It sounds like you have a device that is radiating signal @310 MHz and is effectively jamming your transceivers. If it is a device that is failing (oscillating) it will not be transmitting the proper X10 format and will be ignored by the transceivers - you won't see any events. You have a couple of tools at your disposal - 1) The tried and true circuit breaker approach. Turn off circuits until the noise stops (communication improves), then isolate devices on the circuit. 2) Use your transceiver to determine where the noise source isn't. Move the transceiver around the house to find an area where the remote range improves. Then reverse the process to find where the range is worst (noise source nearby). It is of course possible that the noise source is outside your home. The breaker test would confirm that.

@rwsani99, Your log from the "show device links" is showing evidence of communication timeouts (no-response from the target device). If things were working properly, you would see a "[INST-SRX ] 02 50 4E.7D.16 71.17.44 XXXXX" after the [INST-ACK}. In the above, the PLM is re-trying communications up to 5x per request, and the ISY is re-trying 3x (15x total). That's rather bad. Since you indicated that you are having issues with multiple devices, I'm am going to guess that you have a rather strong noise source near the PLM. I say near the PLM because you are having problems with multiple devices. I am guessing that it's a noise source, rather than a signal absorber, because it's rather intermittent. Your second log section showed sections of total failure, followed by rather good communication (hops remaining = 2). Inspect the circuit where the PLM is installed for problem items (Pc's, UPS, Printers, etc). Alternatively, you could try moving the PLM to another circuit. Let us know how things are progressing

@alixer, when you performed the "restore device", was the ISY able to complete write the link table (no errors)? If this is the case, then your device has the correct PLM address and the scene information is incorrect. I say this because newer devices (I2CS units produced after 2012) will not allow the ISY to read/write to them unless the PLM address is in their link table. It may still be helpful is you could post your device link table, ISY device link table, and PLM address. The membership tree on the right is also helpful since it shows how many scenes the device is associated with. If your link table compare looks similar to mine above (no missing or mismatched entries) then the ISY believes the device has the correct link table/scene information. If the device does not respond correctly to a scene command (assuming that it received the command), then the ISY Link Table for the device is incorrect. The ISY maintains link tables for each Insteon device and for some reason, yours may have been corrupted. You can correct this by manipulating the device settings within the scene, causing a re-write to the device (as you are doing) OR your can restore the ISY from backup. Obviously, the backup may also have incorrect information, or be missing information on your more recent devices. If you do choose to restore a ISY backup, please follow with the process that @lilyoyo1 outlined above.

That's unfortunate. It indicates that the ISY does not have the correct scene information. You could try installing an ISY backup (restore ISY, restore modem, restore devices) , but that may be more work than "refreshing" you scene devices.

To be clear, my system failure was two fold: Poor programming on my part that led to a program cycling the system on/off causing water hammer. Poor irrigation design causing excessive main pipe flow (erosion). Pipe erosion occurs when you have large zones (high flow) and a capable supply. It's not that hard to avoid as long and you understand the pressures and flows in your system. I found the following site helpful. It includes spreadsheets for calculation pressure loss (friction) in various types of irrigation plumping. For reference, I was just below 7 ft/sec in my system mainline with certain zones operating. https://www.irrigationtutorials.com/#gsc.tab=0

It sounds like your new PLM address did not get written to your older devices. Not quite sure why. When you adjust the parameters of scene devices you are re-writing the scene AND the PLM address. That's why things work properly after the update. I can understand why you wouldn't want to do this for all of your scenes - you probably have a life. Could you try performing a Link Table Read/compare on one of your problem devices and posting the results? Please also post the new/old PLM address. This will tell us if the ISY contains the correct information. If it does, a simple "restore device" should correct the problem. If it doesn't, things get a bit more complicated...