Time-based pistons ran 1 hour early today

#5

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.

#6

I put this code at the top of each piston that could be affected by DST<>EST changeovers:

image
image.png1301×269 12.4 KB

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.

#7

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).

#8

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.

#9

You don’t have to ‘fix it’ if it is working…

#10

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?

#11

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.

#12

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.

#13

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.

#14

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?

#15

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.

#16

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.

image
image.png1178×378 9.12 KB

#17

thx for this, I think I found the error and will push an update once I’m done testing.

#18

So I have posted an update for testing - if you have a user install you can get it via HPM repair on webCoRE

#19

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.

#20

If you are running on HE, do hpm update. I don’t expect you to have problems if you are up to date.

#21

We had DST change today in the UK. My HE is up todate (HPM install), but looks like its got the times wrong.

My lights have just come on at 17:20, but looking at the piston, tomorrow they’ll be coming on at 18:20. The DST change was +1hr at 01:00 today.

It’s not a big issue, but thought its worth mentioning in case this is supposed to be fixed.

#22

what version of webcore are you running?

HE console -> apps -> webcore ->. all the data at ‘Engine block’

#23

v0.3.114.20220203 HE:v0.3.114.20230222_HE -March 22, 2023

Hopefully I’ve type that correctly

#24

Show me a green snapshot of a piston that did not run properly, and you still have logs for it would like to see those to.

Can be a private message if you don’t want it all in the forum.