CoolToys

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

Quick Update - In one scene I used "Motion" from the first motion II sensor instead of "Activity" which is where motion was registered. One scene problem solved and possible one "random" light since "Motion" was always "On" for that option on that sensor. Doesn't explain why that light/scene wasn't always on but... I also realized that in my "Bedtime" program I used the option of "Switched" instead of "Status" IF MB Door Keypad is switched off Instead of IF MB Door Keypad Status is off. My guess is that "Switched off" is momentarily true, where "Status off" is true until "on". That would explain a lot. I have that in a lot of places and just made them all "Status" since I force the switched "on" when the lights come on at sunset and the only momentary command I use is the side gate lock release. To monitor this I have colored the buttons green and have the LED on so I know the status without logging into the UDI AC. Fingers crossed the next few days work.

@paulbates, Thanks I will try and figure out how to turn the blink on traffic on. I don't see that in the UDI admin panel so it must be another way. Last week I tried changing the IF statement and having only IF $sBedtime=1 Then I created a program "Bedtime Trigger" IF $sOccupied =1 And (MB Keypad door is switched off or MB Keypad Window is switched off) THEN $sBedtime=1 When I pressed the button, $sBedtime went from "0" to "1" but the Bedtime program didn't run at all. Last night I took out the state variable $sOccupied and reverted to the buttons. So instead of IF $sOccupied=1 and (MB Keypad door is switched off or MD Keypad window is switched off) I used IF MB Keypad door is switched off or MB Keypad Window is switched off The bedtime program ran. But it ran before sometimes with $sOccupied = 1 in there. Today I have been going through the system with a fine tooth comb, comparing everything and I noticed I have three Insteon Motion II v.47 sensors but for some reason the UDI admin panel sees them differently. The First One Has: Activity (With the same boxes as the Motion option below) Motion (Always On) Tamper (blank) The Other Two Have Motion (on or off depending on activity) Motion.Enabled (blank) Tamper (blank) I also found several scenes where the light was off but the button was on. Since the button on the 6 buttons is a controller/responder I assumed the button would follow the light if the light was turned off somewhere. So as I followed some earlier advice of using scenes in the longer programs it appears where there is still a direct command to the light, the button is not "responding". I also added the Amazon command "time for bed" via the mobile app, to see what that does to the bedtime scene. It didn't work at all. Alexa said "Sleep Well" and that was it. I wish I could have an option to return the eISY to "linear" thinking so this "wait" thing wouldn't be the looming question. It shouldn't be, especially when i used triggers for variables, and yet those are the least consistent results. According to the UDI guide, ISY works on states and the $svariable=1 doesn't change so each wait should still read true, and the fact that the program has a green bar also indicates true and yet the program randomly stops or light come back on. I am thinking of relocating the eISY and PLM today to a position closer to the main panel as a test of noise/signal strength issues. I do have a dual mode switch in at least every other room. If Lutron/Control4/Crestron had the capability of the Insteon 6 button in a prosumer product so I didn't need a dealer or need to become one, I would switch today.

@paulbates, New experiment, one "bedtime" all scenes, one all direct commands with 2 seconds in between. The button on my side of the bed started the scene version, my wife's side the other version. Similar issues, first three-five steps completed and it stops. Working from the thought process that the wait statement causes a re-evaluation of the "if" I went to the next experiment. The "off" button next to the bed would change sBedtime from 0 to 1. Then the "If" was changed to if sBedtime = 1. This time nothing happened. The variable changed to 1, so we know the command was received, but not one light went out. I then used UDI mobile to run the "Then" of the bedtime flows. This time the one will only direct commands worked, however 45 seconds later a light came back on downstairs. I then sent the "Then" for the version with scenes, and the light went out and a few minutes later a different light came back on. All the other state variables were 0 so no other lights should be triggered.

