Turn on lights annually starting the fourth Friday of November(Reactor)

Yes, if you guessed xmas lights, you’re correct.

I start my lights ablaze on the night of Black Friday. As Thanksgiving is the fourth Thursday of November, this makes Black Friday the fourth Friday of November.

I’m looking for guidance on how to configure Reactor to turn on xmas lights from Black Friday thru January 7th (for our Orthodox xmas friends out there.)

1 Like

Actually, it makes Black Friday the day after Thanksgiving. This year 2019, that’s FIFTH Friday of November.

The simple answer, of course, is to just use date conditions and leave it at that, but you’ll need to adjust for Thanksgiving every year. If you don’t want to do that, which I fully understand, then an RS to tell you it’s the holiday season might look something like this:

  • Root group “Holiday Season” – “AND” operator
    • Group “Holiday Season” – “AND” operator, SUSTAINED FOR 86400
      • Group “Thanksgiving Day” – “AND” operator, LATCHED
        • Weekday is fourth THURSDAY
        • Date/Time between Nov 1 (no year) and Nov 30 (no year)
      • Date/Time condition between Nov 1 (no year) and Jan 8 (no year)

Working from the inside out… the “Thanksgiving Day” group will go true on the Fourth Thursday of November. It uses latched output, so once it goes true, it stays true until reset.

The date/time condition “between Nov 1 and Jan 8” is anded with the Thanksgiving Day group, driving the “Holiday Season” group true (and when this Nov1-Jan8 date/time condition goes false, it causes the latch on the Thanksgiving Day group to be released). Together, the Thanksgiving Day group and the date/time condition cause a true condition on the “Holiday Season” group from Thanksgiving Day through the end of Jan 7 (i.e. until midnight Jan 8). To defer the true for 24 hours so it doesn’t start until Black Friday, the “Holiday Season” group is given a 24-hour (86400 second) “sustained for” delay option. The overall tripped/untripped state of this ReactorSensor advertises holiday mode (tripped = holiday period). You can use this in other ReactorSensors, or with other groups in this sensor (carefully grouped!), to turn your lights on and off at the right times.

1 Like

I’ve implemented the above - now we wait :slight_smile:

1 Like

This hasn’t been doing too well in my testing. Now that we’re past 10/31 I’ve been picking at this a bit.

Using TOOLS I’ve been trying to simulate tripping this device and it only shows ‘tripped’ specifically on Nov 28 (which is Thanksgiving and expected.) If I change the test date to 11/29 the device goes untripped again.

Please post a Logic Summary from the same-named link on the Tools page.

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.4 config 19226 cdata 19082 ui 19237 pluginDevice 160
    System: Vera version 1.7.4454 on Sercomm G550; loadtime 1573387821; systemReady 1573387844; Lua 5.1; JSON dkjson 1.2
Local time: 2019-11-10T11:40:28-0500; DST=0; South Carolina United States
House mode: plugin 1; system 1; tracking on
  Sun data: { "stamp": 2019314, "civdawn": 1573384792, "nautdawn": 1573383018, "sunset": 1573424532, "nautdusk": 1573427862, "latitude": 32.94709, "astrodusk": 1573429610, "longitude": -80.01376, "civdusk": 1573426088, "astrodawn": 1573381270, "sunrise": 1573386349 }
  Geofence: not running
     Power: utility, battery level 95
