IndyMike

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

Possibly. It would depend on: Distance from your house to the photocell (wire length or RF distance). Size of the enclosure for your photocell (will the Micro On/Off fit). Temperatures at the enclosure. You're in Texas so cold probably isn't a problem. How about heat? I'll be the first to admit that it's nice to have all your outside lights operate in unison. It's rather classy. I had a similar situation with a post lamp that I fought for years, After numerous photocells, Insteon bulbs, and inlinelincs I finally wound up with Dusk to Dawn bulbs Cheap and stupid simple - Just the way I like it: Amazon Basics Dusk to Dawn Bulb Edit: Another thought would be to find where the circuit enters your house. It likely originates at a GFCI outlet, possibly in your garage. If so, you might be able to install the Micro On/Off module in the box with the GFCI. That would put it in a protected environment. You would need to bypass the Photocell.

I guess we'll have to re-wind to my previous post. Your MS II's behave differently than mine. I have no problems triggering the sensor in the Off cycle regardless of which mode it's in.

You are sensing the MS II On with a Program and then turning the Lights OFF after 4X seconds. If you are issuing the OFF prior to ~ 50 seconds you are still within the MS II 40 second duration. Motion at this point will not trigger an on. Edit: Timing is for 1 MS II on battery. Your timing may be different.

Have a close look at your switches before you start down this path. The PWB is inexpensive epoxy glass and rather easy to damage with heat. The Triac leads are bent at a right angle (you can see the bends in my photo) so the Triac can be riveted to the metal case and soldered into the board. Save your old Triac so you have a "template" for bending the leads. You'll need a pop-rivet (or similar) and thermal paste to attach the new Triac to the AL case. Not trying to talk you out of anything. Just letting you know what is involved and what materials you'll need.

@larryllix, sorry if I'm beating a dead horse, but... Some of this is coming back to me as well. That probably means that we've been doing this far too long. I've been doing some testing, and I do agree with your statement that the MS II sensor On/Off timing is rather inaccurate. The table below shows "On/Off Time Error" for one of my MS II's (battery). In all cases the Off time exceeds the MS II setting by a substantial %. If you re-trigger the MS II within the On window it will reset the internal timer and thereby extend the off time (as you have noted). Note that Test 1 - is longer in every case. This is likely due to the fact that I am programming the MS II during the 1st activation. Once I knew the On/Off cycle timing for the sensor, I programmed it for On Only operation ( On Only Trigger below). In every case I was able to trigger the sensor On AS LONG AS I WAITED for the On cycle to complete. The times for the On Only Trigger are longer as I was manually timing the cycle and manually activating the sensor. I don't believe there is a problem with the On only mode of the MS II. The issue is the relative inaccuracy and variation of the Sensors timing (all modes). Viewed as % error, the timing stabilized @5% once the duration extended past 5 Minutes. There is apparently a bit of overhead involved in the timing, communication, and processing of the signal. All in all, I don't think that a 10% error is all that bad (2 minute duration) and I certainly don't worry about a 6 - 12 second error in the duration. If you applications require more accurate duration's, you should be able to "Test" the on/off timing and compensate the duration. Switching to On Only mode with a compensated duration should give you the performance that you're looking for. On/Off Timing - MS II Set to 20 seconds Off Issued after 32 seconds Tue 08/20/2024 01:55:40 PM : [ 4A 72 A0 1] DON 1 Tue 08/20/2024 01:56:12 PM : [ 4A 72 A0 1] DOF 1 MS II Sensor On Only Timing - Sensor Set to 20 Seconds Sensor Manually Re-triggered at Times Noted Tue 08/20/2024 02:07:36 PM : [ 4A 72 A0 1] DON 1 Tue 08/20/2024 02:08:09 PM : [ 4A 72 A0 1] DON 1 Manual Trigger at 33 Sec Tue 08/20/2024 02:08:39 PM : [ 4A 72 A0 1] DON 1 Manual Trigger at 29 Sec Tue 08/20/2024 02:09:08 PM : [ 4A 72 A0 1] DON 1 Manual Trigger at 28 Sec

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

You were pretty much spot-on Brian. I opened up one of my old 2476D's. Last letter is a "W". BTA12-600SW. Shows up OK below. Looks much clearer with a 10x loop.

That's unfortunate. I thought it might be a difference in battery (mine) vs USB (yours) power. Tested the same configuration as above. After turning OFF, My MS II will respond with a ON within seconds. Wouldn't be the 1st time something was broken by a firmware/software change (just ask Delta, banks, hospitals...). Not sure it helps, but this is the configuration I'm running on the MS II's. I do turn off the Cleanup messages to cut down on traffic.

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.

You are correct - I do not see an OFF Duration. That would be rather annoying. I ran another test with the MS II set to 5 minutes. I extended the ON time by re-triggering the sensor. Sensor turned the light off after 6 Min 30 Sec. I was able to re-trigger the sensor back ON 5 seconds later. If you see something different it could be hardware/firmware revisions? My sensor is a V.46 unit R3.1 with a date code of 4317. Sun 08/18/2024 11:10:51 AM : [ 4A 72 A0 1] DON 1 6 Min 30 Sec Sun 08/18/2024 11:17:21 AM : [ 4A 72 A0 1] DOF 1 5 Sec Sun 08/18/2024 11:17:26 AM : [ 4A 72 A0 1] DON 1

