Sunset to Sunrise?

[CoolToys]

I have a program set (I thought) to turn on the porch lights and yard lights anytime the front porch light is off and the door is opened.  Ideally this would only happen at night so I set sunset to sunrise the next day.  

It comes on all the time, so I added +5 and -5

The "Front Door" is an elk zone. (BTW, new ELK module once I got it figured out, waaaaaay better)

Same issue.  As soon as door open, 24x7 lights come on?

Any ideas?  

[dbwarner5]

Can you go to the program and Right click on it and select "copy to clipboard" and then post it? It would be helpful to see the whole program. thanks. 

[CoolToys]

Here it is, If the light is already on, I don't want it to trigger program and turn off the lights unexpectedly.


Front Door Open Copy - [ID 000C][Parent 0001]

If
        'Area 1 / FRONT.DOOR' Logical Status is Violated
    And 'Entry Front Door Light' Status is Off
    And From    Sunset  +  5 minutes
        To      Sunrise -  5 minutes (next day)
 
Then
        Set 'Entry Front Door Light' On
        $Front_Door  = 1
        Set 'Garage Front Porch Lite' On
        Set 'Courtyard Niche Top' On
        Set 'Courtyard Niche Bottom' On
 
Else
   - No Actions - (To add one, press 'Action')
 

Edited September 18, 2023 by CoolToys
Adding note

[tazman]

@CoolToysyour front door needs to be a control item not a status so when the door is opened it activates the program to run as long as the rest of the conditions are met.

[CoolToys]

So as a status, it can activate the lights 24x7?  That makes zero sense to me, If opening the door causes a condition and the program runs it should run. But just for fun here is the updated version and same problem. Open door 3:44 pm and lights turn on.  The Niche is the landscape lighting which also turns on.

 

 

Front Door Open - [ID 0013][Parent 0001]

If
        'Area 1 / FRONT.DOOR' is switched On
    And 'Entry Front Door Light' Status is Off
    And From    Sunset  +  5 minutes
        To      Sunrise -  5 minutes (next day)
 
Then
        $Front_Door  = 1
        Set 'Entry Front Door Light' On
        Set 'Garage Front Porch Lite' On
        Set 'Courtyard Niche Top' On
        Set 'Courtyard Niche Bottom' On
 
Else
   - No Actions - (To add one, press 'Action')
 

 

[apostolakisl]

I can't explain your issue.  Since all "if" statements are "anded", then any of them being false would make the whole thing false and it would run the "else" clause (which of course is blank).  

Please confirm that this actual program is what is turning on the lights and that you do not have another program lingering somewhere that maybe you were working on and forgot about.  If you look at the program tree, the program will have a half red icon to the left of it if it last ran false and half green if it last ran true.  The program summary page will also list it along with last run time and true/false.  

Try opening the door, then sort your program summary page by time last ran and see if some other program ran at that time and turned the lights on.

[Andy P]

Any chance that there is a direct link between FRONT.DOOR and Entry Front Door Light or they are linked together in a scene? Try disabling the program entirely and opening the door and see if the light goes on.

[DennisC]

13 hours ago, CoolToys said:

So as a status, it can activate the lights 24x7?  That makes zero sense to me, If opening the door causes a condition and the program runs it should run. But just for fun here is the updated version and same problem. Open door 3:44 pm and lights turn on.  The Niche is the landscape lighting which also turns on.

 

 

Front Door Open - [ID 0013][Parent 0001]

If
        'Area 1 / FRONT.DOOR' is switched On
    And 'Entry Front Door Light' Status is Off
    And From    Sunset  +  5 minutes
        To      Sunrise -  5 minutes (next day)
 
Then
        $Front_Door  = 1
        Set 'Entry Front Door Light' On
        Set 'Garage Front Porch Lite' On
        Set 'Courtyard Niche Top' On
        Set 'Courtyard Niche Bottom' On
 
Else
   - No Actions - (To add one, press 'Action')
 

 

Are you sure you don't have a conflict with another program? Try a search using the front door and the light to make sure.

Once that is ruled out, try rewriting your program to list the sunrise/sunset trigger first and enclose it in ( ) by clicking the brackets on the right and moving them in to position.

Doing this will insure that condition is met first.

