Simple evening kitchen light program

[FBoucher]

Hello all,

I created a simple program to turn on the lights (via a scene) in the kitchen. I want the lights to turn on at 6PM or before if sunset is earlier than 6PM. So I created this:

If
        From     6:00:00PM
        To      11:00:00PM (same day)
   Or From    Sunset  - 30 minutes
        To      11:00:00PM (same day)
Then
        Set 'Kitchen RGBW + puck' On
 Else
        Set 'Kitchen RGBW + puck' Off

Tonight, at 6PM, the lights turned on, but a new requests to turn the lights on was made 30 minutes before sunset. So it means that each part of the IF would trigger an event separately regardless of the status of the other.

I could create a first program that determines if the sunset is before or after 6PM and have actions in Then and Else to execute programs for each condition. But is there a simpler way to code this?

[larryllix]

When I have multiple logics affecting the same device cycle I find a control variable the simplest and most reliable method. With a variable once the variable flag is turned on and the scene is turned on it cannot be turned on any more and cannot be reset by other logical inputs.

You could try this
If
        From     6:00:00PM
        To      11:00:00PM (same day)
   Or From  at  Sunset  - 30 minutes
        To      11:00:00PM (same day)
        AND
        Light status is Off <---- pick a major light out of scene
Then
        Set 'Kitchen RGBW + puck' On
 Else
        Set 'Kitchen RGBW + puck' Off

[apostolakisl]

So what is the behavior you are looking for?  Currently the program triggers 3 times.  At 6pm, at 30 minutes before sunset (both true) and 11pm (false).  Are you trying to only have one true trigger?  If so, why?  What is the behavior as written that  you don't want? Having the program run true the second time each day simply sends a command to turn lights on that are already on . . . effectively doing nothing.  The only thing that I can imagine is that you are sometimes manually turning the lights off in between the two on times and don't want it coming back on.

And as Larry noted above, the from/to isn't needed for both times.  You only need the 11pm off trigger in there once.   You can just do if time is 6pm or time is from 30 minutes before sunset to 11pm.  This no longer holds true if you have additional triggers, like an outside program that does a "run if" on this one. 

 

[FBoucher]

Thank you both for the replies.

I wrongly thought that a IF statement would turn true only once, i.e. when either of the conditions would turn true, instead of twice, i.e. when each condition would turn true.

apostolakisl, you are right. Some of the lights that turns on automatically with the program will eventually be turned off manually and, depending on the sunset time, they could be turned on again, which I don't want to happen.

Thanks larryllix, using a control variable is the way to go, because I want the program to trigger true only once and false only once. Also, I want the lights turn on at 6PM or earlier, if (sunset-30 minutes) is earlier than 6PM.

Thank you both.

[apostolakisl]

2 hours ago, FBoucher said:

 

apostolakisl, you are right. Some of the lights that turns on automatically with the program will eventually be turned off manually and, depending on the sunset time, they could be turned on again, which I don't want to happen.

 

Using @larryllixsuggestion won't help with this issue.  To force it to run just once, the first time the conditions are met, you would need two programs. 

Program 1
If 
  time is from 6 to 11pm
Then
  turn scene on
  disable program 2
Else
  enable program 2
  turn secne off

Program 2
If
  time is from sunset to 11pm
Then
  turn scene on
  disable program 1
Elase
  enable program 1
  turn scene off

 

[MrBill]

Since there is always multiple ways to do it, I'll throw mine in.  With a two program approach I'd do this, because it's easier to figure out the logic being used when I look again 4 years later....  The variable can be simple Integer, it does not need to be a State variable in this case.

AAATest.3 - [ID 007E][Parent 0001]

If
        (
             Time is Sunset  - 30 minutes
          Or Time is  6:00:00PM
        )
    And $iTest.KitchenLight is 0
 
Then
        Set 'Kitchen Recessed' On
        $iTest.KitchenLight  = 1
 
Else
   - No Actions - (To add one, press 'Action')

----

AAATest.4 - [ID 00FA][Parent 0001]

If
        Time is 11:00:00PM
 
Then
        Set 'Kitchen Recessed' Off
        $iTest.KitchenLight  = 0
 
Else
   - No Actions - (To add one, press 'Action')
 

 

 

[apostolakisl]

18 minutes ago, MrBill said:

, because it's easier to figure out the logic being used when I look again 4 years later....  

I would recommend using the "notes" to write out in plain English how the programs work regardless of how you do it.  Of course I like my method better, save yourself a variable.  Anytime you need a Boolean variable (2 states), you can always use a program's status to store the two states.  True or false, enabled or disabled.  

[MrBill]