@larryllix, I'm confused (it happens a lot these days). I am not sure what you would prefer the MS II to do under these conditions. If I set my MS II for 20 seconds and it doesn't see motion, it sends an OFF (as I would expect). The Event log below shows an off time of 27 seconds. A little late, but I normally use 30 seconds for hallways and stairs. Sat 08/17/2024 03:20:29 PM : [INST-SRX ] 02 50 4A.72.A0 00.00.01 CF 11 01 LTONRR (01) Sat 08/17/2024 03:20:29 PM : [Std-Group ] 4A.72.A0-->Group=1, Max Hops=3, Hops Left=3 Sat 08/17/2024 03:20:29 PM : [D2D EVENT ] Event [4A 72 A0 1] [DON] [1] uom=0 prec=-1 Sat 08/17/2024 03:20:29 PM : [ 4A 72 A0 1] DON 1 Sat 08/17/2024 03:20:56 PM : [INST-SRX ] 02 50 4A.72.A0 00.00.01 CF 13 01 LTOFFRR(01) Sat 08/17/2024 03:20:56 PM : [Std-Group ] 4A.72.A0-->Group=1, Max Hops=3, Hops Left=3 Sat 08/17/2024 03:20:56 PM : [D2D EVENT ] Event [4A 72 A0 1] [DOF] [1] uom=0 prec=-1 Sat 08/17/2024 03:20:56 PM : [ 4A 72 A0 1] DOF 1 The same sensor will extend the OFF command indefinitely if it continues to see motion. The following log is from my same sensor when it continues to see motion. The Off command was extended by 1:30. This is what I would expect. What was it that you were expecting? Sat 08/17/2024 03:21:16 PM : [INST-SRX ] 02 50 4A.72.A0 00.00.01 CF 11 01 LTONRR (01) Sat 08/17/2024 03:21:16 PM : [Std-Group ] 4A.72.A0-->Group=1, Max Hops=3, Hops Left=3 Sat 08/17/2024 03:21:16 PM : [D2D EVENT ] Event [4A 72 A0 1] [DON] [1] uom=0 prec=-1 Sat 08/17/2024 03:21:16 PM : [ 4A 72 A0 1] DON 1 Sat 08/17/2024 03:23:18 PM : [INST-SRX ] 02 50 4A.72.A0 00.00.01 CF 13 01 LTOFFRR(01) Sat 08/17/2024 03:23:18 PM : [Std-Group ] 4A.72.A0-->Group=1, Max Hops=3, Hops Left=3 Sat 08/17/2024 03:23:18 PM : [D2D EVENT ] Event [4A 72 A0 1] [DOF] [1] uom=0 prec=-1 Sat 08/17/2024 03:23:18 PM : [ 4A 72 A0 1] DOF 1 I do use a program to manage my Kitchen sensors I with a short timeout) to ensure that no one has been around for XX minutes prior to shutting down the lights/ That's an entirely different configuration that unfortunately consumes batteries.

Followup to my previous post. Using a wait after the trigger will NOT work. The motion sensor goes into sleep mode very quickly after it transmits it's On/Off status. I played around a bit and found that the following 2 programs seem to work well with my ISY994. The "enable program" runs a timer on the "last run time" for the query program. After one hour, it enables the query program. After the enable, the next time the sensor is triggers (and turns off) the 2nd program will query it. The query program is normally disabled to prevent over polling the motion sensor. After an enable and a Off trigger, it runs a query. 10 sec's later (time allowed for the query) the program disables itself. This program is set to "run at startup" to reset the "last run time" in the 1st program. I've had roughly 85% success with this program. Querying the motion sensor is a time sensitive process. Other Insteon activity can delay the query and allow the sensor to go into sleep mode. Nor worries, after another 1 (or xx) hours you can try again. I really don't know how much functionality this adds. I've seen temperatures ranging from -25 to 130+ on the same sensor. Illumination also seems to vary substantially. Hopefully battery level is consistent. I'm currently monitoring 3 battery sensors and will report back. Test Sensor Enable - [ID 005C][Parent 004E] If Time is Last Run Time for 'Test Sensor Query' + 1 hour Then Enable Program 'Test Sensor Query' Else - No Actions - (To add one, press 'Action') Test Sensor Query - [ID 0053][Parent 004E][Not Enabled][Run At Startup] If '4A.72.A0.1 Motion' is switched Off Then Set '4A.72.A0.1 Motion' Query Wait 10 seconds Disable Program 'Test Sensor Query' Else - No Actions - (To add one, press 'Action')

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.

@johnjces, I'm curious what features are not working for you? You mentioned the Led On/Off setting. I can confirm that this setting DOES work using my ISY994. I was able to disable the LED on 2 of my MS II's using both battery and powered mode. You also mentioned the EISY GUI. Most of the features in the GUI were designed for USB Powered devices. As @paulbates indicated, the MS II performs nicely on USB. Like you, I use battery mode on my devices. Since the MS II's don't actively send Level information, you will normally see an empty screen as follows. I'm guessing that's what you're referring to. The MS II can be queried for this information, but it must be done when the device is awake. I normally don't worry about the temp and luminance, but battery level would be nice. The following program can be used to query the MS II after it detects motion. It does work, but I would be very careful using this since it generates a good deal of communication with the sensor. I had initially tried this with the sensor switching ON (not recommended). The query worked, but the sensor was trying to send Off commands while the ISY was querying it (not good). If you want to deploy this, I would put time constraints on it (don't execute more than X times/day) and experiment with "waits" after the trigger. Polling too often will run down your battery and runs the risk of communication collisions. Not trying to talk you out of "different" motion sensors. I have both Zwave (Zooz ZSE 40) multisensor and am test driving some Zigbee mmWave occupancy sensors. The have nice features that include accurate temperature and light monitoring. In the mean time the Insteon sensors are still serving me well for basic motion detection. BSMT Stair Sensor Query - [ID 0044][Parent 0066] If 'Motion/RF / BSMT Stair.1 Motion' is switched Off Then Set 'Motion/RF / BSMT Stair.1 Motion' Query Else - No Actions - (To add one, press 'Action') After program query

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.