kclenden

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.

How do you know it's running? You haven't posted the actual programs that you're using, and the pseudo-code you've provided has been inconsistent. First you say the program sets a light ON, then you say it enables another program. In any case, you should first be sure that the program you suspect is running is indeed running. Click the "Programs" tab, and then below it click the "Summary" tab. Find the suspect program in the table and look at the "Status" column. If it says "False" then it last ran the ELSE section. If it says "True" then it last ran the THEN section. Now look in the "Last Run Time" column. What time does it show? Do you ever see the "Status" as "True" with the "Last Run Time" showing a time between 5:30pm and 5:30am?

I know you know this, but just for clarity, that should read more like "Anytime the status of a trigger in the IF statement changes, the IF will be reevaluated." In the OP's first post, the program has a trigger (the status of the switch) and a filter ($Int_MotionGolf - if it's actually created as an INTEGER variable and not a STATE variable).

Again, none of my devices are in folders so I've never run into this. While the device you circled seems to be in the main folder, other devices in the scene appear to be in folders. I don't know whether that matters, but given the warning about the device not being in a folder, it wouldn't surprise me if that also goes for other devices in scenes with the device being replaced. What happens when you replace a device is that the ISY/Polisy/eISY goes through all the links in the PLM Links table and all the links in each device Links table and replaces the old device's address with the new device's address. If being in a folder affects the device being replaced, I'm not sure why it wouldn't affect any other device having its Links table update. This would seem to matchup with your experience whereby after replacing the device you can control it, but it doesn't seem to have any connection to other devices in the scene. Or it may be, as you sorta touched on, that the problem is the scenes being in a folder. I don't know, but just wanted to add to the conversation in case it sparked something from the memories of other longtime forum members. Probably too late now, but it would be interesting to have a copy of the PLM Links table, and the Links table from several of the devices in the scene both before and after the device was replaced. That would allow us to tell exactly what is, and isn't happening. Just as importantly, if you were to submit a bug report to UD, it would be very helpful to them, I think. Edit: Actually, on second look, maybe the device you circled is in a folder called "Main". On my ISY, devices that aren't in a folder have nothing in the folder column.

It appears from your screenshot that the device being replaced is in a folder. I have read in other posts that you cannot replace a device if it's in a folder, but haven't actually tried it myself.

You'll also want to look for instances where you see an [INST-TX-I1] in the Event Viewer, but don't immediately see a following [INST-ACK] with the command echoed back with an "06" appended. In these instances, the device shouldn't have reacted to your command from the Admin Console because the PLM never received the command from the ISY to send onto the device. While I really suspect your PLM, I suppose you might try disconnecting the cable between the PLM and the ISY (looks like a network cable but isn't) and reconnecting it just in case it is somehow loose.

There are PLM repair services available online. I think Insteon itself even offers this service. That would be much cheaper than replacing your entire setup. 🙂 Additionally, the last I heard new PLMs were slated to be available by March, I think. Though there will probably be a run on them right off the bat since they've been unavailable for so long.

