Mode based changes not triggering? (SmartLights - Night -> Home)

So my time-based schedules look like they will probably trigger tonight, after I updated the sunset offset last night. At least, it says it’s scheduled for tonight, unlike when it was last scheduled for the previous day and still waiting!

But anyway, I have a Smart Lighting script set to turn a couple lights on in the morning, with the following rules:
Which lights do you want to control?

  • Living room corner
  • Rec Room Ceiling C
    What do you want to do?
  • Turn On & Set Level
    Dimmer Level
  • 80%
    Select trigger
  • When Mode Changes
    Turn on & set level when mode changes to
  • Home
    Also turn off when mode changes back
  • No

More options
Only during a certain time

  • Starting at: 4:00 AM
  • Ending at: Sunrise
  • Offset in minutes: 15
    Only on certain days of the week
  • None set
    Only when mode is
  • Night

When the mode changes from Night -> Home, the listed lights aren’t turning on, and I see no log in the events for this schedule. The last entry I see in there was from 10/14 when it was last set to run on a timed event.

Is this another instance of, make a change to the app, save it, and then change it back, to reset the triggers?

This would definitely cause some problems. If your mode changes to “Home” and you want it to do something only when the mode is “Night” this is what would happen:

  1. Mode changes to “Home”
  2. Smart Lights sees mode change
  3. Smart Lights runs through app logic you have setup
  4. Part of this logic is checking the mode
  5. Mode = Home… Mode != Night
  6. Since mode does not equal night the automation will not run.


  • Use multiple modes for each “home State” based on the “Sun State”
  • I use these
  • Home - Day
  • Home - Night
  • Away - Day
  • Away - Night
  • Goodnight
  • This allows you to do mode triggers like you want.
  • Use “Routine Director” to set your home to the certain modes based on whether the sun is up/down and your home is Empty/Occupied.
1 Like

I think it’s perfectly reasonable to want to create an action when mode changes from A→B and not C→B; this is fairly standard logic in a state machine. The problem as it stands is that when triggering an action on a mode change, there is no way to test the previous mode.

Your solution of multiple modes for each day/night and home/away permutation points out a fundamental problem; home/away and day/night are orthogonal concepts and we really want to test for them independently.

So just a thought, but seems this could be resolved by the SmartLights app keeping a prior state variable, when the state changes.

Pseudo code example:

def handleModeChangeEvent(evt) {
  prevMode = currentMode
  currentMode = evt.Mode // However the mode is retrieved from a mode change

That way, the comparison of A -> B mode changes could be detected.

That seems like it could help, but…

…wouldn’t the option to: Turn on & set level when mode changes to [mode] already trigger a handler for the mode change event? And if so, wouldn’t the mode conditions be applied to the previous mode? In other words, why doesn’t this already work? Unless perhaps location.mode is already changed when the mode change handler is called.