Seems not correct calculation for sunrise/sunset

Hi, I’ve decice to take advance of the auto-turn-on/off by the timezone/latitude, unfortunately these is not MSK time in the zone choice so I’ve used GMT and added 10800 seconds (3 hours), anyway the sunrise and sunset seem one hour later… 8:59 and 17:29 seems the correct ones.
How can I fix it? Thanks


Another question, how can I activate effect according to these times? I?ve put this to 1 but nothing is happening

Are you using anything below 0.13-b3?
If yes, upgrade to 0.13-b6.

I have 13b6, thanks for help

I have simply pressed “save” now with the same data and it corrected to the right values, 8:59 and 17:29. I don’t now what went wrong.
I still don’t understand now how to take advance of it, how to turn on the effect and turn it off daily

Create 2 presets, one for the effect (include brightness) and another one for off (you can enter T=0 into API field).
Then assign those presets in Time & Macro settings page.

Thanks, but where exaclty? I see only “Timed-Light-Over Presets”, what to write there? Preset of the desidered effect or the “off” preset? And where inster the opposite one?
When this is done, it starts immediatly? or I need to set somthing else/turn on wled?

Screenshot 2022-02-07 at 16.15.07

thanks again, but I don’t want to specify a time, I want that it uses the caluclated sunrise and sunset to turn it on/off. how can I do it?

Sunrise/set is below that on the page. :wink:

somthing is wrong here, for me:

it’s not auto complete, led doesn’t turn on.
If I’ve to put the values manually then this function is useless for me, I?m living in north europe, on summer we have white nights, every day the difference can be up to 10 minutes.
There is no way to tel ESP to automatically change the time, each day?

The general idea with Sunrise/Sunset events is to use the last two entries under “Time-controlled presets” to activate a preset at Sunrise/set offset by +/- some minutes. Normally you’d use a “lights on” Preset at sunset +15mins (my preference) and a “lights off” Preset at sunrise -15mins. I use this in many instances, it works very well.

The actual Sunrise/set times are calculated dynamically by WLED based on entered Lat/Lon and corrected for UTC offset/time zone. Time of day is updated via NTP so the daily sun times can be adjusted on the fly. Your page shows what seems to be the correct Rise/Set times for your Lat/Lon. You just need to enter the correct Presets in the lower “Time-controlled presets” section.

Sorry mates, I can’t figure out how it works, I’ve set 10 and 20 minutes in the hope it delays the time when to turn on preset 1 or preset 2, here nothing happens.
Should I turn on manually? I do but it doesn’t switch to any of those presets
What about if the power is mirring and restore? Will it understand the time and according select preset?

It works for me exactly as you have shown.
Per your example:
10 minutes after Sunrise time (shown at the top of that settings page) Preset 1 is activated.
20 minutes after Sunset time (shown at the top of that settings page) Preset 2 is activated.

One of the tricky parts of testing this stuff is you have to wait for each of these times to actually occur before they trigger. These triggers only happen once very 24Hrs so if you miss the time you wait til tomorrow or add large offsets to prove that they will trigger at a particular time.

I just noticed you had “Timed-Light-Over Presets:” set to 1, you’ll want to change that to 0 and make sure you’ve got the Timer (Night Light) turned off when you’re testing this as well. Start with very simple presets, no effects just to verify operation.

You might also want to pick an NTP pool in your region such as That will help make sure the onboard clock is accurate.

thank you, yes it worked, maybe before somrthing went wrong and didn’t switch on. Thank you for your kind help.

I would ask developers, if they are reading here, if they can implement the function to activate preset even if the trigger passed, based on actual time.
It would be helpful to others to comment sunrise and sunset below in a way that make it understand… we’re talking about delay from trigger

We do read.
But I am sorry to disappoint you, this cannot be easily implemented (too many factors to go wrong).

Thanks, It’s just necessary to introduce this setting:
“use always sunset preset till the sunrise” if at boot (ot better say at NTP update) we’re within that time., please double it for sunrise.
I would proceed like this:
At boot reset variable “sunset” and variable “sunrise”
Any time NTP is updating check those variables, if they are reset and on settings it’s checked “use always XXX preset till the YYY” then activate that preset and set this variable.
On next NTP the variable is already active, don’t need to do anything.
The next trigger, opposite one (sunset or sunrise), will switch the preset, set the according variable and reset the other.

This way I can be sure any error income, any blackout, the system wll boot and work again.

While I can understand your desire to try and maintain the lighting settings based on Sun Rise/Set throughout the day, @ Blazoncek has a much better handle on the downsides. This type of feature will rapidly get outside the scope of what WLED does best.

There are many options (and much better tools) to handle the scenarios you’re describing with interfaces like Home Assistant.

You could of course create a fork and usermod if you wish to try and code something yourself.

1 Like

timed presets trigger at specified time, not at every millisecond after that time.

As @divsys says, you can try to code that yourself by forking WLED. The relevant code is in ntp.cpp.

As I suggested the control shuld not be at any millisecond, it’s enough when it gets update from NTP, the first update only. This is very simple code to add and it occours only after reboot. For the rest of operations, it doesn’t affect them, please think about it, it’s really useful in case the power turns off. Thank you

What if NTP updates happen every n-minutes? Your preset would be triggered at each update.
As I said: It will not be implemented but you can fork and create such modification for your particular use. Relevant code is in ntp.cpp.