Daylight Savings Time

#1

So I have noticed that every time daylight savings time changes, all my timed pistons run either 1 hour early or 1 hour late depending on if daylight savings time is starting or ending. I understand this is simply due to the fact that my timers are setup before the change. My question is how do I get thru a daylight savings time change over without having any issues, is this possible?

Right now I either have to wait for the piston to run once and then the correct time is set or I have to go into the piston and hit edit and then save so it sees the new time. How can I get thru the time change without a manual intervention or have the 1st run of the pistons run on the correct time? Any ideas?

#2

I believe people have had success setting up a trigger for 2:01am to adjust the timings for any piston that would be affected. For example, an if statement at the bottom of the piston with the time happens at trigger, or a timer. Just something to wake up the piston after the time change and update the schedules.

#3

I am currently using two different methods to end having to manually pause and restart each affected piston after DST <> EST (for me) changeovers. Both methods seem to work. I haven’t settled on which is better so I currently have both methods running. Each takes a somewhat different approach.

Method One pauses each timed piston and then restarts it so that it recalculates next-run times based on the changed time:

download
download.png1178×1677 275 KB

Method Two uses a NO OPeration task embedded into each desired piston. When the circled portion of this piston runs, it also causes the piston to recalculate the next-run times based on the updated time:

download
download.png1178×1192 66.6 KB

Hope this helps!

#4

If you don’t do anything, it auto-corrects the next day, right? I don’t have anything that critical that I can’t handle two days a year being off by an hour.

#5

Yes. Anything that makes the affected piston run after the time changeover will cause the piston to recalculate and then use the recently updated time. So, next day runs should be correct.

Although most of my pistons are not ‘critical’, I do have several that would be inconvenient - like morning thermostat set point changes, if not corrected in time would come on too early or too late. Likewise, I have some motion pistons that would turn on the bedroom lights 1 hour too early - or one hour too late. Critical? Probably not. Inconvenient? I’d say so.

#6

I’m using what I believe is the first version of above. It appears, for the most part, so have paused all the pistons I needed paused, but for some reason it didn’t resume them. Trying to figure out what’s wrong.

Here’s some of the errors I received, but they appear to be for the pausing part, which seems to have worked ok:

3/8/2020, 4:11:08 AM +182ms
+10297ms ║Piston waited at a semaphore for 10123ms
3/8/2020, 4:11:02 AM +990ms
+2601ms ║Piston waited at a semaphore for 2507ms
3/8/2020, 4:11:01 AM +238ms
+4364ms ║Piston waited at a semaphore for 4261ms
+7538ms ║Error executing virtual command [].pausePiston: (167ms) java.lang.NullPointerException: Cannot get property ‘logging’ on null object
3/8/2020, 4:11:03 AM +788ms
+1881ms ║Piston waited at a semaphore for 1756ms
3/8/2020, 4:10:51 AM +426ms
+3862ms ║Piston waited at a semaphore for 3758ms
3/8/2020, 4:10:52 AM +912ms
+2361ms ║Piston waited at a semaphore for 2257ms
+15860ms ║Error executing virtual command [].pausePiston: (176ms) java.lang.NullPointerException: Cannot get property ‘logging’ on null object

Here’s the transition between the paused and resume, maybe this is where the issue is?

49%20AM
Screen Shot 2020-03-08 at 8.32.49 AM.png775×96 38.5 KB

#7

The only thing I can say is that I have a 10 second pause after every 6-7 pistons - both during the pause and resume sections. I also have a 1 minute pause after all pistons have been paused and before I then start the resume section. I remember in testing that without both of those types and lengths pauses, things didn’t work reliably.

#8

To embellish a bit to @lflorack’s post…

Personally, I would add a 1-2 second WAIT between each and every PAUSE… and
I would add at least 3 seconds WAIT between each and every RESUME. (a lot happens when a piston first turns on)

#9

Alternatively instead of pausing and resuming pistons, you can just wait for a day to pass and the DST thing will fix itself.

#10

This is true. Waiting a day will likely fix things. However, events such as having the heat not come on ahead of waking up or lights coming on too early, etc. - are inconvenient and relatively easily avoidable with a minor amount of effort.

#11

Thanks for all the input. I didn’t realize that after a day, everything resumes the way it should, but I agree with lflorack in having everything work without having to wait a day.

#12

Yeah, I just slept in too long because my blinds were still closed and I thought it was still too early to get up, LOL. I guess I’ll set a pause/wake piston to fix the DST issue. Thanks for the ideas.

#13

See also:

Having multiple every blocks in a piston can have what seems to be strange timer updates…