Sunset to Sunrise?

[CoolToys]

Removed the sunrise to sunset conditions in the three programs and reloaded them.  So far so good.  More testing in an hour after sunset.

Just for fun on one of the three I did what @Andy P said and put the sunset to sunrise in a and (...) no change.  As of now all working after delete, restart and then add the condition back. 

Correction edit, none of them are activating in the day time.  Only tested front door so far at night and it worked fine.  On the road again will do a thorough test in a few days.

Edited September 21, 2023 by CoolToys
update and correction

[CoolToys]

Since doing the delete, reset eisy, reload the if statements for sunset to sunrise does appear to work, I did follow @apostolakisl idea of a single reference point for sunset to sunrise, and I used the same idea to set a new program for "peak power" which is currently 4-9pm, and has lots of implications in other programs.  Doing this, if the power company changes the times with the time change, then I only need to correct in one place.  Thanks for the idea.  

While @apostolakisl made a program, I made a state of "Night".  and then zero it out at sunrise with two programs.  The same for "peak power".  One less line to watch in the event viewer and the event is only true in that moment so it seams like less processing for the eisy. 

 

Sunset Night Time - [ID 000C][Parent 0001]

If
        Time is Sunset  -  5 minutes
 
Then
        $Night  = 1
 
Else
   - No Actions - (To add one, press 'Action')
 

[apostolakisl]

1 hour ago, CoolToys said:

Since doing the delete, reset eisy, reload the if statements for sunset to sunrise does appear to work, I did follow @apostolakisl idea of a single reference point for sunset to sunrise, and I used the same idea to set a new program for "peak power" which is currently 4-9pm, and has lots of implications in other programs.  Doing this, if the power company changes the times with the time change, then I only need to correct in one place.  Thanks for the idea.  

While @apostolakisl made a program, I made a state of "Night".  and then zero it out at sunrise with two programs.  The same for "peak power".  One less line to watch in the event viewer and the event is only true in that moment so it seams like less processing for the eisy. 

 

Sunset Night Time - [ID 000C][Parent 0001]

If
        Time is Sunset  -  5 minutes
 
Then
        $Night  = 1
 
Else
   - No Actions - (To add one, press 'Action')
 

Just know that if you used an integer variable for $night that it will not be a trigger where "from sunrise/sunet" statement is a trigger so it will behave diffeently.  If you use a state variable, it will be identical.  

I would also suggest you use the naming convention of placing an "i" on all of your integer variables and an "s" for state.

ie  $iNight  or $sNight

It is helpful for yourself and also when you post to the forum with questions everyone will know.

[CoolToys]

On 9/21/2023 at 9:44 AM, apostolakisl said:

Just know that if you used an integer variable for $night that it will not be a trigger where "from sunrise/sunet" statement is a trigger so it will behave diffeently.  If you use a state variable, it will be identical.  

I would also suggest you use the naming convention of placing an "i" on all of your integer variables and an "s" for state.

ie  $iNight  or $sNight

It is helpful for yourself and also when you post to the forum with questions everyone will know.

What is the difference if I use an integer for $night and make it = 1 or a state for $night and make it = 1 when the if statement is IF $Night = 1 THEN Do "What Scott says to do".  Isn't it going to run either way?

[larryllix]

What is the difference if I use an integer for $night and make it = 1 or a state for $night and make it = 1 when the if statement is IF $Night = 1 THEN Do "What Scott says to do".  Isn't it going to run either way?

Programs using State variables in the IF section can be self triggered for re-evaluation each time the value changes.

Integer variables do not self trigger programs and must be manually run via another program (subroutine) or another trigger in the same If section. IOW they can be used as filters only.

Sent from my SM-G781W using Tapatalk

[CoolToys]

@larryllix, My understanding is the eisy continuously cycles through the programs checking the If statements, so I will test this by replacing a state with an integer in one of my programs and see what happens.

[DennisC]

9 minutes ago, CoolToys said:

