CoolToys

@JJJ, I think you are looking at this correctly in that the Alexa command merely turns the switch on. In Insteon world the only way to get Insteon to act like you pushed a button is to push the button. Lutron doesn't know the difference because it was built around the "human factor" meaning that all actions are treated as if a human did it. While I am a HUGE Lutron fan, Insteon is at a better price point and has some flexibility not offered by Lutron. There is a way to do this without spending money and pulling switches out of the wall. While it may be frustrating, Insteon is giving you one more fork in the logic than Lutron. I agree with @Guy Lavoie that you can use the Alexa command to change a state variable which then triggers the appropriate program. The ISY world is based on "States" and as pointed out above only state variables are checked as part of the state of the system. Integer is not. "Switched On" (manually) and "Status On" (true whenever on) are different "States" in ISY world, so if you want a specific state to be achieved when "Switched On" or "Alexa On" happen, but not when "Status On" from another program happens, the best way to do that is with a program where you can check the status first, and then if other things are true change the variable. This way if the light is already On, Alexa commands don't change the state in the wrong way also. Keep in mind that one second after Switched On or Alexa On become the state, Status On is also a true state, so you will need to write your logic to block that possibility. Simply add $sGarage="0" to the "IF" statement so if the lights already on, you don't change the outcome. I added the query because this is turning on a scene, and I have some scene reliability issues going on. Auto Garage Lights - [ID 0012][Parent 0001] If 'Garage Lights' Status is Off And ( 'Garage.1 Motion' Status is On Or 'ELK Alarm / Garage Courtyard' Logical Status is Violated Or 'ELK Alarm / Garage Big' Logical Status is Violated ) Then $sGarage = 1 Set 'Garage Lights' On Wait 2 seconds Set 'Garage Lights' Query Else - No Actions - (To add one, press 'Action') Auto Garage Off - [ID 0029][Parent 0001] If $sGarage is 1 And 'Garage.1 Motion' Status is Off And 'ELK Alarm / Garage Big' Logical Status is Normal And 'ELK Alarm / Garage Courtyard' Logical Status is Normal Then Wait 15 minutes $sGarage = 0 Set 'Garage Lights' Off Else - No Actions - (To add one, press 'Action')

Thank you to everyone listed here that helped. I think the admins can close this thread and here are the highlights to save anyone else a lot of reading. Given the time spent it might have been easier to just wipe the Eisy clean and build everything from scratch as was suggested early on however my pea brain may have left the logic error of "the big one" in the new code too. The program in question now works correctly and consistently. The only two open issues with my system are the scenes not working reliably (see Step 7 and request at the end) and blinds not added (Matter 2025?), neither of which are part of this thread. Every Step listed led to improvements which helped me find the big one. Without all of the help, I would have never seen the real issue. The length of the list shows why I think I should have just started over from scratch when I moved to the Eisy. The system worked with my ISY, but the Eisy has way more brainpower so it was faster than my linear thinking and programs built for an HAI Omni Pro. Step 1. Batteries low in Insteon Motion I sensor, changed states randomly due to "false motion" - @IndyMike Step 2. Move variable reference to the end of a program if same variable used in the program @dbwarner5 Step 3. Improved Variable naming for better tracking $sVariable for State, $iVariable for integer @larryllix Step 4. Rewrite Problem Program if system otherwise working normally @dbwarner5 Step 5. Disable the program, Click and select each line, save program, enable program. This action Re-syncs Tokens @larryllix Step 6. Find and Fix "Broken Variables". Look at every program for a [Variable_undefined] or similar entry - @IndyMike Step Seven. Be aware a scene command sent by the Eisy via PLM to Insteon is not verified, but assumed so Admin Console and device status may disagree. - @oberkc Step 7. Add a 2 second wait between commands in a program to prevent communications collisions. Keep in mind each "wait" verifies the "IF" is still true. @paulbates I added 4 seconds after scenes which helped but due to 7 above, still some issues. Step 8. The Big One, Two conflicting programs were true for a short period of time. As "Bedtime" started turning off the lights Night_Daily_Home saw the lights off but the "$sBedTime" Variable still = "0" so it started running again turning on lights since the state had not changed. When the Bedtime program finished, the $sBedTime became "1" and the Night_Daily_Home program stopped. Where the conflicting program stopped was slightly different each time hence the "randomness" I was seeing. This did not happen with the isy. Eisy runs faster? I think states are checked every minute so the Bedtime program needed the $sBedTime = "1" command moved to the first line. @oberkc Step 9. Run the Scene Test from the Eisy. Click on the Scene, right click (control click on mac), diagnostics, scene test. @IndyMike Side note on this one. Nothing appears to happen for any scene so maybe all of mine fail? Step 10. Similar to step five, click on each variable that isn't changing when program runs and resave program @Guy Lavoie Step 11. i3 outlets that turn off and back on due to possible load sensing on low wattage devices require a double tap even after the scene they are in is commanded off, (Meaning in the program: Hallway_Curio_Scene "off", Curio_Light "off", wait 2 seconds, Curio_Light "off") .@SteveL The program in question (Bedtime) that started this thread now appears to be reliable. The only known issue remaining is scenes not staying synced. i.e. the device turns off but the associated keypads stay lit as if the master device was on. This is a scene/communications problem since ISY doesn't verify. I would also like my blinds on the system but that is for another day. Request to @Michel Kohanim and Company - Please query scenes as insteon devices do or add a "retry" to the devices list in the scene command so we can beat them into submission.

