IndyMike

So, rather than telling @CoolToys why what he was seeing couldn't happen, I tried some "stress testing: Constructed a program with 29 devices and the same wait sequence he used. Used a Set variable = 1 at the beginning and set variable = 0 at the end (to test if the program completed). Triggered the program with a 2477D switchlinc using a control "switched off". Seven (7) of the devices were plug-in's (lamplincs, ApplianceLincs, IOLincs) powered on a strip. These were for inducing communication failures Bottom line - the program ALWAYS finished. My variable was always set to 0 at the end. There were a crazy number of "other" programs being triggered as I went through the sequence. None of this stopped the test program from completing. Turning off the strip of 7 devices caused PLM retries and ISY Retries. Again - the program finished. There was 1 very interesting development during the testing - The following would show up at in response to some commands to the PLM. The 1st line is the command from the ISY to the PLM. The 2nd line is the PLM acknowledging the command. The 3rd line is very strange. The PLM is sending a 2nd ACK back to the ISY. I have never seen this before, nor can I find any reference to it on the forum. Has anyone ever seen this message? Seems like the PLM is getting confused or out of synch with the ISY. Tue 12/24/2024 08:44:50 AM : [INST-ACK ] 02 62 18.93.83 0F 13 00 06 LTOFFRR(00) Tue 12/24/2024 08:44:51 AM : [INST-ACK ] 02 62 54.A5.19 0F 13 00 06 LTOFFRR(00) Tue 12/24/2024 08:44:51 AM : [INST-ACK ] 02 62 54.A5.19 0F 13 00 06 LTOFFRR(00): Duplicate or ACK for a different device Test Program - bold items are installed on power strip CoolToys - [ID 0068][Parent 0067] If 'Basement / BSMT Fam Cans' is switched Off Then $FirstDining.On = 1 Set 'Basement / BSMT Back Room' Off Set 'Basement / BSMT Back Room Load' Off Wait 5 seconds Set 'Basement / BSMT Fam Cans' Off Set 'Basement / BSMT Fam Rm Sconce' Off Set 'Basement / BSMT Game KPL Overhead A' Fast Off Wait 5 seconds Set 'Basement / BSMT Game Sconce' Off Set 'Basement / BSMT KPL Game' Fast Off Wait 4 seconds Set 'Basement / BSMT Kitchen Cans' Off Wait 4 seconds Set 'Basement / BSMT Kitchen Ceiling' Off Set 'Basement / BSMT Stair' Off Wait 5 seconds Set 'Basement / BSMT Stair 2' Off Set 'Basement / BSMT Storage' Off Set 'Basement / BSMT Video Cans' Off Set 'Basement / Basement Bed' Off Wait 5 seconds Set 'Basement / Furnace Room' Off Set 'Basement / Test LampLinc' Off Set 'Basement / Test Matthew Lamp' Off Wait 5 seconds Set '13.32.8B-Sensor / 13.32.8B-Relay' Off Wait 5 seconds Set 'Basement / Test-Sensor / Test-Relay' Off Set 'Basement / Test 13.07.33.1' Off Wait 5 seconds Set 'Basement / Test 13.05.A8.1' Off Wait 4 seconds Set '0F.82.A9.1' Off Set 'Basement / BSMT Back Room' On Wait 5 seconds Set 'Basement / BSMT Back Room Load' On Set 'Basement / BSMT Fam Cans' On Set 'Basement / BSMT Bed' On Wait 4 seconds Set 'Basement / BSMT Fam Rm Sconce' On Set 'Basement / BSMT Game KPL Overhead A' On Set 'Basement / BSMT Game Sconce' On Wait 4 seconds Set 'Basement / BSMT KPL Game' On $FirstDining.On = 0 Else - No Actions - (To add one, press 'Action')

@CoolToys, let me start by saying that I agree with what @oberkc has posted above. Dividing things into two programs avoids a number of pitfalls with negative triggers (program exits) and can be made to ignore "re-triggers". I am focused on your item #3 where you changed your trigger to "control". This should have looked like the following: If 'MB Door Keypad 70 9B C0All On' is switched Off Or 'MB Window Keypad.On' is switched Off Then Set XX on Wait Set yy off Wait If this program did not run to completion there are very few explanations: 1) One of the Keypads was manually "switched on" (program exit), or "switched off" (program re-trigger). 2) You have another program that is being triggered and is "retriggering" or disabling your Bedtime program. This could be a "run if", "run then" or "run else" statement. Or a program disable or stop statement. 3) Your Eisy is re-booting. I'm assuming that you are not manually pressing buttons on your KPL's, so we can eliminate #1. For #2, you can search your programs to see if anything is trying to call or modify your bedtime program. It may be easier to place all your other programs in a conditional folder and disable the folder. That's a favorite tactic of mine when things aren't making sense. For #3 I am not much help. I don't have an Eisy and can't tell you how to detect a reboot. I have seen posts on the subject.

