Sunrise/sunset times stuck since Jan 22, 2021

Hi, I noticed that my lights were turning on too early in the evening and staying on too late in the morning. Turns out the sunset and sunrise times I use in my automations have been stuck at 5:51pm and 7:29am since Jan 22.

This is defeating all the automations that use sunrise/sunset time. I already tried changing my address to a different one and then setting it back.

Has anyone else experienced this? How can I fix this?

It is a known issue. Pending a fix you can mitigate it by saving affected Automations again every few days (whenever you feel the deviation from the correct timing is getting too large). I find adding a space to the end of the name works well as it allows the Automation to be saved but the space won’t be there next time you edit.

1 Like

Hi, is this just impacting ST app Automations? Seems like my Smart Lighting automations are working, and shifting a minute every day. Webcore I’m guessing does its own calculations.

1 Like

@orangebucket thanks – this was working correctly for months, are you saying this bug was introduced recently?

@glenmm in my case I am using ST app automations.

I noticed this also, ST support told me it was a known issue and to rebuild the automation. I switched to a SmartLighting routine (or whatever it’s called there now).

1 Like

Thank you. It took me forever to post this question on the forum, I’m so glad I did. I just switched my lighting automations to the smart app that you suggested, they are pretty nice actually, fingers crossed that they work without an issue.

I’d imagine Smart Lighting might use the events sent out by the Weather Station app (events at Sunrise and Sunset, and events with the next day’s times after Sunset), but if not it uses the function calls in the legacy library/API. Or both.

No, it uses the legacy library/API too, though only updates the times every few hours. Pistons do their own scheduling, so how accurate they are depends on when they last ran. At certain times of year some ‘sunrise’ pistons may be fired twice because they fire at the previous day’s sunrise time and then immediately reschedule for the current day. You’ll often see pistons written to fire during the night before it can possibly be sunrise but when the new times should be available, just to reschedule and avoid this. The same can happen with ‘sunset’ pistons too - it depends on what other times of day they run.

I mention all that just to illustrate this isn’t as trivial as it might seem.

The description I’ve seen is that Automations only used to reschedule Sunrise and Sunset timers when they’d drifted from the actual times by a certain amount. Indeed I seem to remember seeing that behaviour. I am sure they have reasons for this. I can’t think in terms of tens of thousands of users to appreciate them. Anyway this rescheduling hasn’t been happening.

My sunrise/sunset stuff is all in Smart Lighting and I’ve only really noticed reports of the problem with Automations in the last month or so. Naturally that makes me wonder if the switch to using the Rules API was a factor. I can imagine how it could be. Pure speculation though.

1 Like

The short update:
I was able to move out of the Smart Lighting App and go back to the stock automation rules for lights that need sunrise/sunset time. This means that now it is possible to have local processing rules that use sunrise/sunset.

The long update:
I noticed after the SmartThings Edge rollout that some of my non sunrise/sunset lighting automations were marked as local processing with the little :houses: icon. So I decided to switch my sunrise/sunset lighting automations back to directly use simple automations and deleted the Smart Lighting App.

After a a few days I noticed that my old issue with my simple automation rules not getting updated sunrise/sunset times. After running into this thread I logged into the Groovy IDE and checked under My location > My home > List SmartApps and noticed I did not have the Weather Station app. To resolve this I added the SmartLighting App to my automations, but did not put any rules in it. This caused the Weather Station app to show up under My location > My home > List SmartApps under the SmartLighting App. This also caused the hub to start tracking sunrise/sunset times correctly, and my plain vanilla rules started getting the correct sunrise/sunset times!

So now I have local processing using simple automation rules for my lighting rules which use sunrise/sunset.

I have been having this problem with Rules for quite some time now - I detected it in early September and it would have been happening for a while before that. It is still an ongoing problem and I am pretty fed up about it.

I am seeing it in cloud based Rules and as I can update the Rules and the times will update it isn’t a case that the correct sunrise and sunset times aren’t known, it is just that the Rules aren’t using them.

I am a bit surprised that the Weather Station makes any difference. I don’t have it running any more so the sunrise/sunset times shown in the IDE are stuck, but the Rules aren’t using those times.

That reminds me, probably time to update some Rules …

1 Like

I may be wrong but I believe I have seen @Brad_ST post a few times that the weather part in IDE is no longer being used. So it would have no effect on automations/routines by installing it.

1 Like

There hasn’t been a ST Edge rollout. v2 and v3 hubs are capable of running Edge drivers but you would have had to have manually changed your devices to use an Edge driver.

Also as noted above, Weather Station only impacts Smart Lighting automations and has no impact on automations created with the If/Then custom routine builder.

1 Like

Brad, by the “SmartThings Edge rollout” I was referring to the software update some months ago that allowed certain rules to run locally. Clearly I am missing a nuance here, is it not correct that my if/then rules were running on the cloud (and did not support local processing) prior to the rollout of the “Edge changes”?

I did not manually change my devices to use an Edge driver, the devices are Z-wave light switches. After I opening and re-saving the if/then rules that controlled these Z-wave switches they now have the little “home” icon (presumably indicating they can running locally).

Thanks for that information. I could try again removing the Weather Station app to see if it breaks my if/then rules. I have a ST Hub v3 btw.

To circle back on this, @jkp you were right about the weather station in the IDE not affecting automations. Sometime after @Brad_ST confirmed it I removed the weather station in the IDE and the sunrise/sunset lights continued turning on/off for several weeks. I have noticed that the exact turn on/off is sometimes missed from anywhere from 5 to 15 minutes, but this is not an issue for me.

P.S. Unrelated to this my hub has been disconnecting from Wi-Fi very frequently over the last few weeks, now that sunrise/sunset on/off now works locally even when the hub is disconnected has been has been really helpful.

P.P.S. My hub Wi-Fi disconnect issue started a few months ago with a frequency of once every few weeks, and in the last some weeks became once every some hours, and stayed mostly disconnected until it decides to reconnect for a few hours and then disconnect again. About 2 weeks ago I even stopped rebooting the hub which would cause it to reconnect.

About 4 days ago it self-reconnected and a little bafflingly has stayed connected since. No config changes whatsoever in weeks.