kclenden

"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. 😄

There have been discussions about link counts which give some pretty detailed information. As a summary, the count of links that are in the PLM can be a diagnostic tool because links are only created when you add Insteon devices to the ISY, or add devices to scenes. They are only deleted when you remove Insteon devices from the ISY or deleted devices from scenes. Knowing that: If you don't get a stable count of links in the PLM and you're not adding/deleting devices and/or scenes then the PLM is likely faulty If you don't have at least twice as many links in the PLM as Insteon devices added to the ISY, then something is likely wrong because whenever you add an Insteon device to the ISY, at least two links are created (one that says the PLM is a Controller, and one that says the PLM is a responder). It's those links that allow the ISY to control devices and that allows devices to report their status back to the ISY. If the device is more complex than a switch (say a Keypad) then more than two links are added when the device is added to the ISY. Generally you'll have more than twice as many links in the PLM as Insteon devices because every time you add a device to a scene, at least one more link is added to the PLM. From the points above, you can generalize that you should see at least two links per Insteon device and two links per scene (because why create a scene if you don't want to control at least two devices). If you have fewer than 2xDevices + 2xScenes links in the PLM then something is likely wrong. What you do with the info depends: If the link count is 0, then you should try File->Restore Modem. This will instruct the ISY to rewrite all the links in the PLM with the backup that it maintains. Afterward, if the count is still 0 then the PLM is likely faulty. If the link count is more than 0, but less than 2xDevices + 2xScenes then you probably also want to try File->Restore Modem. If the link count is > 900 then your PLM is probably full. Newly added device links might not be added correctly, or old ones might be wiped out. You either need to delete Insteon devices from the ISY, reduce the number of scenes, or reduce the number of devices in the existing scenes. Sometimes weird power happenings can cause the PLM Links table to become corrupted, and a Restore Modem has you back up and running just fine for a long time. Other times, a corrupted PLM Links table means the PLM is failing and the Restore Modem only fixes things for a short time.

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.

For me your post again appears as the last post on page 40. So isn't it really 1000 redux?

Maybe the thread has grown so large that it is collapsing under its own gravitational pull and will eventually become a black hole - though some might say that has already happened. ?

That's interesting because your post appeared at the bottom of page 40 and @Teken's appeared at the top of page 41 in my browser. Now neither of your posts is the 1000th. I understand how your 999th post is now lower (prior posts deleted), but I don't know how your post could have been 999 when you posted and looked at it, but then became the 1000th when Teken and I looked at it. That would require someone to insert a post before yours.

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.

It does seem like @MrBill stole the 1000th post which so rightfully belonged to you. ? But if you went back a couple pages and deleted one of your posts, your 1000th post would then become the 1000th post. ?

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.