CoolToys

@IndyMike Geez, I had forgotten about filterlinc's I used them in my last house, two ordered, one for each AV rack and I also ordered a 2477 to replace the 2476 in our bedroom and see if that helps. Like many of the people with issues on Tesla Power Walls, I filter the inbound power. My solar edge inverter induced its own noise problems so I added a Leviton 42120. I do have dual mesh switched on each phase in "steps" throughout the house. When we did the remodel the sheathing and roof are techshield which is great at blocking/reflecting RF and used RockWool insulation in a lot of the walls and attic which is also a terrific audio and RF absorbent material. The house is divided into four zones with each zone stepping off of the previous. As I am re-mapping that out I see that there is a small potential gap leading to our bedroom. The "hop" in the middle from the next closest dual mesh is another 2476 although directly below the keypad linc in the bedroom is another dual mesh 5 button so that hop shouldn't be the issue. Isn't powerline fun.....

@IndyMike That's the interesting thing isn't it. Oddly it was the reverse happening when I had the keypadlinc as responders only to the scene command. I made all three controller/responders and it reversed. The house has three panels, A main that connects the old section, a sub panel for the outdoor kitchen, greenhouse (was a spa) etc outside, and a sub panel for the addition where the recording studio, guest room and editing room are. Logically the PLM is about as far from the main panel as possible, as are the three devices listed. I did add an i/o link on the wall from the old section, about 30 feet from the PLM to the new section because the new section wasn't working well at all. That solved the issue. It is a two story house so runs are not really that long in the old section. The PLM is located on the second floor in the screening room rack. I have considered moving it to the Living AV rack which is 3 feet from the panel, but there are no free outlets. The location has a lamplinc with the top controlled outlet running a lamp, and the bottom connected to the RackMaxx power filter in the AV rack. I put an 2456.S3 appliance link in the bedroom along with the keypadlinc's hoping that would solve what I agree to be a power line comm problem. X-10 will not work at that outlet at all. The keypadlincs turn the scene on and off perfectly, but the reverse isn't true. It is odd the switch works though and the Eisy see the switch position changes quite accurately. By the same note the keypadlinc status changes are also received by the Eisy correctly. The only issue is when the scene is set by the Eisy the keypadlinc's do not follow. I am going to find a noise filter/surge suppressor outlet and plug that in, maybe forcing the keypadlinc to RF only. and see what that does. I might also try a 2477D in the same spot as the 2476D

@Guy Lavoie I'll try that but I don't understand if the scene doesn't change the switch, how does the virtual switch work? To solve the three way issue I used the "scenes" as outlined in the ISY cookbook, and they work 99% of the time. I also extended that thought process and where I needed dual band keypads I used those keypads to show me lots of things like active motion zones. If I am in the recording studio and someone walks in the front door a keypad lights up. as they come up the stairs the next key lights etc. If they go the wrong way, I know to go get them. How did you set up the Virtual key program to monitor? Endless query loop?

@Guy Lavoie There are several scenes that don't sync, this morning it was the temperature scene but the one in question is a 4 set up with. 2476D Switchlinc Dimmer W Beeper 4.0 - The live load KeypadLinc Dimmer 5 Button V.43 Button 2 KeypadLinc Dimmer 5 Button V.45 Button 2 When the scene for all of these turns off, the 2476D turns off the other two remain "on" If I press any of the three buttons, they work as they should. Scene command from Insteon ok, ISY not so ok. I am guessing due to the lack of verification by ISY?