Hey all, not sure about this. In the AC, I can set both the on level for the device and the scene. Here is how I did it from another thread asking the same question. I just ran both programs to verify it works. So I think like @Javi, if you just create a new scene that sets the levels it will work. I realize it isn't within the program itself but it could be an option? Ever since HAI/Lutron days, I think of a scene as a mood. When you change your mood it really is a new mood, so just make a new scene. Hit switch, on 80%, IOX sends on it is on 75%, Send Scene on, it is on 50%

@flsenior, there are lots of things that can cause a mismatch. I am also assuming you are talking about Insteon? The two biggest are: 1. Simple comm issues. 2. Sending a scene from IoX, the IoX AC "assumes" the status is what was sent, it does not verify. I do a few things to combat this since my house has some known comm issues and I am way too lazy to troubleshoot it past the cyber power UPS that killed the entire side of the house. - Every program that triggers a scene has a query at the end to verify the device did in fact turn on or off. - I do a daily ISY query at 3:15 am, the ISY had that as a default, the Eisy did not when I upgraded. - Where I can in scene or device triggers I went to two or three retries. I still find a switch or light not set correctly after a scene fires from IoX, but the light side is 99% correct, just some switches indicate the light is on when it isn't meaning the scene is turned off, the lights go off but a remote keypad switch stays illuminated indicating "on" and the Admin Console (AC) indicates "Off" for the switch so I know it is scene send related. Also if you are having scene issues and other programming problems since upgrading, check your variables and position in the programs. With the ISY it was slow enough some of my errors never showed up. As soon as I upgraded the house went nuts because one program saw the $sVariable as "1" so it started turning lights back on before the other program finished and changed the $sVariable to "0". Moving a variable change to the top fixed several issues. Much of my stupidity and laziness is documented in the Long Running Randomness Thread.