Everything in the first log segment looks normal. "Hops Left" is either 3 or 2 which seems to indicate good communication between PLM and Device. Here's an interpretation of the log segment so you have an idea of what things mean: Thu 01/19/2023 14:18:08 : [INST-TX-I1 ] 02 62 57 65 64 0F 11 4D 02 = Start of Command 62 = Send Message 57 65 64 = Address of Device the Message is being sent to OF = Message Flags (OF means Direct Standard Message, Hops Left=3, Max Hops=3) 11 = Command for Device to Execute (11 means GO ON) 4D = LEVEL (Level is in HEX 00-FF so 4D/FF which is 77/256 is 30%) Thu 01/19/2023 14:18:08 : [INST-ACK ] 02 62 57.65.64 0F 11 4D 06 LTONRR (4D) PLM echos back to ISY the command and appends 06 to indicate that the message was successfully sent Thu 01/19/2023 14:18:08 : [INST-SRX ] 02 50 57.65.64 40.53.13 2F 11 4D LTONRR (4D) 02 = Start of Command 50 = Message Received 57 65 64 = Address of Device the Message is from 40 53 13 = Address of Device the Message is being sent 2F = Message Flags (2F means ACK Direct Message, Hops Left=3, Max Hops=3) 11 = Command for Device to Execute (11 means GO ON) 4D = LEVEL (Level is in HEX 00-FF so 4D/FF which is 77/256 is 30%) Thu 01/19/2023 14:18:08 : [Std-Direct Ack] 57.65.64-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Thu 01/19/2023 14:18:08 : [D2D EVENT ] Event [57 65 64 1] [ST] [77] uom=100 prec=0 Thu 01/19/2023 14:18:08 : [ 57 65 64 1] ST 77 (uom=100 prec=0) Shows ISY interpretaton of received message ---------- Thu 01/19/2023 14:18:15 : [INST-TX-I1 ] 02 62 57 65 64 0F 13 00 02 = Start of Command 62 = Send Message 57.65.64 = Address of Device the Message is being sent to OF = Message Flags (OF means Direct Standard Message, Hops Left=3, Max Hops=3) 13 = Command for Device to Execute (13 means GO OFF) 00 = Means nothing just default for command 13 Thu 01/19/2023 14:18:15 : [INST-ACK ] 02 62 57.65.64 0F 13 00 06 LTOFFRR(00) PLM echos back to ISY the command and appends 06 to indicate that the message was successfully sent Thu 01/19/2023 14:18:16 : [INST-SRX ] 02 50 57.65.64 40.53.13 2B 13 00 LTOFFRR(00) 02 = Start of Command 50 = Message Received 57 65 64 = Address of Device the Message is from 40 53 13 = Address of Device the Message is being sent 2B = Message Flags (2B means ACK Direct Message, Hops Left=2, Max Hops=3) 13 = Command for Device to Execute (13 means GO OFF) 00 = Means nothing just default for command 13 Thu 01/19/2023 14:18:16 : [Std-Direct Ack] 57.65.64-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 01/19/2023 14:18:16 : [D2D EVENT ] Event [57 65 64 1] [ST] [0] uom=100 prec=0 Thu 01/19/2023 14:18:16 : [ 57 65 64 1] ST 0 (uom=100 prec=0) Shows ISY interpretaton of received message For the second log segment. I didn't break out the meaning of each log line since they could be interpreted using the same method as above. "Hops Left" is always 2. This indicates good communication between PLM and Device, but the fact that it's always 2 could mean that the device is always depending on another device to relay its messages, or could just be a function of limited data. If it's the former, it could be a Device that is on a different power leg than the PLM, or an RF only device that is out of RF range of the PLM and needs a power line device to receive its message and forward it. Here are some comments on things that look strange. I also ignored the first four lines since they seemed to be two different commands colliding in time: Thu 01/19/2023 14:28:22 : [INST-TX-I1 ] 02 62 54 A0 07 0F 13 00 It doesn't appear that the ISY received an acknowledgement from the PLM ---------- Thu 01/19/2023 14:28:35 : [INST-TX-I1 ] 02 62 54 A0 07 0F 13 00 Thu 01/19/2023 14:28:35 : [INST-ACK ] 02 62 54.A0.07 0F 13 00 06 LTOFFRR(00) Thu 01/19/2023 14:28:37 : [INST-SRX ] 02 50 54.A0.07 40.53.13 2B 13 00 LTOFFRR(00) Thu 01/19/2023 14:28:37 : [Std-Direct Ack] 54.A0.07-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 01/19/2023 14:28:37 : [D2D EVENT ] Event [54 A0 7 1] [ST] [0] uom=100 prec=0 Thu 01/19/2023 14:28:37 : [ 54 A0 7 1] ST 0 (uom=100 prec=0) Log indicates OFF was successful ---------- Thu 01/19/2023 14:29:09 : [INST-TX-I1 ] 02 62 54 A0 07 0F 11 FF It doesn't appear that the ISY received an acknowledgement from the PLM ---------- Thu 01/19/2023 14:29:24 : [INST-TX-I1 ] 02 62 54 A0 07 0F 11 FF Thu 01/19/2023 14:29:25 : [INST-ACK ] 02 62 54.A0.07 11 FF 00 02 62 54 A0 07 0F 11 FF 06 02 50 54 A0 07 40 (00) The PLM's acknowledgement back to the ISY seems to be corrupted. It seems to be a partial acknowledgement, a full acknowledgement, and a partial received message all crammed together. Thu 01/19/2023 14:29:29 : [D2D EVENT ] Event [54 A0 7 1] [ERR] [1] uom=0 prec=-1 Thu 01/19/2023 14:29:29 : [ 54 A0 7 1] ERR 1 The ISY recognizes the acknowledgement as an error ---------- Thu 01/19/2023 14:29:37 : [INST-TX-I1 ] 02 62 54 A0 07 0F 12 00 Like above, it doesn't appear that the ISY received an acknowledgement from the PLM ---------- Thu 01/19/2023 14:29:50 : [INST-TX-I1 ] 02 62 54 A0 07 0F 12 00 Command 12 is a Fast ON Thu 01/19/2023 14:29:50 : [INST-ACK ] 02 62 54.A0.07 0F 12 00 06 LTON-F (00) Correct acknowledgement from the PLM Thu 01/19/2023 14:29:50 : [INST-SRX ] 02 50 54.A0.07 40.53.13 2B 12 00 LTON-F (00) Thu 01/19/2023 14:29:50 : [Std-Direct Ack] 54.A0.07-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 01/19/2023 14:29:50 : [D2D EVENT ] Event [54 A0 7 1] [ERR] [0] uom=0 prec=-1 Thu 01/19/2023 14:29:50 : [ 54 A0 7 1] ERR 0 Thu 01/19/2023 14:29:50 : [D2D EVENT ] Event [54 A0 7 1] [ST] [255] uom=100 prec=0 Thu 01/19/2023 14:29:50 : [ 54 A0 7 1] ST 255 (uom=100 prec=0) Log seems to indicate Fast ON was successful. Not sure what ERR 0 means. ---------- Thu 01/19/2023 14:29:57 : [INST-TX-I1 ] 02 62 54 A0 07 0F 14 00 Command 14 is a Fast OFF Thu 01/19/2023 14:29:57 : [INST-ACK ] 02 62 54.A0.07 0F 14 00 06 LTOFF-F(00) Thu 01/19/2023 14:29:58 : [INST-SRX ] 02 50 54.A0.07 40.53.13 2B 14 00 LTOFF-F(00) Thu 01/19/2023 14:29:58 : [Std-Direct Ack] 54.A0.07-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 01/19/2023 14:29:58 : [D2D EVENT ] Event [54 A0 7 1] [ST] [0] uom=100 prec=0 Thu 01/19/2023 14:29:58 : [ 54 A0 7 1] ST 0 (uom=100 prec=0) Log indicates Fast OFF was successful Given that there are log entries that seem to indicate the PLM didn't acknowledge messages from the ISY, and log entries that seem to indicate the PLM sent corrupted data to the ISY, my guess is that your PLM is failing. I suppose it could also be that the RS232 port on the ISY is failing, but I've never read of that happening.

