kclenden

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.

Here is a link to a post within a discussion on pulling variables from an ISY. The post talks about remotely executing programs on another computer and references an application called "SayWhat". I just tried the "Windows 9x, ME, NT, 2000, XP" version on a Windows 10 desktop and it worked. You'd need to create a ".bat" file that contained the shutdown command and put it in the SayWhat "actions" folder. Next you'd have to configure the Windows 10 firewall to allow the ISY to get through to port 1080 on the PC. Then a network resource on the ISY should be able to execute the "shutdown.bat" file on the PC. Finally you'd have to set SayWhat to run at startup on the PC.

Red indicates that program's IF last evaluated FALSE, while green indicates the IF last evaluated TRUE. If the program icon is a solid color then the program is still running. If the solid color is green, it is running the THEN section, while if it is red, it is running the ELSE section. If the program icon only has the left portion colored, then it is not currently running, and the color tells you if it last ran the THEN (green) or the ELSE (red).

You are misunderstanding what the "enable/disable" option does. It does not enable/disable the program, it enables/disables the program's IF. You can still right-click on the program and run the THEN or ELSE, and the programs will run when the ISY starts up if they are set to "Run At Startup". The only thing that won't happen is the program won't be triggered by anything in its IF.

It would be helpful to know what version of the firmware were you running before the upgrade.

@DennisC laid it all out, but here is a slightly more concise troubleshooting table from the ISY994i manual, though it is exactly the same for the ISY99:

My ISY 994i running v5.0.16 returns 49 as the result, so I'm guessing your 48 is a bug. Until someone reports the bug, or UDI discovers the bug, and they fix it. Then you'll be one off the other way. You might want to report it to UDI as a bug.

Yes it does. My mistake. That's the clarity I was looking for.

Your are correct. That is what I was missing. While there is no code to execute in the ELSE, it does switch the execution from the THEN to the ELSE, thus halting the WAIT state.

I disagree. The WAIT will count down 5 minutes and then move onto the next line below the WAIT. After executing the next line, in this case sending an OFF to some device, the program will run out of lines to execute and then stop. By your logic, if a "switched OFF " was received, but a "switched ON" was never received then the program would just keep running forever. If you don't believe me, how about the "ISY994i Series User Guide". Here's a screen shot from a description of "WAIT" on page 39: Edit: Why doesn't that program need a "not switched ON"?

How so? Once triggered the WAIT will count down and then perform the OFF statement that follows it. The WAIT will only restart the count down if the IF is retriggered. Let's analyze two different programs. One with the "not switched on" and one without. If motion is switched off and not switched on Then wait 5 minutes switch off State: Program Not running Motion is switched OFF start timer Motion is switched ON no effect because there is no code in ELSE State: Program running and in middle of WAIT countdown Motion is switched OFF restart timer Motion is switched ON no effect because there is no code in ELSE If motion is switched off Then wait 5 minutes switch off State: Program Not running Motion is switched OFF start timer Motion is switched ON no effect because ON not a trigger in IF State: Program running and in middle of WAIT countdown Motion is switched OFF restart timer Motion is switched ON no effect because ON not a trigger in IF Wouldn't both programs result in exactly the same code execution? What am I missing?