This should not be the case if you are triggering from an Insteon Keypad. Keypads can be configured for Toggle (On/Off), Non-Toggle On, and Non-Toggle Off. Momentary is not an option. I constructed the following programs as an example. The "BSMT fam cans" device is a 2477D Switchlinc dimmer. Both of the programs will evaluate true when triggered positive, and false when triggered negative. Beyond that: 1) Local device control will trigger both programs on/off. 2) The control program WILL NOT trigger if the Switchlinc is turned on/off by a scene, program, or Admin console. 3) The Status program WILL trigger if the Switchlinc is turned on via scene, program, or Admin console. Control On If 'Basement / BSMT Fam Cans' is switched On And 'Basement / BSMT Fam Cans' is not switched Off Then Set 'Basement / SC BSMT Back Room' Query Else - No Actions - (To add one, press 'Action') Status on Test Status - [ID 0065][Parent 0067] If 'Basement / BSMT Fam Cans' Status > Off And 'Basement / BSMT Fam Cans' Status is not Off Then Set 'Basement / SC BSMT Back Room' Query Else - No Actions - (To add one, press 'Action')

Interesting disconnect on the SD card size. I can see where the Wiki specifies 32Gb in multiple places. The ISY994i User Guide 4.2.8 specifies 16Gb max. I've been using the User guide since I keep a PDF locally. I suspect that the Wiki is more up to date, but it would be good to get clarification. Can someone verify the 32Gb SDCards work?

Right with you my friend... I can't begin to remember what I've forgotten. Google is my friend... The Wiki link that @Techman posted offers useful techniques for mitigating the issue. I have 7 motion sensors and Many KPL's. Since implementing the mitigations, I'm down to around 1-2/year events. There are a number of posts around that detail All-On detectors. Having said that, I can't locate any. I use a 2457D2 LampLinc located next to my PLM. The LampLinc is linked to the PLM, but is not part of any scene or program. Edit - Not completely correct since the LampLinc is a member of MyLighting which is effectively a scene. The thinking here is that the only way this device turns on is if an All-ON event occurred. I use a program to poll the device every 5 minutes. If the program sees an ON status, it shuts down MyLighting. Note that this is not foolproof. It assumes that the LampLinc will be turned on during an even. There have been reports of "partial" all-on events. The protocol supports commands to any scene #, so it is certainly possible to have random scenes activated. Query Program All on Poll - [ID 0023][Parent 000A][Run At Startup] If Time is Last Run Time for 'All on Poll' + 5 minutes Then Set 'All On Detect' Query Else - No Actions - (To add one, press 'Action') Shutdown Program All on response - [ID 0013][Parent 000A][Run At Startup] If 'All On Detect' Status > Off Then Set 'My Lighting' Off Else - No Actions - (To add one, press 'Action') Another theory is that the events became prevalent after the introduction of the 2413S PLM with RF. The RF interface allows MS's and other devices to bombard the PLM out of synch with the powerline. I have tried disabling the RF receiver on PLM's with inconclusive results. In the end, I can't reliably re-produce the problem, so I can't reliably say that I've fixed it. In other words, I got tired and lost interest. It seems that some of the older posts on All-On events have been removed or locked. Here's a walk down memory lane for anyone interested. how-to-test-insteon-devices-for-all-on-vulnerability all-on-removed-in-what-firmware-version-of-switchlinc-dimmers all-on-all-off-incidents considering-disabling-isy-due-to-all-on-bug-process-to-remove-it another-all-on-event devices-turn-on-or-off-unexpectedly random-all-on-event

In a couple of words - yes and yes. No one has actually documented an All-On collision. There are numerous theories about how and where the collisions occur. My personal favorite is that they occur at the serial interface between the ISY and PLM. As far as I know, current PLM still contain the all-on command. Many modules have had the all-on response removed, but there is no clear listing of devices/firmware revisions. You can test to see which of your devices is susceptible by issuing an All-On command from the admin console - All-On Susceptibility Testing

Understand completely. That's why I asked the question. Insteon can work on a 3 phase system. Unfortunately, PLM's will not be able to communicate X10 on 3 phase. The older X10 CM15a interfaces would communicate @120 degrees for 3 phase applications. On the flip side, I have 3 phase motor controllers that operate off split single phase 240V power. Again, that's why I asked for clarification on the house/fan power.

The XPF is a rather capable in-line filter. It's rather large, normally requires a 3-gang box to install. The XPNR is a shunt filter. As such, it's rather small and does not have a specific current specification. It will absorb both Insteon and X10 signals. It can be effective if placed near the offending device with a good line length back to the electrical panel (higher impedance). You mentioned that your fan was 3-phase. That's rather unusual for a home install. Is your home also 3-phase, or is this a 240V powered fan with a 3-phase inverter? I ask because Insteon PLM's are not configured to provide X10 in a 3 phase installation (120 degree phase separation).

