IndyMike

Hey @CoolToys, sorry to hear that problems are rearing their heads again. I looked over your logs. There's a couple of things that I see, and some that I don't: I do not see a trigger for your program. Neither your "MB Window Keypad.ON" nor your "MB Door Keypad 70 9B C0All On" show as having been switched on. It's possible that you have these set as Non-Toggle On. In this case the Log would only show the 1st on event. Please confirm. Your HallwayOutletCurio is showing a "ON" status and is immediately followed by an "ON". This can sometimes happen when a device like a lamplinc is connected to a non-resistive load. The load can provide and electrical kick-back and fool the lamplinc into thinking it has turned back on. Please confirm the device type and model. Turn off the local load sensing if equipped. You have many devices and scenes in your program. 11 devices and being addressed individually and you are using 17 additional scenes. Why not put all of them in a single "bedtime" scene and issue a single "fast off" command? This would eliminate a ton of communication and program waits. Are you experiencing issues communicating to some of the devices? Beyond the above, I would guess that you have another program that is being activated and turning (some) things back on. Look at the program summary tab for programs that have run in the same timeframe. You can sort by "Last run time".

Answers to your questions above. Use the scene in your programs and from the Admin console.

@twired, I find it extremely interesting that your program is ONLY executing the Else section. If the IOLinc status NEVER becomes true, I'm not sure how you could be activating the Else multiple times (there is no state change). Are you basing your statement that the IF section didn't run on the Lack of and Email? I'm asking because this might be interrupted by a quick change in the IOLinc status. A quick Off - On - Off might exit the If section and run the Else. Do you have another program that calls the Else section of the alarm program? Are you running a periodic query program on the IOLinc? Please do perform the changes as suggested by @paulbates and @Techman. If things still aren't happy, we can take a look further.

@Blackbird, I'm thinking this is coincidence. Home Assistant shouldn't do anything to prevent an ISY scene from activating. If you have Automations (programs) set up on Home Assistant, It could turn off devices using the ISY. The ISY should have knowledge of this - it will show up in your event viewer and Logfile. Please check - Run a device link table compare on your KPL. If there are corrupted/missing links, do a restore. Manually activate the scene from the ISY console. Chances are you are having communication problems and not talking to the KPL If the scene doesn't work, try device direct communication from the Admin console (turn the KPL itself on, not the scene). Let us know how things go. If you absolutely can't talk to the KPL, we'll need to get a bit more invasive. Edit: Are you running Home Assistant on the EISY or another device?

Could you post the program that is running the Else clause (IOLinc activated)?

Sorry - looks like I was the one that was confused. Back to your normally scheduled broadcast...

As @oberkc indicated, the ISY log should show X10 activity received by the PLM. In the view below, activity on house code F is valid. Activity on House Code P is not. Unfortunately, X10 signals are likely very low level. If you don't have X10 repeaters in your system, it's unlikely the PLM will receive ALL the X10. Time to pull out the age old X10 troubleshooting tools: Look for battery devices that may be failing (motions, etc). These can spontaneously change house/unit code as the battery drains. Trace circuits (flip breakers, unplug devices)- if the problem is isolated to a circuit or phase try filtering or improving signal levels. As @paulbates indicated, try changing house codes. Certain house codes are more prone to noise issues. J is one of them because of the bit coding. I have always gotten spurious signals on P. House code A is typically where battery devices communicate when they start failing. It is possible that an Insteon device has a X10 house code programmed. The only way to eliminate the House code is to factory reset/ restore the device. You may need to head over to the old X10 forum for additional tools.

It sounds like we are confusing terms here. Tazman is referring to the Secondary Buttons on a KeyPadLinc. It looks as if you are referring to a 2477 Dimmer Switch that is a SECONDARY (responding) device in a scene. Please respond whether this is correct. If this is the case, the load should react when the 2477D Leds react. If it does not, you have a defective load, problems with your wiring, or a blown Triac (output stage) in you 2477D.