Having the light status is off will mean that the if condition will re-evaluate as false as soon as the light turns on. I don't think that is what you want. I would remove that and use a variable to monitor when the light is already on.

[apostolakisl]

41 minutes ago, DennisC said:

 

Having the light status is off will mean that the if condition will re-evaluate as false as soon as the light turns on. I don't think that is what you want. I would remove that and use a variable to monitor when the light is already on.

Yes, indeed.  This would make looking at the last status of the program ineffective.  You can always add a line in the then clause that sends you an email or sets a test variable.  I don't know what the variable that is already there is doing and what other programs might affect it so not sure if you could use that.  You could also add a line in the else clause that does similar.  

In summary, I really don't think this program is turning the lights on.  The only other thought is that the ISY clock is set wrong.  I really doubt ISY is having a logic fail like this.

[Goose66]

8 hours ago, DennisC said:

Having the light status is off will mean that the if condition will re-evaluate as false as soon as the light turns on. I don't think that is what you want. I would remove that and use a variable to monitor when the light is already on.

I do want to point out that, while I completely agree there is a basic flaw in the program's design, this flaw you point out will not prevent the remaining lights from turning on after turning on the  'Entry Front Door Light', as may be interpreted from your post. That is because there is no WAIT or REPEAT statement in the running program that makes the program "re-entrant," thus once the Then branch of the program starts running, it will run to completion.

If it were me, I would have a first, enabled program that had the  "'Area 1 / FRONT.DOOR' is switched On" condition and a second, disabled program that had the remaining conditions and the commands from the Then statement. The "Then" branch of the first program runs the "If" branch of the second program. 

But neither using a variable to track the light nor structuring your programs with the "two-program" methodology (discussed ad nauseum in these forums) would appear to solve your problem of the program seemingly ignoring the sunset to sunrise condition.

Edited September 19, 2023 by Goose66

[apostolakisl]

13 minutes ago, Goose66 said:

I do want to point out that, while I completely agree there is a basic flaw in the program's design, this flaw you point out will not prevent the remaining lights from turning on after turning on the  'Entry Front Door Light', as may be interpreted from your post. That is because there is no WAIT or REPEAT statement in the running program that makes the program "re-entrant," thus once the Then branch of the program starts running, it will run to completion.

If it were me, I would have a first, enabled program that had the  "'Area 1 / FRONT.DOOR' is switched On" condition and a second, disabled program that had the remaining conditions and the commands from the Then statement. The "Then" branch of the first program runs the "If" branch of the second program. 

But neither using a variable to track the light nor structuring your programs with the "two-program" methodology (discussed ad nauseum in these forums) would appear to solve your problem of the program seemingly ignoring the sunset to sunrise condition.

All good info, but I would also like to point out that the "if status light off" element of the program isn't needed at all.  If the light is already on, and you send an on command to it, big whoop, nothing happens. 

You would only need that line if say the light being at some partial level of on meant you wanted it to stay at the level and not turn all the way on when the door opened.

[Goose66]

40 minutes ago, apostolakisl said:

All good info, but I would also like to point out that the "if status light off" element of the program isn't needed at all.  If the light is already on, and you send an on command to it, big whoop, nothing happens. 

You would only need that line if say the light being at some partial level of on meant you wanted it to stay at the level and not turn all the way on when the door opened.

I imagine the thought is generally if there’s been any adjustments to outside lights other that “all off” then leave them alone.

[garybixler]

Just something to try. I have similar programs and they perform as expected. The only difference is that I have the Sunset Sunrise schedule first.

Garage Lights 1 - [ID 001F][Parent 000F]

If
        From    Sunset 
        To      Sunrise (next day)
    And 'ELK / Area 1 / Driveway Sense' Logical Status is Violated
    And 'Outside Garage Lights' Status is Off
 
Then
        Run Program 'Garage Lights on/off' (Then Path)
 
Else
   - No Actions - (To add one, press 'Action')

 

Also I might suggest putting the  'Set 'Entry Front Door Light' On'  last.

Edited September 20, 2023 by garybixler

[CoolToys]

@DennisC,Yes I wrote this for the exact situation that you mentioned and @Goose66you are correct.  If the lights are already on and I open the door I don't want to run this program.  I have a two other programs that turn the outside lights on with other conditions, i.e. we are home or alarm is set so it looks like we are home.  This program is only to work if the lights are off and someone rings the bell and I open the door like my mother showing up at 3 am.  Yup it happens.  