@larryllix, My understanding is the eisy continuously cycles through the programs checking the If statements, so I will test this by replacing a state with an integer in one of my programs and see what happens.

As @larryllixindicated, only a state variable will trigger a program. It doesn't matter if it is an ISY994, Polisy, or eisy, variables work the same across all platforms.

From the wiki on variables https://wiki.universal-devices.com/index.php?title=ISY_Users:V5:Program_Variables:

Integer Variables

• A signed integer (32 bit)
• Arithmetic operations available in Actions
• Comparison operations available in conditions
• Initialized at startup
• Changes to the value do not cause an event to be sent

State Variables

• Identical to an Integer variable except that changes to the value do cause an event to be sent, causing programs to run

[CoolToys]

@DennisC and @larryllix, Ok, I see where my confusion is.  I don't ever use a variable as the only condition to run a program.  I use them to start timers.  i.e. come home at 1 am to dark house.  Front door opens lights come on, set $Front_Door = 1.  

Next program is 
 

Front Door Auto Off - [ID 002B][Parent 0001]

If
        'Area 1 / FRONT.DOOR' is switched Off
    And $Front_Door is 1
 
Then
        Wait  15 minutes 
        $Front_Door  = 0
        Set 'House Front' Off
 
Else
   - No Actions - (To add one, press 'Action')

Because the front door being closed is the status change that runs the program, this works.  

Looking at the example I should be using integers to increment and decrement more often to make the lights more efficient/accurate when people keep moving around maybe.  Since I use MSII to trigger the internal lights around the house, I think I would have the same issues, if everyone stops moving long enough lights go out.  

With this particular one, if the door is re-opened the program changes to "false".  I think that stops the timer but more to play with.

For this thread, the Sunset/Sunrise appears to have been fixed by removing all of the references, restarting the eisy and reloading.  I am down to trying to get my last program working again with a mini remote. 
 

[DennisC]

The document below may help you. While the document I linked below was written for ISY994, all of the excellent examples would work the same.

https://www.universal-devices.com/docs/production/The+ISY994+Home+Automation+Cookbook.pdf

[CoolToys]

@DennisC Thanks, it is amazing after having my ISY/ELK/Insteon for so many years how many other things it can do that much more I never thought of or how many ways there are to do the same thing better.

[larryllix]

13 hours ago, CoolToys said:

@larryllix, My understanding is the eisy continuously cycles through the programs checking the If statements, so I will test this by replacing a state with an integer in one of my programs and see what happens.

ISY/eISY does not poll programs or variables. They are event driven logic. An event or device sends a signal and the input drivers get the interrupt and process it, changing a variable or status somewhere. In the main processing that event is then handled by the main processing engine  to check every program and only those programs involved with that event or variable  and then processes the program logic (IF) involved.

As far as I understand it, the whole sequence is event driven from end to end, and no polling is ever done or required. Basically, is is an interrupt driven system using semaphores to communicate those interrupts from I/O drivers  to the main processing engine via processing table lists that tell ISY what to do next. This is one of the reasons ISY can be so fast....as it is not running useless checking on static programs that may be sleeping for days or weeks at a time.

[larryllix]

13 hours ago, CoolToys said:

@DennisC Thanks, it is amazing after having my ISY/ELK/Insteon for so many years how many other things it can do that much more I never thought of or how many ways there are to do the same thing better.

If you like to use variables, I use state variables to operate most of my lights buy triggering programs scenarios with them.

Here is an example of my occupancy detection system. Variabes can make it so simple to write ISY code.

These programs run a timer during waking hours, warn me verbally if it is about to expire, and finally turn the lights of in my apartment.

You may notice another usage of Integer variables for constants. In one program you may see a variable named $cFALSE.
'c' denotes a constant value that never changes, and the all caps is another standard used in many programming languages to denote a constant value.

Occu.countdowner - [ID 0005][Parent 0004][Run At Startup]

If       
        // Run at Startup enabled
 
        $sHouse.occupied.timer > 0
    And From     9:00:00AM
        To      11:00:00PM (same day)
 