@paulbates and @oberkc, the idea of direct v scene and inserting delays, along with noise etc are all challenges of the system at this point. Sadly I don't have enough data points that are consistent to have any reliable data. The only thing that really conclusively screwed up my system was a cyber power UPS. Everything on that phase quit working and the minute I unplugged it, back to normal. Rebuilding the entire program from scratch and using more scenes and fewer direct commands resulted in one perfect run and one zero run. Again no data. Last night when I pressed the "off" button, the program started running and nothing happened. I manually ran the "then" from the AP and it worked. Since X-10 is weaker and less reliable I keep an old X-10 keypad and plug it in when I have issues and test. The AP doesn't see a thing when I use the X-10 keypad next to my bed, so maybe comm, but then why did it work perfectly two nights ago? As you both pointed out scenes don't have a response, so if the command is lost, that scene never turns off. That I have experienced over and over. Very frustrating. As I look around the house this morning, I see that two of the three way slave switches that are in scenes still display an "on status". The AP says "off", the master is off and the light is off. When I select "Query" the AP still says off. When I force the scene on and then off, everything corrects. Clearly the "handshake" of the query is not happening or the comm noise is so bad, 50% is being read as "off". One very odd thing from time to time is that I will find a light stops working and the "on level" in the scene is set to 0%. Something that was working, now isn't. I change it to 60% or something and the scene again works. I thought as a practice after deleting variables or scenes that I should re-boot IOX or the entire eisy. Last night the reboot did all kinds of odd things. The unknown variable [Var2.8] came back, and the sDaytime Variable appeared in some of the programs as "State_8" again. I resaved, restarted and State_8 changed to sDaytime in the programs again. I don't change anything when it is working. I only dig when it stops. I haven't made any major changes to my system except the eisy upgrade and zigbee/matter module upgrade. I bought the zigbee/matter for my Greywind blinds but they don't work with the eisy for some reason. I can find them but can't control them. Like you guys many of my insteon switches are pushing 15 years old.

Well, it is getting to be more fun.... I wiped the program. Rebooted and recreated the program clean. The bedtime button worked (only once and this has happened before) but now random lights are turning off. When I query the device it says "on" when I can see the red LED from here that it is off. There is clearly a communication problem. The isy would show "unable to communicate" when it couldn't see the device. In this case I have no idea where the problem is. Noisy lines, Insteon issues, PLM issues?

