Simple evening kitchen light program

[lilyoyo1]

1 hour ago, FBoucher said:

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.

Even simplerprograms/situations will grow to become more complex over time. As you can see, a simple variable (hmm, ironic how it's called that) thrown into the mix can exponentially complicate things. It's easier to start out building with the future in mind than mucking things as you add more capabilities to your system

[apostolakisl]

I was thinking, would there ever be a logical reason to use a Boolean state-variable.  At first, I thought, what if you had multiple programs setting that state variable.  But generally speaking, still no, because you could just list those programs true/false status in your "if" and connect them with an "or" or "and" statement.  There might be some issues with triggering events since your target program would trigger when any of the listed programs changed states whereas the state-variable would only trigger your target program upon it changing, which under certain logical situations would not change when one of the programs that set it changes.

But I can't come up with any actual use cases for this sort of logic.

[apostolakisl]

52 minutes ago, lilyoyo1 said:

If you actually had an argument i would

??  Seriously, that is your defense of your logic?

[lilyoyo1]

12 minutes ago, apostolakisl said:

I was thinking, would there ever be a logical reason to use a Boolean state-variable.  At first, I thought, what if you had multiple programs setting that state variable.  But generally speaking, still no, because you could just list those programs true/false status in your "if" and connect them with an "or" or "and" statement.  There might be some issues with triggering events since your target program would trigger when any of the listed programs changed states whereas the state-variable would only trigger your target program upon it changing, which under certain logical situations would not change when one of the programs that set it changes.

But I can't come up with any actual use cases for this sort of logic.

That's because you aren't seeing the big picture in regards to future changes nor when other devices can potentially come into play. 

For example, if you dim a light on/off or to a certain percentage; is it still on or considered off? Should the program trigger a second time or stay put?

What about assistants? If you tell your assistant to turn on/or off, do you want it to come back on or stay off and for how long. What if you add a motion sensor? When that turns it on/off, how is the program supposed to respond. 

For the ops specific situation, you would want to account for someone dimming the light up or down or using voice/app control. If other devices are linked to his (status button as a controller, what happens then if it's turned on? How does that impact the programs?

Should he add sensors later, they can be easily integrated into the programs to account for those as well. 

Variables allow you to capture those minute details which can improve performance and experience. 

[lilyoyo1]

8 minutes ago, apostolakisl said:

??  Seriously, that is your defense of your logic?

Yes. I'm not going to rehash what 2 people have already stated because you can't get over the fact that there are better ways to program things to account for more than basic actions.

Regardless, it's not our house. We each have our own method of programming and it's up to the op to decide what's best for his situation short and long term

Edited May 18, 2022 by lilyoyo1

[apostolakisl]

1 minute ago, lilyoyo1 said:

That's because you aren't seeing the big picture in regards to future changes nor when other devices can potentially come into play. 

For example, if you dim a light on/off or to a certain percentage; is it still on or considered off? Should the program trigger a second time or stay put?

What about assistants? If you tell your assistant to turn on/or off, do you want it to come back on or stay off and for how long. What if you add a motion sensor? When that turns it on/off, how is the program supposed to respond. 

For the ops specific situation, you would want to account for someone dimming the light up or down or using voice/app control. If other devices are linked to his (status button as a controller, what happens then if it's turned on? How does that impact the programs?

Should he add sensors later, they can be easily integrated into the programs to account for those as well. 

Variables allow you to capture those minute details which can improve performance and experience. 

None of what you say has anything to do with the logic of your program.  You are using time conditions to set a state variable.  100% of the time, the variable will match the true/false state of the program.  Except on a power outage in which case your variable could be wrong whereas the program will be correct.

The state-variable will be in the exact same state as the true/false status of the program.  End of story.  It is fully redundant.  It is also a triggering event, the same as the state variable.  It is a one-to-one copy.  It would be no different than having 2 or 3 or 10 variables that are just copies of the fist one.  I don't know how else to say this.  

All this stuff about what if the lights change or whatever is not setting the variable.  That has nothing to do with it.

[lilyoyo1]

8 minutes ago, apostolakisl said:

None of what you say has anything to do with the logic of your program.  You are using time conditions to set a state variable.  100% of the time, the variable will match the true/false state of the program.  Except on a power outage in which case your variable could be wrong whereas the program will be correct.

The state-variable will be in the exact same state as the true/false status of the program.  End of story.  It is fully redundant.  It is also a triggering event, the same as the state variable.  It is a one-to-one copy.  It would be no different than having 2 or 3 or 10 variables that are just copies of the fist one.  I don't know how else to say this.  

All this stuff about what if the lights change or whatever is not setting the variable.  That has nothing to do with it.

All of those options can play into changing a variable if programmed properly. Since you don't understand that, you don't see it. 

[apostolakisl]

11 minutes ago, lilyoyo1 said:

All of those options can play into changing a variable if programmed properly. Since you don't understand that, you don't see it. 

No, you don't see it.   It is a one to one relationship.

Program true = Variable 1

Program false = Variable 0

 

Whatever the program is, the variable is the same.  There is no need for the variable . . . 

 

EDIT:  Go ahead and write a set of programs that you think need a Boolean state variable, and I will re-do it without the variable and the programs will have fewer lines of code, no variable, and will be easier to track back.

Edited May 18, 2022 by apostolakisl

[lilyoyo1]

16 minutes ago, apostolakisl said:

No, you don't see it.   It is a one to one relationship.

Program true = Variable 1

Program false = Variable 0

 

Whatever the program is, the variable is the same.  There is no need for the variable . . . 

Like i said, you don't see it 

Variable of 0- program runs

Control on-1 second program doesn't run

Fade up- 3 - light doesn't change at new time so it stays dim

Fade off-1 second program doesn't run

Tap Off -1 second program doesn't run

Double tap off- 2 long term time out. Programs don't run

The things that can be captured and how goes on and on. 

Then you can use each variable state for on/off to have it work the way you want. 

 

 

 

 

 

 

Edited May 18, 2022 by lilyoyo1

[apostolakisl]

15 minutes ago, lilyoyo1 said:

Like i said, you don't see it 

Variable of 0- program runs

Control on-1 second program doesn't run

Fade up- 3 - light doesn't change at new time so it stays dim

Fade off-1 second program doesn't run

Tap Off -1 second program doesn't run

Double tap off- 2 long term time out. Programs don't run

The things that can be captured and how goes on and on. 

Then you can use each variable state for on/off to have it work the way you want. 

 

 

 

 

 

 

You are speaking of things that have nothing to do with setting a state variable as either 1 or 0.  You also haven't posted programs.  Post the programs and I will show you how you don't need the 0/1 variable and in fact how they will be easier to follow.

[Geddy]

@lilyoyo1 and @apostolakisl, I think @FBoucher has enough information about how to answer the original question. Let's keep the rest of the chatter a little more on point.  Thanks!

 

[MrBill]

  

this thread certainly moved right along....  I only have a couple additional comments.

21 hours ago, FBoucher said:

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

@FBoucher  Polisy is likely more forgiving, I haven't tried to over use State Variables on Polisy yet.... State Variables CAN be overused on an ISY994 tho.  Probably about 7 years ago I used state variables for everything under the sun.  The ISY got to the point it was slow and produced queue overflow errors frequently.  Polisy is a much faster processor and there's probably less issue.  The difference between a State Variable and an Integer Variable, its that State Variables are monitored constantly and if change will trigger any IF statements that use it to be re-evalauated.  On the other hand an Integer variable isn't monitored for changes and only helps filter when an If statement should or should not run.   In short, usage of Integer Variables is less resource intensive, than use of State Variables... Thus the example I posted above is a better choice than this one.

The winner really goes to @apostolakisl this time.... his second try is probably the best choice here.  Using the Truth of the first program to run a second is very efficient (it's in fact a program style I haven't used a lot of because I frankly forget it can be done that way).   @apostolakisl wanted to say my variable added unnecessary clutter but in reality his first try was full of much more clutter.... enables and disables that will really only make changes twice a year, once in the spring and once in the fall as the Sunset time crosses 6PM... yet those enables and disables are executed everyday... that's the true definition of unnecessary clutter.

5 hours ago, FBoucher said:

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

Welcome to the club.  Don't let us scare you away... just join the fun.

[oskrypuch]

A bit of historical reflection. Before there were variables AT ALL in ISY (not that long ago), we had to use Program TRUE/FALSE state as boolean variables, and even creatively using several together to keep track of binary number values.

Now we have the luxury of using either method, as it best fits our programming style and priorities.

All good!

* Orest

 

[lilyoyo1]

41 minutes ago, MrBill said:

  

this thread certainly moved right along....  I only have a couple additional comments.

@FBoucher  Polisy is likely more forgiving, I haven't tried to over use State Variables on Polisy yet.... State Variables CAN be overused on an ISY994 tho.  Probably about 7 years ago I used state variables for everything under the sun.  The ISY got to the point it was slow and produced queue overflow errors frequently.  Polisy is a much faster processor and there's probably less issue.  The difference between a State Variable and an Integer Variable, its that State Variables are monitored constantly and if change will trigger any IF statements that use it to be re-evalauated.  On the other hand an Integer variable isn't monitored for changes and only helps filter when an If statement should or should not run.   In short, usage of Integer Variables is less resource intensive, than use of State Variables... Thus the example I posted above is a better choice than this one.

The winner really goes to @apostolakisl this time.... his second try is probably the best choice here.  Using the Truth of the first program to run a second is very efficient (it's in fact a program style I haven't used a lot of because I frankly forget it can be done that way).   @apostolakisl wanted to say my variable added unnecessary clutter but in reality his first try was full of much more clutter.... enables and disables that will really only make changes twice a year, once in the spring and once in the fall as the Sunset time crosses 6PM... yet those enables and disables are executed everyday... that's the true definition of unnecessary clutter.

Welcome to the club.  Don't let us scare you away... just join the fun.

True and false works for basic tasks but as you start automating and integrating different systems it starts having an impact. In high use cases, it's better to plan ahead vs getting caught in a trap where logic isnt working properly because other variables are thrown into the mix. 

I'm looking more at what can be done (and probably will as he progresses) vs only today since we know all of this changes over time. No

[MrBill]

19 minutes ago, lilyoyo1 said:

True and false works for basic tasks but as you start automating and integrating different systems it starts having an impact. In high use cases, it's better to plan ahead vs getting caught in a trap where logic isnt working properly because other variables are thrown into the mix. 

I'm looking more at what can be done (and probably will as he progresses) vs only today since we know all of this changes over time. No

I agree that things can grow.  My $sAway variable started out binary (0/1) and grew to where it has 5 states.  Even if it only had two tho there's no way to "set" a program for that value that only exists because I created a variable for it.   I started using $sDark in programs instead of Sunrise and Sunset because it was easier to test in the middle of the day... $sDark evolved tho and now has 3 values (Day, Evening, Latenight--two of those are triggered by "Sunset" and "Sunrise" but the 3rd is by an arbitrary "bedtime" and bedtime occurs when we are home based upon a momentary state, so again a program wouldn't be good for keeping track of that.. "bedtime" when $sAway is set to "Vacation" occurs based on a time followed by a random wait.  So yes the system can grow and become more complicated.

But then there's the case of "too many state variables"... been there done that.   Then there's the case that I've explained to people of how to use a state variable for dimming with Alexa... A usage that YOU don't see the need for.  You followed up one of my long posts detailing with... "don't do that, just use scenes".  My wife doesn't set her lamp to presets tho.. it might be 20%, 40%, 50% , 60% or some other number. I've even hear numbers like Alexa, set my lamp to 88%...  Bottom line.. she can have it her way.  In reality, that system grew too, those same Alexa helper programs now are also Home Assistant helper programs so that Home Assistant can keep Scene's (Kpl buttons) in synch, but also offer on demand dimming.

Bottom line.. there's multiple ways to do anything with this system.  Sometimes one is better than an another for one reason or another.  There's also programming styles... I'll give someone a complex set of 5 programs using enabale and disable and @larryllix will say use a variable instead.

There is no way (that I know of) to change a program from true to False or vice versa so for somethings a variable is definitely called for.  For the application in this thread the program true/false state is actually a good idea.  If I wanted to have the concept of Home/Away without using a variable, the only way I can think of to do it is create a Scene, and attach it to an unused KPL button somewhere (I just tried a scene won't keep track of it's state with no devices).

Another thing is we are all passionate around here.... I jumped on Doc for using a bunch of enables and disables that at the time I couldn't figure out (I realized later even tho they run everyday they only change program states twice a year)... I presented my method using an Integer Variable to solve the problem and he trashed it and said a variable is unneeded clutter... reality is his first method had more unneeded clutter than mine..  His final method is really the best FOR THIS ISSUE.  It's simple, it's elegant and it uses the fewest resources.  On the other hand I don't see a way to create even a simple Home/away variable without a device, so variables do have their place.

[apostolakisl]

2 hours ago, MrBill said:

  

 

The winner really goes to @apostolakisl this time.... his second try is probably the best choice here.  Using the Truth of the first program to run a second is very efficient (it's in fact a program style I haven't used a lot of because I frankly forget it can be done that way).   @apostolakisl wanted to say my variable added unnecessary clutter but in reality his first try was full of much more clutter.... enables and disables that will really only make changes twice a year, once in the spring and once in the fall as the Sunset time crosses 6PM... yet those enables and disables are executed everyday... that's the true definition of unnecessary clutter.

Welcome to the club.  Don't let us scare you away... just join the fun.

Yes and no.  I have no idea how resource intensive various tasks are for ISY, but the first solution only runs a single program each day.  All other options run 2 programs each day. 

[larryllix]

2 hours ago, MrBill said:

  

this thread certainly moved right along....  I only have a couple additional comments.

@FBoucher  Polisy is likely more forgiving, I haven't tried to over use State Variables on Polisy yet.... State Variables CAN be overused on an ISY994 tho.  Probably about 7 years ago I used state variables for everything under the sun.  The ISY got to the point it was slow and produced queue overflow errors frequently.  Polisy is a much faster processor and there's probably less issue.  The difference between a State Variable and an Integer Variable, its that State Variables are monitored constantly and if change will trigger any IF statements that use it to be re-evalauated.  On the other hand an Integer variable isn't monitored for changes and only helps filter when an If statement should or should not run.   In short, usage of Integer Variables is less resource intensive, than use of State Variables... Thus the example I posted above is a better choice than this one.

The winner really goes to @apostolakisl this time.... his second try is probably the best choice here.  Using the Truth of the first program to run a second is very efficient (it's in fact a program style I haven't used a lot of because I frankly forget it can be done that way).   @apostolakisl wanted to say my variable added unnecessary clutter but in reality his first try was full of much more clutter.... enables and disables that will really only make changes twice a year, once in the spring and once in the fall as the Sunset time crosses 6PM... yet those enables and disables are executed everyday... that's the true definition of unnecessary clutter.

Welcome to the club.  Don't let us scare you away... just join the fun.

Again...variables are not constantly monitored, or even monitored at all. ISY is a trigger based / event based logic engine. If nothing happens at the source of a trigger, nothing needs to be processed. No routine cycling of checking variable values, no scanning tables...nothing. Just the OS switching tasks to monitor trigger inputs.

Variables not changing values do not use CPU time. That is the nature of the political concept inside event triggered processing.

Using program logic states as triggers for other programs is just a disaster waiting to happen. Millions of people study programming techniques in colleges and universities for years and using such a cryptic technique would get you a complete fail due to later confusion it will cause, inevitably. I have been programming since 1971 and learned the hard way too many times. I don't use cryptic techniques now. I am over the controllers that only have less than 500 bytes of RAM. ISY used these techniques when it was just a baby too. We are way past the Y2K and memory is cheap now.

 

[oberkc]

1 hour ago, MrBill said:

There is no way (that I know of) to change a program from true to False or vice versa

???

Run a program step that calls the binary status program "then" or "else" action.

Did I miss the intent of this quoted statement?

Edited May 18, 2022 by oberkc

[lilyoyo1]

1 hour ago, MrBill said:

I agree that things can grow.  My $sAway variable started out binary (0/1) and grew to where it has 5 states.  Even if it only had two tho there's no way to "set" a program for that value that only exists because I created a variable for it.   I started using $sDark in programs instead of Sunrise and Sunset because it was easier to test in the middle of the day... $sDark evolved tho and now has 3 values (Day, Evening, Latenight--two of those are triggered by "Sunset" and "Sunrise" but the 3rd is by an arbitrary "bedtime" and bedtime occurs when we are home based upon a momentary state, so again a program wouldn't be good for keeping track of that.. "bedtime" when $sAway is set to "Vacation" occurs based on a time followed by a random wait.  So yes the system can grow and become more complicated.

But then there's the case of "too many state variables"... been there done that.   Then there's the case that I've explained to people of how to use a state variable for dimming with Alexa... A usage that YOU don't see the need for.  You followed up one of my long posts detailing with... "don't do that, just use scenes".  My wife doesn't set her lamp to presets tho.. it might be 20%, 40%, 50% , 60% or some other number. I've even hear numbers like Alexa, set my lamp to 88%...  Bottom line.. she can have it her way.  In reality, that system grew too, those same Alexa helper programs now are also Home Assistant helper programs so that Home Assistant can keep Scene's (Kpl buttons) in synch, but also offer on demand dimming.

Bottom line.. there's multiple ways to do anything with this system.  Sometimes one is better than an another for one reason or another.  There's also programming styles... I'll give someone a complex set of 5 programs using enabale and disable and @larryllix will say use a variable instead.

There is no way (that I know of) to change a program from true to False or vice versa so for somethings a variable is definitely called for.  For the application in this thread the program true/false state is actually a good idea.  If I wanted to have the concept of Home/Away without using a variable, the only way I can think of to do it is create a Scene, and attach it to an unused KPL button somewhere (I just tried a scene won't keep track of it's state with no devices).

Another thing is we are all passionate around here.... I jumped on Doc for using a bunch of enables and disables that at the time I couldn't figure out (I realized later even tho they run everyday they only change program states twice a year)... I presented my method using an Integer Variable to solve the problem and he trashed it and said a variable is unneeded clutter... reality is his first method had more unneeded clutter than mine..  His final method is really the best FOR THIS ISSUE.  It's simple, it's elegant and it uses the fewest resources.  On the other hand I don't see a way to create even a simple Home/away variable without a device, so variables do have their place.

I stay away from variables as much as possible for many tasks. However, i will use them when multiple scenarios come into play as it's easier to manage things and keep running how i want and when I want... Especially as more and more talks are integrated and automated with cross capabilities.

I agree that most basic things do not require them. 

[oskrypuch]

I remember when ISY first introduced variables, of course most rejoiced.

But, there was one comment, I think from someone not familiar with such things, "What are variables used for (in programming)?". I had to chuckle.

This is an interesting discussion. I thought for a bit that I was on stackoverflow. ?

* Orest

Edited May 18, 2022 by oskrypuch

[larryllix]

2 minutes ago, oskrypuch said:

I remember when ISY first introduced variables, of course most rejoiced.

But, there was one comment, I think from someone not familiar with such things, "What are variables used for (in programming)?". I had to chuckle.

This is an interesting discussion. I thought for a bit that I was on stackoverflow. ?

* Orest

I was smart enough to not think of my ISY as an Insteon Hub.  I have occupancy light switches that are just as smart and cheaper.

Strangely enough, I was the owner of two Insteon Hubs when I discovered ISY. After a few questions and answers from Michel, I sent the Hubs back to the vendor. Even my old software from the X10 days, back in the 1940s?, had, and used, variables.

[apostolakisl]

43 minutes ago, oskrypuch said:

I remember when ISY first introduced variables, of course most rejoiced.

But, there was one comment, I think from someone not familiar with such things, "What are variables used for (in programming)?". I had to chuckle.

This is an interesting discussion. I thought for a bit that I was on stackoverflow. ?

* Orest

I remember that as well.  Later I wrote probably the single most variable intensive set of programs ever to track time and date.  ISY for a very long time had no way do something as simple as say "every May 18th".  You had to go in and enter May 18 2022, May 18 2023, May 18 2024, etc.  Or every other day, or on even days, or whatever.

[LarryCRetired]

apostolakisl

I still use your calendar programs.  And I thank you for writing them.  

[oskrypuch]

37 minutes ago, apostolakisl said:

I remember that as well.  Later I wrote probably the single most variable intensive set of programs ever to track time and date.  ISY for a very long time had no way do something as simple as say "every May 18th".  You had to go in and enter May 18 2022, May 18 2023, May 18 2024, etc.  Or every other day, or on even days, or whatever.

Yes, that was a serious irritant. I found my own solution, just noticed yours (I believe it is yours) in the cookbook.

* Orest

 

[MrBill]

16 hours ago, oberkc said:

???

Run a program step that calls the binary status program "then" or "else" action.

Did I miss the intent of this quoted statement?

Nope, you missed nothing... but I just learned something.

So it is possible to conceptualize "away" and then use an empty program to determine it's status...

It's not particular useful to me personally however because I also use Home Assistant, and Home Assistant has no concept of a Programs True/False status.

16 hours ago, apostolakisl said:

Yes and no.  I have no idea how resource intensive various tasks are for ISY, but the first solution only runs a single program each day.  All other options run 2 programs each day. 

That's true, I don't really either.  I do know too many State Variables with 994 hardware you will reach a point of queue overflows errors and a sluggish half operating system.  In the case of the two programs that run sequentially, without extra pointless enables/disables my guess is that it's more efficient... and it's certainly easier code to read.