Then    
        // self perpetuating loop
 
        Wait  1 minute 
        $sHouse.occupied.timer -= 1
 
Else
   - No Actions - (To add one, press 'Action')
 
Self retriggering timer.
-If startup occurs outside wake timeframe, will self start at beginning of timeframe.
-If timeframe commences while occupied.timer is 0, first new occupied.timer value will start again.

 

Occu.timeout.warning - [ID 000E][Parent 0004]

If
        $sHouse.occupied.timer is 7
     Or $sHouse.occupied.timer is 1
 
Then
        $sSay.occupancyTimerExpiring  = $cTRUE
 
Else
   - No Actions - (To add one, press 'Action')
 

 

Occu.flagger - [ID 0012][Parent 0004]

If
        $sHouse.occupied.timer > 0
 
Then
        $sHouse.occupied  = $cTRUE
        $sHouse.occupied Init To $sHouse.occupied
 
Else
        $sHouse.occupied  = $cFALSE
        $sHouse.occupied Init To $sHouse.occupied
 
Power up resumes previous state! Shouldn't be long to correct.
Program cannot be combined into "Occ countdowner" program as it's timeframe end would zero occupied.timer

 

Occu.vacantLightsOff - [ID 006E][Parent 0004]

If
        $sHouse.occupied is $cFALSE
 
Then
        Run Program 'Lights.inside.onOff.initiate' (Else Path)
 
Else
   - No Actions - (To add one, press 'Action')

 

 

 

Edited September 25, 2023 by larryllix

[CoolToys]

@larryllix, thanks for the input on the polling.  Maybe I confused it with the Elk or something else I have here to play with.

Your method of occupancy testing is also very cool.  I use MSII sensors to set a state variable of $sOccupied to 1 and at 4 am or if the ELK M-1 alarm is set to away it is set to 0.  This changes lighting scenes and HVAC usage when no one is there and prevents me from making the guest area dark when I go to bed if someone is in there.  Your method might let me eliminate the 4 am reset. It might also make the guest area a bit more accurate in case I pop in to put out halloween decor and then leave. Something to play with.

There are three major areas to the house so in addition to $sOccupied there is $Guest and $Garage as well.  Some programs test one of the states, others test two or all three.  

There are two other states I use $sHighPower for when electricity is super expensive from 4-9.  I am hoping to use the new solaredge node to monitor if I am producing or using power during that window to adjust the AC, if producing, leave AC on, if using, turn it off type thing.  I am also looking into the ADR functionality for similar management.

The last state is $sNight from this thread.  I like the idea of one place to make changes instead of going to each program if I have to do a delete and reload like this again.  So now Sunset turns $sNight to 1, Sunrise turns $sNight to 0.  

Yes I did add the "s" and the "i" to all of my variables too, I only code in Swift now, the last formal training was COBOL and PASCAL in the 80's so the the tips to clean up my work are helpful thanks!

[apostolakisl]

7 hours ago, CoolToys said:

The last state is $sNight from this thread.  I like the idea of one place to make changes instead of going to each program if I have to do a delete and reload like this again.  So now Sunset turns $sNight to 1, Sunrise turns $sNight to 0.  

 

You can do this if you want, but it just isn't necessary and adds clutter.  The variable $sNight is just a mirror image of the program state itself.  If you reference the program, it will behave exactly the same as referencing the variable but without the extra step.

If

$sNight = 0 (if you used 0 for night)

is precisely the same as

If

program Dark outside is true

 

The state of a program that sets a binary state variable is indistinguishable from the state of the variable that it set.  When the program changes state, it will be a trigger, when the variable changes state it will be a trigger.  Both only have two possible states, day and night.

[CoolToys]

@apostolakisl, I do understand the concept.  For me personally, I like to keep it simple.  When I open the "Dark" program I see what it does.  It sets a variable, "sNight" so I know why I put it there. If it had no "then" or "else" function and I haven't seen it in a year I might forget why I did it.  I could add comments, but for some reason I don't on my ISY, even though I have a lot of comments in my App codes to make fixes easy.  

