kclenden

@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.

I don't see how it would be causing a problem, but I'm curious why you have both "On Network is False" and "On Network is not True". I've only ever seen "not True" included in an IF when there is something in the ELSE that is supposed to run upon a TRUE state, but you don't have anything in the ELSE.

Given all the symptoms you've reported, I'm not convinced the PLM was the source of your flickering problem. I'm more likely to think it was a victim of the whatever event caused the flickering. The PLM doesn't control the power going to each device. It can only send messages to the devices instructing them to perform an action for which they have been programed. Perhaps the PLM was flooding the powerline with messages and that somehow caused flickering, but... if that was the case then when you removed the PLM and replaced it with another, the flickering should have stopped. It seems like your timeline is something like: Came home and lights in pantry, keypad and dimmer switch were flickering, but no other lights or switches were flickering Replaced dimmer switch and tried to link it to Polisy All hell breaks loose and now all lights, keypads, and switches in the house are flickering If that's an accurate summation, some more information would be helpful: Were the lights in the pantry, keypad and dimmer switch all on the same electrical circuit? After shutting off the power to replace the dimmer switch, installing the new switch, and turning the power back on, were the pantry lights flickering? Was the keypad flickering? Was the new switch flickering? Once the flickering throughout the house started, did it continue non-stop? Was it flickering when the power company and/or the electrician game out?

You could use a state variable to track the status of your wireless door sensor. Something like: If 'Door Sensor-Opened' Status is On Then $sDoorSensorOpen = 1 $sDoorSensorOpen Init To $sDoorSensorOpen Else $sDoorSensorOpen = 0 $sDoorSensorOpen Init To $sDoorSensorOpen This program will set the state variable "sDoorSensorOpen" anytime the door sensor status changes and then save it to non-volatile memory which survives an ISY reboot. Then you just use the variable "sDoorSensorOpen" in your programs.

How old is the switch? Older switches allowed an X-10 address to be assigned to a device so that it could be controlled by X-10 commands. I had a switch acting weird and eventually traced it to the fact that an X-10 address had been assigned at some point (though not by me). What kind of reset? If it was a factory reset at the switch that would wipe out any assigned X-10 addresses as well as any erroneous Insteon links which might solve your problem. If it was simply removing the switch from the ISY and then adding it back, you could still have erroneous links or X-10 addresses.

If that fixed the problem, it implies the the PLM Links Table had lost some records. That can be a sign of a failing PLM. I'd recommend doing a count of the records in the PLM Links Table now and then every so often checking it again to see if the number changes without you adding/removing new devices or scenes. You can get a count of the links in your PLM Links Table via Tools->Diagnostics->Show PLM Links Table. Then click "Start". It will take a while, but eventually all the links will be listed. When that is done, click "Count". That number shouldn't change* unless you add or remove devices and/or scenes. * if the ISY is interrupted via an event while it's listing the links in the PLM Links Table, it will stop listing links and you'll get an incorrect count. So you may want to run the listing several times until you get a consistent count.

You don't. That actually doesn't show a problem. The only difference between the rows is that one has "EA" and the other has "E2". They're effectively the same thing. You see when the original link was created, it was "E2", but as the devices are used they detect whether there are communication issues and adjust the second part of the byte accordingly. The ISY "Compare" function doesn't take this into account and reports as mismatch (which there is) but it's not a mismatch that matters. That most certainly isn't the cause of your scene issues. The cause is that there isn't an "E2" record for your PLM. Since the ISY copy of the device Links Table also doesn't have an "E2" record, using "Restore Device" isn't going to solve your problem. When UD looks at the mismatch issue, which isn't really a problem, ask them about the missing "E2" record for your PLM. As far as I know, the only way to fix that will be to relink your switch to your PLM.

Not quite kosher. The first hexadecimal number of each row indicates whether the the device is a responder or controller. There should be an "Ax" and an "Ex" row that contains the address of the PLM. For example, the first row and seventh row that starts with "A2" says that the switch is a responder to the PLM. The second hexadecimal number "00" and "19" indicate the scene. There is no "E2" record for the PLM. That row would indicate that the switch is a controller of the PLM. It needs to be there so that when the switch changes states, it will send a command to the PLM. Note the "EA" records in the 4th-6th rows. Those indicate that the switch is a controller of other devices (presumably other switches). Because they're there, the switch will send a command to those other devices whenever it changes states. Without an "Ex" record for the PLM, the switch will not communicate its state changes to the PLM. At the bottom of the dialog that shows the device links should be a "Compare" button. Click it and it will compare the device links with what the ISY thinks the device links should be.

Insteon works by linking devices to each other via Links Tables in each device. Given that you've replaced your PLM, and the issues you're having, it seems likely that your Links Table(s) are not correct. You can do a cursory check of this by looking for device addresses in the corresponding Links Tables. First, determine what your PLM address is. Do this by using Tools->Diagnostics->PLM Info/Status. You should see an address specified by 3 hexadecimal numbers separated by periods in the form xx.xx.xx. Next look at the switch's Links Table. Do this by right-clicking on the switch and choosing Diagnostics->Show Device Links Table. You should see several rows of links that consist of 8 hexadecimal numbers. The 3rd, 4th, and 5th are the address of a linked device. You should see your PLM address in several of the rows. Do you?

