kclenden

Your Event Log shows the ISY attempting to get the status of 35 devices over the course of about 13 minutes. In every case, it doesn't hear even a single peep back from those devices. During that time, it does, however, hear unprompted from two devices. Interestingly, one of the two devices it hears from is a device from which it earlier attempted to get a status update. My conclusion from this is that the PLM never actually sent the status requests. This could be a result of a hardware problem or a corrupt PLM Links Table. These two statements should not be able to exist side-by-side. Start the Event Viewer and set it to Level 3. Then do "Tools->Diagnostics->Show PLM Links Table" followed by "Start". If you post the resulting log that may allow for more troubleshooting.

The PLM is really just another Insteon device. Every Insteon device has a Links Table. This table tells it who it will respond to, and who it can control. When you add an Insteon device to your ISY two* links are added to the PLM Links Table (a controller and a responder link) and two links are added to the device Links Table (a controller and a responder). Without these links, the PLM and device would simply ignore each other and your ISY would not be able to control or receive status messages from a device. * It's possible more links are added depending on the type of device. For example, a 6-button keypad will have links added for each button.

The log available via "Tools->Error Log" should be able to tell you the IP address of whatever device is sending the random "rest" commands. After you save it, open it with a text editor and use the date/time to find the ON command that arrived via a "rest" command and the line above should show you the IP address of the device that sent the command. Here's an example of when I used a "rest" command from the browser of my desktop to get the value of one of my state variables. Mon 2025/10/13 06:32:58 AM 0 -170001 [HTTP:6-9] ::ffff:192.168.2.166:2259->64288 Mon 2025/10/13 06:32:58 AM 0 -170001 [HTTP:6-9]: GET-->/rest/vars/get/2/25 Mon 2025/10/13 06:32:58 AM 0 -170001 [HTTP:6-9] Closing socket normally

I seem to recall some people mentioning that the "Insteon Support" checkbox became unchecked after an update. So you might goto the "Configuration" tab and make sure that the "Insteon Support" checkbox is indeed checked.

Upgrading to an eISY is a nice way of supporting UD. I did that earlier this year when UD sent out a notice that eISY prices would be going up because of tariffs. For that reason, I have a decommissioned ISY 994i PRO. It was purchased in Jan 2013, and used through July of this year. It's yours for the price of shipping (~$8 in USA), if you want it. It's on v5.3.4, so I think you'd need to upgrade your existing ISY first before you could create a backup that could be restored to it.

The Event Viewer log you posted does not show a communication issue. I'm 99.9% sure you'll get the same result with the new switches. Guy is correct, there is a limit, though it depends on whether you have the PRO model, or not. Given your result, I'm guessing you don't have the PRO model which means your limit is much lower. Here is a link to a discussion from 2019 which I think covers your issue:

You are adjusting the on-level for each device when it is locally controlled (i.e. when you press the SwitchLinc button). What you want to do is modify the on-level for the device when it is activated by a scene controller. So, in the example above, the on-level for "GR-Built-In Accent #1" would be set to 30% when the scene is activated by the controller "HW-Keypad-Button A". In your case, you would want "Set" to be "Master Bath Sink Lts - Load" and the "Controller" to be "Master Bath Sink Lts - Ctl".

This is only half correct. When a scene is activated, the command that activates it is an SA ALL-Link Broadcast message. After an SA ALL-Link Broadcast message is sent, the device sending it can, but doesn't have to, send individually-addressed cleanup messages. Those cleanup messages act as a second notice to devices that the broadcast message was sent, and causes the devices in the scene to respond with an ACK or NAK message. Importantly, the eISY/Polisy/ISY does not send individually-addressed cleanup messages after it activates a scene, so devices do not respond with ACK/NAK messages and the power-line is not overloaded with communication. So programmatically activating a scene from the eISY/Polisy/ISY will not overload the power-line with cleanup messages between devices. You can see this in the Event Viewer at Level 3. Here's the result of activating a scene from the Admin Console. The scene has three devices: two SwitchLinc 2477S and one KeypadLinkc button. You can see one command (first line) that goes from my eISY to the PLM and one command (second line) that goes from the PLM to the devices. Lines 3-8 are not actually power-line communication, but merely the eISY logging the fact that it has changed the state of the three devices in the scene based on the fact that it sent the scene command. Importantly, you don't see a second [INST-TX-I1] message from the eISY with a cleanup message, and there are no [INST-SRX] responses from the scene devices with an ACK/NAK. I said only half correct above, because device to device scene activation (e.g. if I press the Keypad button to activate the scene instead of activating it from the Admin Console/Program) does involve cleanup messages. If the scene has a lot of responders, this can tie up the power-line for a while, but this generally doesn't cause a problem because I can only push buttons so fast. It does mean, though, that if you have a program that is activated by a scene controlling device, you need to be aware of that and control how quickly the program starts sending out power-line commands.