@JJJ, I will start with that I am not super clear on the difference of state and integer variables so for my pea brain, I only use "0" and "1" for any State Variable. That way each "state" variable only can have a binary state. (Yes I am that old I started with binary programming) I've read the ISY guide and just don't see a need to increase by "1" or "2" with integer variables with the exception of the "atomic_check" so I can see how many times a program runs or something. With your program my thinking is that two separate variables named for easier tracking might help, but that is just me. If I understand the ISY manual, what you are doing is just fine, just harder to see what is really happening because one "State" can be changing back and forth without you knowing because you are forcing the value instead of increasing like you would with an integer variable. So my first suggestion for easy tracking is to make two variables. $sLightSwich_On and $sMotionSensed. @Geddy is correct, you would need to set up two separate programs, however, it might be easier to just build a scene with the motion sensor as the "Controller" so as long as there is motion and set the timeout value to 120 seconds. (This is in the "Options" panel when you select the options button for the motion sensor in the Admin Console for Insteon Motion Sensors) Then 120 seconds after motion stops, the lights go off. When the switch is "Switched On", start the program that does the 30 minute test. Quick note, I tried the two minute motion thing and certain times of year the lights would go off when we were still in the room so WAF was zero and I had to reprogram. Another option might be to use the If "Room.Motion is On" on to start the program that only runs for 2 minutes and use IF "switch_name is Switched On" to start a different program. Even if you use the motion sensor or switch to fire the program directly, add the $sState_Variable to the program so you can see that the program ran quickly without going to the Summary page. This makes it easier to find comm issues, and you can use the $sState_Variable to run the countering program. One glance at my variables list I know exactly the overall state of my system and can quickly pinpoint where something is or isn't running when it should. For the garage, if I switch the light on I want it to stay on but here is the auto on/off sequence if I just arrive home or need a tool or soda from the fridge. The Variable change is first in the Then line so I don't get conflicting programs. With my ISY it was so slow it wasn't a problem but the eisy can run two or three large programs and if the variables aren't placed right one will cancel the other somehow. That might be why I went to two variables some time ago, the speed of the newer IoX controllers can change a state so fast you spend hours looking at logs to find it. I'm lazy. Auto Garage Lights - [ID 0012][Parent 0001] If 'Garage Lights' Status is Off And ( 'Garage.1 Motion' Status is On Or 'ELK Alarm / Garage Courtyard' Logical Status is Violated Or 'ELK Alarm / Garage Big' Logical Status is Violated ) Then $sGarage = 1 Set 'Garage Lights' On Wait 2 seconds Set 'Garage Lights' Query Else - No Actions - (To add one, press 'Action') Then to turn off. Auto Garage Off - [ID 0029][Parent 0001] If $sGarage is 1 And 'Garage.1 Motion' Status is Off And 'ELK Alarm / Garage Big' Logical Status is Normal And 'ELK Alarm / Garage Courtyard' Logical Status is Normal Then Wait 15 minutes $sGarage = 0 Set 'Garage Lights' Off Else - No Actions - (To add one, press 'Action')

One other thing I learned the hard way was "retries". When I migrated from the ISY to the eisy, many scenes didn't work. I had to delete and rebuild but a few still failed. Looking back at the ISY (I keep it plugged in with the PLM just dangling so it can't do anything but I can compare programs) I realized that many scenes had "2 retries" so I edited the ones that were giving me fits and of the four, three were fixed.

@DerekL, dumb question but you said you replaced the plm without following the directions. Did you go back and start as if you got a new PLM? Swapping PLM's causes its own set of issues. Also have you tried a few device resets or "writing changes" to a couple of devices to see if that helps?

@someguy, that is very interesting. Are these lights in scenes? If the ISY sends a direct "ON", the device should send a response. I have an issue with a few programs sending "ON" but to a scene. In that case the ISY just logs the command as the status and doesn't wait for a response from each device. If the device didn't turn on or off along with the scene command, the ISY gets out of sync. My experience is that a noisy line might turn things on, but the console will still read off because it doesn't "hear" the response as long as the commands are direct not embedded in a scene. I also keep two PLM's on hand so I can flush and reset them just as a way to remove them from the culprit list. I had a cyberpower UPS cause a ton of problems this way. To save you a lot of reading in another thread, I also migrated from and ISY to an eisy, and the position of a state variable in one program suddenly became an issue in another program and I had to move the variable to the very top to stop the conflict. Several scenes with three way switch set ups failed to migrate properly as well.

@someguy I see that the Malibu programs are all [Not Enabled]. Any reason for that? Also when the console says it should be on and it isn't, can you manually press the switch or outlet button and it comes on? If you query the device what does it do? Does the query come back correct or does it stay incorrect? As @IndyMike is questioning, step one is to see that the device is actually on or off and then verifying communication with IoX by query and manual control. In theory if you send "on" from the console, the console should not indicate "ON" unless the device responded that it is on. The caveat is that if you are sending the "ON" command as part of a scene the ISY does not verify status before changing to the "expected" status.