@eric_allman, glad you made it to the end of the long and winding road... As far as the IRLinc is concerned, I believe these are powerline only devices. You could try plugging it in next to the PLM to see if it will link.

@arzoo, glad to hear you have things under control again. As far as why, not a clue. As stated earlier, there was no evidence that your IOLinc was communicating during the events. But then, disconnecting the IOLinc eliminated the problem. Doesn't make sense on the surface, and probably isn't worth chasing unless it reoccurs. One additional observation - It sounds like you are running the IOLinc in Voltage sense mode (On > ~1.4V/ Off < 1 V). That's a bit more challenging than a simple contact closure. It's possible that you had a bad connection that finally reared it's ugly head making your system more sensitive to line level disturbances (communication on the powerline). People sometimes see this type of powerline activity when their LED bulbs flicker. The communication on the powerline is affecting the dimmer drive level to the Triac powerline the LED. It's possible that the IOLinc could be similarly affected on the measurement side (I don't have a schematic to make an assessment). This is why hitting a solid gnd level ( 0V = off) on the IOLinc is important. It's effectively increasing the signal to noise ratio. You may want to measure the "Sense to Gnd" voltage level (both on and off) to see what your alarm system is putting out. From memory, the IOLinc will indicate OFF with a 0.9V input (< 1V). Unfortunately, that provides you very little noise margin in the event of a disturbance.

That's an excellent response. You must have a 5 V activated siren module. Please check to make sure that you are NOT using "trigger reversed" on the IOLinc. It produces erroneous indications when queried.

@arzoo, when you say you're connecting the "alarm siren" to the GND and S terminals, what type of output is this? The IOLinc terminals normally accept a contact closure type of input. The Sense terminal is capable of 5 Vdc max. It can't handle a speaker level AC input. Beyond that, most siren "Modules" that I've seen require a 12V input. There are probably ways that you can connect the IOLinc to your panel, but I don't think a Siren output is one of them.

When I looked at this previously, I attributed the on/off behavior to activity on the power line + the load. When you tested with the "new" extension cord, was the LL plugged into the same outlet? If so, that's rather damning. You might want to give it a little more time to increase your confidence. After that - extension cords are cheap. I would cut the ends off (make sure no one else tries to use it) and dispose of it.

Please perform your due diligence before jumping to a new technology/protocol. You're accustomed to Insteon and it's very different from the "other" protocols. Rather than jade you with my preconceptions, I would encourage you to read up on WIFI, Zigbee and Zwave protocols. They all have their + and - and I use all of them. Insteon is extremely effective for lighting (scenes and the like). Very few other protocols can match it. Other protocols are far better at security and power (battery devices).

Thanks, I'll set up a test rig. I'm curious if this was the same thing that I had blamed on low wattage dimmable LED's. I'm assuming "lamp cord" the the AWG. My LampLinc is pretty old - V.3B/ R1.5 Date Code 0211.

@paulbates, makes a good point. My judgement is likely clouded by my disdain for the 2450. I could not find any entries in your logs for the address 70.7B.5B. That's a very "high" address for an IOLinc. It's newer than anything in my system. Are you sure it's correct? If it is correct, your logs do not show any IOLinc activity.

@arzoo, can you describe how you're using the IOLinc sensor input. You mention that it's "Hardwired" to the alarm siren?? Voltage sensing? Contact closure? Do you have any Zwave or Zigbee devices in your system?

If I understand you correctly, you are saying that you have an EMPTY extension cord plugged into the LampLinc. It's possible that the extension cord presents enough of a capacitive load that it's confusing the LL. I'd call that a bad extension cord. Can you describe the cord (2 wire, 3 wire, length, AWG)? I'd like to run some tests - never tried this previously.

I do hope you've found your culprit. It's difficult for me to describe my dislike for the IOLinc without using language that would get me banned from this forum. I would very much advise that you find a different sensor to use as the trigger. Describe the application and there are many members that can help. As you indicated, I don't see any reason that having the sensor in the same outlet as the PLM would be a problem. The real problem is using the IOLinc ANYWHERE in your system. They are simply failure prone devices. Could you provide the address for the IOLinc - I'd like to check your event viewer posts for activity.

@eric_allman, Sorry, I know it's painful rebuilding scenes (particularly for a KPL). I wish there was a neat trick to help with all the On-Levels and Ramp Rates - I don't have one. I've spent a good amount of time looking through the rest interface and the ISY SD card. I honestly don't know where the ISY stores this information for scenes. You can interrogate the ISY for Scene Members and Controllers using the rest interface : /your.ISY.IP Ad/rest/nodes/scenes This will open a XML file in your browser (you'll probably be prompted to login first). You can open the file in Excel as a table. That allows you to sort device addresses to determine which scenes they are members of. It does not include brightness or Ramp Rate information. The following is the scene listing for one of my 8 button KPL's @15.C6.C7. Notes: All devices are members of the My Lighting Scene Type 16 is a controller, 32 is a responder. The Device Group is what is stored in the PLM/Device Link tables. This listing shows decimal, the Link Tables and Event Viewer will show Hexadecimal. That's about all I can offer. Be patient, methodical, and take your time. I find that drowning bait and killing brain cells reduces the tension. But then that's my answer to many problems.

@arzoo, I agree with @Geddy that it's probably time to submit a ticket. We've not been able to identify an Insteon trigger for your events. Possible that things are being initiated by a node server/rest event. Best to get the experts involved.

@arzoo, you appear to have a program firing every 30 seconds and generating the timestamps. That's a pretty tight loop. You should be able to locate the program by looking at the program summary tab. You also have a REST command executing every 5 minutes. I'm not sure if this is program related or an external communication.

The program comparison is being performed (IF statement check on 55.FF.B6). If the program or folder is disabled, the THEN/ELSE will NOT be run. This is not an error. My 994I does the same.

@eric_allman, thanks for posting the table. It explains a lot. Probably not going to be a news item, but it's messed up. I'm guessing that your PLM is address 70.8B.6C. I can see a Main button responder record on line 1: 0FF0 (the PLM can control the main button). The only controller record I see for the PLM is on line 5 : 0FD0 for button 5 (only the c btton can control the PLM). The "F2" record on lines 3 and 4 is rather odd. I've never seen bit 4 set to 1 before (normally a E2). Bit 4 is defined by protocol to be "product dependent" (see below) so it may not cause problems - I've just never seen it used. Rather than detailing everything wrong with your table, I think it would be easier to show how "minimum" table should look for a 5 button KPL. The table below is from a "factory reset" KPL that I added to the ISY. My PLM address is 53.BC.3A. The KPL shows 1 responder link to the PLM and Controller links for all of the KPL buttons. Getting back to the point, you need to delete/factory reset/re-link this device. Make sure to make note of the scenes and programs where it's used prior to deleting. I would also delete/reset/re-link any devices that you believe have links to your old PLM. If these are control links, they will bog down your system while your devices try to communicate with a PLM that no linger exists. Feel free to post additional tables if you wish. For anyone interested, the link table data is listed in the modem developers guide (among other places): https://cache.insteon.com/developer/2242-222dev-062013-en.pdf

I understand venting. I do it often - it's a healthy release... I understand your thought process regarding the programs. The difficult part is we don't understand the trigger, so we can't really asses whether the problem has gone away without significant time. There may also be more than 1 program that is being activated (more than 1 folder affected). I am not well versed on plug-ins, mobile-linc and the like. I don't know if these could be the trigger for the 52 after events. What type of alarm are you using? What type of input devices (hardwired or rf)? Your "powering down" to time shift polling programs is a good thought. Please do report back on the results. Since the "beep" seems common to the occurrence, you could search programs that perform this function and work backward. Just saw @Javi's response. Please pay particular attention - these are next level "failure mode" types of upsets that most of us never consider. Lastly - I would consider opening a ticket before you replace the PLM. My comment about replacing the PLM was based on the fact that it was loosing it's link tables. That doesn't appear to have happened to your recently and I would discount this as the source of your current issues. At this point I feel that replacing the PLM would only further confuse things.