====================================================================================================================================
FOH Xmas - Season (#169)
    Version 19082.36 11/10/19 10:12:44
    Message/status: Not tripped
    Condition group "Christmas lights, Front of House" (AND)  false as of 12-10.09:28:00 <root>
      &-F-group "Start in November" (AND)  for ge 86400s; latching false as of 12-10.09:28:00 <grpinje5si>
      |     &-F-weekday { "id": "condinjeh69", "type": "weekday", "value": "5", "operator": "4" } [6 => 1 at 10:16:19; F/F as of 11-29.20:10:00/11-29.20:10:00] <condinjeh69>
      |     &-T-trange bet ,11,1,0,0,,11,30,23,55 [1575076200 => 1573398979 at 10:16:19; T/T as of 11-30.20:10:00/11-30.20:10:00] <condio77rdk>
      &-F-group "The whole season" (AND)  false as of 10:16:19 <grpio77888>
      |     &-T-trange bet ,11,1,0,0,,1,8,0,0 [1575076200 => 1573398979 at 10:16:19; T/T as of 12-10.09:28:00/12-10.09:28:00] <condio76b80>
      |     &-F-sun after sunset+0, [1575076200 => 1573398979 at 10:16:19; F/F as of 10:16:19/10:16:19] <condio79map>
    Activity grphtd501r.false
        Device Fountain (4) (46) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="0" )
    Activity grphtd501r.true
        Device Fountain (4) (46) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="1" )
    Events
        11/10/19 09:30:18 condchange: newState=true, cond=condio79map, oldState=false
        11/10/19 09:30:18 evalchange: newState=true, cond=condio79map, oldState=false
        11/10/19 09:30:18 condchange: newState=true, cond=grpio77888, oldState=false
        11/10/19 09:30:18 evalchange: newState=true, cond=grpio77888, oldState=false
        11/10/19 09:35:51 action: action=Restart
        11/10/19 09:35:51 start: 
        11/10/19 09:35:52 condchange: newState=true, cond=condio77rdk, oldState=false
        11/10/19 09:35:52 evalchange: newState=true, cond=condio77rdk, oldState=false
        11/10/19 09:36:52 action: action=Restart
        11/10/19 09:36:52 start: 
        11/10/19 09:36:53 condchange: newState=false, cond=condio77rdk, oldState=true
        11/10/19 09:36:53 evalchange: newState=false, cond=condio77rdk, oldState=true
        11/10/19 09:37:55 action: action=Restart
        11/10/19 09:37:55 start: 
        11/10/19 09:39:05 action: action=Restart
        11/10/19 09:39:05 start: 
        11/10/19 10:06:28 action: action=Trip
        11/10/19 10:06:28 sensorstate: state=true
        11/10/19 10:06:33 action: action=Restart
        11/10/19 10:06:33 start: 
        11/10/19 10:06:34 sensorstate: state=false
        11/10/19 10:10:26 action: action=Restart
        11/10/19 10:10:26 start: 
        11/10/19 10:10:27 condchange: newState=true, cond=condio77rdk, oldState=false
        11/10/19 10:10:27 evalchange: newState=true, cond=condio77rdk, oldState=false
        11/10/19 10:10:50 action: action=Restart
        11/10/19 10:10:50 start: 
        11/10/19 10:10:52 condchange: newState=false, cond=condio77rdk, oldState=true
        11/10/19 10:10:52 evalchange: newState=false, cond=condio77rdk, oldState=true
        11/10/19 10:12:44 configchange: 
        11/10/19 10:12:45 condchange: newState=true, cond=condio77rdk, oldState=false
        11/10/19 10:12:45 evalchange: newState=true, cond=condio77rdk, oldState=false
        11/10/19 10:12:59 action: action=Restart
        11/10/19 10:12:59 start: 
        11/10/19 10:13:31 action: action=Restart
        11/10/19 10:13:31 start: 
        11/10/19 10:13:32 condchange: newState=true, cond=condinjeh69, oldState=false
        11/10/19 10:13:32 evalchange: newState=true, cond=condinjeh69, oldState=false
        11/10/19 10:13:32 condchange: newState=true, cond=grpinje5si, oldState=false
        11/10/19 10:14:08 action: action=Restart
        11/10/19 10:14:08 start: 
        11/10/19 10:14:09 condchange: newState=false, cond=condinjeh69, oldState=true
        11/10/19 10:14:09 evalchange: newState=false, cond=condinjeh69, oldState=true
        11/10/19 10:14:09 condchange: newState=false, cond=grpinje5si, oldState=true
        11/10/19 10:16:18 action: action=Restart
        11/10/19 10:16:18 start: 
        11/10/19 10:16:19 condchange: newState=false, cond=condio79map, oldState=true
        11/10/19 10:16:19 evalchange: newState=false, cond=condio79map, oldState=true
        11/10/19 10:16:19 condchange: newState=false, cond=grpio77888, oldState=true
        11/10/19 10:16:19 evalchange: newState=false, cond=grpio77888, oldState=true

OK. This isn’t really set up the way I suggested, and what you have won’t work. The structure I gave you is critical for successful operation. Specifically, you’ve conflated two groups into one, and put both “sustained for” and “latching” on the same one group, which is incorrect. You’ve also put the Date/Time condition into a group and added another condition, which also modifies the logic incorrectly. Please go back and look at my post and restructure the logic as shown (with no additions).

If you want to add a sunrise/sunset condition to control the lights during the holiday season, for simplicity at the moment until you get more comfortable with how all of this hangs together, I would just make another ReactorSensor (they’re light weight) in which you test the state of this RS (tripped is true) AND after sunset (so your sunset test goes there).

That’s what I get for doing this in bits/pieces instead of dedicating some time to it, uninterrupted. I completely missed the second level, too, in addition to the mistakes you noted. AND I had the sunset/sunrise condition in the device calling this one…

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.4 config 19226 cdata 19082 ui 19237 pluginDevice 160
    System: Vera version 1.7.4454 on Sercomm G550; loadtime 1573470050; systemReady 1573470071; Lua 5.1; JSON dkjson 1.2
