IndyMike

@CoolToys, sorry to hear you still have some gremlins running around. Your failed scene is rather curious. The 2476D dimmer is likely powerline only. Surprising that it's the one that responded. The KPL's (V.43 and V.45) are dual band. Would have expected those to have responded. The difference between the 2476D that responded, and the KPL's that didn't, is the path that your scene command took from the PLM to the devices. The path to the 2476d is from your PLM, to the panel, and then to the 2476D circuit. The path from to the KPL's is complicated since it uses RF. It should be better due to the dual band capability. Unfortunately, this isn't perfect. I've seen dual band devices Ignore RF communication due to a low level (below noise level) insteon signal on the powerline. My advice would be to investigate the circuit the KPL's are on for signal absorbers/noise. Beyond that, you can use the "scene test" to determine whether "verification" would help here. The scene test uses the Insteon standard method of activating a scene/interrogating the responders. The PLM will poll each device to determine if it responded correctly. If it does not, it will re-try up to 5x. In my experience, the "scene test" shows failures that do not exist with standard ISY scenes. Beyond that, we may need to understand your "house" configuration (plm placement, home sq footage, #' panels, number of devices, other "problem devices") to go forward.

@JJJ, you are correct. While there is a "feature" in the ISY programming to allow you to set a scene to a specific level, it doesn't work. Turning the scene on to any level above 0% will simply execute the scene command at the stored device on levels. Turning the scene on @0% will turn the scene off. Insteon protocol does allow for scenes to be turned on to a level. This feature may have been removed previously when other devices (Z-Wave) started to be included in scenes. https://forum.universal-devices.com/topic/25805-is-set-scene-on-possible/

Device level retries as explained be LeeG: Understanding Retries in ISY

I'm thinking you may have mis-stated things here. You can't activate a scene by turning one a Controller from the Admin Console. That will activate the controller by itself. You have to activate the "Scene" from the admin console tree (or a program). If this was the case, we need to start looking for noise/signal absorbers on the responder circuits.

Are these scenes locally activated (device) or activated from the ISY? Very different scenarios. Device activated scenes will attempt to determine the status of the responders. The ISY will not.

Right click on the program and "Export" to a file, or "Export to Clipboard". You resulting file is a jumbled mess. You can manually insert carriage returns using clipboard, or find a quick XLM viewer on the web.

I'm sorry, I'm not being clear... The following is my guess based on my recent experience with the ISY994 - Your program is not triggering properly because it is not saved properly. Said differently, the program that you posted is not what is saved in XML. It was corrupted some time back and "updating/re-saving" is not changing/fixing the corruption. I saved and copied my program several times to no avail. The XML was still wrong. When you re-save, you are resetting the "last run" status and the state (true/false) of the program. It's possible that is allowing the program to trigger once. Can't tell you why without seeing the XML. I don't understand what I did to screw up my program. It was an isolated case. I had been editing the program frequently throughout the day. The program is very long with numerous embedded waits. Suddenly it began to execute things that I couldn't explain. That's what drove me to look at the XML code.

@dbwarner5, another possibility is that your program became corrupted. I ran into this a week ago and had a difficult time finding/fixing the problem. My program is shown below next to the actual XML that my ISY994 was running. They didn't match. The RED scene control is incorrect in the XML. What I saw in the program editor was correct and no number of saves, copy to a new program and saving, etc would correct it. I corrected the program by deleting the "Set Basement/ SC Basement On" statement, saving the program, and then adding the statement back. My example dealt with a "then" action that was incorrect. I could SEE that the program was turning on the wrong scene. You may have a corrupt "IF statement". That would be much more difficult to determine. You could export the program XML and inspect it for errors (somewhat painful), or simply rewrite the program. Program Program XML If <if><and /> '19.21.5C.1' is switched Off <control id="DOF" node="19 21 5C 1" op="IS"></control></if> Then <then> $FirstDining.On = 1 <var id="11" type="2"><op>EQ</op><val prec="0">1</val></var> Wait 5 seconds <wait><seconds>5</seconds></wait> Set 'Basement / SC Basement' On <cmd id="DON" node="46453"></cmd> Wait 23 seconds <wait><seconds>23</seconds></wait> $FirstDining.On = 2 <var id="11" type="2"><op>EQ</op><val prec="0">2</val></var> Set 'Basement / BSMT Back Room' Off <cmd id="DOF" node="B B7 F8 1"></cmd> Set 'Basement / BSMT Back Room Load' Off <cmd id="DOF" node="16 5C BF 1"></cmd>

@DerekL, happy to hear that your earlier backup is working better. That rules out a hardware or (current) firmware problem with your EISY. I would still encourage you to submit a ticket. It's possible that your more current backup could be recovered. It is also possible that the backup was saved under a firmware version that had an issue - this would be a new item. In either case we (as a community) and UD learn when documented issues like this arise.

@DerekL, I went through your Event Log and agree with your assessment (thanks for posting) - things appeared to go rather well during the update. You have good communication, and the two devices that experienced NACK errors were corrected by the ISY. Unfortunately, that's not the end of the story. The link table shown below is what I pulled from one of my device that is linked to the PLM ONLY. No scenes whatsoever. As such, it has the Minimum number of links for any Insteon device. Link 0 @0FF8 is a responder link to the PLM @53.BC.3A. This is group 0. Link 1 @0FF0 is a controller link to the PLM @53.BC.3A. This is group 1. When I activate the device manually, this link is used to communicate back to the PLM. In going through your event log, I found many devices that had only 1 responder link to your NEW PLM. The result would be exactly what you are observing - you can control the device, but the device isn't communicating changes back to the PLM. This should not happen. The following devices are a few that show this error (there are many). If you perform a link table read on these devices they should show only 1 record (or 2 if you count the last 00 record). Furthermore, a compare should show that the ISY believes the link table is correct. If this is the case, the only thing I can think of is that you restored the EISY from a bad backup. Restoring again from a different backup would hopefully correct things. The alternative would be to factory reset/re-link all affected devices (a rather large task). If you believe that your backup is valid, I would encourage you to open a ticket with UD. They may be able to look at your backup file and determine where things are going awry. Minimum Device Link Table Edit: After reviewing your log a bit more I've realized that the EISY did not write Any controller links to Any of the 65 devices in your installation. That's rather bizarre. None of your devices can control anything else. At this point any recommendation I might have would be a SWAG and a waste of your time - please open a ticket with UD.

@tporada, if you are using Zwave and Zigbee dongles, conventional wisdom is to use a USB extender to put some distance between the dongle and the Hub. My experience is with a Raspberry PI, but I would think the same would apply to the EISY unless it's shielded. A second comment in regard to Zigbee - it can be challenging to use in a WIFI environment. Zigbee frequencies overlap many of the WIFI 2.4 GHz channels. There are a number of sites that give instructions on how to change the Zigbee channel to avoid crowded WIFI channels. I do not know how to do this with the EISY. There are also apps that you can download to your phone to identify what channels are in use in your vicinity (I use WIFI analyzer). Best advice is to move as many things to 5Ghz as possible to avoid interference, then change 2.4GHz zigbee/WIFI channels as necessary.

@someguy, as @paulbates indicated the ISY provides a Option box for enabling the Blink on Tx for most devices. @MrBill had a nice post on the subject here: https://forum.universal-devices.com/topic/35258-blink-on-insteon-traffic-setting/#elControls_330388_menu The option has been around since at least 2015. From what I can see, it's available on all of my V.45 and newer KPL's, SWL's, and plug in devices. Earlier devices are hit and miss. As it turns out, Blink on TX is the same as Blink on Traffic since all modules repeat Insteon traffic. In looking at your original post, I noticed that a number of your problem items were named "Malibu" and all seemed to be associated with outdoor devices. I tend to associate Malibu with low voltage lighting (maybe incorrectly). Is it possible these are low voltage applications on outdoor GFCI circuits? Any photocells on fixtures? The presence of GFCI's, LV transformers, and/or photocells can send troubleshooting in different directions (boosting vs filtering vs isolating). Would you mind describing your problem circuits a bit more (indoor/outdoor, load type, GFCI, fixture type)?

@CoolToys, I'm glad to hear that you re-wrote the entire program. I am starting to think along the same lines as @Guy Lavoie, that this is at least partly due to a ISY994/Eisy transfer. I was playing with my test program for awhile today. After numerous edits, I found a situation where the program was calling the incorrect scenes and executing things in the incorrect order. I exported the program to XML and could see that it was incorrect, but the "text" version was correct. Saving the program, copying and saving, etc. did not correct the issue. I had to go line by line, change the "text", update, save and then re-change to correct things. Quite the process - rewriting would have been easier. If your programs didn't transfer properly, it would be very difficult to correct them given the complexity. They look correct visually, but execute very differently. I am still playing with the "Duplicate or ACK for a different device" error from the PLM. I can turn it on/off now based on devices communication failures and wait times. Still not sure whether it's a problem - can't imagine that it's a good thing. One interesting thing that I did put in the program was an integer variable that I increment after each "Wait". It's far easier to track the program progress in the event viewer with the variable incrementing. CoolToys Copy - [ID 006B][Parent 0067] If '19.21.5C.1' is switched Off Then $FirstDining.On = 1 Wait 5 seconds Set 'Basement / SC BSMT' Fast On Wait 5 seconds $FirstDining.On = 2 Set 'Basement / BSMT Back Room' Off Set 'Basement / BSMT Back Room Load' Off Wait 5 seconds $FirstDining.On = 3 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 $FirstDining.On = 4 Set 'Basement / BSMT Game Sconce' Off Set 'Basement / BSMT KPL Game' Fast Off Wait 5 seconds $FirstDining.On = 5 Set 'Basement / BSMT Kitchen Cans' Off Wait 5 seconds $FirstDining.On = 6 Set 'Basement / BSMT Kitchen Ceiling' Off Set 'Basement / BSMT Stair' Off Wait 5 seconds $FirstDining.On = 7 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 $FirstDining.On = 8 Set 'Basement / Furnace Room' Off Set 'Basement / Test LampLinc' Off Set 'Basement / Test Matthew Lamp' Off Wait 5 seconds $FirstDining.On = 9 Set '13.32.8B-Sensor / 13.32.8B-Relay' Off Wait 5 seconds $FirstDining.On = 10 Set 'Basement / Test-Sensor / Test-Relay' Off Set 'Basement / Test 13.07.33.1' Off Wait 5 seconds $FirstDining.On = 11 Set 'Basement / Test 13.05.A8.1' Off Wait 5 seconds $FirstDining.On = 12 Set '0F.82.A9.1' Off Set 'Basement / BSMT Back Room' On Wait 5 seconds $FirstDining.On = 13 Set 'Basement / BSMT Back Room Load' On Set 'Basement / BSMT Fam Cans' On Set 'Basement / BSMT Bed' On Wait 5 seconds $FirstDining.On = 14 Set 'Basement / BSMT Fam Rm Sconce' On Set 'Basement / BSMT Game KPL Overhead A' On Set 'Basement / BSMT Game Sconce' On Wait 5 seconds $FirstDining.On = 15 Set 'Basement / BSMT KPL Game' On Wait 5 seconds $FirstDining.On = 16 Set 'Basement / SC BSMT' Fast Off Wait 5 seconds $FirstDining.On = 17 Set 'Basement / SC BSMT Entry' On Else - No Actions - (To add one, press 'Action')

When you actuate a device, you are executing a scene. However, the device will (try to) interrogate each member of the scene to determine if it responded correctly. If a group member does not respond, the device will try again up to 3 times. If any device in the scene responds incorrectly, the initiating device (may) retry the command up to 3 times. If the scene still fails, the device (may) flash red. When there is high Insteon traffic, the device may abandon the group interrogation. The ISY does NOT do this. It sends the Group On command (scene) and does not interrogate the individual group members. It assumes the command was followed and reflects this status. LeeG's description (better than mine): https://forum.universal-devices.com/topic/11690-understanding-retries-in-isy/#findComment-109217 If you are concerned scenes not responding, you can run the "scene test" under "Tools/diagnostics/Scene Test". This is a special test that runs the scene ON followed by an OFF followed by a group cleanup on each device. It's actually not an easy test to pass.

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?

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

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