IndyMike

Thank you Paul. I am familiar with the switch monitoring technique. I've been using it since my first ISY26 back in 2007. It most certainly does work. The technique allows me to monitor each floor of my house (1st, 2nd, basement) and display the status on keypads so I can turn monitor/turn off sections of the house as I am leaving or going to bed. It is also, unfortunately, very easy to break. Devices moving in/out of scenes, devices being replaced by dissimilar devices, naming issues all contribute to broken status programs over the years. With IF statements of 25 to 75 devices, it's easy to miss things. This maintenance issue could be avoided if we had access to the scene state (on/off). Somehow the ISY is communicating this information to Home Assistant (very nicely). As @Guy Lavoie stated, this is a feature request - not a problem to be solved through a work around.

This discussion has been going on since scenes were implemented by Smartlabs. The bottom line is Insteon does not support either Scene "Status" or "control states" and creating an architecture for this has been LOW PRIORITY for UDI. One workaround that I have found is to use the Home Assistant integration for the ISY. Home Assistant treats scenes as "switches" or "relay devices". They are either ON or OFF. Curiously, I noted that Home Assistant shows scenes as active (ON) if ANY scene member has a Level > Off. Conversely, all scene members must be Off for a scene to be shown as Off. I use this functionality for triggering programs on Home Assistant. I seriously doubt that Home Assistant is divining the scene status on it's own. Unfortunately, we don't have access to the information on the ISY platform. Seems a little ridiculous, but there are far worse things in life.

That's it. The top "On" button and bottom "Off" button on the 5 button KPL are essentially Non-toggle buttons. The ON can only send On commands (or bright) and the Off can only send Off commands (or dim). As we discussed above for the Motion sensor, multiple consecutive ON commands will NOT show up in the Log (same for multiple Off). The device communicates and will show up in the event viewer (and trigger programs), but repeated commands will not be reflected in the logfile. I have never used the "buttons grouping" feature. As recommended by UDI, I use scenes to accomplish similar things. Look for programs that may be triggered by the devices turning ON. You may want to disconnect the loads to see if this eliminates the issue. Good answer. I've used the vacation mode feature on a few controllers. Being from the "dogpatch" section of the country, I don't have a real application for the feature. I can understand it's value for others. Not sure how repeatable this problem is... If you manually run your program can you force the problem to occur? If so, you can copy the program and try removing devices to see if the problem goes away. I think there is a way to accomplish what you want. It involves switching the KPL to 8-button mode and then joining the A+B and G+H buttons in a scene. From the outside the KPL looks like your 5-button. A+B buttons are Non-toggle ON (as they are on a normal 5 button) and the G+H buttons are Non-toggle Off. It allows you to control the lighting on all of the buttons - when all buttons are off, the KPL can be completely dark. If you're interested, we could start another thread on the configuration (may already be something on the forum). Probably better to figure out your current issues 1st.

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

Sorry, I'm out of town so I can't really try/test anything at the moment. Unfortunately, this is looking more and more like next level stuff... I'd hoped that there was a simple bypass that could be used to insert the arm code. Doesn't appear so. The Template code actually goes in your Configuration.yaml file. You'll need an editor to access the file (I use Studio Code Server). There are a number of tutorials on how to install various editors and HOW TO CHECK YOUR YAML FILE FOR ERRORS. As you probably realize, having a configuration file that is free from syntax errors does not guarantee you won't crash your system. Have a recent backup at the ready. There are also other Alarm Panel's that are available (manual, template, Alarmo - HACS). https://community.home-assistant.io/t/manual-alarm-template-alarm-or-alarmo/616032

If you were using 500 Series Z-wave devices I am not surprised that you were displeased. Like you, I was looking hard as Smartlabs began it's freefall. I wound up using Zooz 700 series Z-wave switches. Much improved. They are now my go to for switches/dimmers. One of the huge plusses is that you can mix a single switch/dimmer in a N-way installation with MANUAL switches. Huge $ savings. As far as the EISY supporting the Zigbee Presence Sensor - really don't know. I do not have the EISY to test and I would think that UDI would being by supporting the more mainstream devices first. I decided to test drive these because they were battery powered (most are USB). They work well enough, but generate a lot of traffic. Haven't had them long enough to assess battery life. Battery life is normally the strong suit of Zigbee devices. I've had some temperature sensors operating outdoors (wide temperature swings) and in my freezers (-15F) for over a year.

@Bladerunner, you're correct about needing a code to Arm the Elk. Not sure why that is. You can certainly add your alarm code to an automation. You can also add the Code to the configuration file and invoke it using a template. Template Alarm Code I honestly don't have a problem entering the code on my phone. Now if I had Tablets in the house where other family members were involved - that would be another matter. Dashboards are very personal. I tend to go for lists and charts (I'm an Engineer). Not everyone's cup of tea. Google around and you'll likely find something that catches your eye. Try it - if you don't like it (you probably won't at first) keep looking.

In a word - YES. HA ISY Integration: https://www.home-assistant.io/integrations/isy994/ The integration will "bring in" Switches, sensors and scenes from the ISY. Home assistant is very good at "controlling" these devices and displaying their states. If you want to control something within HA using the ISY, you'll need to write an automation: If Scene KPL XX goes from off to on and if Fan is off Then Turn on fan Note that the SC Fam Fan trigger below is a ISY Scene activated by a KPL

@Bladerunner, The short answer is Yes, it can be done. I have used the ELK integration on the ISY994 for years. I am not familiar with the PG3 ELK implementation on the PolISY and EISY. I added the ELK integration to my HA system about a year ago. It exists in parallel with the ISY994. It presents a standard ELK panel to allow you to arm/disarm the system. I don't have UD Mobile, so I went to the HA integration to allow me to monitor the system when away from home. I appears to be able to do most of the things the ISY did (speak, bypass zones, etc) but I have not made use of these. If there is something specific you are looking for, let me know.

@Hoosier Daddy, I should clarify that I am using the ZWave and Zigbee sensors on Home Assistant. I am still running the ISY994 for Insteon. The Human Presence Sensor is from AliExpress - Tuya ZG-204ZM. I purchased 2 of them. They added to HA easily and have a number of controls for "Tuning" the motion and mmWave sensor. I have one in my office which works very well. The second sensor is in our Family Room (16 x 18). I am still tuning this one. The room presents a number of challenges with large windows, TV, Sound system, and obstacles. The challenge is to be able to detect my wife sleeping on the couch (under a cover) and not falsely detect the TV/Sound system when we're out of the room. It's close, but not quite there yet. My only real complaint is that these devices are "chatty" (as are most things Tuya). When there is motion, the sensors let you know CONSTANTLY. It would be easy to overload a Zigbee router if you had a number of these. I probably wouldn't purchase more for that reason. Here's a review from the SmartHomeScene: https://smarthomescene.com/reviews/zigbee-battery-powered-presence-sensor-zg-204zm-review/ I will say that my sensor has a couple more "tuning" controls than shown in the review.

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.

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.