Strange Program Issue - Works Fine When Run Manually, But Status Issue When Run From A Schedule

[bjs169]

I have an issue that has been plaguing me for some time. Status changes are detected from a device when I trigger a program manually, but when that same program is triggered on a schedule status changes are not detected.

I have a sunset program that turns on a scene, sets the backlight level of a keypad, and runs a "downstairs lights" program. No issue with the scene or the backlight level.

The "downstairs lights" program runs and sets a device to 60%, turns on a few scenes, and calls a networking resource. Everything executes fine and everything that is supposed to turn on does turn on. However, one of the scenes has an issue related to status. It turns on four devices. Two of those devices are monitored by "status change" program for any status changes in those devices. This "status change" program never triggers under these conditions.

HOWEVER!

If I run the "downstairs lights" program manually from ISY interface then the "status change" program DOES get triggered.

Sunset - [ID 0016][Parent 0021]

If
        Time is Sunset  - 30 minutes
 
Then
        Run Program 'Downstairs Some On' (If)
        Set 'Scenes / Device Scenes / Front Outside' On
        Set 'Devices / Master Bedroom / Master Bedroom KP Dimmer / A: Master Bedroom Outlet' Backlight On  1 / Off 0
 
Else
   - No Actions - (To add one, press 'Action')
 

Downstairs Some On - [ID 0035][Parent 0020][Not Enabled]

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Set 'Devices / Living Room / Living Room Lamp Dimmer' On 60%
        Set 'Scenes / Special Scenes / KitchenIslandAndSink' On
        Set 'Scenes / Device Scenes / Office Brian' On
        Set 'Scenes / Device Scenes / Office Lori' On
        Resource 'Hue Morracan Lamp On'
 
Else
   - No Actions - (To add one, press 'Action')

KitchenIsandAndSink scene:

 

HandleKitchenKPStatusChangeA - [ID 000E][Parent 0005]

If
        'Devices / Kitchen / Kitchen KP Dimmer / A: Kitchen LV' Status is Off
    And 'Devices / Kitchen / Breakfast Dimmer' Status is Off
    And 'Devices / Kitchen / Kitchen Island Switch' Status is Off
    And 'Devices / Kitchen / Kitchen Sink Switch' Status is Off
 
Then
        $kitchenKPLStatus  = 0
 
Else
        $kitchenKPLStatus  = 1

I have to be missing something, right? Either that or I am having bad luck and I experience interference only when the sunset program runs and never when I run it manually? Seems unlikely, so I assume that I just don't understand something about how ISY programs execute in different situation (i.e. scheduled vs. manual).

Any thoughts?

Thanks!

Edited December 2, 2022 by bjs

[Techman]

A few things to try/check

In your Sunset program you need to run the DOWSTAIRS "THEN" not the "IF"

Make sure your variables are STATE and not integer variables if they trigger a function. I see where you're setting the variables but not where they are in the program

Sometimes adding a 2 second WAIT before a line that's not executing helps.

Edited December 2, 2022 by Techman

[bjs169]

10 minutes ago, Techman said:

A few things to try/check

In your Sunset program you need to run the DOWSTAIRS "THEN" not the "IF"

Make sure your variables are STATE and not integer variables. I see where you're setting the variables but not where they are in the program

Sometimes adding a 2 second WAIT before a line that's not executing helps.

Thanks for the quick response.

1) I will try running the THEN, but was under the impression that running an empty IF is the same as running a THEN. But I am open to trying anything. Will see how that works out tomorrow.

2) My variables are state variables. Here is how I use it:

HandleKitchenKPStatusChangeB - [ID 0066][Parent 0005]

If
        $kitchenKPLStatus is 0
 
Then
        Set 'Scenes / Program Related_Scenes / KPL All Off On / prs_KPL_All_Kitchen_Off' On
 
Else
   - No Actions - (To add one, press 'Action')
 

HandleKitchenKPStatusChangeC - [ID 0067][Parent 0005]