This description has me confused. You say you have an On/Off module but then say it's a controller for a scene. Is it actually a switch? Then you say it controls a network resource to turn on the main audio amp. So it's an On/Off module but it doesn't actually control the load for the audio amp? It would be helpful to know the model # of the On/Off module. This would seem to rule out the module itself as the cause of the problem. How did you actually replace the old module with the new module in the ISY control panel? Did you use the "Replace Device" option, or did you manually recreate the links between the module and other devices. If you used the "Replace Device" option, you might try doing a factory reset on the device and recreating all the links manually. If there was an aberrant link in the old device causing your problems, using "Replace Device" might have copied it into the new device. In your description above, you mention a KeypadLinc button. Is that only a responder in the scene, or is it also a controller? If it is also a controller, then it might be causing the problem. You might try doing a factory reset and then a "Restore Device" on the KeypadLinc.

You can't see the Device Links Table for an individual keypad button. You have to display the Device Links Table for the entire keypad (i.e. right-click on the top line of the keypad list). All of the Device Links Tables look correct. I've taken each one, sorted them by the first five columns and then tried to explain what each link represents: I also experimented to see if the ISY will see device links that are created externally (i.e. created manually between devices) and the answer is YES. So the records shown above should represent all of the links in each device. All of that leads me to believe that things should be working which leads me to the conclusion that maybe they are. Looking back at the screenshots from your original post it looks like the "Master BR Chandilier" is coming on at 50% no matter which controller is used. However, when you used "Robn Chandilier Contrl" that switch came on at 100% even though the "Master BR Chandilier" came on at 50%. Is that what you're actually seeing? If so, you can fix that by setting the Local On-Level for "Robn Chandilier Contrl". You do that by selecting "Robn Chandilier Contrl" in the Admin Console and setting its "On Level" to 50%. You'd also have to do that for "Robin - MBR Chandilier". If that's not what you're actually seeing then I'm stumped.

@Brian H's suggestion to check the PLM Links Table makes sense. It sounds like the link table in the PLM has become corrupted. The ISY relies on the PLM to see insteon traffic. The PLM only accepts unsolicited insteon traffic from devices that have a record in its links table. I think you'll probably have to restore the PLM links table with a copy from the ISY.

If you right-click on each of the controllers in the scene and choose "Diagnostics->Show Device Links Table" and post a screen shot of each, we can check to see if the correct links are actually in the memory of each device.

You should select one of the controllers that isn't working as you expect it should and post a screenshot.

How old is the GFCI socket? I have a similar setup, though the Insteon switch is ahead of the GFCI socket (inside the house), while the pump is plugged into the socket and outside. It worked without a blip for 14 years then started occasionally tripping. Replaced the GFCI socket four years ago and has been blip free since. Replaced a friend's GFCI socket about a year ago because it started tripping regularly and she's had no problems since. So as @MrBill says it's possible the GFCI outlet is bad, and the older it is the higher I would say the likelihood.

That I know of, the only difference between the ON/OFF/DIM commands and the Set Backlight command is that the former use a Standard-length message while the latter uses an Extended-length message. What this means is that the ON/OFF/DIM commands send 10 bytes while the Set Backlight command sends 24 bytes. All of the documentation that I've seen indicates that both Standard and Extended messages are broadcast by both RF and powerline. If there is interference on the powerline, I guess it makes sense that a 24 byte message is more likely to be corrupted than a 10 byte message. Still, I wouldn't expect the shorter messages to always make it through. I would expect some of them to be corrupted.

While that could explain how the ISY is getting out of synch with your programs, it probably won't contribute to a solution. If the ISY tries to change the backlight level and fails, it's probably because of failed communication. Either the device never received the original command and didn't change its backlight level, or it did receive the command, changed its backlight level, and sent an acknowledgement but the ISY never received it. In both cases, the Event Viewer log is going to show the same thing - Insteon command sent but no acknowledgement. The only way you'll know whether it was the command not being received by the device or the acknowledgement not being received by the ISY is to visually confirm the backlight level at the device.

After some testing, while I was wrong about the ISY not sending out an ON command if it thinks a device is already ON, I have confirmed that the ISY does not send out a backlight command if it thinks the device is already set at that backlight level. I did this by creating a program that set a switch backlight to 50%. Then I ran that program multiple times. The first time the program is run, there is a corresponding Insteon command in the Event Viewer. All further executions of the program result in the "Writing 0 bytes" message. Then I manually changed the backlight level from the AC. The next execution of the program resulted in an Insteon backlight command in the Event Viewer. So I'm guessing that the ISY attempts to prolong the life of the memory of devices by not writing data it thinks is unnecessary.

It might be helpful if you posted your programs as well. It's clear from the Event Viewer log that the ISY is not sending any Insteon commands at 1:59:00, 2:00:29 and 2:00:59. My guess is that the ISY thinks the device backlight is already set at the level your program specifies and thus does not send out an Insteon command - similar to how the ISY won't send an On command if it thinks the device is already on. So, for debugging purposes, you might try querying the devices first, and then sending the backlight command, though I don't know if the backlight level is returned as part of a query response. You could also try setting the backlight level to an unwanted level first, and then to the actual level you desire. If either of those things makes the process more reliable then it would seem likely that it is an issue of the ISY not sending out commands it deems unneeded to reduce powerline activity. UPDATE: Just did a little testing and the ISY does actually send an ON command even if it thinks a device is on. Not sure what I was thinking above... I'll blame it on Monday. Still, you might try the two suggestions above to see if they impact whether the ISY sends out the backlight commands.

What? Doesn't the preceding "c" make everything sort based on the "c", not the "Z"?