kclenden

That likely indicates a failing PLM. Line 1: (T0) First command from Polisy to PLM to turn on computer room light Line 2: (T+2) Second command from Polisy to PLM to turn on computer room light Line 3: (T+5) First response from PLM to Polisy acknowledging the first command to turn on the computer room light. This is an extended response from the PLM, and my docs don't tell me what the extended data means but the last byte (33) is not 06, so the PLM did not send the ON command to the computer room light. Line 4: (T+5) Third command from Polisy to PLM to turn on computer room light Line 5: (T+5) Second response from PLM to Polisy acknowledging the second command to turn on the computer room light and indicating that it did indeed send the ON command to the computer room light Line 6: (T+5) Third response from PLM to Polisy acknowledging the third command to turn on the computer room light and indicating that it did indeed send the ON command to the computer room light. Also flagged as a duplicate acknowledgement because the Polisy has no way to associate PLM replies with the Polisy command that initiated the reply. Line 7: (T+5) The computer room light acknowledges that it received and executed an ON command from the PLM. You will note that unlike the PLM, devices will not acknowledge additional commands if those command do not change their state (i.e. the light received two ON commands in a row, but it only responded to the first one) Line 8: (T+5) Polisy's decoding of Line 7 Line 9 & 10: (T+5) Polisy updates its status for the computer room light to ON The Event Viewer shows that the delay between you presumably clicking ON in the Admin Console and the computer room light actually coming on was caused by the PLM. The PLM waited five seconds before acknowledging your first attempt to turn on the light. After that the PLM reacted instantly to the additional attempts to turn on the light. It also shows that once the PLM sent the ON command to the light, the light reacted instantly. An additional piece of information appears in line 8 (Hops Left=3). This means that the response from the light to the PLM came directly from the device. More interesting bits of info from these 10 lines is that even though you clicked ON twice before the PLM got around to responding, all three ON clicks were eventually registered by the PLM. This implies that the PLM was queueing the commands even though it wasn't doing anything with them. I don't know why the PLM waited five seconds before responding to the Polisy. I do know that Insteon devices are supposed check the power-line before sending a message so that they don't interfere with messages being sent by other devices. If there was line noise on the power-line, or the PLM circuitry that is used to make sure it is safe to send a message is failing, then the PLM would delay sending the ON command to the device, which would delay it replying to the Polisy.

Both of those could be signs of a failing PLM, or they could be signs of a noisy power-line. One of the things I have found by looking at the Event Viewer on Level 3 that helps me decide whether the problem is a noisy power-line is the response that comes back from devices - [INST-SRX] and [INST-ERX]. Right after those responses, you should see a [Std-Direct-Ack] line that contains "Hops Left=". The number of hops left tells you how many times a response had to be forwarded by another device before reaching the PLM. It starts at 3 and is reduced by 1 every time it is forwarded. Once it reaches 0, the response will not be forwarded by any more devices. So a Hops Left=3 means that the response came directly from the device. Hops Left=2 means that the response had to be forwarded by another device before it got to the PLM, Hops Left=1 means the response had to be forwarded by two other devices and so on. If you are consistently seeing Hops Left=0 or 1, that means PLM to device communication is consistently relying on intervening devices for forwarding which often means line noise.

It would be interesting to get more information about this. What kind of delay are you seeing? Seconds? Minutes? Do any other commands happen in between you commanding a light on/off and it actually turning on/off? If we break down what happens when you command a device using UD Mobile it would look something like this: UD Mobile tells the Polisy to a send command to a device - this happens by sending a REST command over your network Polisy tells the PLM to send a command to a device - this happens by sending a command either via a serial or USB connection PLM sends a command to a device - this happens by sending a command over the power-line or RF Device executes the command You can see each of these things happen in the Event Viewer when it is set to Level 3. For the first, you'll see a "Create REST" line For the second, you'll see a [INST-TX-I1] line For the third you'll see a [INST-ACK] line And for the fourth, you'll see an [INST-SRX] or [INST-ERX] line By observing the timestamp in the Event Viewer, you should be able to tell where the delay is being introduced.

The issues he has reported don't seem to me to be the kind that are caused by a full PLM Links Table. For example, he reported being able to control a device via UD Mobile a couple times, and then not being able to control the device and/or having a significant delay between commanding the device and it actually responding. A full PLM Links Table wouldn't cause this kind of issue. Either he'd be able to command the device, or he wouldn't. His ability to command the device wouldn't come and go.

It might help, but it also might leave you in a much worse state if after the factory reset you are still unable to restore the PLM.