If
        $kitchenKPLStatus is 1
 
Then
        Set 'Scenes / Program Related_Scenes / KPL All Off On / prs_KPL_All_Kitchen_On' On
 
Else
   - No Actions - (To add one, press 'Action')
 

3) I already tried the wait approach (3 seconds, not 2) thinking maybe there was just too much traffic at once on the network. It didn't help, so I reverted that change.

The other thing I was thinking is I could just add a query command to the program to query the state of one of the devices (Kitchen Sink / Kitchen Island), but that seems like a hack. I'd rather solve the real problem if it can be solved.

Thanks again!

[Techman]

@bjs

The IF is used to evaluate a condition. Being that your IF statement is blank nothing will happen when you call it.  

The THEN statement will run when either it's called from another program or if it meets the conditions in the IF statement.

 

Edited December 2, 2022 by Techman

[bjs169]

32 minutes ago, Techman said:

@bjs

The IF is used to evaluate a condition. Being that your IF statement is blank nothing will happen when you call it.  

The THEN statement will run when either it's called from another program or if it meets the conditions in the IF statement.

 

I appreciate your help and will try your suggestion about using THEN, so don't want to argue with you, but what you say about an empty IF is not accurate. You had me second guessing myself, so I just verified by running an empty IF and the THEN ran fine. And, recall from my OP, the instructions in the THEN have been executing. Just one of them has an issue with status, but the control does actually work. The empty IF executing the THEN makes sense to me from a Boolean logic perspective. But go ahead and try yourself.

None-the-less, I have already taken your advice and updated the program to run the THEN just to see if that helps.

Thanks again!

[MrBill]

@bjs169 I'd rewrite the first program like this:

If
        Time is Sunset  - 30 minutes
 
Then
        Set 'Scenes / Device Scenes / Front Outside' On
        Set 'Devices / Master Bedroom / Master Bedroom KP Dimmer / A: Master Bedroom Outlet' Backlight On  1 / Off 0
        Wait 3 seconds
        Run Program 'Downstairs Some On' (THEN)

Else
   - No Actions - (To add one, press 'Action')

I suspect the Insteon buffer is getting trashed, because two programs are sending commands at once.  The error log probably shows these collisions.  Let the first "sunset program" get it's commands out, then trigger the second program.

What's the purpose of the variable that is being set via the third program?  That program seems like there are better ways to approach the issue?  how is the variable used?  I assume it's a state variable? i See you already answered that let me study that a minute...

Edited December 3, 2022 by MrBill

[MrBill]

14 hours ago, bjs169 said:

HandleKitchenKPStatusChangeB - [ID 0066][Parent 0005]

If
        $kitchenKPLStatus is 0
 
Then
        Set 'Scenes / Program Related_Scenes / KPL All Off On / prs_KPL_All_Kitchen_Off' On

If these programs are about turning keypad buttons on an off, just include them in scenes.  You don't need programs for this.  Insteon has what I call "sloppy" scene's.  You can create scene's that are separate and include those devices and buttons in other scene's.   For example I have two buttons at the front door that are scene controllers for the top and bottom of the front porch outlets.  Those outlets, and the buttons are also included in other scenes, one in the general outdoor lighting scene that has many members, and the other outlet and its button appears in the "holiday" scene.

[bjs169]

5 hours ago, MrBill said:

If these programs are about turning keypad buttons on an off, just include them in scenes.  You don't need programs for this.  Insteon has what I call "sloppy" scene's.  You can create scene's that are separate and include those devices and buttons in other scene's.   For example I have two buttons at the front door that are scene controllers for the top and bottom of the front porch outlets.  Those outlets, and the buttons are also included in other scenes, one in the general outdoor lighting scene that has many members, and the other outlet and its button appears in the "holiday" scene.

I've implemented the change you suggested in the sunset program. That's not something I have tried before. We shall see how it goes.

