Use Sunrise/Sunset for scheduler

[tripplet]

Hi,

It would be nice to have an option for the scheduler component based on sunrise/sunset with an additional offset like sunset +30 minutes.
Based on a quick search it should be possible to calculate sunrise/sunset in C++ with minimal code, stackoverlow example.

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
The user enters the gps coordinates or maybe espurna uses the location api of the browser to allow additional scheduler options based on sunrise/sunset with an offset.
The precision of the gps does not need to be super accurate,

Describe alternatives you've considered
A possible alternative is to use homeassistant or another external component and trigger the switch via mqtt. But it would be nice for standalone solutions without external home automation components.

Thanks

[tripplet]

I just read that the geo location API might only be available via HTTPS which is not the case for espurna, manual entry seems like the only option.

[mcspr]

Also see #1263, #943 and #412

Specific to this issue, idk if code actually does the correct thing. Given:

double latitude { 55.752546226498275 };
double longitude { 37.61737956002365 };

float localT = calculateSunrise(2021, 1, 17, latitude, longitude, 0, 0);

Output is:

5:48

Which is correct for the specified date (UTC, idk if it actually needs the correct 'timezone offset' for the coordinates), but swapping for the setting alternative (see comments), it does not work as well and shows 9:44 as sunset

I'll try to implement wikipedia page at least locally.
There is also https://www.esrl.noaa.gov/gmd/grad/solcalc/index.html and https://www.esrl.noaa.gov/gmd/grad/solcalc/calcdetails.html, but one would need to unroll that giant table-cell formulas chain (or see the pdf example, but I am pretty sure the wikipedia page describes the same approach)

[tripplet]

Another alternative would be the Arduino library SunRise, which seems to work fine in a quick test.
It definitely needs an utc-offset.
The only problem seems to that it doesn't take daylight saving time into account, at least I couldn't find anything related in the code.

[mcspr]

c:/users/maxim/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/10.2.0/../../../../xtensa-lx106-elf/bin/ld.exe: c:/users/maxim/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/10.2.0/../../../../xtensa-lx106-elf/lib\libm.a(lib_a-w_remainder.o):(.literal+0x0): undefined reference to `__ieee754_remainder'
c:/users/maxim/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/10.2.0/../../../../xtensa-lx106-elf/bin/ld.exe: c:/users/maxim/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/10.2.0/../../../../xtensa-lx106-elf/lib\libm.a(lib_a-w_remainder.o): in function `remainder':
/workdir/repo/newlib/newlib/libm/math/w_remainder.c:60: undefined reference to `__ieee754_remainder'

It does work with current (2.7.4) gcc-4.8.2 toolchain, std::remainder(a, b) does not work with the new one though.
(and I don't remember using it with the table one... still not finished though, sry)

[mcspr]

On topic, it matches the real (Google, same lat / long as above) values with -1 minute diff

sunrise
now: 1611793083
rise: 2021-01-28 08:30:20 // including TZ for the location, simply ntpDateTime(sunrise.riseTime)
set: 2021-01-27 16:53:10 // ... i guess implementation detail?

[brunetton]

Any new on this? I'd really need it! (for now I'm manually editing my schedlings every months or so to adjust opening and closing times for my roller shutter)
Thanks a lot

[mcspr]

Just a lack of time and focus on the issue. iirc, library above has the 'shortest' algorithm (loc wise :)
The idea is still to not re-write the schedule, but to create a new event type that will replace the time of day one.

Also see https://github.com/mfreeborn/heliocron

[brunetton]

Are you open to contributions for this point ? Thanks

[mcspr]

@brunetton Sure

[tripplet]

Alternativ you could have a look at ESPHome, which I have been using:
https://esphome.io/components/sun.html

Implementation here:
https://github.com/esphome/esphome/blob/dev/esphome/components/sun/sun.cpp

[mcspr]

Alternativ you could have a look at ESPHome, which I have been using: https://esphome.io/components/sun.html

Implementation here: https://github.com/esphome/esphome/blob/dev/esphome/components/sun/sun.cpp

thanks for link, I do remember looking at that too but forgot to include some reference here

ESPTime local_event_(ESPTime date, int hour) const {
// input date should be in UTC, and hour/minute/second fields 0

this also reminds me of the mistake I made originally w/ SunRise, since that one definitely does not try to 'stabilize' the input timestamp and can't be expected to return the same value during the day

[mcspr]

The idea is still to not re-write the schedule, but to create a new event type that will replace the time of day one.

btw I have scrapped that idea and just rewritten the scheduler based on systemd calendar spec. Sunrise/Sunset calc is disabled in default build, but added through SCHEDULER_SUN_SUPPORT flag. Time specified would look something like this for weekend sunrise action

schTime0 => "Sat,Sun Sunrise"

sry @brunetton if you intended to work on this (or used the original scheduler types, events, etc.) :)

Since it is a pretty big slab of code all at once, have to test it a bit more before building the .bin
Mind the size increase as well and missing documentation. WebUI also missing, only build flags or manually setting schLat (latitude), schLong (longitude) and schAlt (altitude)

Calc is taken from https://en.wikipedia.org/wiki/Sunrise_equation#Complete_calculation_on_Earth, but as implemented in https://github.com/nathan-osman/go-sunrise (since it included code tests and saved me the work on those as well)

For time strings, test/unit/src/scheduler/scheduler.cpp should give a general idea. At least for now.
Or, referencing systemd docs (base cases at least, not everything is the same for last-day-of-week, etc.)
https://www.freedesktop.org/software/systemd/man/latest/systemd.time.html#Calendar%20Events

[brunetton]

No problem, I didn't took time to solve this problem for now. Very happy to see that something is being started :) Can't wait to use it from UI ! Thank you ! Le jeu. 16 mai 2024 à 00:45, Max Prokhorov ***@***.***> a écrit :

…

The idea is still to not re-write the schedule, but to create a new event type that will replace the time of day one. btw I have scrapped that idea and just rewritten the scheduler based on systemd calendar spec. Disabled in default build, but added through SCHEDULER_SUN_SUPPORT flag. Time specified would look something like this for weekend sunrise action schTime0 => Sat,Sun Sunrise sry @brunetton <https://github.com/brunetton> if you intended to work on this (or used the original scheduler types, events, etc.) :) Since it is a pretty big slap of code all at once, have to test it a bit more before building the .bin Mind the size increase as well and missing documentation. WebUI also missing, only build or manually setting schLat (latitude), schLong (longitude) and schAlt (altitude) test/unit/src/scheduler/scheduler.cpp <https://github.com/xoseperez/espurna/blob/dev/code/test/unit/src/scheduler/scheduler.cpp> strings should give a general idea, though. Or, referencing systemd docs (base cases at least, not everything is the same for last-day-of-week, etc.) https://www.freedesktop.org/software/systemd/man/latest/systemd.time.html#Calendar%20Events — Reply to this email directly, view it on GitHub <#2417 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAVCMXWPXMO3LXTMI37ZEDZCPQPHAVCNFSM4WF7U6K2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJRGM3DAMRYGIZA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mcspr]

Wiki updated, WebUI updated. Optional restore flag also taken into an account, looping back N days and N sunrises and sunsets to check.

Linked issues also describe offset for sunrise and sunset like 30min before, 1h after, etc., but pretty sure that would blow up the 'OnCalendar=...' time string chosen currently. Relative events like 'BOOT' maybe make sense to also add as a different type, but the list of such possible events does seem pretty short atm