20 minutes ago, apostolakisl said:

I would recommend using the "notes" to write out in plain English how the programs work regardless of how you do it.  Of course I like my method better, save yourself a variable.  Anytime you need a Boolean variable (2 states), you can always use a program's status to store the two states.  True or false, enabled or disabled.  

Well of course you like your method better, just like I prefer mine more. and of course I comment complicated stuff, something like this I should be able to tell at a glance.  The whole point was to show yet another way to do it. and I've gotten to the point I prefer Schedule based programs to be simple "At...Then" with no else anyway, they often have $sAway logic included which gets messed up when there are Else statements that run too often.

[asbril]

21 hours ago, FBoucher said:

Tonight, at 6PM, the lights turned on, but a new requests to turn the lights on was made 30 minutes before sunset. So it means that each part of the IF would trigger an event separately regardless of the status of the other.

Why is that a problem ?  I have similar programs for lights and curtains.  Yes, they get two instructions (one at sunset minus X  and one at  XX pm) to turn lights On or close the curtains, but so what ?

[larryllix]

I would recommend using the "notes" to write out in plain English how the programs work regardless of how you do it.  Of course I like my method better, save yourself a variable.  Anytime you need a Boolean variable (2 states), you can always use a program's status to store the two states.  True or false, enabled or disabled.  

'Save yourself a variable?

A whole 5 bytes? I remember the early 70s, when that was more important than being able to read your own software two years later

Sent from my SM-G781W using Tapatalk

[FBoucher]

To asbril: the problem is that I don't want to issue two requests (one at 6PM and one at sunset-30) to turn the lights on because some of the lights will be turned off manually at some point during the period. For example, today's sunset is at 8:20PM. According to my initial program (first post), the IF is triggered TRUE at 6PM and at 7:50PM. So, the Insteon devices linked in the scene (there are 5 light responders) receive a request to turn the lights on at 6PM and at 7:50PM. Around 7PM, I generally turn some of the light responders off manually (end of dinner). But because of the IF logic firing twice, the lights I turned off manually will be turned on again at 7:50PM. I don't want that.

I concur that there are different ways to code this. Before reading your replies, I decided to have 2 programs, one for logic and one for the lights. So it looks like this:

Program KitchenEvening - Control

If
        From     6:00:00PM
        To      11:00:00PM (same day)
   Or From    Sunset  - 30 minutes
        To      11:00:00PM (same day)
Then
        $sKitchenEvening  = 1
 Else
        $sKitchenEvening  = 0

Program KitchenEvening

If
        $sKitchenEvening  is 1
Then
        Set 'Kitchen RGBW + puck' On
 Else
        Set 'Kitchen RGBW + puck' Off

 

larryllix in his first reply suggested to simplify the first IF like this:

If
        From     6:00:00PM
        To      11:00:00PM (same day)
   Or Time  is  Sunset  - 30 minutes

I considered it. But then I asked myself, what if the ISY is turned off and restarted before and after the sunset-30 trigger. That would mean the program would only be triggered at 6PM (if the sunset is before 6PM), thus missing the intended period for that time of year. Wouldn't it be safer to keep both periods in the IF?

[LarryCRetired]

Just to put in my two cents and my reasoning may be all wet.   I have always used a variable in these types of programs.  One too reduce the load on the PLM and secondly to reduce the amount of communication traffic.  As I said, my reasons may not be an issue ar all. 

[apostolakisl]

2 hours ago, FBoucher said:

To asbril: the problem is that I don't want to issue two requests (one at 6PM and one at sunset-30) to turn the lights on because some of the lights will be turned off manually at some point during the period. For example, today's sunset is at 8:20PM. According to my initial program (first post), the IF is triggered TRUE at 6PM and at 7:50PM. So, the Insteon devices linked in the scene (there are 5 light responders) receive a request to turn the lights on at 6PM and at 7:50PM. Around 7PM, I generally turn some of the light responders off manually (end of dinner). But because of the IF logic firing twice, the lights I turned off manually will be turned on again at 7:50PM. I don't want that.

I concur that there are different ways to code this. Before reading your replies, I decided to have 2 programs, one for logic and one for the lights. So it looks like this:

Program KitchenEvening - Control

If
        From     6:00:00PM
        To      11:00:00PM (same day)
   Or From    Sunset  - 30 minutes
        To      11:00:00PM (same day)
Then
        $sKitchenEvening  = 1
 Else
        $sKitchenEvening  = 0

Program KitchenEvening

If
        $sKitchenEvening  is 1
Then
        Set 'Kitchen RGBW + puck' On
 Else
        Set 'Kitchen RGBW + puck' Off

 