All of my 8 button KPLs use the G button as an "all off" and the H button as an "all on" shortcut to turn off / on everything controlled by that KPL. They also act as status indicators. If a single device controlled by the KPL is on then the H button will be on and the G button will be off to indicate something is on. When everything the KPL controls is off then t G button will be on and the H button will be off to indicate nothing is on. I have had quite a bit of difficulty in getting this to work reliably and this approach does seem to work on my other KPLs. But certainly open to suggestions if this "all on / off" is something others have done before.

[MrBill]

43 minutes ago, bjs169 said:

I've implemented the change you suggested in the sunset program. That's not something I have tried before. We shall see how it goes.

All of my 8 button KPLs use the G button as an "all off" and the H button as an "all on" shortcut to turn off / on everything controlled by that KPL. They also act as status indicators. If a single device controlled by the KPL is on then the H button will be on and the G button will be off to indicate something is on. When everything the KPL controls is off then t G button will be on and the H button will be off to indicate nothing is on. I have had quite a bit of difficulty in getting this to work reliably and this approach does seem to work on my other KPLs. But certainly open to suggestions if this "all on / off" is something others have done before.

I have a lot of H is "all off" instances, but I don't really use the concept of all on.  H is simply set as "Non-Toggle Off" and is attached to a scene only, not a program. 

If your use case is working for you go for it.... but it does increase the amount of insteon communication required, thereby creating some of the collisions you're dealing with.  I really think moving the "sub-routine" to starting 3 seconds after the other commands will improve your situation.

[bjs169]

1 hour ago, MrBill said:

I have a lot of H is "all off" instances, but I don't really use the concept of all on.  H is simply set as "Non-Toggle Off" and is attached to a scene only, not a program. 

If your use case is working for you go for it.... but it does increase the amount of insteon communication required, thereby creating some of the collisions you're dealing with.  I really think moving the "sub-routine" to starting 3 seconds after the other commands will improve your situation.

Unfortunately, the changes suggested by you and Techman in this thread did not help today. Sunset program ran, all my devices turned on as expected, but no status to trigger the "status change" program (HandleKitchenKPStatusChangeA). I then manually run the "downstairs lights" program (Downstairs Some On) and the status change program does trigger.

Very weird. Maybe I need to redesign the way the KPL all on / all off work, but very odd that it is only this one KPL and only when triggered by a schedule.

Maybe someone has some ideas. Instead of talking about how I have it programmed, maybe I will talk about what I want to achieve, and someone can suggest an approach.

1) I want the G button to turn off every device / scene tied to the A-F buttons when the G button is pressed. And when everything tied to A-F is off then I want the G button to be lit. If any device / scene tied to the A-F buttons is on then the G button should be not lit.

2) I want the H button to turn on every device / scene tied to the A-F buttons when the H button is pressed. And when any devices tied to A-F is on then I want the H button to be lit. If all devices / scenes tied to the A-F buttons are off then the H button should not be lit.

Status pseudo-code:

IF (A OFF AND B OFF AND C OFF AND D OFF AND E OFF AND F OFF) THEN G = ON AND H = OFF

IF (A ON OR B ON OR C ON OR D ON OR E ON OR F ON) THEN G = OFF AND H = ON

[MrBill]

What I would do if I were you is just simplify this. 

If
        Time is Sunset  - 30 minutes
 
Then
        Set 'Scenes / Device Scenes / Front Outside' On
        Set 'Devices / Master Bedroom / Master Bedroom KP Dimmer / A: Master Bedroom Outlet' Backlight On  1 / Off 0
        Set 'Devices / Living Room / Living Room Lamp Dimmer' On 60%
        Set 'Scenes / Special Scenes / KitchenIslandAndSink' On
        Set 'Scenes / Device Scenes / Office Brian' On
        Set 'Scenes / Device Scenes / Office Lori' On
        Set 'Scenes / Program Related_Scenes / KPL All Off On / prs_KPL_All_Kitchen_On' On
        Resource 'Hue Morracan Lamp On'
 
