Easier Way to set SunRise and Sunset on a yearly schedule

Use case: During the winter I want the "Day" mode to start at sunrise and the "Evening" mode to start approx. 15 minutes before Sunset. I also want the inverse for the summertime. My solution is to pick two dates (equinoxes) and pause/un-pause a pair of rules based on my requirements above. The rules I created are below. First, is there an easier way to do this?

Second (bonus question), is there a way to move the mode times easily during the year? For example, in April, the Sunrise would have an offset of "Sunrise-5 minutes" but in June it has an offset of "Sunrise -15 minutes." I could see doing this with several rules, but I can't get my head around a more elegant or simpler way.

47%20AM
40%20AM
00%20AM
46%20AM

1 Like

I use virtual switches for spring, summer autumn & winter (set with ‘scheduled switch”)
I control mode setting etc with reference to these switches

This works for me :slight_smile:

I wanted to accomplish something similar. I had a virtual switch turn on at sunset for my living room lamp I then want it to turn off at the later of two times, Sunset plus 90 mins or 9:30. Because in the summer, 9:30 is before sunset plus 90 minutes. I did it this way:

Triggers ;  Sunset +90 minutes and specific time 9:30.

Actions:
If First Pass if False:
    Then Turn off switch
    Set First pass to True
Else
    set first pass to True
END-IF

I had to create the local bool variable first pass but this has worked flawlessly to turn off that virtual switch through 3 shifts from one being first to the other.

I wanted to know if Sunset (that day) was earlier or later than 7pm. (I live in the Northern Hemisphere).
With Bruce's new time variables, and support in RM, it's easy-peasy.
I made up a global variable, and used it in a condition in a rule:
image
I think that you can use the same concept.

I put an old Aeotec MS6 outside with a clear outlet cover and use it to monitor the illuminance. It adjusts automatically and includes times when a storm comes by or things are particularly overcast in the late afternoon.

As an alternative to time, I've repurposed a Dome Motion Sensor (DMMS1) into a window inside facing outside and use low lux levels to trigger my new "cloudy" mode, which is basically a light version of my "evening mode," if lux drops below a certain level after a certain time and my Day mode is still active. I see someone above is using the Aeon Multi for something similar. I've only used that one indoors but seem to remember its lux readings being usable for this too. Unless it's USB-powered, however, I've had batteries die pretty quickly (just a couple months' life). The Zooz 4-in-1 does lux too, but the range is almost too narrow for me to use it for me to use it for this purpose. So depending on what your actual usage is, this alternative might work for you, too.

The other suggestions are certainly good as well! I might add something like that to mine and do it both ways. I recently created "season switches" for the purpose of automating my blinds differently throughout the year this seems like a good way to get even more use out of them! (And it's certainly a good idea with the desired offset generally needing to be longer in the summer due to the longer "transition times" of sunrise/sunset).

2 Likes

I use several of the suggestions above for other things. I'll add in a feature request to see if the offset can use a variable. So it would be "Sunset -%summertime%" I think that would do what I want.

You could use the Luxuriant driver that gets twilight/sunrise/sunset times from https://sunrise-sunset.org. (3 different twilight defs: The Different Types of Twilight, Dawn and Dusk). You could use the lux calcs from the driver as an alternative.

Or based on sun position calcs

1 Like

Yeah I use usb power and have it mounted above (and plugged into) an outdoor outlet - using same type of outlet cover for both. Has been working well in both the heat of summer and cold of winter. The cover messes with the motion detection but that was not a concern for this purpose.

It would probably be somewhat trivial to write an app that provide this data. Here are the equations for it, they are pretty simple:

I did the same with my old Zooiz mini motion sensor (same as the dome). Completely useless as motion sensor but not terrible at lux.

You can also just poll sunrise-sunset.org to get it, that's what I do.

I feel like my SunCalc driver would be perfect for this. Just determine the altitude you want things to trigger at and it will be consistent all year long. Since it's based on the position of the sun, the time is irrelevant and you don't have to worry about faster or slower sunsets/sunrises.

This like something I wanted to do. I like lamps to come on at about 6:30am and off at 8:00am, but it really only matters in the winter. Even now, in April, it's getting to be light enough in the morning that I don't need lamps to come on at all. So what I did was set a mode change at sunrise from Night to Day. Then I set up a rule to turn the lamps on at 6:30, but only if the mode is still Night.

On a side note... I found this thread because I am preparing for another issue. I have large east-facing windows in my living room, and the room gets very warm when the sun shines in. I'm in Minnesota, so this is a good thing in the Winter, but by mid-March it gets to be too much, even if the outside temp is in the 20s or 30s. I am planning to order some solar shades that have Z-Wave control built into them. When I get them, I want to have them automatically close at 10:30pm (when I already have a bunch of nighttime automations running) and stay closed until sometime around noon or 1:00pm when the sun has moved around to where it isn't shining directly in the windows. I was looking for a way to have this only run from sometime in March until sometime in September or October.

I set up a rule similar to what homeauto2112 has above, but in March it sets a variable called "Summer" to True, and in September it sets the variable to False. The shades will only close when "Summer" is False.