kclenden

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"?

There are two link parts for every scene. The first is a record in the Links Table of the controller. That record basically tells the controller (in your case the 2477D dimmer switch) to send out a scene message whenever it is physically turned ON or OFF. The second is a record in the Links Tables off all the responders. That records tells each responder how to react (ON level and Ramp rate) whenever they see the scene message from the controller. When you restored each of the responders, you removed the record in their Links Tables that told them to respond to the scene message from the controller. The controller would still send out the scene message since you didn't restore it as well, but the responders would no longer react to the message. Since all of the responders are now again reacting to the the message from the controller, something has recreated the record in their Links Table for that scene. If it is indeed a phantom record in the Links Tables of the responders that is causing this behavior, a factory reset and restore will have the same result - temporarily breaking the link between the controller and the responders until whatever is recreating the link does its thing again. Since we can reasonably rule out you manually adding the responders to a scene using the Admin Console as the cause for the recreated links ?, is there any chance that you once used an "Adjust Scene" command in a program and later deleted the scene but forgot to update the program? If it were me, I'd try factory resetting the controller and all responders, followed by a restore of each from the ISY. Then I would open the Event Viewer, set it to level 3, and allow it to run for 24-48 hours. If during that time the link between the controller and responders comes back then you should be able to see communication in the Event Viewer that corresponds to the recreation of the links which should help narrow down what it happening.

The top external photo (Photo 1) shows an Insteon ID. It's directly below the QR code on the black portion of the switch to the right of the photo.

Your program currently turns the scene on at sunset and turns it off at sunrise the next day. That's not what you want to do. You want to change how the responder reacts at sunset and the reset how it acts at sunrise the next day. So you need to use the Adjust Scene command. Replace "Set 'motion test' On" with "In 'XXXX' Set 'YYYY' To On, Z retries" where XXXX is the controller and YYYY is responder and Z represents the number of retries - to do this you must choose "Insteon" Replace "Set 'motion test' Off" with "In 'XXXX' Set 'YYYY' To ignore" where XXXX is the controller and YYYY is responder Since you're using a mixed Zwave / Insteon scene, replacing your scene with the program that @oberkc provided should work just as well as modifying how your scene reacts based on time. The reason is that for mixed protocol scenes, the ISY has to act as a middleman anyway, so you shouldn't lose any reaction speed by using a program instead.

Click the right pointing triangle that I've circled in red:

@larryllix's warning should be taken seriously, but I don't think it should keep anyone for using a condition to disable a folder. Consider that any and every program can be stopped in an unknown state due to a power failure. So you really should have some way to gracefully recover whether you're using folder conditions to control program execution, or not. In my case, for long running programs in folders that are controlled by a condition, I use variables to know whether the program has completed. If the program hasn't completed, then I either do not allow the folder control condition (a variable) to be changed, or I allow it to be changed, but then execute cleanup programs based on the values of the variables that are used to monitor the program execution. Having said all that, the only things I'm controlling are lights, and pond pumps. So if I've screwed up and haven't correctly accounted for all cleanup conditions, the worst that happens is a light (or completely submerged pond pump) remains ON or OFF when I would rather it be in the opposite state.

To put a finer point on @larryllix's points, here are a couple things you should know: Only one instance of a particular program will ever run. So if something causes a program to restart, the old instance just ceases to exist at whatever execution point it was at when the new instance starts "Wait" statements allow a program's IF to be reevaluated. This means that if at any point during the wait, a trigger in the program's IF goes off then the current instance of the program ceases, and the IF is reevaluated and either the THEN or ELSE section will begin executing as the new instance of the program. In your program, the humidity reading is the trigger for the IF. So when it changes, the IF will be evaluated. So in your case, let's say the humidity was 70 and the THEN started to execute. It turns the light on and then enters a 10 second WAIT. If at any point during those 10 seconds the humidity changes from 70 to something else (could be 70.1 or 69.9 or anything else), then the current instance of the program will cease to exist, and a new instance will begin by evaluating the IF. Depending on the the result of evaluating the IF, either the THEN or the ELSE will begin to execute.

Here is another post where the different kind of responder links are described: I haven an Insteon Only setup. There are only two times that I see a link type of "default". The first is when a controller is listed as a responder in its own table of responders. This makes sense since there is no actual link between the controller and itself. The action that the controller executes as a responder when it is physically activated is solely defined by its own hardware and not a link that the ISY can store in the device's Links Table. The other time I see a link type of "default" is when a one-way device (e.g. a motion sensor) appears as a responder in its own or another controller's responder table. By design, all scene controllers are also defined as responders in the scene. But a one-way device like a motion sensor really can't respond to other controllers. So it seems the the ISY defines its link type as "Default". What this means is that the ISY doesn't try to create an Insteon responder link in the device's Links Table and simply leaves it to the device to perform its default action. I'm not sure any of the explanations of link types has been completely accurate. For example, @Chris Jahn consistently says that default means "Takes the command the ISY receives from the controller and forwards it on to the responder device." But I don't believe this actually happens for Insteon commands. And when you think about it, it wouldn't make sense for the ISY to do that for Insteon devices since for the ISY to have seen the command the command must have appeared on the power line (or RF which eventually gets repeated on the power line) and in that case all other Insteon devices should also have seen the command. It only makes sense for the ISY to forward a command that is crossing protocols (e.g. Insteon to Zwave, or vice versa). So all of the out loud thinking above is my way of saying that for an Insteon only installation, whenever you see a link type of "Default" you can interpret it as the ISY not being involved in any way in the communication between the controller and responder. When you see "Insteon" as a link type, it means the ISY originally defined the links between the controller and responder, but after that it is not involved in the communication between the two devices (unless it is the controller).