Else
   - No Actions - (To add one, press 'Action')

[bjs169]

On 12/4/2022 at 8:14 AM, MrBill said:

What I would do if I were you is just simplify this. 

If
        Time is Sunset  - 30 minutes
 
Then
        Set 'Scenes / Device Scenes / Front Outside' On
        Set 'Devices / Master Bedroom / Master Bedroom KP Dimmer / A: Master Bedroom Outlet' Backlight On  1 / Off 0
        Set 'Devices / Living Room / Living Room Lamp Dimmer' On 60%
        Set 'Scenes / Special Scenes / KitchenIslandAndSink' On
        Set 'Scenes / Device Scenes / Office Brian' On
        Set 'Scenes / Device Scenes / Office Lori' On
        Set 'Scenes / Program Related_Scenes / KPL All Off On / prs_KPL_All_Kitchen_On' On
        Resource 'Hue Morracan Lamp On'
 
Else
   - No Actions - (To add one, press 'Action')

Hey MrBill, thanks for taking so much time with me. I really appreciate it.

I am not asking you to do my homework, but the install is more complex than that as you probably could imagine. Many scenes, programs, and, of course, manual button presses can cause the devices tied to A-F to change status. I want G&H to be responsive to all those events and not just the events raised by a single program (e.g. sunset). That is why I have tried to abstract the state of G&H into their own program so no matter how state on A-F devices changes I *should* end up with G&H in the right state, but it has been a challenge for sure.

One change I made to try today is created a second sunset program that kicks off at Sunset - 15 minutes and will put the "downstairs on" program in there to see if the longer delay helps. This sort of imitates what I have been doing manually which is wait for the current sunset program to run, go and take a look and see the state is incorrect, and then run the downstairs on program from the ISY UI to "fix" the status.

It's an odd one.

[MrBill]

7 minutes ago, bjs169 said:

but the install is more complex than that as you probably could imagine.

Gosh I guess your right, I'd have trouble imagining a complex installation.  I have 346 Insteon Nodes, 112 scenes, 67 node server nodes, 87 state variables 109 integer variables and 507 programs, that the ISY, on the Home Assistant side there's even more.... but I likely can't imagine an installation as complex as yours.

Good Luck!

[bjs169]

25 minutes ago, MrBill said:

Gosh I guess your right, I'd have trouble imagining a complex installation.  I have 346 Insteon Nodes, 112 scenes, 67 node server nodes, 87 state variables 109 integer variables and 507 programs, that the ISY, on the Home Assistant side there's even more.... but I likely can't imagine an installation as complex as yours.

Good Luck!

Sorry. I apologize if my comment sounded sarcastic. It wasn't intended that way. I appreciate all your help. I was just clarifying that the status gets changed in a variety of situations and not just the one use case. Sorry again. You have been very helpful so far.

[kzboray]

45 minutes ago, MrBill said:

Gosh I guess your right, I'd have trouble imagining a complex installation.  I have 346 Insteon Nodes, 112 scenes, 67 node server nodes, 87 state variables 109 integer variables and 507 programs, that the ISY, on the Home Assistant side there's even more.... but I likely can't imagine an installation as complex as yours.

Good Luck!

Beginner! 😁

[bjs169]

3 hours ago, bjs169 said:

One change I made to try today is created a second sunset program that kicks off at Sunset - 15 minutes and will put the "downstairs on" program in there to see if the longer delay helps.

This helped. So, next question is did it help due to the delay being longer or did it help because the "downstairs on" was executed twice.

I'll eliminate the second sunset program and add a 15 minute wait to the original sunset program to see if it still works with the longer delay, but not the second execution.

[MrBill]

18 hours ago, bjs169 said:

Sorry. I apologize if my comment sounded sarcastic. It wasn't intended that way. I appreciate all your help. I was just clarifying that the status gets changed in a variety of situations and not just the one use case. Sorry again. You have been very helpful so far.