When you perform "Restore Modem (PLM)", it's a two step-process. First the PLM is restored then all the devices are restored. I agree with Michel that there is no queue for the first step. If the attempt to restore the PLM is unsuccessful, your Polisy will not try to restore it later unless you again choose "Restore Modem (PLM). For the second step, restoring the devices, there is most definitely a queue as evidenced by the "1001" that shows next to each of your devices. If those updates do not complete, the Polisy will try to complete them later. Having said that, I don't know what happens to the queue of device updates if you were to perform another "Restore PLM". From Michel's response, it sounds like they may be wiped out and be replaced by the device updates created with the new "Restore PLM" command. So from Michel's response, it appears that he is saying that he believes the PLM is the issue because you are unable to restore it, not because of any communication issues he sees in the Event Viewer when the PLM attempts to talk to devices. I can't argue with his logic. If it were me, I'd probably try factory resetting my PLM and then attempting another "Restore PLM". Recognize, however, that if you do that and you are still unable to restore the PLM, all the things that currently work will no longer work. Device statuses won't update in UD Mobile or the Admin Console. Any programs that are activated by a device status change will no longer work. Any programs that send commands to devices, or use scene commands will not work. Hmmm . . . After writing those four sentences, maybe I wouldn't try factory resetting my PLM until I had received the new one.

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.

So I am also currently experiencing issues with my eISY/PLM setup. I won't go into details of my issues at this point, but suffice to say I've been using "Backup IoX", "Restore IoX", "Restore PLM", "Restore Device", "Show Device Links Table", and "Show PLM Links Table" quite a bit lately. Here are bits of information that I think might be useful: My PLM Links table also returns 292 links. I have about 60 Insteon devices. I find it quite interesting that we have the same number of PLM links. Probably doesn't mean anything . . . The PLM has memory that holds a link for every device it controls, every device that controls it, and every device that is either a scene responder or scene controller. Each device has memory that holds a link for every device it controls, every device that controls it, and every device that it either responds to in a scene, or controls in a scene. When you first link a device to your ISY/Polisy/eISY two links are stored in the PLM and two links are stored in the device. The links stored in the PLM tell the PLM that it is both a controller and a responder for the device. The links stored in the device tell the device that it is both a controller and a responder for the PLM. You might think it strange that the device is a controller for the PLM but that is what allows the device to communicate manual status changes to the PLM. It's not really controlling the PLM just updating it with its status. Every link stored in the PLM and Device Links Tables has either a device address or the PLM address. When the PLM or a device receives a message, it checks the message for the address from which the message originated and then looks in its Links Table to see if that address exists. If it does, then it executes the command that is also stored in the message. If the address does not exist in its Links table, it will ignore the command. Usually when it executes the command it will respond with an ACK message, and if it ignores the command it will respond with a NAK message. The ISY/Polisy/eISY maintains a backup of the PLM and devices Links Tables so if the PLM or devices have their table corrupted, you can fix them with the backup from the ISY/Polisy/eISY. I provide that context to help you understand why a failing PLM memory, or corrupted device memory might cause problems. An example: to communicate a manual status change (say from OFF to ON), a device will send a message to every device for which its Links Table shows it to be a controller. By default it will always be a controller of the PLM, but it may also have been assigned as a controller for a scene. If its Links Table has become corrupted and a controller link has been lost, then it will not send a message to the device that was in the missing link. Likewise, after the device sends its message with its status change, all devices will receive that message, but only devices that have the address of the sending device in their Links Table, including the PLM, will actually accept the message. So if the PLM Links Table memory if failing, and it has lost links that tell it that it is a responder to a device, it will not accept messages from that device even if the device sends them. By not accepting the message, the PLM won't accept the manual status change and communicate it to the ISY/Polisy/eISY. So what happens when you get a new PLM and perform a "Restore PLM"? What I describe below is if you have connected a new PLM to your ISY/Polisy/eISY. Since the address of the new PLM is different than what the ISY/Polisy/eISY last knew to be the PLM's address it will execute what follows. If the currently connected PLM has the same address as the last known PLM address, I think it was hart2hart that suggested only the PLM will be updated (next paragraph) and not the individual devices (second next paragraph), but I've never done that so I can't confirm. None of the links that exist in your old PLM will exist in the new PLM. So the first thing that happens is that ISY/Polisy/eISY will use its backup PLM table to fill the new PLM with all the links that currently exist in your old PLM. This happens via the serial or USB connection between the ISY/Polisy/eISY and the PLM so occurs relatively quickly. If all those links weren't put into the new PLM, it would not accept manual status updates from devices, nor know anything about any of the scenes you might have defined. Next the ISY/Polisy/eISY will update every link in every device that has the old PLM address with the address of the new PLM. This happens over the power-line and can take quite a long time. If the old address wasn't changed to the new address in the device Links Table then the devices would simply ignore the new PLM because its address did not appear in the device's Links Table. Power-line devices are always waiting for commands, so they'll automatically accept the link updates, but wireless device spend most their time sleeping are won't likely be awake when the new link commands are sent. That is why you want to unselect the little battery icon just below the menu row before running "Restore PLM". That way the new link commands aren't sent to wireless devices until you right-click on the wireless device and select "write updates". Before doing that, you go to the device and put it in setup mode by holding down its set button for 3-5 seconds so that it is awake to receive the new link commands. If the ISY/Polisy/eISY is not able to communicate with a device during it's attempt to update the device's links, it will leave all those message queued up. This can leave your ISY/Polisy/eISY is quite a bad state, as it will try to send all those message later. You'll notice that there are messages to be sent because "1001" will appear in green or gray next to the device's name. The only way I know of to wipe out all those queued up messages is to use "Restore IoX" to the last known good backup. If you've made it this far, based on what you've reported so far, I'd start with "Show PLM Links Table". If you get the 292 links that you've been getting all along, I'm not sure you need to try to update the PLM. If you aren't getting the 292 links you were getting before, I'm not sure there's any reason not to factory reset the PLM and try a "Restore PLM". I will mention that the factory reset procedure laid out by hart2hart above has an error. When you plug in the PLM while holding the black set button, you need to hold down the set button until the PLM stops its continuous beep. Don't let up when you first hear the beep. It's important to "Backup IoX" before doing a "Restore PLM". Your system can be left in quite a state if lots of messages for devices are queued up as they'll flood the power-line at the most inconvenient time, and if you're having power-line communication issues, the queued message may never clear. The only way I know to get rid of queued message is to either have them successfully reach the device such that the device sends back and ACK message, or to "Restore IoX" using a the last known good backup. This is way longer than I intended, but one last thing. A failing PLM can be caused by a lot of things. As laid out above, if its memory fails the links lost from its memory will cutoff communication with the specific devices whose links have been lost. If it is losing signal strength then commands that it sends may not reach the intended devices. Both memory loss and signal strength loss are things that should be able to be diagnosed using the Event Viewer and/or "Show PLM Links Table" and "Show Device Links Table". The PLM may also lose signal strength receptivity, but that is a little harder to diagnose using the Event Viewer because only things that the PLM hears appear in the Event Viewer so you don't know what you don't know. Still if it has been confirmed that a responder link with the device's address appears in the PLM Links Table, and a controller link appears with the PLM's address in the device's Links Table, but no messages are appearing in the Event Viewer when you manually change the status of the device, then either there's too much noise on the power-line, or the PLM's sensitivity has been diminished, or the device's transmit signal has been diminished. All of that is my way of saying that with some sleuthing, I would expect Michel to be able to posit a guess as to whether he thinks the PLM is experiencing memory issues, signal transmit issues, or signal reception issues since you indicated he says the PLM should be replaced.

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.

