kclenden

How did you change the state of your switch? The log shown above is not consistent with changing the state of the switch from the Admin Console. Were you changing the state by manually pressing the switch? These would be commands that the eISY is sending to the device. Since they work, it implies that at least one half of the link combination between the eISY and device is intact. The fact that you're not receiving status updates from the devices when they are manually activated implies that the other half of the link combination between eISY and device is not intact. When you add a device to your eISY network, at least four links are created. The first two links allows the eISY to control the device. The other two links allow the device to control the eISY. One link stored in the PLM tells it that it can control the device. This is called a controller link. A corresponding link is stored in the device that tells it that the PLM is allowed to control it. This is called a responder link. The exact same thing happens with the device. One link (controller) is stored in the device that tells it that it can control the PLM. Another link (responder) is added to the PLM that tells it that it can be controlled by the device. Depending on the type of device (e.g. keypad, motion sensor), many more links will be created between the PLM and device. Also, when you add devices to scenes, links are added to both the PLM and device. The fact that you can query and turn on/off devices from the eISY tells you that the PLM has a controller link for the device and that the device has a responder link for the PLM. Since you're not receiving status updates from the device it implies that either the device is missing a controller link that allows it to control the PLM or the PLM is missing a responder link that tells it that it can be controlled by the device. Since you're having problems with more than one device, it seems more likely that the missing links are in the PLM as opposed to several devices. If the PLM is missing links, it can be caused by many things, but generally falls into several areas. The PLM hardware is failing - Replacing or repairing the PLM fixes this. An electrical anomaly caused the PLM to corrupt its links table - Using the restore PLM command should fix this. Too many devices have been added to the eISY Insteon network or to scenes. The PLM links table can only hold so many links (~1000). If the PLM links table is full when a new device is added or a device is added to a scene, sometimes links for existing devices/scenes are overwritten by links for the new device/scene. The fix for this is to either remove Insteon devices from the eISY network, or to reduce the number of scenes being used, or reduce the number of devices that are included in scenes. I'd recommend doing "Tools->Diagnostics->Show PLM Links Table" followed by clicking the "Start" button. You want to do this at a time when nothing else is happening on the eISY or Insteon devices as activity can cause the link listing to abort. Because of this, you'll want to list the PLM Links Table several times so that you know you got a complete listing. When you have a complete listing, click "Save" and save the listing to a text file. This will allow you to use a text editor to search for the appropriate links for the devices that are not reporting status updates.

Like the previous discussion, I tried installing the AVServer plug-in but it remains disconnected. I can see in the log that it tries to startup every 30 seconds. It appears to be missing a module (xmltodict), which is strange because it is included in the "requirements.txt" shown on the guthub site. Below is what appears in the log every 30 seconds. How do I resolve this? 2025-10-16 01:50:35.871 MainThread udi_interface INFO polylogger:set_basic_config: set_basic_config: enable=True level=30 2025-10-16 01:50:35.871 MainThread udi_interface INFO __init__:<module>: UDI interface initializing 2025-10-16 01:50:35.871 MainThread udi_interface INFO __init__:<module>: User=None 2025-10-16 01:50:35.871 MainThread udi_interface INFO __init__:<module>: Home=/var/polyglot/pg3/ns/0021b902702f_9 2025-10-16 01:50:35.871 MainThread udi_interface INFO __init__:<module>: Node Server Path=/var/polyglot/pg3/ns/0021b902702f_9 2025-10-16 01:50:35.872 MainThread udi_interface INFO __init__:<module>: PG3INIT=eyJ1dWlkIjoiMDA6MjE6Yjk6MDI6NzA6MmYiLCJwcm9maWxlTnVtIjo5LCJsb2dMZXZlbCI6IklORk8iLCJ0b2tlbiI6InBadHhIKGw4RGU1dCptSHEiLCJtcXR0SG9zdCI6ImxvY2FsaG9zdCIsIm1xdHRQb3J0Ijo4ODgzLCJzZWN1cmUiOjEsImlzUEczeCI6dHJ1ZSwicGczVmVyc2lvbiI6IjMuMy4yMSIsImlzeVZlcnNpb24iOiI1LjkuMSIsImVkaXRpb24iOiJGcmVlIn0= 2025-10-16 01:50:35.872 MainThread udi_interface INFO __init__:<module>: Loading interface module 2025-10-16 01:50:35.912 MainThread udi_interface INFO interface:<module>: Loading MQTT module 2025-10-16 01:50:36.392 MainThread udi_interface INFO interface:<module>: MQTT module loaded 2025-10-16 01:50:36.603 MainThread udi_interface INFO __init__:<module>: Loading udi_interface module 2025-10-16 01:50:36.604 MainThread udi_interface INFO __init__:<module>: Loading node module 2025-10-16 01:50:36.604 MainThread udi_interface INFO __init__:<module>: Loading custom module 2025-10-16 01:50:36.604 MainThread udi_interface INFO __init__:<module>: Loading isy module 2025-10-16 01:50:36.604 MainThread udi_interface INFO __init__:<module>: Loading OAuth module 2025-10-16 01:50:36.605 MainThread udi_interface INFO __init__:<module>: UDI interface initialized 2025-10-16 01:50:36.605 MainThread udi_interface INFO __init__:<module>: UDI Python Interface for Polyglot version 3 3.3.18 Starting... 2025-10-16 01:50:36.608 MainThread udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2025-10-16 01:50:36.608 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b902702f_9/udi-av-poly.py", line 8, in <module> 2025-10-16 01:50:36.608 MainThread udi_interface ERROR udi_interface:write: from nodes import AVController 2025-10-16 01:50:36.608 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b902702f_9/nodes/__init__.py", line 6, in <module> 2025-10-16 01:50:36.608 MainThread udi_interface ERROR udi_interface:write: from .av_controller import AVController 2025-10-16 01:50:36.608 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b902702f_9/nodes/av_controller.py", line 8, in <module> 2025-10-16 01:50:36.609 MainThread udi_interface ERROR udi_interface:write: from nodes.node_factory import NodeFactory 2025-10-16 01:50:36.609 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b902702f_9/nodes/node_factory.py", line 3, in <module> 2025-10-16 01:50:36.609 MainThread udi_interface ERROR udi_interface:write: from ssdp.ssdp import SSDP 2025-10-16 01:50:36.609 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b902702f_9/ssdp/ssdp.py", line 10, in <module> 2025-10-16 01:50:36.609 MainThread udi_interface ERROR udi_interface:write: import xmltodict 2025-10-16 01:50:36.609 MainThread udi_interface ERROR udi_interface:write: ModuleNotFoundError 2025-10-16 01:50:36.609 MainThread udi_interface ERROR udi_interface:write: : 2025-10-16 01:50:36.610 MainThread udi_interface ERROR udi_interface:write: No Module named 'xmltodict'

Sort of. That is the only command in the lines that you posted. All the other lines are status updates. I think the fact that it doesn't show an IP address means it wasn't an external device that issued the command, but rather something running on your ISY/Polisy/eISY. I'm not really fluent in node servers (or whatever they're called now), but the line seems to indicate that whatever plugin is in slot 10 of your Polyglot3 setup is involved. If you launch Polyglot V3 and go to the "Dashboard", look for the plug-in that ends in (10). Updated: You can also find out what's in slot #10 via "Plugins->Configure->[01] to [20]->[10]..."

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.