My point is the best way to do it is just create programs that do everything themselves....   the way you're using programs as subroutines can work, I do it several places such as my goodnight and away routines that use the same list of turn off's.   You're not saving a million lines of code doing it the way your doing it, but you're creating a buffer timing issue.  I thought you could work around that by moving the Run program to the bottom of the program and adding a wait before it, but you said that didn't work.  My best suggestion is have your programs do everything they need to do within one program.  In the case of my Goodnight / away situation yes the turn off list is a common THEN block but it's the only string of insteon commands being sent, so once insteon is being executed there are no other programs to inject "noise" or "confusion".

[bjs169]

On 12/5/2022 at 5:37 PM, bjs169 said:

This helped. So, next question is did it help due to the delay being longer or did it help because the "downstairs on" was executed twice.

I'll eliminate the second sunset program and add a 15 minute wait to the original sunset program to see if it still works with the longer delay, but not the second execution.

Adding the 15 minute wait worked.

Sunset - [ID 0016][Parent 0021]

If
        Time is Sunset  - 30 minutes
 
Then
        Set 'Scenes / Device Scenes / Front Outside' On
        Set 'Devices / Master Bedroom / Master Bedroom KP Dimmer / A: Master Bedroom Outlet' Backlight On  1 / Off 0
        Wait  15 minutes 
        Run Program 'Downstairs Some On' (Then Path)
 
Else
   - No Actions - (To add one, press 'Action')
 

I will try shortening it today.

[bjs169]

On 12/6/2022 at 9:58 AM, MrBill said:

My point is the best way to do it is just create programs that do everything themselves....   the way you're using programs as subroutines can work, I do it several places such as my goodnight and away routines that use the same list of turn off's.   You're not saving a million lines of code doing it the way your doing it, but you're creating a buffer timing issue.  I thought you could work around that by moving the Run program to the bottom of the program and adding a wait before it, but you said that didn't work.  My best suggestion is have your programs do everything they need to do within one program.  In the case of my Goodnight / away situation yes the turn off list is a common THEN block but it's the only string of insteon commands being sent, so once insteon is being executed there are no other programs to inject "noise" or "confusion".

My approach previously had been to try and treat these buttons like a state machine, but I think I see what you are saying. Do you have an example you could provide? 

[MrBill]

3 hours ago, bjs169 said:

My approach previously had been to try and treat these buttons like a state machine, but I think I see what you are saying. Do you have an example you could provide? 

I did that above... here it is repasted:

What I would do if I were you is just simplify this. 

If
        Time is Sunset  - 30 minutes
 
Then
        Set 'Scenes / Device Scenes / Front Outside' On
        Set 'Devices / Master Bedroom / Master Bedroom KP Dimmer / A: Master Bedroom Outlet' Backlight On  1 / Off 0
        Set 'Devices / Living Room / Living Room Lamp Dimmer' On 60%
        Set 'Scenes / Special Scenes / KitchenIslandAndSink' On
        Set 'Scenes / Device Scenes / Office Brian' On
        Set 'Scenes / Device Scenes / Office Lori' On
        Set 'Scenes / Program Related_Scenes / KPL All Off On / prs_KPL_All_Kitchen_On' On
        Resource 'Hue Morracan Lamp On'
 
Else
   - No Actions - (To add one, press 'Action')

Basically everything you were doing with other routines is included in this revised program.  The sunset program, the "some downstairs" program and the state change of the on button.  I used to use a lot of run Programs to avoid setting the same things up multiple times, in the end tho the ISY or the PLM doesn't seem to manage the buffer very well.  You must remember while creating programs that the Insteon protocol is very slow compared to the speed programs run.  It also seems like having program X inject something into the buffer, then program Y also inject into the buffer just creates collisions.  In short, I've had better luck only letting one program at a time inject Insteon commands into the buffer.   I'm even careful when i create a new Sunset program to use some random offset to keep it away from the others.  For example the lighting controls run at sunset, but adjust scene for the bathroom light programs runs at Sunset + 1:11.   Sure it seems like we shouldn't have to deal with things like that, but I've found when I do, I have much greater system reliability.   The beast is really how slow the Insteon protocol is.