Here are some things you can try: In the Admin Console start the Event Viewer (Tools->Diagnostics->Event Viewer). Set the Level to "3. Device communication events". Now try commanding devices from the Admin Console. Look in the Event Viewer log for "Std-Direct-Ack" lines. This is an acknowledgement from the device to the ISY (via the PLM). Note the "Max Hops" and "Hops Left" values. The higher the "Hops Left" value the better. It's a measure of how many times a message was repeated by another device as it traversed from the sending device to the receiving device (each repeat causing hops left to go down one). The more times a message has to be repeated, the harder the network it working to get the message to its intended destination which generally means there is some interference on the line. Try connecting a device to the same circuit as the PLM and repeat #1. You should see "Max Hops" and "Hops Left" always being equal. Some people wire switches to a three-prong plug and put the PLM and switch on the same power strip. Shutoff all circuit breakers but the one for the PLM. Turn on a single circuit breaker for another device. Try commanding that device as in #1 above. If communication is good, then turn on another circuit breaker. Test and repeat until turning on a circuit breaker significantly degrades communication

My time choices are always grayed out like that but I am able to make selections by clicking them. Have you tried shutting down your Admin Console and then restarting it?

Yeah, that's what happens when I try to program on the fly without testing. Many a prof in college used to notice the same kind of thing. 😁