All of the programs that have something to do with the state of sNight are named things like "Home Night" "Away Night" etc.  It is very easy for me to find specific lines when an insteon part fails and I have to replace it or I want to change something because my wife didn't like my ideas.  Over the 10 or maybe even 15  years the ISY was running my home, I needed to change things no more than once a year.  For that reason alone, I don't mind a little code bloat if it makes it easier for me to figure out what I did.

Call it lazy mans documentation.  

[apostolakisl]

@CoolToys I would say all you are doing is shifting your question mark from why does the program exist to why does the variable exist.  You either have a program called "dark outside" or a variable called "dark outside".  Both seem pretty self explanatory, but at least with a program you can put notes on it whereas a variable has not opportunity for notes.  Either way, if you want to see its usage, you do a "find/replace" on your programs and search for either the name of the variable or the name of the program.

 

[CoolToys]

@apostolakisl, you are correct, however for me, using sVariables does several things:
 
1. Easier to glance at a short list of variables to know if eisy thinks it is dark, house is occupied and power is expensive when I am troubleshooting and watching the event viewer.

2. When adding condition to a program, I only need to scroll through 7 variables, not 30+ programs

3. I understand intuitively how to make a program change a sVariable like the program "Alarm Set" makes "sGuest" and "sOccupied" instantly = "0" to save energy and set the ELK to "Armed".  While I might be able to us the Action of THEN  "Program" "Guest" > "Stop" for the blank/flag "Guest" program, I don't know what that does for sure and am too lazy to dig through the ISY cook book or bother to try it.  Maybe someday, but not today 🏄‍♂️ 

You are correct that I do have some minor redundancies in my system but my way to skin the cat works for me is all I am sayin.

 

Edited September 27, 2023 by CoolToys
correction

[larryllix]

11 hours ago, CoolToys said:

@apostolakisl, you are correct, however for me, using sVariables does several things:
 
1. Easier to glance at a short list of variables to know if eisy thinks it is dark, house is occupied and power is expensive when I am troubleshooting and watching the event viewer.

2. When adding condition to a program, I only need to scroll through 7 variables, not 30+ programs

3. I understand intuitively how to make a program change a sVariable like the program "Alarm Set" makes "sGuest" and "sOccupied" instantly = "0" to save energy and set the ELK to "Armed".  While I might be able to us the Action of THEN  "Program" "Guest" > "Stop" for the blank/flag "Guest" program, I don't know what that does for sure and am too lazy to dig through the ISY cook book or bother to try it.  Maybe someday, but not today 🏄‍♂️ 

You are correct that I do have some minor redundancies in my system but my way to skin the cat works for me is all I am sayin.

 

Also... using a central variable allows one to use multiple logical inputs (complex logic) to derive the desired outcome. Program logic only allows one program. It keeps things modular, independent, simpler to understand, and less obscure.
When you duplicate a program and modify it, and then delete the original program, any obscure dependency from another program will be lost unbeknownst to the programmer.

When I was cruising in the Carribean and some of my logic didn't work properly, I found it was nearly impossible to run Then or Else for any program to corrects things, as I could never be sure exactly what they would do. However, my variables were easier to understand their functions and easy to understand what was happening in my system.

Another negative for program logic is it will be incorrect after a power blink until a sensor reports a change. That may never happen. Variables have methods of keeping values through ISY rebooting.

As a side note: I had a temperature variable based on three sensors and a program that determined if any sensor was not within limits of the previous average, and cut it out of the averaging equation....sort of "self-healing" logic, if you will. Now, I had a much more secure temperature reading to base downstream logic on.

[Andy C]

I've had exactly the same problem with sunset / sunrise triggering on regardless of the time of day.  It didn't matter the order of my syntax, use of brackets, etc.  I had to use exact times to make my programs (sort-of) work.