Before climbing a ladder to reset the Fanlinc, if you're just looking at the "Log" and not the "Event Viewer", then you might try opening the Event Viewer and setting it to Level 3 a little before sunset. That should allow you to see all the communication that is happening when your Lamplinc turns on. At least all the communication that your PLM can see. Another thing to do would be to run Tools->Diagnostics->Show Device Links Table and post the results here. That will tell us the address of all the devices that can control the Lamplinc.

I'm confused. Your last statement indicates that you are making the adjustments using an API Rest command (by calling an ISY program). That is only one level of abstraction away from what you're apparently trying to accomplish. In both cases, you'd still need the ISY, right? Or am I missing something?

Interestingly our robot overlords do not agree: Now mind you, I trust Michel more than any AI, but maybe he meant HTTPS vs HTTP as opposed to HTTP2 versus HTTP1.1?

A 403 error generally means that the server has received your command but has decided that you're not authorized to execute that command. So unless the URL that you're trying to use includes credentials (and they're being cutoff because the URL is too long), I don't think the problem is the length of your URL, but instead that you must first authenticate so that the server knows your are authorized. This is from the virtualsmarthome.xyz website: Since you have an URL, I'm assuming that you've completed steps 1 & 2, but have you also done steps 3 & 4? I have absolutely no experience with Alexa skills, nor virtualsmarthome.xyz, so I'm just shooting in the dark in case any of this triggers (all puns intended) something in your mind.

A little late to the conversation, but as Techman says, scene data resides within all the controllers and all the devices. So let's say that you've created a scene on the ISY that has a SwitchLinc as a responder to the A button on two different KeypadLincs. What you've actually done is create three controllers, and one responder. The controllers are the ISY, and each of the A buttons on the KeypadLincs. The scene command is sent from whichever controller is activated. So if you turn the scene on from the ISY Admin Console (or a program), the scene command is sent from the PLM. If you push one of the A buttons then the scene command is sent from that A button device. That means if the scene fails when you turn it on from the ISY but works when you turn it on from the A buttons, then the PLM might be suspected of failing. But if the scene fails when you press either of the A buttons, the PLM is not suspect since it didn't actually send out the command. Instead, you'd suspect line noise or an incomplete path between devices (maybe wired only devices that are on different phase of the power line). It's also possible that a Links Table in the one or more of the devices has become corrupt. You'd need to do a "Show Devices Links Table" for each device in the scene, and after the links are shown, click "Compare" which will compare to a list of links the ISY thinks should be there showing any differences.

I know it feels that way, but you just have to flip things around to understand what's going on. You presented a mystery in a place populated by very logical thinking people who enjoy solving puzzles. While they want to help you, they also want to solve the mystery. So they asked for additional information but for one reason, or another, you haven't provided it. So they feel frustrated and it comes out feeling like an attack.

You're using "Status is On" in the IF. I think you want to use "is switched On". So use "Control" instead of "Status". They don't go off because while the program is in the WAIT 5 MINUTES, the status goes to OFF and the program switches to the ELSE.

Not sure what you actually mean when you say that you moved your ISY outside the firewall, but a firewall is designed to keep things that are outside from communicating with things that are inside. So if your ISY is outside the firewall, and your Russound and Onkyo devices are inside the firewall, the ISY is not going to be able to talk to them, even with the Network module, unless you specifically open the necessary ports in the firewall.

The "random all on" that people experienced in the past was hard to catch because the affected devices simply turned on without reporting a status change. People ended up creating "watch dog" programs that monitored a device whose state was tightly controlled and reported if it was in an unexpected state. Say for instance your "pool refill relay". If you control it via programs, then whenever your program turns it on, set a variable to 1. Whenever it turns it off, set a variable to 0. If you control it via an Insteon switch then have a program that sets the variable to 1 whenever "switched ON" is received from the switch, and sets it to 0 whenever "switched OFF" is received. Now create a program that queries the status of the relay every X minutes, with X being the amount of time you're comfortable having the relay be ON even though you didn't turn it on yourself. Finally, create a program which sends you an email if the "pool refill relay" in ON and the variable is 0.

As @tlightne said you can set the program to "disabled". This essentially turns off the "IF" so that any triggers it contains will not cause the program to "fire". The program can still be launched by another program, and you can still right-click on the program and choose "Run Then" or "Run Else". If you want to make sure the program doesn't run under any condition, then you'd have to create a folder; set the condition for the folder so that it's FALSE; move the program into the folder.

eisy uses Java to access the Admin Console. I haven't heard of users having such trouble with Java.

"Status" is an event caused by a state change (ON to OFF or OFF to ON). "Switched ON" is an event caused by a command being sent (ON command sent). For an IF looking at STATUS to trigger, the device being monitored must have been in one state and then change to the state you're monitoring. For an IF looking at SWITCHED to trigger, the device must send the command you're monitoring. You've set your button to non-toggle OFF which means it will always be in the OFF state. So looking at STATUS will never trigger a program. The button does, however, send an OFF command every time you push it, so looking for "SWITCHED OFF" will trigger a program.

The IF should say "Button.B is switched OFF"

Thanks for providing the Links Tables. The Device Links Table shows that the device is a responder to the PLM (first link), but it does not show that the device is a controller of the PLM. This means that the device listens for messages from the PLM, but it does not send messages to the PLM when its status changes. That matches your symptoms exactly. Since the E2 links tell the devices that they are controllers of the PLM, their absence means that none of the devices send status updates to the PLM. Other way around. None of the controller links means none of the devices think they control the PLM, so none of them send out status updates to the PLM. What strange is that the Device Links Table you posted shows one E2 (controller) record where the Main Hallway (50 88 D4) controls device (50 96 2A). So some E2 records were written, just none where the device controls the PLM. The problem with that theory is that the eisy communicates with the PLM via USB or Serial, both of which are very reliable communication methods. That would seem to leave communication with the devices as the cause, but since every single device was missing its PLM controller link, it seems unlikely that would be the cause. Thanks for taking the time to document your experience and make a recommendation. It will be very helpful to other users.

Could you humor us with a screenshot? It seems hard to believe that all the links are there if none of the device activity is showing up in the Event Viewer Level 3 log. Either the device isn't sending the status because a controller link is missing, or the PLM isn't paying attention to the status because a responder link is missing. Just because the "Compare" comes back equal doesn't mean all the links are there. It just means all the links that the eisy thinks should be there, are there, but it seems like something in the migration is confusing the eisy as to which links should be there.

The way Insteon works is typically via links between devices. The ramification of this is that devices only pay attention to communication for which they have an existing link (with some exceptions). Devices only send status out to devices for which they have a controller link, and they only listen for messages from devices for which they have a responder link. So in the case of a switch, it will only send its status to the PLM if it has a controller link for the PLM. And the PLM will only listen for a status update if it has a responder link for the device. Given your issues, it sounds like one, or both of those links are missing. Some other people have described similar problems after migration, and I have asked if they would post their device links table so we could look for missing links, but so far none have. Perhaps you could by right-clicking on one of your devices and choosing "Diagnostics-Show Device Links Table". After the window populates, click the "Compare" button. Post the results here. It will help us help others in the future, and it will be useful information for UDI.

Maybe the condition on his "My Programs" folder is SUNSET.