@JJJ, there are several issues at play here, and I just want to clarify, you are actually pushing the insteon switch with a finger, not activating it through a program or scene? Lutron and Insteon both send a position change over the network. In this way they are similar. If that is true that you are physically pressing the button, then @GlowingHair is correct. In my case I set up one of each to test and both work as below. There are two six button keypads one on each side of the bed. Forgive my very lazy naming of the buttons both refer to the bottom off button or status of the ON/OFF buttons. The big question is why are you using a switch to set a state and unset the state? A direct command would be a lot easier or setting the switch as a scene controller. Why "2" as the state shift? I am guessing there are some complex interactions when $Front_Lights = "2". Using a state variable to monitor switch position is a bit of overkill? Is there a State where Front_lights = "1"? What happens if you force feed $Front_Lights to "2" in the Admin console? does the next appropriate program run? Also as was recommended to me, I have changed all integer variables to be $iFront_Lights and state variables to be $sFront_Lights to make it easier for others to help. So more questions (I ask because if you read the Long Running Randomness post you will see I have done all of this wrong as some point). When you switch the 3C_4 Front Porch switch on, does the state variable change, even for a second? And does the program 3B-2 Front Lights On Hold V2 turn green in the left side bar indicating it is true? When you select off, does it turn red indicating false and does the state change again even for a second? Under Programs, Summary tab, select the order to be last run, and see if another program runs at the same time or within a minute, maybe there is a conflict? Have you done a search to see what other places the $Front_Lights state variable appears in programs. Is there a direct conflict or timing conflict possible? Programs Tab, Details, Select a program, right click and then "Find/Replace". Bedtime Trigger - [ID 001D][Parent 0001] If 'MB Window Keypad.On' Status is Off Or 'MB Door Keypad 70 9B C0All On' is switched Off Then $sBedtime = 1 Else - No Actions - (To add one, press 'Action') At Sunrise or one of several other events $sBedtime is set back to zero and the switches are both put in the on position to tell me that has happened. I like to know what my system is doing or has done. To do this I created scene called "Home Status" and made both of the switches responders. Here is the short version of one of the programs. At Sunrise - 1 minute, I set $sSunrise_Daytime to "1" and at Sunset, it is set back to "0". This is a huge clean up program to catch all the things missed the night before or manually turned on after the system has run its programs. I edited the big middle out for simplicity. Sunrise Clean Up - [ID 0026][Parent 0048] If $sSunrise_Daytime is 1 Then $sBedtime = 0 ... Wait 2 seconds Set 'MB Home Status' On Else - No Actions - (To add one, press 'Action')

@IndyMike, no that wasn't a mis-statement, I did it as a test to see how Insteon, and UDI play. I wanted to fully understand the logic. Insteon devices defined as a controller have two modes, controller and responder. When pressed directly (with my finger) the device responds as a controller. When I press a scene button on another Insteon device, i.e. keypad 8, the device then acts as a responder. I had assumed (hoped?) that Insteon had two different commands so the ISY sending a scene command could also be treated differently than a direct command by the Insteon device. My apologies for venting in the thread that it doesn't work as I wanted.

@IndyMike, You are correct, the scenes fail when commanded by the eisy. I tried using the eisy to turn on the master switch and the slave (controller/responders) still don't follow. When i manually turn on the switch the slaves follow. @Guy Lavoie, I had that same issue before the remodel, and wired the new garage to the ELK and solved that issue with the ISY and now with the eisy and ELK poly (when I paid the bill that is). I never considered the motor noise and timing, makes perfect sense now. There are four different motion sensors in the house, each activates one of four different scenes, sets occupancy states of two zones for HVAC and change the lighting configuration of the house at night automatically if there are guests or zone 2 is in use. All four scenes have occasional failures. The garage and stairwell are close to the switches so I made them beep. The other two are semi remote so I added the query to see what happens. We'll see. Some electrical side notes, - Every breaker circuit has at least one dual band device on it. - A dual band i/o linc is at the farthest point from the sub panel, in an "A" phase outlet with a "B" phase dual band switch right above it. I learned that trick as soon as dual band hit the market. - A dual band i/o linc is also in the garage on the "B" Phase just a few feet from an "A" phase switch on the main panel circuits. - Main Panel has a leviton filter on it with a SolarEdge Inverter attached. The two sub panels do not. - Batteries are being considered to clean up the power even more and minimize power failure recovery issues. Edit add - and I only use the "on" command from motion and then query the off. Auto Garage Lights - [ID 0012][Parent 0001] If 'Garage Lights' Status is Off And ( 'Garage.1 Motion' Status is On Or 'ELK Alarm / Garage Courtyard' Logical Status is Violated Or 'ELK Alarm / Garage Big' Logical Status is Violated ) Then $sGarage = 1 Set 'Garage Lights' On Wait 2 seconds Set 'Garage Lights' Query Else - No Actions - (To add one, press 'Action') Auto Garage Off - [ID 0029][Parent 0001] If $sGarage is 1 And 'Garage.1 Motion' Status is Off And 'ELK Alarm / Garage Big' Logical Status is Normal And 'ELK Alarm / Garage Courtyard' Logical Status is Normal Then Wait 15 minutes $sGarage = 0 Set 'Garage Lights' Off Else - No Actions - (To add one, press 'Action')

