kclenden

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.

That is correct. That is correct. Creating a custom log is one way to do it. You can also allow the Event Viewer to run at Level 3 for a couple days. Save that log to a text file and then you'll be able to search for messages from all of your sensors.

There is very little in the Event Viewer log that you attached. It appears that a Status Request was attempted three times, nine seconds apart. In each case, while the ISY is able to talk to the PLM, there is no response from the device being queried. This is consistent with the other Event Viewer log that you posted and probably means that the PLM is not actually sending anything out on the power line for the device to see and respond to. Since the PLM also doesn't seem to see any status updates being sent out by devices when you activate them locally, it does seem likely the the part of the PLM responsible for putting messages on, and receiving them off, the power line is not functioning.

Try right-clicking on one of the devices that is not updating its status automatically and choose "Diagnostics->Show Device Links Table". Once it's done reading links from the device, click "Compare". Post the results here and we can see if there appear to be links missing.

The Event Viewer Log shows that your ISY994 is communicating with the PLM just fine. Those are the [INST-TX-I1] and [INST-ACK] lines. What it doesn't show is any response from any Insteon devices. So either A) the PLM isn't actually sending anything out over the power line for the devices to hear, B ) it is sending stuff out but it's not making it to any of the devices, C) it is sending stuff out and it is making it to the devices, but their responses are not making it back. If you've actually tried this with both PLMs, then my guess would be that somehow the circuit the PLM is on has so much interference or a signal sucker that none of the commands from the PLM are getting through to other circuits. Have you tried plugging the PLM into a power strip and plugging an Insteon device into the same power strip to see if the ISY can communicate with it?

It's possible the heartbeats from those two sensor are having trouble getting through to the ISY. You could try as @tmorse305 suggests, or you might try starting the Event Viewer, setting it to Level 3, and then letting it run. After a couple days, save the log it has created and look for any heartbeat communication. What you really want to see is the "Hops Left" for the heartbeat from the two troublesome sensors. If they're having trouble getting their signal through, you'd expect to see "Hops Left" being 0 or 1. Another thing you could do, if you have the Network Module, is to change your program that looks for heartbeats so that it saves to a file the time each heartbeat is received. With that information, you'll be able to check whether the heartbeats from the two sensors is consistent. By that I mean, if on Day 1 the heartbeat comes in at 12:01, and you don't see a heartbeat on Day 2, but on Day 3 you see a heartbeat close to 12:01 and on Day 4 you see a heartbeat close to 12:01, then you can reasonably infer that on Day 2 there was a heartbeat around 12:01 but it just didn't make it to the ISY.

Generally speaking, statuses are only logged when they change. Heartbeats usually only send an ON or an OFF, but not both. So generally speaking, you won't see heartbeats logged by the ISY. Your listing only shows ONs, and it doesn't look like you filtered the "Value" column, so I don't have an explanation for why any of the lines after 527 appear in your log without an intervening OFF. Some of them might be explained if your ISY was rebooted since going from no status to ON would be logged.

Generally when a device's status is not updated without running a manual query, it means that there is a link missing in the device, or PLM. How did you upgrade? Knowing that might help explain any missing links. In any case, you can try right-clicking on the device and then clicking "Restore Device". That will rewrite the links in the device with any links the Eisy thinks should be there.

So you updated from v4.x to v5.x? All of the things you reported are known possible side effects when you migrate from v4.x to v5.x. Those side effects are why people who have documented going through the migration recommend that before the migration you right-click the very top of your program list (in my case "My Programs") and select "Copy Folder to Clipboard". Then open a text editor like Notepad and select "Paste". This will give you a text listing of all your programs, including whether those programs are set to "Run at Startup" and whether "Enabled" is "On" or "Off". Those particular settings, for some reason, are sometimes messed up through the migration. Since you don't have such a program listing, you'll have to check each program for "Run at Startup" and "Enabled" and set them based on your memory. Or, if you have a backup from before the migration, you could revert back to your v4.x firmware, restore your back up, create a program listing as outlined above, and then redo the firmware upgrade.