[bjs169]

3 hours ago, MrBill said:

I did that above... here it is repasted:

..

Basically everything you were doing with other routines is included in this revised program.  The sunset program, the "some downstairs" program and the state change of the on button.  I used to use a lot of run Programs to avoid setting the same things up multiple times, in the end tho the ISY or the PLM doesn't seem to manage the buffer very well.  You must remember while creating programs that the Insteon protocol is very slow compared to the speed programs run.  It also seems like having program X inject something into the buffer, then program Y also inject into the buffer just creates collisions.  In short, I've had better luck only letting one program at a time inject Insteon commands into the buffer.   I'm even careful when i create a new Sunset program to use some random offset to keep it away from the others.  For example the lighting controls run at sunset, but adjust scene for the bathroom light programs runs at Sunset + 1:11.   Sure it seems like we shouldn't have to deal with things like that, but I've found when I do, I have much greater system reliability.   The beast is really how slow the Insteon protocol is.

Thanks, the paragraph was really helpful. 

You are right that I break everything out due to long being observant of the DRY principle. I'll see if I can rethink my approach and try to combine programs instead of aiming for reuse.

How would you approach incorporating physical device feedback into the installation? Say someone turns on the breakfast dimmer from the physical device. This will turn on button B on my KPL because of a scene. But also want to ensure G and H are in the right state in this situation. Is that an appropriate time to use my existing "state machine" programs?

[MrBill]

15 hours ago, bjs169 said:

But also want to ensure G and H are in the right state in this situation. Is that an appropriate time to use my existing "state machine" programs?

I don't know, outside of the method you're attempting to use with a state variable.   As I mentioned before we don't really have the concept of "all on" in our system.  H in almost all cases is "All Off behind you"  In short, that means if your existing the Master Bath H will turn off the bathroom, if you're existing the master bedroom then H will turn off the bedroom AND the bathroom.  As far as turning on we either have scene's to use or individual devices.  In the case of scenes the respective button will be on if the scene has been activated.  The "All Off" button is set as  "non-toggle Off" which means when the button is pressed it always sends "off' to the scene it's attached to.  As a "non-toggle Off" the H button is never lit (it does light briefly when pressed but is normally always off)

The only place I'm really trying to make a button display a status not part of scene is a "door open" light.  I fought with this for a long time.  It was always wrong.  Originally it was a single program such as....

If
         Front door is on
    or  Back door is on
    or ......etc.....
then
        Turn on dooropen light
else
         turn off dooropen light

"dooropen light" being a scene, whose only member is the button.

It was rarely in synch... adding a little delay helped as in...

If
         Front door is on
    or  Back door is on
    or ......etc.....
then
        wait 2 seconds
        Turn on dooropen light
else
         wait 2 seconds
         turn off dooropen light

but it was still constantly out of synch....

It finally evolved into the following 4 programs:

===================================================================================
DoorOpenLight - [ID 018B][Parent 0034]

Folder Conditions for 'DoorOpenLight'

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
   Allow the programs in this folder to run.
 

 

-----------------------------------------------------------------------------------
DoorOpenLight.off - [ID 0125][Parent 018B]

If
        (
             'Door Switches / Barn OHD' Status is Off
         And 'Door Switches / LowerSlider' Status is Off
         And 'Door Switches / UpperSlider' Status is Off
         And 'Door Switches / Front Door' Status is Off
         And 'Door Switches / Garage-North OHD' Status is Off
         And 'Door Switches / Garage-South OHD' Status is Off
         And 'Door Switches / Playroom OHD' Status is Off
         And 'Door Switches / Barn Walk-thru Door' Status is Off
         And 'Door Switches / Playroom Door' Status is Off
         And 'Door Switches / Garage to House Door 2' Status is Off
        )
    And 'Garage Entryway+# / Door Open' Status is On
 