Local time: 2019-11-11T08:43:56-0500; DST=0; South Carolina United States
House mode: plugin 1; system 1; tracking on
  Sun data: { "stamp": 2019315, "civdawn": 1573471244, "nautdawn": 1573469468, "sunset": 1573510891, "nautdusk": 1573514227, "latitude": 32.94709, "astrodusk": 1573515977, "longitude": -80.01376, "civdusk": 1573512451, "astrodawn": 1573467718, "sunrise": 1573472804 }
  Geofence: not running
     Power: utility, battery level 100
====================================================================================================================================
FOH Xmas - Season (#169)
    Version 19082.41 11/11/19 08:43:06
    Message/status: Not tripped
    Condition group "Christmas lights, Front of House" (AND)  false as of 12-10.09:28:00 <root>
      &-F-group "Xmas season" (AND)  for ge 86400s false as of 08:39:03 <grpkaoi7t5>
      |     &-F-group "Start in November" (AND) ; latching false as of 12-10.09:28:00 <grpinje5si>
      |     |     &-F-weekday { "id": "condinjeh69", "type": "weekday", "value": "5", "operator": "4" } [1 => 2 at 00:00:00; F/F as of 11-29.20:10:00/11-29.20:10:00] <condinjeh69>
      |     |     &-T-trange bet ,11,1,0,0,,11,30,0,0 [1573479666 => 1573479787 at 08:43:07; T/T as of 11-30.20:10:00/11-30.20:10:00] <condio77rdk>
      |     &-T-group "And the rest" (AND)  TRUE as of 08:36:28 <grpio77888>
      |     |     &-T-trange bet ,11,1,0,0,,1,8,0,0 [1573479666 => 1573479787 at 08:43:07; T/T as of 12-10.09:28:00/12-10.09:28:00] <condio76b80>
    Activity grphtd501r.false
        Device Fountain (4) (46) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="0" )
    Activity grphtd501r.true
        Device Fountain (4) (46) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="1" )
    Events
        11/11/19 06:01:06 reload: notice=Luup reload
        11/11/19 06:01:06 start: 
        11/11/19 08:36:27 configchange: 
        11/11/19 08:36:28 condchange: newState=true, cond=grpio77888, oldState=false
        11/11/19 08:36:28 evalchange: newState=true, cond=grpio77888, oldState=false
        11/11/19 08:39:02 configchange: 
        11/11/19 08:39:03 condchange: newState=false, cond=grpkaoi7t5
        11/11/19 08:39:03 evalchange: newState=false, cond=grpkaoi7t5
        11/11/19 08:40:45 configchange: 
        11/11/19 08:41:05 configchange: 
        11/11/19 08:43:06 configchange: 

This should be better.

Yessssss… this is looking much better! It’s going to be difficult to test using the Test Date feature, because of the UI of that feature (auto-saves every change, so if you change the month then day then year, the RS sees three changes, two of which probably don’t make sense–I’ll improve on this for the next version). I’ve been testing this config in my own environment, and it’s working as expected.

Now, for your after sunset, you can do one of two things:

  1. As I previously suggested, put it into an RS of its own that tests this RS’s state with an “AND”;
  2. You can create a new subgroup in this RS (I’'ll call it “Xmas Lights On Front” just for illustration), directly under the root group (under “Christmas lights, Front…”), that contains your “after sunset” condition and a Group State condition that looks at “Xmas season” in “(this ReactorSensor)”. Then, add activities for this new group–“Xmas Lights On Front is TRUE” and “(same) is FALSE”–to turn the lights on and off respectively. For clarity, the conditions would look like the screen grab below…

1 Like

I’d actually created a sep device to trigger from that one:

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.4 config 19226 cdata 19082 ui 19237 pluginDevice 160
    System: Vera version 1.7.4454 on Sercomm G550; loadtime 1573482714; systemReady 1573482735; Lua 5.1; JSON dkjson 1.2
Local time: 2019-11-11T09:59:15-0500; DST=0; South Carolina United States
House mode: plugin 1; system 1; tracking on
  Sun data: { "stamp": 2019315, "civdawn": 1573471244, "nautdawn": 1573469468, "sunset": 1573510891, "nautdusk": 1573514227, "latitude": 32.94709, "astrodusk": 1573515977, "longitude": -80.01376, "civdusk": 1573512451, "astrodawn": 1573467718, "sunrise": 1573472804 }
  Geofence: not running
     Power: utility, battery level 100
====================================================================================================================================
Xmas FOH ON/OFF (#172)
    Version 19082.20 11/11/19 08:58:01
    Message/status: Not tripped
    Condition group "Xmas FOH ON/OFF" (AND)  false as of 10:06:54 <root>
      &-F-grpstate FOH Xmas - Season (169) Tripped/Untripped (root) (root) istrue [false at 10:06:54; F/F as of 10:06:54/10:06:54] <condio7hlbx>
      &-F-sun bet sunset+0,sunset+360 [1573480682 => 1573482731 at 09:32:11; F/F as of 08:54:03/08:54:03] <condkap2ffm>
    Activity root.false
        Device Front porch lights (72) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="1" )
        Device Front porch lights (72) action urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget( newLoadlevelTarget="20" )
        Device FOH Wash (2) (42) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="0" )
    Activity root.true
        Device FOH Wash (2) (42) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="1" )
        Device Front porch lights (72) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="0" )
    Events
        11/11/19 09:32:10 reload: notice=Luup reload
        11/11/19 09:32:10 start: 