This eventually cleared itself on the last upgrade to 5.7.0, and everything is working exactly as it used to on my old ISY994i.

[CoolToys]

I gave up and created a sNight variable, and then two programs where when sunset sNight = 1 and Sunrise sNight = 0.

I did the upgrade and all my programs were disabled.  I re-enabled them all one at time so i am out of patience for tonight.  I will try in the next day or two to use the sunrise to sunset within the programs instead of the state variables. I am starting to think the PLM may be an issue.  I have had to delete several devices and reload to make them reliable.

Edited October 4, 2023 by CoolToys

[larryllix]

I gave up and created a sNight variable, and then two programs where when sunset sNight = 1 and Sunrise sNight = 0.
I did the upgrade and all my programs were disabled.  I re-enabled them all one at time so i am out of patience for tonight.  I will try in the next day or two to use the sunrise to sunset within the programs instead of the state variables. I am starting to think the PLM may be an issue.  I have had to delete several devices and reload to make them reliable.

Typically RESTORE will fix wayward devices. It writes what ISY thinks should be in the devices into a device.

This can be found by right clicking on a device name and selecting it. However in the last few versions it has become much more complicated and needs to be followed by a WRITE or an UPDATE or more complexity than it previously was.

Sent from my SM-G781W using Tapatalk

[apostolakisl]

9 hours ago, CoolToys said:

I gave up and created a sNight variable, and then two programs where when sunset sNight = 1 and Sunrise sNight = 0.

I did the upgrade and all my programs were disabled.  I re-enabled them all one at time so i am out of patience for tonight.  I will try in the next day or two to use the sunrise to sunset within the programs instead of the state variables. I am starting to think the PLM may be an issue.  I have had to delete several devices and reload to make them reliable.

EDIT: It see that Andy C posted in another thread and a second person also said they had issues.  Both said issues went away with firmware update even though they weren't on the same firmware.  Perhaps there is an issue with the migration and the issue gets fixed by a firmware update, regardless of the version.  In other words, the update process fixes it, not the firmware.  I am on Polisy 5.6.4 and have no issues nor did I have issues when I migrated to Polisy a couple years ago.

Short of ISY having some glitch that is making the sunrise/sunset terminology not work, I suspect you have some other program that is doing this. Checking the current state of the night/day program and the state of the variable at any given time and seeing that it is as expected for that time of day rules it out as the problem.  Again, watching the program summary page while you are doing things (or at the time it does things) that trigger these programs to run incorrectly will show you what program is doing it.

Moving the sunrise/sunset line into your program instead of the variable won't fix anything.  If the sunrise/sunset program is setting the variable wrong, it will be just as wrong if it is in the program itself.  It is quite easy to see if the sunrise sunset program is setting the variable wrong by just looking at the variable value and seeing if it is correct for the time of day.  Of course you can also look at the current true/false status of the sunrise/sunset program.  Also, you can also do a "run if" on your programs and see if it the outcome is what you expect for that time of day and other conditions that may exist in the if clause.  

It looks @Andy C is saying he had the sunrise/sunset programs run wrong as well.  I don't know, I have not seen this being an issue on the forum and I have had my sunrise/sunset programs work correctly through every firmware update over the last 15 years including 99i/994i/and now Polisy running two units at two different locations.

It is unlikely that this has anything to do with the PLM.  Orphan links can happen and can turn devices on and off as responders to other devices where they are not supposed to be linked.  I see the chances of the behavior you described being related to the PLM or Insteon links to be very tiny.

Edited October 4, 2023 by apostolakisl

[CoolToys]

@apostolakisl, Agreed that for nearly 15 years I have had almost zero logic problems with UDI. Generally it has been me trying something left in my brain from Basic, Pascal or COBOL logic that didn't work.  I am sure there are times when Michel sees my name and just rolls his eyes, but he has always been there to laugh and set me back on the right track.