Jan 12 2025 update. The bedtime random relighting of the house is over (Thank you again @Guy Lavoie and @IndyMike) but because I am now paying ultra close attention to the system, I have realized a few other random things that I knew about but were much lower priority. Remaining "random" items from migration to eisy: One i3 outlet that needs a double tap command ("off", wait 2 seconds, "off") to stay off even after being set to load sense off. This is true if the off is sent from the program or a "controller" switch. There were two. I removed them both from the system, manually set load sensing to off, re-started IoX and added them back. One is now working correctly with a 6w bulb, the other is not. Both had 3w before Steve Lee clued me in that 3w is too small of a load. (Admittedly both of these outlets were non i3 with the ISY, when I upgraded and they started doing the auto on thing, I thought they failed and replaced with i3.) Two scenes that don't work. One is a 3 way with a master and slave switch, one is a 4 way with a master and two slaves. In both cases the slaves don't follow the master. There are 9 such scenes, the others all work. I removed and rebuilt all nine scenes since most were not working correctly after the migration. Finally the motion activated scenes have been failing randomly. I do know why but just started testing a patch. I discovered this a few days ago when walking in the garage. There is an Insteon Motion II (was a motion I with ISY but I thought it failed) it blinks green but the big lights didn't come on, a review of the AC indicated the garage lights were already on. The switch indicated off. I selected "query" which synced the garage to "off". When I went back in the garage the lights worked normally. The same has happened a couple of times with each of the other motion areas. There is a daily query at 3:15 am, and in the past I chalked this up to motion sensors not picking us up because the scenes worked "later". I went so far as to buy an aeotech motion sensor thinking it might help. Now that I am checking every event failure every time, the cause was simple. The eisy and the insteon system are occasionally getting out of sync. When that happens the motion activated programs fail. Over night the system syncs and the next day the scene works. All of these events activate a scene, and I am wondering that since the "scene" command is sent without requiring a response if some noise in my lines is preventing the command from being received and the eisy is assuming a switch position? As silly as this sounds, to experiment, I just added a "wait 2 seconds" and "{device_name}, query" to half of the programs and an "beep" on the switch to the others to see if this is a possible band-aid until I figure out my random noise generator.

@gdavis is correct, since Harmony was designed to work with any system they were programmed to allow for Phillips toggle codes. This was Phillips solution to discrete codes, saving a separate Power On and Power Off button on the remote among other things. Wherever the database came from for the IR codes could be the issue. The second button press could be blank or some code unknown to the ISY/Eisy. I have a Request Video Server and had similar issues. Harmony only programmed the "A" codes, leaving the "B" codes blank, which would do odd things if there were codes on the "B" pages. The off command for my TV was hiding under the FF command for the request. So instead of stopping the FF operation it turned off the screen with the second press. Manually programming (learning) the button twice from the Request remote solved it. 99% of the time Harmony just pasted the A codes in the B page unless the device had discrete A/B Phillips style codes.

This might sound silly, but the region is set to NA? Does it need to have US set? The "Connected to Tesla Cloud" reading Disconnected is where I would start. That looks like the node server isn't logged into Tesla to get the data from your car. the "Controller Connected" displaying "Connected" might only be the node server to your AC?

@Gamarando, when you restored the back up from the ISY your devices didn't appear? @jkmcfadden is correct, that going slowly using the migration guide will make life much easier, however we did discover that some variables and scenes don't transfer properly and can lead to erratic behavior. Fortunately the fix is simple. Any scene not working reliably, just delete and rebuild. Small hassle but it helps troubleshooting any other minor quirks. I have what I think is a pretty large system and the speed and logic change of the Eisy created a few issues that took a lot of troubleshooting but now appear to all be fixed. I had a bug in my programming logic that never appeared with the ISY. The Eisy is so much faster that I was having all kinds of fun trying to find it. Until I rebuilt two variables and half a dozen scenes (all three way switche scenes BTW), I couldn't see or find the bug in my programming logic. If you get bored look at the Long Running Randomness Thread. The fix turned out to not quite be it, so if you experience similar problems look at the tests that @IndyMike came up with to help troubleshoot after the "solved" date.