Then
        Wait  2 seconds
        Set 'Door Open Light' Off
 
Else
   - No Actions - (To add one, press 'Action')
 

 

-----------------------------------------------------------------------------------
DoorOpenLight.on - [ID 002D][Parent 018B]

If
        (
             'Door Switches / Barn OHD' Status is On
          Or 'Door Switches / LowerSlider' Status is On
          Or 'Door Switches / UpperSlider' Status is On
          Or 'Door Switches / Front Door' Status is On
          Or 'Door Switches / Garage-North OHD' Status is On
          Or 'Door Switches / Garage-South OHD' Status is On
          Or 'Door Switches / Playroom OHD' Status is On
          Or 'Door Switches / Barn Walk-thru Door' Status is On
          Or 'Door Switches / Playroom Door' Status is On
          Or 'Door Switches / Garage to House Door 2' Status is On
        )
    And 'Garage Entryway+# / Door Open' Status is Off
 
Then
        Wait  2 seconds
        Set 'Door Open Light' On
 
Else
   - No Actions - (To add one, press 'Action')
 

 

-----------------------------------------------------------------------------------
DoorOpenLight.Query - [ID 014C][Parent 018B]

If
        From     5:28:28AM
        To      11:59:59PM (same day)
 
Then
        Run Program 'DoorOpenLight.refresh' (Then Path)
        Repeat Every  54 minutes and 54 seconds
           Set 'Garage Entryway+# / Door Open' Query
 
Else
        Stop program 'DoorOpenLight.refresh'
 

 

-----------------------------------------------------------------------------------
DoorOpenLight.refresh - [ID 00FF][Parent 018B]

If
        'Garage Entryway+# / Door Open' is switched On
     Or 'Garage Entryway+# / Door Open' is switched Off
 
Then
        Repeat Every  10 minutes and 10 seconds
           Run Program 'DoorOpenLight.on' (If)
           Wait  3 seconds
           Run Program 'DoorOpenLight.off' (If)
           
        // to instantly force the door open light to refresh, push the Door Open button to activate the (IF)
        //
        // Otherwise this program will continue to run every 10 minutes.
        // What still may not work is if ISY thinks status of button in differnt than actual button status
        // (current design Minimizes insteon traffic-- we could add a device query to the loop)
        //
 
 
Else
   - No Actions - (To add one, press 'Action')
 

 

All of these were carefully written to minimize Insteon traffic.  For example you'll note that in the .on and .off programs (the first two) the THEN body only runs if the light needs to change state... in other words if the status light is already off we don't turn it off anyway... (remember Insteon is SLOW communication and other things are  injecting traffic.)  When looking at just these two programs it doesn't make sense why... but consider that the 4 program (.refresh) is running each of these programs every 10 minutes and 10 seconds.... as a result no Insteon traffic is generated if it doesn't need to be, only of the button has gotten out of sync.  Further the .query program runs a query every 54 minutes and 54 seconds to make certain the ISY knows the current state of the button.

It query stops overnight because when the query runs during the 3AM query it sometimes causes Insteon collision problems, I could have written the timing to stop the programs from 2:55am to 3:30am but i just stopped it overnight because the buttons never get out of sync overnight.

This type of logic all works well on a small scale but won't work well for lots of different queries all over the place.   the problem is Insteon collisions is real-- that's how the door open light gets out of sync in first place. 