What's weird is that my "My Programs" folder doesn't even appear in my "Summary" tab. Does it appear in yours? Update: Never mind. I added a condition to "My Programs" and it appeared in my "Summary" tab. Removed the condition, and it disappeared from the "Summary" tab. Guess I didn't read all the way through your post. 🙂

I don't see any reason the Sunrise program shouldn't be triggered at sunrise. When weird things like this happen, the first thing I check is that my Firmware and UI version match in the "About" dialog box that you get via "Help->About".

Received an email from UDI indicating they are supporting i3 products on eisy and Polisy as of version 5.5.9. Guess I have a reason to migrate my ISY944 to an eisy now. https://www.universal-devices.com/i3-support/

In short: You need the Network Module - among other things this adds a webserver to your ISY You create a notification that appends to a file on your webserver - in this notification you should include variables that contain the data you want to log You create a program that is triggered by whatever action you're wanting to log - in this program you put information into the variables that are referenced in your notification, then you launch that notification You can review your custom log via a browser by going to http://[your ISY IP address]/USER/WEB/[your log file name] @waffles message above gives you the link to the wiki with detailed instructions about the notification that becomes the core of your logging. Here is a screenshot of the notification that I use to log the date/time of the heartbeat received from a garage door sensor. In the program that reacts to the garage door sensor hearbeat, I put the current date into ${var.1.25} and I put the time into ${var.1.26} then I execute "Send Notification" for that notification.

Seems like for troubleshooting purposes which in my experience can not only be invaluable, but also quite illuminating. But as you point out, could be a distraction if you don't have a clear goal. This is really good advice. Often the best course is to step back and ask yourself what your goal is. Then concentrate on the steps that move you toward that goal. Heartbeats tell you that a sensor is communicating with the ISY. Consistent heartbeats tell you that a sensor is consistently communicating with the ISY. A sensor that is not consistently communicating with the ISY can not be trusted to communicate with the ISY when it really matters. My guess is that most people only use heartbeats to know when a sensor's battery has died, but they can be used for so much more. Over the course of a month, if you only see 15 heartbeats, are you really going to trust that sensor to alert you when needed? And if you only see 15 heartbeats, then what? How do you fix it? By logging the date/time of heartbeats to a file, you can look for patterns. Is the time of the heartbeat consistently changing? If so, then the power to the sensor could be being interrupted. Are they only missing during times that some other device is turned ON? By default, the ISY logs status changes. Unfortunately it doesn't log control signals. Augmenting the default ISY log with custom programming to log control signals can be very useful.