@IndyMike and @Guy Lavoie, thank you for your help, I am happy to report since returning home there have been three successful nights in a row where all programs and all but one scene are working perfectly. The Variables not transferring and scene's not transferring correctly is odd, but those two things solved a lot of problems. As a side note, a couple of the new i3 outlets still require an off command wait 2 seconds and another off command to keep them off even though I manually turned off the load sensing feature per a suggestion from @SteveL in another thread. I have three of them now, one works perfectly with a 8W LED, the others have 6W which should be enough but isn't. The last scene has been rebuilt three times. There is a button by the bed labeled "bed" which is in a scene with some over cabinet spot lights in our bedroom. The very last step of the new version of the bedtime program is to turn the MB Cabinet scene off. The lights go out but both .2 buttons on the 8 button keypads remain lit. Before I rebuilt the scene the opposite was true, the buttons would indicate off and the lights remained on still working on it, but your help got me on the path to getting the wife approved solution working. Thank you again and happy new year

@IndyMike, The integer update for each wait is a great idea. Last night there might have been a breakthrough. I have been moving blocks of programs that work correctly into folders with similar programs like 3-Way switches etc. Last night I watched the Bedtime Run perfectly but about 90% of the way through I saw "Night Daily Home" turn green. I looked at the summary tab and saw that both Bedtime and Night Daily Home were true and running. I checked the variables and they were correct so "Night Daily Home" should have been false. The IF statement is. Night Daily Home - [ID 0003][Parent 0001] If $sOccupied_Main is 1 And $sNight is 1 And $sBedtime is 0 Going back through my logs, before creating the Bedtime Trigger and using $sBedtime = 1 as the IF for Bedtime, I didn't set $sBedtime = 0 until the end of the Bedtime program. This would have let Night Daily Home start, and if it wasn't running in order, create a randomness. By the time I checked it, Bedtime was finished running and so Night Daily Home would be red. Following @Guy Lavoie 's earlier idea, I reset all of the variables in the Night Daily Home IF just in case one of those didn't transfer. This is a very plausible explanation of the randomness given @IndyMike's experiment. Moving from a slower (possibly linear action model) ISY to a faster eISY, with a couple of variables that didn't transfer it may be that the Daily Night Home was starting to run, and when Bedtime hit the last line of $sBedtime=1 it stopped giving a random appearance. Because I shrank the program list length I could see it all on one screen last night. I should have caught it while looking at the programs "last ran" column but I was clearly a bit myopic only focusing on what I could see running and the top two which are what I expected. Once the reset of the variables was done, I manually changed $sBedtime back to 0 and the house lit up. Five minutes later I pressed the Off on the keypad and the house shut down normally. I am leaving for the next 10 days but will test again when I return. Hoping to find this solved. Thank you all and Happy Holidays.

@Guy Lavoie, Thank you, I wasn't aware of variable reference issues. I use them extensively and this is the only goofy one. I killed and rewrote the entire Bedtime program just in case it was an issue with the program itself. I am not 100% clear on which program to try this on so I went to the Bedtime program, selected the $sBedtime line in the if Statement, clicked update and then Save Changes. If that is what you meant, I will try again tonight. Quick Edit, I had some time so I tried it during the day and it appears to run.. I will double check tonight. Might have just discombobulated the whole house though.

12/27 update. After the full reboot ( not just "restart IOX") and resetting the errors found, the system worked as expected no weird light things except that neither keypad ran the bedtime program. All scenes and automations worked as they should. I used the trigger program that if either is switched off the $sBedime = "1". The variable changed and the bedtime program never ran. Pressing the Bedtime button on UDI mobile forcing a "run then" of the Bedtime program worked perfectly. Ugh.