Prior to the migration, I had a 994i/Pro/ USB PLM / Elk Module.  I migrated to the eisy/Serial PLM / Elk Node server and followed the Wiki step by step, even though that bounced me all over the place.  There isn't a single step by step "checklist" that is complete and in fact there are two sets of instructions that are contradictory.  The Wiki version worked best but I had a long list on non working programs and spent hours troubleshooting.  Looking through the forums I found lots of other people with similar problems but none with the Sunset to Sunrise issue.   I was frustrated because those programs had been working for years.

3 hours ago, apostolakisl said:

 

Moving the sunrise/sunset line into your program instead of the variable won't fix anything.  If the sunrise/sunset program is setting the variable wrong, it will be just as wrong if it is in the program itself.  It is quite easy to see if the sunrise sunset program is setting the variable wrong by just looking at the variable value and seeing if it is correct for the time of day.  Of course you can also look at the current true/false status of the sunrise/sunset program.  Also, you can also do a "run if" on your programs and see if it the outcome is what you expect for that time of day and other conditions that may exist in the if clause.  

 

Maybe I presented this incorrectly.  The programs had the If statement with the time of "Sunset to Sunrise (next day) in the program.  None were working after the upgrade, all worked before.  I created two programs to set the variable on sNight to 1 and back to 0 at sunrise, and in the other programs the IF sunset to sunrise (next day) line was updated to IF sNight = 1.  Everything started working.  

This thread was started to see if anyone else had seen this and had an answer to solve it.  Clearly there are at least two of us now who have seen this, and I will test later today if upgrading to 5.7.0 and resetting the program to use the sunset to sunrise next day option works as well.  I am glad it worked for @Andy C, now we have two possible solutions.  

Every other "bug" or non working program since upgrading except Sunset to Sunrise and the one press of a 2342-2 Mini Remote has been fixed.  I will list this not to argue with you but help others with something that appears to have worked for me when I actually had the issue.  This isn't to say the @apostolakisl way won't work as well.

The big picture process....

Followed the eisy update Wiki step by step to include the device restore process.

What I got was about 50% of my programs remarked out because they were dependent on Elk modes, or zone status.  It took a while and all of that was fixed with the Elk Node which let me do a lot more with my Elk integration.

Once that was fixed I had the following issues remaining:

• Motion Sensor II aka MSII, none were showing motion status, thus related programs didn't work. I have four of them and each sets a variable and has at least one associated program.
• Sunset to Sunrise programs did not work. (Did not think to look and see if the program was "true", but event viewer showed no activity)
• New i3 Outlet stopped working
• Old version of outlet stopped working.
• Single press on 2432-2 Mini Remote to activate programs stopped working.

Each of these issues was "fixed" as follows:

 

• Delete and relink MSII fixed MSII sensors status in admin panel - fixed.
• Created the sNight variable with the two quick programs of If Sunset sNight =1, if Sunrise sNight = 0 Removed Sunset to Sunrise line in programs and added If sNight = 1  (All programs work - fixed)
• PLM reset and restore of devices fixed the new i3 outlet.
• Delete and relink old outlet - fixed.
• Single press solution for the mini remote, gave up, bought an X-10 tabletop remote and changed the line to read If X-10 B-1 "off" then run "Bedtime".  Worked perfectly, moving on.

Last night I upgraded to 5.7.0. and realized a flaw with sNight v Sunset to Sunrise (next day) logic.  The restart reset the variable to 0 so the house thought it was day time.  Manually set to 1 and all was well.

Another interesting upgrade "feature' was that every program was marked "disabled" so I had to manually reenable each one.  

 

[Michel Kohanim]

@CoolToys, 

Since I have less time to frequent the forum lately, it's best to submit a ticket. 

With kind regards,
Michel

[apostolakisl]

@CoolToys  Set the sunrise/sunset program to run at startup to avoid the status of the program/variable from being incorrect after restarts.

It sounds like sunrise/sunset is now working?

And yes, I had to go through when I switched to the Elk node server from Elk module and fix all of my Elk programs.  However, I did not do that at the same time as switching to Polisy so it broke up things up.