@palayman, Have you thought about using a State to trigger a program? I use this to prevent my A/C from short cycling when I go in or out a door but to shut it off when the doors are open too long. I use the reverse methodology to insure the doors/windows are closed for at least 10 minutes before letting the HVAC turn back on. Do something like this and change to 30 minutes? Doors_Windows Open - [ID 000A][Parent 0001] If $sOpenWindow is 0 And 'ELK Alarm' Arm Up State is Not Ready To Arm Then Wait 10 minutes Run Program 'd_Doors_Windows Still Open' (If) Else - No Actions - (To add one, press 'Action') // Used to shut off HVAC if Doors and Windows opened for extended periods of time, but delays shutdown long enough to prevent short cycling of system. d_Doors_Windows Still Open - [ID 0002][Parent 0001][Not Enabled] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $sOpenWindow = 1 Else Run Program 'Doors_Windows Closed' (If) // Used to prevent short term Door or Window openings from short cycling HVAC system - Program should be disabled as it is triggered by Doors_Windows Open Doors_Windows Closed - [ID 0038][Parent 0001] If $sOpenWindow is 1 And ( 'ELK Alarm' Arm Up State is Ready To Arm Or 'ELK Alarm' Arm Up State is Armed Fully ) Then Wait 10 minutes Run Program 'd_Doors_Windows Still Closed' (If) Else - No Actions - (To add one, press 'Action') d_Doors_Windows Still Closed - [ID 0035][Parent 0001][Not Enabled] If 'ELK Alarm' Armed Status is not Disarmed Or 'ELK Alarm' Arm Up State is Ready To Arm Then $sOpenWindow = 0 Else - No Actions - (To add one, press 'Action') // Used to prevent short term Door or Window openings from short cycling HVAC system - Program should be disabled as it is triggered by Doors_Windows_Closed

Jumping in on this, after just thinking I fixed my long running randomness which showed that programs run in a different order and at different relative times. I did some research into core logic and each processor has its own method for stacking accumulators. From what I can tell the Eisy accumulator stacks in FIFO order so whatever states were used most recently are checked last. However the software can read from the top of the stack so understanding the hardware bios doesn't appear helpful. Either way this would lead to some randomness and the humans in this house turn things on changing states at variable times. Today I was wondering why my heat was on with doors open. $sOpenWindow = 1 which sends a scene "Temp Peak Power". This turns the HVAC controllers in both zones off. While trying to figure out what is going on, the "Summary" tab of the programs page in the AC doesn't have a start time for 18 programs. Several of them have run since the last reboot to include Doors_Windows Open which should be running. It has been 30 minutes, and there is no "Last Run Time" in the Summary tab. Using the logic that Wait rechecks the IF this has worked well until today. Should last Run Time be the last "Start" time and the last finish time blank until it finishes? Right now I have all blank, heat on and $sOpenWindow is 0 but the Details page shows Doors_Windows Open to be true (green). Doors_Windows Open - [ID 000A][Parent 0001] If $sOpenWindow is 0 And 'ELK Alarm' Arm Up State is Not Ready To Arm Then Wait 10 minutes Run Program 'd_Doors_Windows Still Open' (If) Else - No Actions - (To add one, press 'Action') // Used to shut off HVAC if Doors and Windows opened for extended periods of time, but delays shutdown long enough to prevent short cycling of system. d_Doors_Windows Still Open - [ID 0002][Parent 0001][Not Enabled] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $sOpenWindow = 1 Else Run Program 'Doors_Windows Closed' (If) // Used to prevent short term Door or Window openings from short cycling HVAC system - Program should be disabled as it is triggered by Doors_Windows Open Temp WinOpen + Peak - [ID 0031][Parent 004B] If $sOpenWindow is 1 Or Program 'Peak Power' is True Then Set 'Temp Scenes / Temp Peak Power' On Else - No Actions - (To add one, press 'Action')

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

@flsenior, When upgrading to the Eisy, many scenes and on levels didn't transfer properly. It is sort of a three step process, that has some goofy options and doesn't work the way I might expect. 1. You can set the on level for the device on the Device window directly. Once you select the level i.e. 60% you must then press the "On Level" button next to the level to set it. Otherwise it remains where it was. Now if you simply send "on" from a scene that level is what happens. Or you can set the level within the scene. 2. You can set the on level in the scene. a. Select the Scene b. Select the device within the scene c. Select the "on level" % in the drop down d. Press the "Update" button just to the left e. Select the Scene again and verify your selected on level appears in the scene line above. I prefer to set the On Level and Scene level separately, so each scene can have a mood. My default for all lights is 80%, and then each scene set appropriately.

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