larryllix in his first reply suggested to simplify the first IF like this:

If
        From     6:00:00PM
        To      11:00:00PM (same day)
   Or Time  is  Sunset  - 30 minutes

I considered it. But then I asked myself, what if the ISY is turned off and restarted before and after the sunset-30 trigger. That would mean the program would only be triggered at 6PM (if the sunset is before 6PM), thus missing the intended period for that time of year. Wouldn't it be safer to keep both periods in the IF?

 

This works fine.  But you have a completely useless variable.  The following is the same function and basic construction without the variable.

If
        From     6:00:00PM
        To      11:00:00PM (same day)
   Or From    Sunset  - 30 minutes
        To      11:00:00PM (same day)
Then
       blank	 
 Else
       blank

Program KitchenEvening

If
        program above is true
Then
        Set 'Kitchen RGBW + puck' On
 Else
        Set 'Kitchen RGBW + puck' Off

Remember what I said, if you have a variable that only has two states, you usually don't need a variable.

[apostolakisl]

1 hour ago, LarryCRetired said:

Just to put in my two cents and my reasoning may be all wet.   I have always used a variable in these types of programs.  One too reduce the load on the PLM and secondly to reduce the amount of communication traffic.  As I said, my reasons may not be an issue ar all. 

Using a variable as above is ever so slightly more load on ISY than not using the variable, though meaningless so.  There is no difference in Insteon traffic.

[asbril]

34 minutes ago, apostolakisl said:

Around 7PM, I generally turn some of the light responders off manually (end of dinner).

That makes sense.

[asbril]

36 minutes ago, apostolakisl said:

If
        From     6:00:00PM
        To      11:00:00PM (same day)
   Or From    Sunset  - 30 minutes
        To      11:00:00PM (same day)
Then
       blank	 
 Else
       blank

Program KitchenEvening

If
        program above is true
Then
        Set 'Kitchen RGBW + puck' On
 Else
        Set 'Kitchen RGBW + puck' Off

would this be same as

In Program 1

THEN 

Run Program 2

in Program 2

nothing in IF

[apostolakisl]

2 minutes ago, asbril said:

would this be same as

In Program 1

THEN 

Run Program 2

in Program 2

nothing in IF

No.  In the scenario you posted, program 2 would run at both on times.  In the scenario I created, program 2 only runs once, the first time program 1 goes from false to true.  Program status is a trigger like a status variable.  It must change to be a trigger.  So when it runs true the second time, it does not change state and thus does not trigger program 2.  But with a "run program 2" in the "then" it will run program 2 twice.  No different than if it were just one program.

[larryllix]

3 hours ago, FBoucher said:

<snippage>

larryllix in his first reply suggested to simplify the first IF like this:

If
        From     6:00:00PM
        To      11:00:00PM (same day)
   Or Time  is  Sunset  - 30 minutes

I considered it. But then I asked myself, what if the ISY is turned off and restarted before and after the sunset-30 trigger. That would mean the program would only be triggered at 6PM (if the sunset is before 6PM), thus missing the intended period for that time of year. Wouldn't it be safer to keep both periods in the IF?

All conditions are in the "If" section.

Your power loss concept could apply to any program or program condition. What if the poer failed and came back on the next morning with any of these suggested programs? Yes the lights would stay on all the next day and night. This is why it is much safer, easier, and more reliable to use a variable to control things. You can write the current condition of the variable to the "init to" variable so it can recover from a power outage.

You have also lost the condition ANDed with the Sunset trigger line. That was key to making the program logic work without any variable.

Another suggestion is to stop counting programs. Sometimes more programs make the concepts easier to understand if proper labels for programs and variables, and comments are installed with some forethought.

[apostolakisl]

13 hours ago, larryllix said:

'Save yourself a variable?

A whole 5 bytes? I remember the early 70s, when that was more important than being able to read your own software two years later

Sent from my SM-G781W using Tapatalk
 

It isn't about the bytes, it is about useless clutter.  The variable is truly useless, it servers no purpose at all.  You could add a useless variable or two to every single program using that logic.

 

13 hours ago, FBoucher said:

        From     6:00:00PM
        To      11:00:00PM (same day)
   Or Time  is  Sunset  - 30 minutes

I considered it. But then I asked myself, what if the ISY is turned off and restarted before and after the sunset-30 trigger. That would mean the program would only be triggered at 6PM (if the sunset is before 6PM), thus missing the intended period for that time of year. Wouldn't it be safer to keep both periods in the IF?

I recommend putting ISY on a UPS.  This doesn't solve all problems, but I think it is better than having ISY reboot on a power outage.

 

9 hours ago, larryllix said:

