I recently put a Aeotec Multisensor in our kitchen with the idea to utilize the motion sensor.  Thought it would be easy enough, but I'm a bit perplexed and figure I'm missing something obvious.  Hopefully someone can gently point me in the right direction.

I have three different programs to cover different times of day, where I want different things done.

Daytime;

Daytime - [ID 0061][Parent 0020]

If
        From    Sunrise
        To      Sunset  - 30 minutes (same day)
    And 'Kitchen / ZW KitchMot Motion Sensor 1' Status is Off
 
Then
        Set 'Kitchen - All' Off
 
Else
   - No Actions - (To add one, press 'Action')
 

Evening:

Evening - [ID 0062][Parent 0020]

If
        From    Sunset  - 30 minutes
        To      11:30:00PM (same day)
    And 'Kitchen / ZW KitchMot Motion Sensor 1' Status is Off
 
Then
        Wait  10 minutes 
        Set 'Kitchen / Kitchen ceiling' Off
        Set 'Kitchen / Sink' Off
 
Else
   - No Actions - (To add one, press 'Action')

Overnight:

Overnight - [ID 0063][Parent 0020]

If
        From    11:30:00PM
        To      Sunrise (next day)
    And 'Kitchen / ZW KitchMot Motion Sensor 1' Status is On
 
Then
        Set 'Kitchen / Under Cabinet' On
 
Else
        Set 'Kitchen - All' Off

I didn't notice it until after sunset, but all three trigger every time the motion sensor is triggered off.  For instance, they all triggered at 8:32:19 PM last night while testing, well after sunset but before 11:30 PM.  Also, the under cabinet lights (which are in the "Kitchen -All" scene shut off.

Am I missing something obvious?  Do I not understand how the time schedule works?

 

 

Edited January 4, 20214 yr by Screw Loose Dan

The 'Overnight' program runs Else each time the motion sensor turns off (time doesn't matter). I suspect that's not what you intended. If the lights should turn off when the motion sensor turns off, you need to have a separate program.

To add to what @jfai said, I am using less and less times directly in program conditions.

I have moved to having multiple programs that enable/disable other programs as needed.  Then in the program, I have just the conditions (motion sensor status in your case).

This way I don't have programs triggering at odd times.

@jfaiand @PurdueGuy - Thanks for the input!  Jürgen was absolutely correct, I appreciate the extra set of eyes.  I knew I was missing something obvious. 

Interesting idea about not using times directly in programs.  While troubleshooting this I switched to using a variable (an integer variable = 1 for Daytime, 2 for Evening, 3 for Overnight).  This way there's no way of overlapping these programs, and I can use the variable for other similar/related programs.

I group my timed programs in folders and simply enable the folder during those hours. Helps keep track of stuff and prevents any overlapping of hours

15 hours ago, PurdueGuy said:

To add to what @jfai said, I am using less and less times directly in program conditions.

I have moved to having multiple programs that enable/disable other programs as needed.  Then in the program, I have just the conditions (motion sensor status in your case).

This way I don't have programs triggering at odd times.

I have a state variable $sDark

that can have 3 values:

• 0 = Daytime, from sunrise to sunset
• 1 = Early Evening, Sunset to Bedtime
• 2 = Late night, Bedtime to Sunrise

Bedtime when we are home is determined by a specific button press, if $sAway is set bedtime is a random number of minutes (up to 72) after 9:46pm

A huge advantage to using a state variable is that for testing purposes it's very easy to shift to "Early evening" or "late night"  mode at any given moment.  For example I can manually change the variable right now to see how things work during a different time period. 

Most programs that occur at a time use a combination of $sDark and $sAway in their conditions instead.  The Exception is there is a folder of lighting programs that run when $sAway mode is on... the programs in that folder all have there own timers to make a random 'someone is home' look. 

I did end up with an area specific variable also... $sDark.kitchen has very similar except that Early Evening occurs at Dinnertime, or Sunset (whichever comes first).  "Dinner time" is either pressing a KPL button or saying "Alexa, it's dinner time".

• 0 = Daytime, from sunrise to sunset
• 1 = Early Evening, Sunset or "dinner time" to Bedtime
• 2 = Late night, Bedtime to Sunrise

36 minutes ago, MrBill said:

I have a state variable $sDark

that can have 3 values:

• 0 = Daytime, from sunrise to sunset
• 1 = Early Evening, Sunset to Bedtime
• 2 = Late night, Bedtime to Sunrise

Bedtime when we are home is determined by a specific button press, if $sAway is set bedtime is a random number of minutes (up to 72) after 9:46pm

A huge advantage to using a state variable is that for testing purposes it's very easy to shift to "Early evening" or "late night"  mode at any given moment.  For example I can manually change the variable right now to see how things work during a different time period. 

Most programs that occur at a time use a combination of $sDark and $sAway in their conditions instead.  The Exception is there is a folder of lighting programs that run when $sAway mode is on... the programs in that folder all have there own timers to make a random 'someone is home' look. 

I did end up with an area specific variable also... $sDark.kitchen has very similar except that Early Evening occurs at Dinnertime, or Sunset (whichever comes first).  "Dinner time" is either pressing a KPL button or saying "Alexa, it's dinner time".

• 0 = Daytime, from sunrise to sunset
• 1 = Early Evening, Sunset or "dinner time" to Bedtime
• 2 = Late night, Bedtime to Sunrise

These are some of the values I use for a few different state variables that control banks of lights.

Edited January 5, 20214 yr by larryllix