@Guy Lavoie and @IndyMike I was thinking both would at least verify later? Good to know the scene is just a command sent to the ether with no expected response. STATUS UPDATE After having rebuilt the 6 scenes, nothing changed. So using some cache flushing logic I rebooted the eISY. The interesting thing is that when I rebooted the house started just running random things and the kitchen auto lights stopped working. The scenes all worked fine from the AC though. So once again I started at the top. I found two very odd things. The line for the Kitchen auto lights reversed and instead of IF Dining.Motion = "on" the program had IF Dining.Motion= "off". Second was an "and" swapped to an "or" in another program so the lights were just constantly turning off and on. Those corrected about 10 pm, the house appeared stable so I called it a night. The MB.Door all off button did nothing for the Bedtime program. The program didn't even start. My wife was sleeping so I didn't test her side. Using the "Run Then" Bedtime button on UDI mobile, the Bedtime program worked perfectly. The keypad that didn't work is the newest dual mode 6 button in the house, but possible bad or comm from that outlet. X-10 is not received from that outlet but I hoped a dual mode keypad would work. Going to swap keypads tonight and keep trying.

@Guy Lavoie, I thought that way too, but I also used the model demo that @larryllix posted earlier here and if the state in the IF statement changes then the program stops. That appears to have been solved by making a simple program and Switched and Status both now work fine. Bedtime Trigger - [ID 001D][Parent 0001] If 'MB Window Keypad.On' Status is Off Or 'MB Door Keypad 70 9B C0All On' is switched Off Then $sBedtime = 1 Else - No Actions - (To add one, press 'Action') And then changing the IF of the Bedtime program to : BedTime - [ID 0016][Parent 0001] If $sBedtime is 1 The program now runs all the way through but not everything is working. The random relighting appears to have stopped the last few days and I have no explanation why.

@IndyMike, Happy Holidays and thank you for doing the test, it reminded me to double check my final variable to see if the program was finishing. I will watch the PLM to eISY comm more closely after the family leaves. I have been overlooking this. I do know that the eISY is different that the ISY, and it is why I may go back and give up on adding blinds for now. Last night the final variable triggered so the program did "finish" however four lights stayed on this time. Which led me to comm, especially since using mostly scenes in the program to shut down. Going back, way back in the thread there was a note about scenes not transferring perfectly from the ISY, there was someone who suggested I start over from scratch on the eISY and I may do that. Last night I went through the four scenes that didn't work properly, and found this interesting tidbit which was and is true of all four scenes. Two of these were new last night BTW. Pressing the button next to the bed which was the Controller, turned the lights on and off perfectly. These are three way set ups with one master and either two slave switches or two slave buttons on keypads or a mix of Master Switch, Slave Switch and Slave Keypad button. Sending the command from UDI mobile or the AC did not work. The AC would indicate 60%, On, On and both slaves responded but the master did not. So the two slaves LED lit up as if they were on, and the lights didn't come on. Pressing the master also lit up the slaves. The previous day UDI mobile worked perfectly. Per the recommendation of the post about transferred scenes not holding the keys, I deleted and rebuilt each of the 6 scenes that have randomly failed over the last three days. One of the scenes, did not finish writing, so I selected write changes to device and still the same issue. Now... Either slave button or the master turns the lights on and off and correctly sets the scene. The AC shows "65%,On,On" Turning on the Scene with AC, the devices show "Off, On, On", AC shows "65%,On,On". Turning on Master Switch with AC, the master sets to 65%, keypads remain off, AC indicates "65%,Off,Off" I don't recall this ever being the case with the ISY. Why doesn't the AC triggering the switch trigger the scene when a physical switch press does? For a comm test, I set a button on the other side of the house as a controller and it also turned the scene on and off just fine. Since that last reboot, no lights have randomly come back on which is interesting in itself. Today I am moving the PLM and eISY to another location to see if it is comm, but the scene failures don't indicate that. I am down to three thoughts today, 1. noise/comm issues (but the errors are way more consistent after rebuilding the 6 scenes), 2. Possible corrupt program because I didn't migrate correctly from my ISY. 3. eISY is different logic and I have to do a lot of homework to understand it. Post Edit - OOPS forgot to sync UDI mobile after rebuilding the scenes. UDI mobile now works as I expect, only AC that fails when I activate the scene