That works, too. Whatever your preference. :slight_smile:

So no lights tonight. I’m very curious why the latch says 22k+ seconds remaining. At 13:32:25 I see something about Luup reloading…

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.5develop-19330 config 19295 cdata 19305 ui 19330 pluginDevice 160
    System: Vera version 1.7.4834 (7.30) on Sercomm G550 ID 37 (Vera Secure); loadtime 1575052331; systemReady 1575052350; Lua 5.1; JSON dkjson 2.5+LPeg
Local time: 2019-11-29T18:37:28-0500; DST=0; Hanahan, South Carolina United States; formats %m/%d/%Y %H:%M:%S
House mode: plugin 1; system 1; tracking on
  Sun data: {"stamp":2019333,"civdawn":1575027376,"nautdawn":1575025552,"sunset":1575065631,"nautdusk":1575069068,"latitude":32.94709,"astrodusk":1575070854,"longitude":-80.01376,"civdusk":1575067243,"astrodawn":1575023765,"sunrise":1575028988}
  Geofence: not running
====================================================================================================================================
FOH Xmas - Season (#169)
    Version 19082.41 11/11/19 08:43:06
    Message/status: Not tripped
    Condition group "Christmas lights, Front of House" (AND)  false as of 12-10.09:28:00 <root>
      &-F-group "Xmas season" (AND)  for ge 86400s false as of 11-11.08:39:03 <grpkaoi7t5>
      |     &-T-group "Start in November" (AND) ; latching TRUE as of 19:46:00 <grpinje5si>
      |     |     &-F-weekday {"id":"condinjeh69","type":"weekday","value":"5","operator":"4"} [5 => 6 at 00:00:00; F/F as of 00:00:00/00:00:00] <condinjeh69>
      |     |     &-T-trange bet ,11,1,0,0,,11,30,0,0 [1575014726 => 1575052347 at 13:32:27; T/T as of 19:46:00/19:46:00] <condio77rdk>
      |     &-T-group "And the rest" (AND)  TRUE as of 11-11.08:36:28 <grpio77888>
      |     |     &-T-trange bet ,11,1,0,0,,1,8,0,0 [1575014726 => 1575052347 at 13:32:27; T/T as of 12-10.09:28:00/12-10.09:28:00] <condio76b80>
    Activity grphtd501r.false
        Device Fountain (4) (46) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="0" )
    Activity grphtd501r.true
        Device Fountain (4) (46) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="1" )
    Events
        2019-11-29 13:32:25: Reactor startup (Luup reload)
        2019-11-29 13:32:26: Starting (Luup Startup/Reload)
        2019-11-29 13:32:27: Group Start in November latched true; no change to evalstate
        2019-11-29 13:32:27: Group Xmas season holding evaluation state for check that duration >= 86400 (22413 to go)

No idea. I kept my test configuration, and it worked perfectly. Did you perhaps enable/disable or restart at any point after midnight yesterday (Thanksgiving day)? Edit the config? It looks like it got played with around 7:46pm last night. That may have disrupted it. But it appears it is still armed, nonetheless, to turn on once the delay is expired, so leave it be, and it will catch up and should be good for the remainder of the season.

Here’s what mine looks like now:

And mine is as such:

I did not do a restart of the unit as I wasn’t home until late last night. I bounced my router which I would expect to be totally 1000% unrelated lol

My trigger scene is patiently waiting on the ‘season’ scene to catch up.

So - funny story. I’d emailed Support over why (after the FW update) things were stupid slow and always showing “busy” in the mobile app, Alexa/Google latency, etc. They replied tonight "reset network by pressing reset 3x in :06.

I did so.

Xmas lights are all on LOL

We’ll see how the rest of it is responding but I found that rather… odd.