FWIW: The following Reddit post is related to Enphase communication issues due to a powerwall installation. The noise spectral plot shows noise peaks in/around the 120k to 130KHz region (X10/Insteon range). The noise appears to be Worse when the Powerwall is lightly loaded. As others have noted, not an easy problem to solve. Caveats - this is a power from 2019. Things may have changed on newer Powerwall versions/firmware updates. https://www.reddit.com/r/Powerwall/comments/sr2j2l/powerwall_and_line_noise_affecting_enphase/?rdt=64923

@CoolToys, Have a look at your motion sensor for the guest area. It can disable/interrupt your bedtime program if it fires at the wrong time. I just recently replaced batteries on two MS I sensors that were behaving badly (no low battery set). Aside from that, when programs fire without a trigger or re-enable themselves I start thinking about SDcards and the like. A program should Never spontaneously enable itself (you can enable a program with another program). I have no experience with the Eisy, so I will bow to others who do.

@gempro, not sure if you have been able to resolve your issues. Your event log did show an interesting detail that was not part of the scene test. After the test completed, the ISY attempted to write an update to your 46.2F.CA device (RemoteKP.F). This update failed with a Nack response from the KPL. The Nack indicates that your new PLM is not currently linked to this device. It looks like with update may have been automatically triggered after you performed the scene test. In a system that is having communication issues, that can complicate things. Try turning OFF the automatic writes (screen capture below) and restoring this device. If the restore completes successfully, perform a link table read/compare to double check. Continue in this manner with your other devices. If the restore does not work, come on back and we can develop a plan B. <html><font color="red">----- Keypad LED F Test Results -----</font></html> <html><font color="red">[Failed]</font> KeypadF (44 7D D7 6)</html> <html><font color="red">[Failed]</font> RemoteKP.F (46 2F CA 6)</html> <html><font color="red">----- Keypad LED F Test Results -----</font></html> Wed 10/23/2024 07:18:32 PM : [INST-TX-I1 ] 02 62 00 00 12 CF 13 00 Wed 10/23/2024 07:18:32 PM : [INST-ACK ] 02 62 00.00.12 CF 13 00 06 LTOFFRR(00) Wed 10/23/2024 07:18:32 PM : [Ext MH ] Unexpected Ack imCmd=62 cmd1=LTOFFRR 0x13 Wed 10/23/2024 07:18:32 PM : [46 2F CA 1 ] Link 27 : 0F20 [A22A711973FF1F01] *Failed Writing [A22A711973FF1F01] Wed 10/23/2024 07:18:32 PM : [All ] Writing 8 bytes to devices Wed 10/23/2024 07:18:32 PM : [INST-SRX ] 02 50 46.2F.CA 71.19.73 AB 2F FF (FF) Wed 10/23/2024 07:18:32 PM : [Std-Direct Nack] 46.2F.CA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Wed 10/23/2024 07:18:32 PM : [D2D EVENT ] Event [46 2F CA 1] [ERR] [1] uom=0 prec=-1 Wed 10/23/2024 07:18:32 PM : [ 46 2F CA 1] ERR 1

@CoolToys, the program you posted above has the variable $sOccupied_Guest_Edit is 0 as a qualifier. I'm not sure where this is controlled, but if it is altered it could cause your program to exit prior to completion. The waits in your program will allow this. Some lights could be left in the incorrect state, and the variable $sBedtime = 1 might not be set.

@CoolToys, as others have indicated, a program that uses ONLY the condition "Time is XXXX" will show true until it triggers false. Unfortunately, it will Never trigger false. As a result, you can't use the program status as an IF condition in another program (it will always be true). As a workaround, you could use the "From XX to XX" clause that would evaluate to a false after the time period. The following program will evaluate to false 1 minute after sunset. This becomes difficult if you have embedded "waits" within your program (which you do). You wind up with a race condition between the program and the If statement. It's far better to separate the Trigger (if statement) and program (then clause) into two separate programs so the IF statement won't terminate your running program. Outside Sunset - [ID 0015][Parent 0002] Outside Sunset - [ID 0015][Parent 0002] If From Sunset For 1 minute Then Set 'Outdoor / SC Outside Sunset' On Else - No Actions - (To add one, press 'Action') I'm not sure that's the answer to you issues as nothing that you've posted above would results in your variables both being true ("sEarly_Morning" and "sNight") Please do review your code for any programs that use a program "true" status as a condition.

@SimonK, thanks for taking the time to post back the results of your ticket with UD. It sounds like this problem may have been frustrating users for some time. Curious whether it applies to the Polisy and possibly the ISY994. In the meantime, celebrate by spinning up some Queen "another bug bites the dust"