Ugh... @larryllix I have been thinking that it would be necessary to wipe the slate clean and start over. And after reading thorough all of my posts over the years (I have another name on here that some guy with a skiwear company sued me over so I can't use it, I won, he had more money so I gave up) I realize now that there were two changes about the time I started having issues with the "bedtime" program. I used to have the old smarthome 2430. When that died, no one made a replacement and Ken talked me into the insteon mini-remotes. There are two other threads here about how those never worked. In that mix was the swap from iSY to eIsy. The rest of the house works as it should as long as all of the batteries in the motion sensors are good. I just don't want to reprogram that many battery devices that require manually forcing into set mode. Several of which are the in door sensors so they have to be physically removed. Last night I did watch everything shut down, and while it did work, @Guy Lavoie is correct, the order is wonky. This is where my little human pea brain just doesn't get it. Humans are a linear serial computer. Why isn't this any more? anyway, the first and last items both were in order but the house looked like three people going to bed, lights here and there randomly turning off. I designed it pretty much as I did every Lutron or Creston my former business ever installed. Starting at the alarm keypad I walk to the bedroom turning off lights as I pass the switches. That becomes the program. Last night it looked liked I was a pachinko ball. I think tomorrow, I will invest the time to wipe the bedtime program. Save and reboot the eisy and then build it again and see what happens. I may also set up a stepped state so that when I press the bedtime button it just sets a state variable, so the fact that the button is no longer being pressed can be ruled out.

Well I did that and with the "wait's", I never get there. Worse is that each loop back to the top stops at a different place and I can't figure out why. I don't know if the button is temporary but 12 days of testing, each day the program stops at a different spot. If I press "off" please run the program with the waits so it looks like someone walking though the house. Lutron does it, Crestron does it and Isy used to do it. I gave up my Crestron/Lutron 20 years ago when Crestron released their own lighting panels. My Isy worked great for years but, since upgrading to the eIsy, nothing has worked right since. Insteon Bankruptcy was about the same time so I have no idea where the bugs are... Sorry but this is not what I want the system to do. Yes say it, because I hear it, "Give it up boomer, linear programming is dead". But sadly humans are linear systems so some may think they can outthink with a system like this, but we can't mimic human behavior without it. When A happens, do B, C, D, E and a little later do F. That is how we work. The goal is to make my house "feel natural", and it used to. Now it is just "bedtime = all off" or the system gets lost.

@oberkc, Yes I understand this, my point is that it makes troubleshooting one step harder, and if I make it false otherwise 4:01 there may be other trickle down consequences since each wait statement rechecks validity of the "IF" statement. I once thought I was pushing the limits but have since seen two much larger systems. I have a bug in my program and haven't found it yet. The bedtime button worked for years. Last night it worked except for two lights which are not related, not in any joint scenes. I waited 5 minutes, pressed off again and one light remained on.

And the Saga Continues..... @larryllix thought on variables I think is valid. If you delete a variable but don't save the changes and make sure it is deleted from all programs the variable doesn't get commented or errored out like if you delete a scene or device. I did recheck all of the programs for variables, and resaved each one, a second mystery variable was found and deleted. All of the scenes that used three way switches were deleted and rebuilt with different names. All switches that are in a scene were removed from the main program and the scene became the then action line. There are times where I want only one device in a scene to come on, and it seems to help if I turn the scene off instead of the device but.... In order to troubleshoot, I placed some random switches in the program that light up at different points in the sequence. The trigger or "state" to start the bedtime program is to press the "off" button on one of two 6 button keypads. For the past 10 days, it has: 1. Worked perfectly once. 2. For 7 days it ran half of the program and stopped. After 5 minutes I press off again and it worked. 3. For 2 days (not sequential) it did the same thing where the lights in our bedroom came on and some other random light downstairs. Both times the other light was different and when I look at the variables and programs running, it looks like what I think I should expect. Some programs like "night to early morning" are always green even though the "If" is 4:00 am so there may be something hiding in there. In my mind it should be green at 4 am only at 4:01 back to red but that is just me. Tonight I added a scene where both of the 6 button keypads are responders so they are both "off" when either one is pressed. I'll check back in next week with an update since one or two days are never enough. I almost wonder if I did something wrong in the migration from the ISY to the eISY and should just reset and start over. Unfortunately I am way too busy (and lazy) for that. I'd rather stroke the local control4 or Lutron rep a check. The other question I have is that if each wait goes back and checks the "If" state to make sure it is still true. When you press a button, how long is that press true for. I spent some time today looking for anything that could undo or reset the "off" state and came up empty. I checked the state of the button each of the 10 days and the program and both were correct (off and true). So I don't know why it stopped halfway twice. I assume it looked at the IF and declared it false but the program still showed "true" so that shouldn't be it.

@oberkc, Well there is a thinker. I did a find/replace all on a variable a while ago I had two that did the same thing, so I changed them all to one, and then deleted the variable from the table. I also noticed that "Bedtime_2" test program was back. Did not know that when you delete a program you must "save" or it is still there just not visible, it doesn't have a "red arrow" to remind me to delete, I thought "delete" was enough. Did not know that a broken variable can overload the system. Looking back at logs, there was an extended power failure while I was gone so my guess is the eisy rebooted and brought back my unsaved changes. Thank you

Got a new one tonight. House was in "away" mode, and I got home. The program didn't run so I looked in the AC and the "Away to Home" program was yellow. In the summary, there are two that say "not loaded, out of memory". The interesting thing is I do not have a program called "Bedtime_2". I built it as a test, and then deleted it after @larryllix cleared up the linear thinking issue. I rebooted at the bedtime_2 went away but bedtime still says "out of memory"?

@larryllix, the truth is I never opened the Ecobee once I got one of the 2441Th to work. The second one appears to have corrected however is isn't "calling", or the heater isn't kicking on, nor is the air for that zone. The Thermostat says it is calling, The way the door opens I can't test voltage, only wire continuity, so still without HVAC in the main part of the house. 🥶

@Ross, we looked at Hunter Douglas and they are a better quality product without a doubt. I had hoped that since the Greywind/Yooksmart had the Matter option it would work with my eISY. No such luck. When listening for matter devices they immediately appear but then are blank. I still have hope, but am stuck telling Alexa or Apple to open and close the blinds for me when the fixed schedule doesn't work.

Happy (ish) to say that the full power removal reset and restore of the 2441TH both worked. The Sensi was so much better looking I would have paid to keep it if it worked. Ecobee didn't cover the hole and wasn't that much better looking so it goes back too. Thanks for the help @Brian H. The key is to unplug the PLM, and just as important, plug it in when you try and re-discover the 2441TH