@apostolakisl, As background all of this worked on my ISY just fine.  The problems started when I upgraded to the eisy and changed the ELK module to the ELK node.  While 99% of the new elk node is way cooler and lets me do more things. the one odd ball thing is that none of the three programs with sunrise to sunset programs work any more.  The new i3 outlet also randomly turns back on from time to time, but Steve Lee thinks my lamp doesn't have enough of a load so the auto sensor is kicking on.

I am on the road today, and home tomorrow so I will try @garybixleridea to re arrange the "if" and put the sunset to sunrise command first.   If the house is dark and I enter the house the ISY used to turn lights on at night for 15 minutes with a program I labeled "late arrival".  Now that program also ignores the sunset to sunrise stamens and does it 24x7.  I don't know why. The same for leaving my bedroom at odd hours.  That is my "auto snack" program that used to work at night only and now works 24x7. 

The MSII's did fail to transfer and I had to delete all four of them and relink them so maybe there is something there so I will double check that.  Late Arrival and Auto Snack both use the MSII inputs.  Possibly I linked them to scenes but that doesn't explain the front door which is an elk sensor not an MSII.

I will do the searches tomorrow when I get home and see if somehow the new elk node changed the code or if there is a //error somewhere that I missed or if I linked any MSII to a scene for testing and forgot to unlink after I fixed the // error lines in the programs.

I might also delete the sunset to sunrise lines in the program, reboot and then add it back in just in case there is some latent binary that didn't transfer to the eisy.  None of the MSII transferred, so clearly there are some odd issues with the upgrade.

Thank you all for looking at this and giving me ideas to look at.  

Edited September 20, 2023 by CoolToys
clarity

[apostolakisl]

@CoolToys Changing the order of the conditions when they are all "anded" will not have any affect.

I would start with adding an email or text notification to your "then" and a different one to your "else" and then you will be able to follow the program's every execution.  This will confirm if it is running incorrectly.  

If indeed it is running incorrectly, which would be a new one for ISY, I would delete the sunrise to sunset clause, save it, then re-add that condition and save again.

I also have the Elk node and I have a Polisy, while not eisy, it is still running the same code.  I do not use the sunset to sunrise in individual programs.  I have a single program called "dark outside" that just says from sunset to sunrise the next day.  It has no then/else clauses.  Then all other programs that I want to only run while it is dark outside simply reference that program's status as true or false.  This works.  I have a number of programs that perform the same function.  Below is an example.

Patio Door - [ID 000F][Parent 0013]

If
        Program 'Dark Outside' is True
    And 'Elk / Family Rm Door' Logical Status is Violated
 
Then
        Set 'Family Room / Patio-FamRm-Fans Coach Lts L' On
 
Else
   - No Actions - (To add one, press 'Action')
 

[oberkc]

I don't suppose that the name in the program list has a little green arrow?  Is it possible that you made changes to the program but did not save them?

I agree, this program should work, and not turn on the lights outside the stated time range.

[CoolToys]

@oberkc, no green arrow, and yes I have done that more than once, thanks for reminding me to look at the basics. 

@apostolakisl, interesting idea, to run a separate program for Dark.  That way I can see if it is "true" separately in the details.  Also I could simply use sunset to set a state variable of $Dark and sunrise to return it to "0".  The $Front Door state is used to start a 15 minute timer in another program to turn all the lights back off.  That is why I also check if the switch is on first.  I don't want it going off any time someone manually turns it on or a scene already has it on.

I agree the order shouldn't matter but you never know. I did already try to add a notification line each time the door opens and the program runs.  That worked just fine I got the notice each time the program ran and I verified "true" was also on the program in the details panel.  It is possible the Elk status of the door is also in a scene that I have missed, and it is also possible that the program just didn't restore from the ISY backup to the eisy perfectly.  When I get home tonight I will remove and replace the Sunset to Sunrise program first just to check, but even if it works I like your solution better and will rewrite all three of the programs that way.

 

[garybixler]

After doing some testing the position of the Sunset Sunrise statement didn't really mater. 

Edited September 20, 2023 by garybixler

[apostolakisl]