@Guy Lavoie, thanks for the clarification. Looks like I added 2 + 2 and came up with 22. One question regarding your eisy/Zstick configuration - does it support S2 security? The link that I referenced above (@lilyoyo1) indicated that S2 security was only supported for the Zmatter board. Wasn't sure if that had changed.

Ouch! When did UD UNSUPPORT the Zooz 700 stick? That's a rather major new item and a big departure from previous statements. Did I mis-understand? https://forum.universal-devices.com/topic/34826-zwave-700-series-tips-and-tricks/

@ELA, Nice Photo. That's a failure that I have yet to encounter. I am worried that you may have voided your warranty 😉. Like you, I am on the fixed income plan. When Smartlabs closed their doors I began playing with Z-Wave devices. When Insteon restarted. it was their prices that kept me away. For future planning, you may want to visit the Zooz site (Zen51 Dry contact). They have a number of innovative products that make some financial sense. Unfortunately, if you are still using a ISY994, you will need to upgrade to take advantage of the 700/800 series Zwave features. Zooz plusses: Inexpensive relays, dimmers, and embedded (typically 50% less) Select relay and dimmer devices can be used in N-way configurations with standard mechanical switches (additional cost savings). EX - I had a 5 way insteon setup (4 insteon switches) that I replaced with 1 Zen77 and 3 mechanical switches. Very nice rocker feel. As good or better than Insteon. Smooth dimming performance. I replaced some 2477D's I had controlling 2 chandeliers. The 2477D's produced "herky jerky" dimming with the 45W candelabra LED bulbs. The Zen77's were very smooth even with a slow ramp rate. Responsive customer support - reported an issue with what I termed "excessive communication" using a power monitoring plug-in. Customer service responded, we conversed, and 3 months later they informed me of a firmware update that they had developed to address the issue. OTA firmware updates of devices. No issues with all-on (Insteon issue that still plagues some devices). Full disclosure - I really like these guys. I want to make sure they stay afloat.

I'm thinking that the IF clause is re-evaluating to false after you have run the "Then section" of the program. Your 20 second waits will allow the program to exit. Try separating into two programs (1 program for IF and 1 for Then).

@larryllix, I was unaware (or forgot) about the psudodevice using the Alexa interface. It appears that similar triggers can be accomplished by publishing variables through the portal. Not my cup of tea. I understand that this is my issue. I started with the ISY26 in the way back because it was a local solution to home automation. I've managed to stick with that for most of my ISY994 and Home assistant implementation. Not willing to go to the Dark Side (pun intended) of internet automation. As stated earlier, I have a very different view of scene status. I wan to know if ANY device in a scene (bsmt, 1st floor, 2nd floor, outside) is on so I can display it on a keypad and turn All Scene Members off. My thing - but that's what home automation is, right?

This is precisely the thinking that led to where we are now. We could never agree on what constituted the status of a scene. In trying to please everyone, UD did nothing - and pleased no one. If they had tried something, it would have been a starting point that could have been built upon... I am quite pleased by the scene status that HA currently gives me. If I upgrade my ISY994, I will try the Virtual plugin. I'm quite sure I could find applications for it.

@Guy Lavoie, nice find and good job realizing the possible applications. This is what happens when a new set of eyes looks at an old problem. Rather than enumerating all the ways the problem can't be solved, the new eyes provide a solution. If I could figure out a way of running this on my ISY994, I'd be all over it. I guess it's one more vote for upgrading to the Eisy...

The links for 33.D7.B7 are showing a mismatch, but they are probably OK. The LSb is being set to 1 for some reason, but probably won't cause any harm. A restore will correct this, but it's likely to return. Device 34.E7.8B is a controller for group 00. It's very likely your PLM. The links for 33.10.4F look valid. Your deck lights are listed as a responder to the 33.10.4F switch. There should be in a scene on the admin console showing 33.10.4F as a controller and your 34.09.80 as a responder.

It's listed as a "beacon test" in the full device manual (not the quick start guide). Not all that easy to find these days. Here's one for a 2477D - https://cache.insteon.com/documentation/2477D-en.pdf If you perform this on your PLM, it will signal all the devices in your home that are within range. Devices will flash: Green - opposite phase Red - same phase Nothing - out of range or doesn't support function

@Techman, very interesting. Wasn't aware the ISY994 supported Zwave 700 series dongle's. Which manufacturers are compatible?

That sounds like a definitive result. Built in microwave replacement definitely NOT recommended. I'm looking for a "what changed" item. Unlikely that your microwave suddenly started absorbing more signal. You mentioned constriction and power outages. Is it possible that one or more of your phase coupling devices got damaged/upset? You may want to try the 4-tap phase test on your PLM to see if things are still coupled. Easier than installing an XPF filter.