There are two settings that you can alter via the Admin Console that greatly affect how the MS-II works, "Motion Report" and "Motion Timeout". "Motion Report" controls whether the motion sensor sends both an ON command when it detects motion and an OFF command when motion has ceased. "Motion Timeout" controls how long there must be no motion before the motion sensor decides that motion has ceased. Out of the box, I believe the MS-II has "Motion Report" set to "ON and OFF". If you plan to use a program to turn OFF the device you're controlling with the motion sensor, then you'll want to change "Motion Report" to "ON Only" Also out of the box, I believe that "Motion Timeout" is set to 30 seconds. This means that there must be at least 30 seconds of no motion before the motion sensor sends an OFF command. Now here's where things will get confusing. If you're going to use a program to control turning a device off, you don't want the motion sensor to send an OFF command and so you think the "Motion Timeout" doesn't matter. Unfortunately, the way Insteon implemented the motion sensor code, the "Motion Timeout" also controls the time period during which the motion sensor won't send another ON command. At this point, an example is probably called for: Say you have the motion sensor set to only send ON commands and you have the timeout set to 1 minute: You walk into the room and the motion sensor sends an ON command, it also starts a one minute countdown 15 seconds later, you leave the room 15 seconds later, you reenter the room - since you're still within 1 minute countdown, the motion sensor does not send another ON command, but it does restart it's own 1 minute countdown 15 seconds later, you leave the room, 15 seconds later, you reenter the room - (see above) So long as the motion sensor detects your movement within its timeout period, it restarts its internal timer. This means that you can go long periods without the motion sensor ever sending another ON command even though there is motion. So any program that executes a countdown based on no motion gets starved of the knowledge that motion is actually happening. The best you can do is set the "Motion Timeout" to the shortest period allowed (10 seconds), and hope that sometime during the program countdown period (in your case 4 minutes and 25 seconds) there is at least 10 seconds of no motion so that the motion sensor countdown will finish and it will send another ON command which will restart your program countdown period. There is an alternative, but it's often one people don't find acceptable. That is to set the motion sensor up to send both ON and OFF commands, but don't add the motion sensor as a controller in a scene to control the device. Instead use a program to both turn the device ON and OFF. This way the motion sensor does what it does best, reports both the presence as well as the absence of motion. There are at least two downsides though: Using a program to turn ON a device after it receives an ON command from the motion sensor adds a lag to the device actually being turned on. Usually at least a second, and sometimes more Device to device communication (i.e. motion sensor to light) is more reliable than program to device communication. For two reasons: device to device uses acknowledgements and retries, while program to device does not; and device to device only needs one command to succeed (ms to device) while program to device needs two commands to succeed (ms to program followed by program to device).

I would have said you only need the "not switched on" if you have something in the ELSE clause.

Hate to break it to you but I've been waiting three decades for the home automation market to mature further and all it's done in that time is become more fragmented. Maybe the next ten years will be different, but I ain't holding my breath.

That is good news. It means the device is acting like any other Insteon device. What I don't see in that log is any indication that the ISY is acting on those status messages. So I'm left to assume that the ISY is ignoring them because the Device Subcategory is unknown.

By the way, from those links we can tell that the device reported to the ISY that it belongs to Device Category (01), Device Subcategory (58), and is Version 54. Device Category 01 refers to "Dimmable Lighting Control". Device Subcategory 58 is unknown to the ISY.

Well I'm mystified now. The top line indicates the PLM is a responder to the device and it matches up with the last line of the Device Links Table you posted. I know in your initial testing you said that you didn't see any communication from the device in the Event Viewer when you controlled the device locally. After you performed the Restore Device, did you try looking for communication in the Event Viewer when you controlled the device locally?

That's interesting since if I read the Device Links Table correctly, the last line (E2 01 4A A3 BA 01 00 01) indicates that the device is a controller for the PLM. Your PLM address is 4A.A3.BA, isn't it? You can check via Tools->Diagnostics-PLM Info/Status. If it is, then that would suggest that the PLM Links Table is missing a link indicating that it is a responder to the device. We could try scanning the PLM Links Table for the appropriate link, but since it is likely hundreds of lines long, it might just be easier to delete the device from the ISY and re-add it to see if the missing link is created. If you want to scan the PLM Links Table, you'd look for anything that has 60.11.12 in the middle of the line. If the line starts with an E2 it means the PLM controls the device, and if it begins with an A2 it means the PLM responds to that device. Edit: Unless the PLM has a link that says it responds to a device, it won't accept any traffic from the device, and thus no communication will be reported in the Event Viewer.