@CoolToys  You don't need any variables.  You just use the true/false status of the program dark outside (see my example).  You would only need to use a variable (an integer one) if you didn't want the sunrise/sunset times themselves to be triggers.  Mostly this would be the case if you have items in your "else" clause that you don't want running at sunrise/sunset times.  Whenever you "and" sunrise/sunset times to another condition (either through a dark outside program or directly in the program), getting triggered at sunrise/sunset won't matter provided the else clause is empty.  Using a "Dark outside" program like I did works exactly the same as putting sunrise/sunset times in the actual program, but it is simpler if you have a bunch of programs that use sunrise to sunset (or vice versa) logic since it is now just a single line.  Sunrise/Sunset times are triggers when in a program, and a program changing status is also a trigger when that status is referenced in another program.  So it is the same exact behavior.  

If you got the correct notifications of the program running true/false, then you must have some other program or scene doing something.

[CoolToys]

@apostolakisl, I use the variables/state integers to verify multi layered conditions and allow for timers for some events.  

Lutron used to have a "vacation learning mode".  When I traded to ISY/Insteon, the way to mimic that was  multi layered series of programs.  I tried the "else" but it did other things and didn't allow me to have the door come on after hours.  I don't know how you turn your light off in your example so here is the longer explanation of how I set mine up.  

Door opens, light off the $Front_Door integer of "1" is set.  Then I have a program that checks for $Front_Door="1" waits 15 minutes, checks the door is closed and then sets $Front_Door back to "0" and turns off the lights.  If the lights are on due to another program all of this is skipped. 

There are also two states $Occupied, $Guest and $Away that determine if the house is occupied by only me and my wife then program "Home" runs turning on the lights as I like them.  If there are guests in that part of the house, then "guest" runs.  If both are zero then away runs.  Away doesn't turn on any lights that can't be seen outside of the house, and sets the thermostats to different settings as well.  It is a multi zone HVAC system.  When $guest="0" then that section isn't heated or cooled.  Ultra cheapo energy move on my part.

Using this approach, if the light is on and Home (or Guest) programs are running, then the door open program doesn't run.  If the light is off, the program runs and sets $Front_Door.  Then another program above runs.  This way the eisy is "aware" if the light is already on and a program has already triggered lights or if the Home/Guest programs did not run and can automatically return to the state it was in.   If I enter the geofence area and "Away" is active, it goes to "Home" automatically.

If I don't use the state variable and "home" program is running, I open the front door, then close it, the light will go off before I want it to depending on how you turn off the light.

I am sure there are other ways to skin this cat, but until the eisy upgrade this has worked the best and most reliable.  I will remove the sunset/sunrise line and try the "Dark" mode option later today.

Thanks again for the ideas and insights.

[apostolakisl]

@CoolToys  I understand your use of variables, I usually use cascading programs instead for that, often having program 2 disable program 1 and then reenable it when complete.  However, there is still no need to convert "dark outside" program to a variable.  Since the state of the program works exactly the same as the actual sunrise to sunset clause, anywhere you used sunrise/sunset clause, the dark outside program status will produce identical results.  

[CoolToys]

Like I said, many ways to skin the cat, just trying to figure out why sunset to sunrise not working.  I like the simplicity of Sunset = Dark, Sunrise ¬ Dark idea, but I will go through this step by step and try to figure out if I have the same variables or triggers elsewhere in the program, or at least find a way to make this work. I hope.

[apostolakisl]

35 minutes ago, CoolToys said:

Like I said, many ways to skin the cat, just trying to figure out why sunset to sunrise not working.  I like the simplicity of Sunset = Dark, Sunrise ¬ Dark idea, but I will go through this step by step and try to figure out if I have the same variables or triggers elsewhere in the program, or at least find a way to make this work. I hope.

The quickest way to find out is to watch the program summary page while opening the door and see which programs trigger.  Click on the "last run time" column to sort by most recent run time.

[CoolToys]

Did that, and the correct program runs.  That is why I started this thread. 

 

[apostolakisl]

1 hour ago, CoolToys said:

Did that, and the correct program runs.  That is why I started this thread. 

 

The question is do any other programs run.  You know that one runs correctly because you put notifications in the "then" and "else" clause already and tested, as I believe you stated a few posts ago.  If indeed you received the correct notification showing that the correct clause ran, then it is something else that is turning the light on and that is what you need to look for.