Long Running Randomness

[CoolToys]

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]

6 hours ago, CoolToys said:

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.

No.  There is nothing hiding in there.  As others have pointed out, green is an indication that this program last ran as TRUE and will stay green until (if ever) it runs false.  Did you program run FALSE at 4:01?  If not, you should not expect it to be back to red.

[CoolToys]

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

[larryllix]

6 hours ago, CoolToys said:

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

One the techniques I used for a while was to trigger Else, just to make the indicators more useful.

If a trigger is switched On
Then
. . . . do a bunch of stuff
......Wait 2 seconds so I can see the green flash
..... Run 'This Program (Else)'
Else
..... must be empty or just turning off the same devices.

Edited November 29 by larryllix

[CoolToys]

On 11/29/2024 at 11:55 AM, larryllix said:

One the techniques I used for a while was to trigger Else, just to make the indicators more useful.

If a trigger is switched On
Then
. . . . do a bunch of stuff
......Wait 2 seconds so I can see the green flash
..... Run 'This Program (Else)'
Else
..... must be empty or just turning off the same devices.

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.  

 

[Guy Lavoie]

10 hours ago, CoolToys said:

My Isy worked great for years but, since upgrading to the eIsy, nothing has worked right since.

I've just been reading through the whole thread for the past hour. Sounds like there is something fundamental that changed in the execution logic, when it went from a standalone program to one that runs as a unix application. It also reminds me of my own thread about how the execution order is "unknown", which could do crazy things, especially if the order is not only unknown, but possibly different from time to time.

[larryllix]

IIRC, In the end of porting from my ISY994 to my polISY, after attempting to copy it over, I just printed out all my programs and re-entered them manually into my new polISY box.

However, I had just moved from a larger home to a smaller apartment and my HA needs were much smaller and quite different. I started from scratch using variables for almost all lighting scenes as the operations are much more debuggable, and simpler, to write more complex deviations to the standard trigger on and time off processes.

Edited December 11 by larryllix

[CoolToys]

2 hours ago, larryllix said:

IIRC, In the end of porting from my ISY994 to my polISY, after attempting to copy it over, I just printed out all my programs and re-entered them manually into my new polISY box.

 

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.  

[CoolToys]

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? 

[oberkc]

9 hours ago, CoolToys said:

There is clearly a communication problem.  The isy would show "unable to communicate" when it couldn't see the device.

One of the things I understand about the IoX and Insteon is that direct commands to devices (as opposed to scene commands) involve the command followed by some type of acknowledgement from the responding device.  The command is repeated a few times if no acknowledgement is received.  These types of commands tend to be more reliable, in my experience.  Scene commands, on the other hand, do not have the acknowledgement and IoX simply assumes the responder device reacted accordingly.  I find large scenes can be less reliable in response.  I have devices that respond to queries and direct commands near 100% but respond to scene commands less reliably.

I have a couple of devices at my house that are particularly prone to this problem.  Communication problem?  Yes.  I have also found that replacing the suspect device (some of mine are probably starting to push 15 years old) usually solves the problem which makes me think that Insteon communication performance can fade over time without completely failing.  Of course, the devices of the electrical system in my house have evolved over that same time and I am sure that the electrical environment (noise, attenuation) has evolved along with it.  

The only reason I bring this up is that I it is not uncommon at my house to find status mismatches between IoX and various devices but without showing "unable to communicate".  

[oberkc]

On 12/11/2024 at 10:41 AM, CoolToys said:

Humans are a linear serial computer.

Unless one has ADD

[paulbates]

To @oberkc's point:

I went back and looked at the iox program you posted, and he has a point that plausibly explains what you're seeing

Set 'MB Kelly Watch Winder' Fast Off
Set 'Garage Lights' Off
Wait  5 seconds
Set 'Kitchen Main Lights 3 way' Off
Set 'House Front' Off
Set 'Garage Front Porch Lite' Off

The commands inside of the 2 groups, before and after the "Wait 5 seconds", are banging into each other. Each "Set" command is creating messages to the Insteon device, and the Insteon device is responding. The next 'Set' command from the PLM is banging into that return message from the switch... then its retrying.. more collisions

There are 2 ways to address this:

1.  (Recommended). Put each group of devices into a scene and turn the scene on or off. Scenes don't send clean-up messages, no wait is needed
2. Put a 2 or 3 second wait after each direct device command.

[CoolToys]

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

[CoolToys]

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

Hmmm. Pretty strange. One more relatively easy traffic related suggestion. Most Insteon switches have an option called "blink on traffic" or something like that. The switches status light will blink when it sees any (or perceived) Insteon traffic.

I'd suggest picking one or a couple of switches near where you are when the tests are run, turn that feature on temporarily and see how long the blinking goes for. Typically it will be a few seconds, if it's longer or continuous, something is going on traffic wise. 

[CoolToys]

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

[CoolToys]

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.