I have bunch of time-based pistons that got fouled up by DST and ran at the wrong time. I guess they actually ran at the right time but it was really the wrong time. 
This has happened previously when I was using WC on ST but I don’t remember what I did to correct the issue. All of our exterior lights shut off when it was still very dark and I don’t want that to happen again tomorrow. Will things just sort themselves out? Do I need to pause/resume all of my pistons.
I’d guess they should be ok tomorrow. You should be able to check by viewing the piston with a trace, and you should see a countdown timer on the left, next to your timed event.
Thanks, I had forgotten about that. I appears a pause/resume doesn’t fix things so I’ll do things manually today and hope things work as expected tomorrow.
I think the way it works is after it has been triggered it calculates the time for the next trigger. So if it triggers in the evening and then the clocks change in the early hours it will be out. I’m not sure if you edit & save the piston it might recalculate.
I remember it doing this on ST too, and am pretty sure it corrects after one day.
It would be good to see the piston and logs in question.
HE for me handled this properly, so would have to see what happened in your pistons.
I put this code at the top of each piston that could be affected by DST<>EST changeovers:
Note: {NoOpTime} is scheduled in a staggered manner for each of the pistons affected, from between 04:00 to 04:30.
All of my pistons fired as expected this morning.
I do need to see the pistons in question, and if there are still logs from yesterday.
I don’t expect an every statement to reschedule schedules for other statements (every statements only run the every block).
webCoRE on HE has code to adjust future time wakeups for DST changes. ie it is suppose to do the right thing. So I need to see the misbehaving piston to understand what happened.
All mine seem to adjust correctly (and automatically).
Interesting! I was doing the ‘Do Every’/NoOp statements when I was on SmartThings and it solved the DST changeover issue there. Assuming it was still required, I just carried it over when I moved to Hubitat last fall. Sorry for the misleading information. I guess I should now go back to my ‘affected’ pistons and remove the extra (and unneeded) code.
True enough! Maybe I’ll just remove the extra code whenever I need to make other changes. Removing code is easily done.
Along the same lines as the above and the potential for removing some unneeded code:
Several years ago while on SmartThings, I discovered an issue where seasonal-type ‘Do Every’ blocks that were scheduled for more than 25 days out caused the Piston to initiate every 3 seconds. This was completely repeatable and I brought it to the Minion’s attention. (Edit: Here’s the link to the original discussion thread.) As far as I know, it remained unresolved. So, I solved this by inserting an every-other-week ‘No Operation‘ task. It resolved this issue because there was never anything scheduled out more than 2 weeks and the code that ran seasonally continued to function too. The downside was that the 'countdown clock was no longer showing the actual time/date for the actual event - until it was within two weeks.
I hope that was understandable. If it was, is this still an issue on HE or can I remove the two-week "Do Every’ code?
Answering my own question, I took the plunge and removed the ‘Do Every’ code from one of my seasonal pistons. I let it run - or more accurately sit, for a few hours and it did that with no unexpected, repetitive looping. I’ve now taken this type of code from all of my seasonal pistons.
If you can reproduce the bug you saw do let me know.
HE has a lot of changes in time handling vs. ST, too many to comment on since they started on the initial port of webCoRE to HE.
The error I saw and documented was in 2018 and was on SmartThings. I’m no longer on SmartThings. I just kept the NoOp’s in place when I moved to Hubitat. I just tested for the issue still being in Hubitat and it’s no longer present.
I didn’t have logging on. And everything sorted itself out the next day. As a note, I’m using an older version of the non-native version of Webcore that I installed in September of 2022 so perhaps that played into things?
I would suggest to run the latest webCoRE (user install if fine), ie HPM repair.
I would have to see how the piston is coded to comment further. If you can post a green snapshot.
I noticed a similar anomaly this morning, except it was scheduled to run later. It is just a weekly reminder to take the cans to the curb.
There was no reminder as I was leaving for work, so I opened the webCoRE app. It showed that it was next scheduled for 3/15/2023, 7:15:00 AM. I clicked Edit and then Save, and it showed next week scheduled as expected.
So I have posted an update for testing - if you have a user install you can get it via HPM repair on webCoRE
Every ■■■■ year this happens. How on earth is this such a challenging problem they can’t fix it?
In Europe we hit daylight savings this weekend (last Sunday in March) I might preempt it this year by setting up something to power cycle my hub at 4am on Sunday morning after the clocks have gone forward.
If you are running on HE, do hpm update. I don’t expect you to have problems if you are up to date.