Remember two things when programming... 1) Insteon comms is SLOW... think 300 baud dialup modem slow (if you're old enough to remember those days...) 2) because of 1 take care to write programs in ways that they don't generate excess Insteon traffic... (turning off a scene or device that's already off, etc).

 

[bjs169]

4 hours ago, MrBill said:

...

All of these were carefully written to minimize Insteon traffic.  For example you'll note that in the .on and .off programs (the first two) the THEN body only runs if the light needs to change state... in other words if the status light is already off we don't turn it off anyway... (remember Insteon is SLOW communication and other things are  injecting traffic.)  When looking at just these two programs it doesn't make sense why... but consider that the 4 program (.refresh) is running each of these programs every 10 minutes and 10 seconds.... as a result no Insteon traffic is generated if it doesn't need to be, only of the button has gotten out of sync.  Further the .query program runs a query every 54 minutes and 54 seconds to make certain the ISY knows the current state of the button.

It query stops overnight because when the query runs during the 3AM query it sometimes causes Insteon collision problems, I could have written the timing to stop the programs from 2:55am to 3:30am but i just stopped it overnight because the buttons never get out of sync overnight.

This type of logic all works well on a small scale but won't work well for lots of different queries all over the place.   the problem is Insteon collisions is real-- that's how the door open light gets out of sync in first place. 

Remember two things when programming... 1) Insteon comms is SLOW... think 300 baud dialup modem slow (if you're old enough to remember those days...) 2) because of 1 take care to write programs in ways that they don't generate excess Insteon traffic... (turning off a scene or device that's already off, etc).

 

This is all great. I have had similar ideas about refreshes to ensure the button is in the right state, but it seems so kludgy. I guess you are saying it is just a necessary evil based on the limitations of the ecosystem. I can accept that. Curious, the status checks at the start of the .off and .on programs, are those status checks coming from a query to the device or coming from an internal state representation in ISY? I had assumed from a device query, but since you are saying these conditions are to prevent ISY traffic I am now wondering if was wrong and status comes from ISY. Finally, just curious what is the +# nomenclature in "Garage Entryway+#"? 

And, yes, I am old enough that I did once own a 300 baud modem.

[MrBill]

56 minutes ago, bjs169 said:

Curious, the status checks at the start of the .off and .on programs,

They are insteon door sensors, when they open or close they send on or off to the ISY... the status in the top lines of the .on and .off catch when they change status.... they are married with an AND to the status of the button so that if they button is already off or on, it don't send uneeded insteon traffic.  that doesn't come into play when the say the front door opens triggering the program, but does come into play when .refresh hammers those two programs about every 10 minutes, only sending insteon traffic when there is the need to change the state.

I don't use the + anymore, at one time it meant there was an Alexa spoken in the portal for that node, but there are still a few hanging out in my program tree.  The # indicates the the A button of this switch has the load attached.  that's also about to go away (on a snowy day in January)... All my Insteon nodes either have {hide} or # in the string... that worked great for my needs once when I was still using mobilinc, but now that I also run Home assistant I'm going to change all the {hide} to ~ and drop the # altogether.  That's a giant job tho, because first i need to sit and rename nodes for a long time, then when I reload Home Assistant and lots of things will be broken...lol. I figure my node renaming project is a good two days worth... 🤣

[bjs169]

3 hours ago, MrBill said:

They are insteon door sensors, when they open or close they send on or off to the ISY... the status in the top lines of the .on and .off catch when they change status.... they are married with an AND to the status of the button so that if they button is already off or on, it don't send uneeded insteon traffic.  that doesn't come into play when the say the front door opens triggering the program, but does come into play when .refresh hammers those two programs about every 10 minutes, only sending insteon traffic when there is the need to change the state.

I don't use the + anymore, at one time it meant there was an Alexa spoken in the portal for that node, but there are still a few hanging out in my program tree.  The # indicates the the A button of this switch has the load attached.  that's also about to go away (on a snowy day in January)... All my Insteon nodes either have {hide} or # in the string... that worked great for my needs once when I was still using mobilinc, but now that I also run Home assistant I'm going to change all the {hide} to ~ and drop the # altogether.  That's a giant job tho, because first i need to sit and rename nodes for a long time, then when I reload Home Assistant and lots of things will be broken...lol. I figure my node renaming project is a good two days worth... 🤣

Thanks for everything. Will definitely be taking a close like at my programs over the holiday break.