All conditions are in the "If" section.

Your power loss concept could apply to any program or program condition. What if the poer failed and came back on the next morning with any of these suggested programs? Yes the lights would stay on all the next day and night. This is why it is much safer, easier, and more reliable to use a variable to control things. You can write the current condition of the variable to the "init to" variable so it can recover from a power outage.

You have also lost the condition ANDed with the Sunset trigger line. That was key to making the program logic work without any variable.

Another suggestion is to stop counting programs. Sometimes more programs make the concepts easier to understand if proper labels for programs and variables, and comments are installed with some forethought.

Using a variable will not help you here.  Initing the variable just means the variable will be wrong if power goes out while the program is in one state and then power comes back on during the time it should be in the other state.  You would want to use a "run at startup" on the program to have things be correct at startup, no need to init the variable.  But as I said, I would skip the variable as it is useless clutter.  The variable status precisely matches the true/false status of the program, it is totally redundant.  

[lilyoyo1]

Variables like others have said works best for this though there is no perfect solution. 

I moved away from standard timers and use the lux sensors in my motion sensors to trigger my lights on automatically in the living room area and other rooms based on occupancy. I use variables to track them turning on since that determines whether they change color temp and luminosity as the evening progresses or stay 1 color/dim level. I can override the auto on/change features if i turn the lights off (which auto resets each day). 

 

[apostolakisl]

29 minutes ago, lilyoyo1 said:

Variables like others have said works best for this though there is no perfect solution. 

I moved away from standard timers and use the lux sensors in my motion sensors to trigger my lights on automatically in the living room area and other rooms based on occupancy. I use variables to track them turning on since that determines whether they change color temp and luminosity as the evening progresses or stay 1 color/dim level. I can override the auto on/change features if i turn the lights off (which auto resets each day). 

 

Variable is not best.  There is NEVER a need for a Boolean logic state-variable.  NEVER I tell you!

1) A state variable used in a Boolean context will simply mirror the state of the program that sets it. It is redundant at best.

2) It unnecessarily adds to the list of variables that you need to scroll though every time you write a program that uses variables, plus if you forget what it does, you will have to search your programs to find its use.  The ISY AC and its dependence on drop downs and mouse clicks makes long lists of variables a PITA.

3) Using a variable will require extra steps to account for power failure.  When ISY reboots, the program will init to the correct state all on its own.  The variable will not and would require extra steps to ensure it is in the correct state.

4) Program state change is a trigger, same as a state variable.  Should you instead prefer a non-trigger situation, then an integer variable would be a consideration, though you would likely be better off using enable/disable program logic.  Again, there is never a need for a Boolean state variable.

[lilyoyo1]

3 minutes ago, apostolakisl said:

Variable is not best.  There is NEVER a need for a Boolean logic state-variable.  NEVER I tell you!

1) A state variable used in a Boolean context will simply mirror the state of the program that sets it. It is redundant at best.

2) It unnecessarily adds to the list of variables that you need to scroll though every time you write a program that uses variables, plus if you forget what it does, you will have to search your programs to find its use.  The ISY AC and its dependence on drop downs and mouse clicks makes long lists of variables a PITA.

3) Using a variable will require extra steps to account for power failure.  When ISY reboots, the program will init to the correct state all on its own.  The variable will not and would require extra steps to ensure it is in the correct state.

4) Program state change is a trigger, same as a state variable.  Should you instead prefer a non-trigger situation, then an integer variable would be a consideration, though you would likely be better off using enable/disable program logic.  Again, there is never a need for a Boolean state variable.

3 people say yes while 1 person says no. It's up to the op to decide which is best for him. That's the wonderful part of programming. There's more than 1 way to skin a cat

[apostolakisl]

2 minutes ago, lilyoyo1 said:

3 people say yes while 1 person says no. It's up to the op to decide which is best for him. That's the wonderful part of programming. There's more than 1 way to skin a cat

Being right or wrong isn't something you elect.  Successfully defending your answer and refuting mine would make it right.

[FBoucher]

I never thought that my simple evening kitchen light program would bring so much passion.

I started with a simple 2 states program to get the hang of it. But there is a random variable (no pun intended) I didn't mention ... my wife. Once she realises the capabilities of the ISY, I'm sure she'll have new ideas about how to structure the lights throughout the evening/late night. The kitchen light program will definitively need more states to cover it all. So, for now, I'll continue with a state variable.

Thank you all your inputs. You all made valid points and arguments.

[lilyoyo1]

1 hour ago, apostolakisl said:

Being right or wrong isn't something you elect.  Successfully defending your answer and refuting mine would make it right.

If you actually had an argument i would