Hello,
I did a search on this and couldn't find a definitive answer.
I have several start schedules setup that rely on the built-in sunset option. I noticed that all of my schedules did not respect the new time change today and were still on the DST time.
Rebooting the hub didn't work.
I ended up having to pause and resume the respective pistons and only then did the proper time recalculation happened.
Version:
Example:
Please advise, thanks.
CC'ing: @nh.schottfam
I don’t believe this issue has ever been resolved. When I started using Webcore back with SmartThings, I remember a suggestion was to setup a piston that pauses all the pistons with dates and times to pause just before the time change, then a few minutes later to resume them. I also remember reading that it would resolve itself the next day.
Another reason to finally end this tradition of messing with the time twice a year. I personally prefer daylight savings time but would accept standard time if it never changed again. Ugh!
I remember this on Smartthings too. My blinds (based on sunrise/sunset) were an hour off this morning. No big deal, really. I'm leaving it go until tomorrow. But what if it was something different?
Same here. I'm in another country for 5 weeks and my neighbor just texted me that none of my exterior lights were one. Why is this such a difficult concept? I thought I had left this kind of nonsense behind when I left SmartThings when they abandoned WebCoRE. Did no one at HE think to look at this before today?
It would really help to have full logs for this. (of course after the fact this is difficult/impossible).
It is hard to test these code paths that only execute twice a year, and it is hard to force a test.
If anyone as full logs for the day before, day of dst change, and day after, would appreciate it....
Hi @nh.schottfam,
Thanks for responding. I can provide logging the day after the DST change occurred.
My question is when or what is the methodology for re-calculating 'Next Scheduled' (see screen below) ? It looks like webCoRE has a built-in variable called $nextSunset to look ahead.
In my example, my piston completes at 10:05pm every night. Does the re-calculation or 'Next Scheduled' happen after the piston fully completes? If that's the case (or even if it was not the case), and webCoRE has the data it needs, why did the re-calculation not respect the new non-DST sunset time?
I also see some other built-in variables that seem to be aware of DST: $zoneInDst, $tzInDst. Just trying to better understand with hopes this can be fixed. Thanks.
Hi @nh.schottfam,
Here are the logs as requested:
11/6/2023, 10:05:00 PM +172ms
+7ms ╔Received event [Home].time = 1699337100000 with a delay of 172ms, canQueue: true, calledMyself: false
+22ms ║RunTime initialize > 21 LockT > 1ms > r9T > 3ms > pistonT > 1ms (first state access 7 m:17 9 12)
+30ms ║Runtime (6889 bytes) initialized in 3ms (v0.3.114.20231008_HE)
+47ms ║╔Execution stage started
+101ms ║║scheduleTimer Requesting every schedule wake up at Tue, Nov 7 2023 @ 10:05:00 PM PST (in 86399729ms) for 9 (st:-1)
+188ms ║║Executed device command [Light: Front Porch].off() (79ms)
+191ms ║║Exiting piston at end of Every timer block
+202ms ║╚Execution stage complete. (155ms)
+341ms ║Setting up scheduled job for Tue, Nov 7 2023 @ 5:08:00 PM PST (in 68579612ms),with 2 more jobs pending
+346ms ╚Event processed successfully (340ms)
11/6/2023, 8:30:00 PM +316ms
+15ms ╔Received event [Home].time = 1699331400000 with a delay of 316ms, canQueue: true, calledMyself: false
+48ms ║RunTime initialize > 47 LockT > 11ms > r9T > 13ms > pistonT > 0ms (first state access 8 m:23 26 21)
+56ms ║Runtime (6892 bytes) initialized in 13ms (v0.3.114.20231008_HE)
+87ms ║╔Execution stage started
+130ms ║║scheduleTimer Requesting every schedule wake up at Tue, Nov 7 2023 @ 8:30:00 PM PST (in 86399556ms) for 6 (st:-1)
+140ms ║║Command optimization: Skipped execution of device command [Light: Back Porch].off() because it would make no change to the device. (1ms)
+142ms ║║Exiting piston at end of Every timer block
+167ms ║╚Execution stage complete. (79ms)
+372ms ║Setting up scheduled job for Mon, Nov 6 2023 @ 10:05:00 PM PST (in 5699489ms),with 2 more jobs pending
+423ms ╚Event processed successfully (410ms)
11/6/2023, 5:09:00 PM +33ms
+20ms ╔Received event [Home].time = 1699319340000 with a delay of 33ms, canQueue: true, calledMyself: false
+105ms ║RunTime initialize > 103 LockT > 2ms > r9T > 81ms > pistonT > 78ms (first state access 7 m:20 22 81)
+119ms ║Runtime (6812 bytes) initialized in 81ms (v0.3.114.20231008_HE)
+135ms ║╔Execution stage started
+193ms ║║scheduleTimer Requesting every schedule wake up at Tue, Nov 7 2023 @ 5:08:00 PM PST (in 86339775ms) for 1 (st:-1)
+355ms ║║Executed device command [Light: Front Porch].setLevel(100) (150ms)
+422ms ║║Executed device command [Light: Back Porch].setLevel(60) (58ms)
+425ms ║║Exiting piston at end of Every timer block
+433ms ║╚Execution stage complete. (298ms)
+561ms ║Setting up scheduled job for Mon, Nov 6 2023 @ 8:30:00 PM PST (in 12059523ms),with 2 more jobs pending
+579ms ╚Event processed successfully (560ms)
The way every works is that when an every statement evaluates true, it evaluates the next time it should run and schedules it then.
Hence you see in the logs only one every statement being scheduled, while your piston has 3 every statements in it.
So on the day before the dst change, when the every statement with sunset in it runs, it evaluates the next time it should run. It seems to be this evaluation that is not doing the right thing. This is the one I wish I had detailed logs for. It is hard to test of course as DST changes only happen twice a year.....
I will have to try to setup a test to run for the next dst change to see what is going on. For the most part I have these fixed. for the offset you are using, what is the value of that? I expect there is some issue happening in the dst change and offset calculation....
@nh.schottfam ...
Thanks for looking into this and the explanation, appreciate it.
The value I'm using for the offset is 13 minutes after sunset.
Download the Hubitat app