@IndyMike, 1. Nope no repress until the program stops running then. But previous to this weeks testing with an open laptop and the Admin Console running, sometimes two or three presses 5 -7 min apart will do it. 2. The only reference to the bedtime program is the bedtime trigger, and I disabled that yesterday just to see and just did a "find" and only found the reference in the trigger program. 3. Log doesn't show a reboot for over two weeks, I did that manually to see if there was cached data somehow. Last night, Only used UDI mobile. I like it because it shows "Running then" on the screen . Everything shut down in order but two unrelated items were skipped. $sBedtime remained at "0". The program ran all the way through. The Admin Console showed one of the switches as off, the other on. I queried and the AC and both showed on I manually turned them off and went to bed. Possibly bad communication and since it was a scene off command, a lost command? But why does the AC display "off" when it isn't. Looking more like comm issues even though at least a dozen of the switches are dual mode mesh. The one that showed on is an outlet with a 6W LED lamp that does occasionally turn it self on. Steve Lee thinks it is because the wattage is so low the i3 outlet senses an on from an inline type switch and turns back on. I have tested this and the outlets do it. Tonight I have added a second off for that curio. He said I needed a larger bub so I went from 3W to 6W. There is a way to turn that off but like blinking while running, I haven't figured that out yet. And yes here are the two different IF statements I tried. BedTime - [ID 0016][Parent 0001] If 'MB Door Keypad 70 9B C0All On' Status is Off Or 'MB Window Keypad.On' Status is Off AND BedTime - [ID 0016][Parent 0001] If 'MB Door Keypad 70 9B C0All On' is switched Off Or 'MB Window Keypad.On' is switched Off There is no significant difference in the result but due to a test where "wait" re-evaluates the "IF" condition, I have elected to leave the Status is Off version in place. @oberkc, I don't have any nested programs, it is 90% a copy from my old HAI Omni ProII that has just grown as I added devices to this house. That thing got lost with nesting so I avoid the technique. When I review logs and the status in the AC it appears as if the entire program ran. I added the $sAtomic_Tracker Variable at the end and changed it to 1 last night. It is the last line in the program and it did switch to one. At sunset it reverts to "0". My best guess at this point is two things. First , there is noise in my house that causes faults, and second when running a program with a scene, when the command is sent, the AC assumes it worked. I have even tried swapping PLM from Serial to USB, I have one of each. No change in performance. The next big thing is to move the eISY out of the media closet and down to my office closer to the main panel. After that it is revert to ISY until I find something that will run my lights and blinds autonomously. Amazon and Apple Home both work, I just don't want to be dependent on the matrix.

@IndyMike I am not disagreeing but something isn't working right. Since upgrading to the eISY in an attempt to get my Matter blinds on the system (different thread, they are not). @oberkc, that makes sense and in both cases the program should still (and has on rare occasion) worked. 1. Tried to only trigger the "Bedtime" program with BedTime - [ID 0016][Parent 0001] If 'MB Door Keypad 70 9B C0All On' Status is Off Or 'MB Window Keypad.On' Status is Off Result, Program starts and stops somewhere. 2. Tried to use the IF from above in a new Program Bedtime Trigger - [ID 001D][Parent 0001] If 'MB Door Keypad 70 9B C0All On' Status is Off Or 'MB Window Keypad.On' Status is Off Then $sBedtime = 1 and use only as the Bedtime program If BedTime - [ID 0016][Parent 0001] If $sBedtime is 1 3. Changed "Status" to "Switched" 4. Changed direct Insteon device status changes to scene changes to eliminate collisions. 5. Tried all of the above again with just one switch in the IF statement, just because. 6. Using Alexa skill I added "Time For Bed" command. This didn't work at all. 7. Used UDI Mobile and built a button. The first four of these ideas are somewhere in this thread and all had the same result. They all worked once, they all start the bedtime program and they all get partway through and occasionally lights even randomly come back on. None turned off the house twice in a row. Number 5 didn't change any outcomes significantly. Last night I went through this very methodically, using all four approaches and reseting the variables manually each time. I did this four times for each change with my laptop with me so I could see the $sBedtime variable change and hear the very first item, the watch winder click off so I know the Bedtime program was activated. None worked all the way through. While I was getting frustrated further since the program that once worked no longer works I found a thread about UDI mobile. So I created a button for the Bedtime scene, edited it so that the only visible option was "Run Then". This way when you press the button it can only "Run Then". Wife approved simple and it worked not once but twice in a row. At that point I was told it was good enough and to try again later. If in fact this works, the question is Why?. Bedtime doesn't trigger to "1" so the one thing that does revert as it should is the thermostat. Everything else works and yet the IF statement is false because $sBedtime is still "0".