@larryllix's solution can make for a very robust system. If you're looking for something simpler and want to stay with one program, then create an integer variable (I'll call it iUsageAlertSent) and use it to filter when the notification is sent. Something like this: MBR Aux Heat On If 'Emporia / Vue 2 L / L11 MBR Furnace' Killowatts > 5.0000 kW And $iUsageAlertSent = 0 Then Set 'Notification Controller / Service Pushover polyglot' Send Sys Short With Params To all Priority=Normal Format=Monospace Sound=Pushover (default) Retry=30 Expire=60 $iUsageAlertSent = 1 Else $iUsageAlertSent = 0 This program will send one notification when the usage exceeds 5kW and won't send another until the usage drops below 5kW and then exceeds 5kW again. You want to use an integer variable and not a state variable because you don't want your program to be triggered when you change the variable value from 0 to 1 or 1 to 0. When you create the integer variable, you should set the INIT value to 0 so that whenever the ISY is restarted the variable will default to 0. If you'd rather have a time limit control when another notification can be sent, then create two programs - something like this: MBR Aux Heat On If 'Emporia / Vue 2 L / L11 MBR Furnace' Killowatts > 5.0000 kW And $iUsageAlertSent = 0 Then Set 'Notification Controller / Service Pushover polyglot' Send Sys Short With Params To all Priority=Normal Format=Monospace Sound=Pushover (default) Retry=30 Expire=60 $iUsageAlertSent = 1 Run Program 'Reset Usage Alert Sent' (Then Path) Else - No Actions - (To add one, press 'Action') Reset Usage Alert Sent If Then Wait 10 minutes iUsageAlertSent = 0 Else - No Actions - (To add one, press 'Action')

I'm actually surprised it takes 30 seconds to alternate. Your second program checks the status of the Color Christmas Tree Lights and then changes that status. If they're on, it turns them off. If they're off, it turns them on. But when you turn them on, or off, you cause the IF of the second program to execute again. So you've created a runaway program that runs the THEN, followed by the ELSE, followed by the THEN, followed by the ELSE into infinity.

I think you mean to say "are not triggered". A question and an observation: Why do you perform "$sSys.MM.DD Init To $Clock.scratch" when the program is set to run at startup anyway? Shifting the results two decimal places to the left makes it look nice except when you're comparing to a day of the month that is 10, 20, or 30. When you enter something like "1.10" into the Number field of the Condition, the ISY strips off the trailing "0" making the Then look something like this: If $sSys.MM.DD <= 1.1 Then Else Not a deal breaker, but at first glance it may not be clear whether you're checking for Jan 1st, or Jan 10th.

"Controller" has a specific meaning. If you say something is a controller, you're saying that it controls a scene. If you use the status of device in the IF of a program, then the device is a trigger. Based on that, I assume you are saying that the motion sensor is not a controller for any scenes, but is a trigger for at least one program. When you say you removed the motion sensor, what do you mean? Did you physically remove it from its location, or did you remove it from being registered with the ISY? If it's the former, you can check to see whether its a controller for any scenes outside the ISY by turning it back on so that the ISY can talk to it and then perform TOOLS->DIAGNOSTICS->SHOW DEVICE LINKS TABLE and choose the motion sensor. If it runs off a battery, you'll need to make sure it's ready for communication, but you should see a pop-up telling you how to do that. Any lines where the first, of the eight, byte (2-characters) columns begins with an "E" indicates the motion sensor is a scene controller. You should see at least one line where the 3rd, 4th, and 5th byte columns contain the address of your PLM. If you see any lines where the 1st byte starts with an "E" and 3rd, 4th, and 5th columns have an address other than your PLM , then the motion sensor is a controller for another scene that your ISY doesn't know about. Edit: I'm assuming the motion sensor is an Insteon device. If not then nevermind. 😄

In an earlier post you said: If the program shows green in the program list during the designated time period, then it did not ignore sunset. It was triggered at sunset which is why it shows green in the program list. Your best options are to either look through the log (Tools->Log) or start the Event View as @MrBill suggested: The Log might show you that the lights are coming on and then being turned off. If so, you'll know what time and that should help troubleshoot. If the Log shows nothing useful, the Event Viewer might show commands being sent by the ISY but never being acknowledged. If neither the Log or Event Viewer provides helpful information, then you might have links between devices that the ISY know nothing about. You mention a driveway motion sensor. Perhaps there are some manual links between it and the lights that you're unaware of.

The OP indicated that the ELSE didn't used to exist, and that it was added as an attempt to fix the problem. So there must be some other program that runs to shut off the driveway light scene, or as you say, the scene would never have shut off.