"happens daily at" triggers twice

#1

1) Give a description of the problem
Using “Date & Time happens daily at” to trigger a one time event. Two triggers happen every time.

2) What is the expected behaviour?
A single triggered event at the designated date / time

3) What is happening/not happening?
Piston runs twice every time

**4) Post a Green Snapshot of the piston![image|45x37]

image
image.png1178×481 44.4 KB

5) Attach logs after turning logging level to Full
6/10/2020, 7:33:59 AM +114ms
+0ms ╔Received event [Elmwood].time = 1591799640000 with a delay of -887ms
+96ms ║RunTime Analysis CS > 21ms > PS > 55ms > PE > 20ms > CE
+98ms ║Runtime (37703 bytes) successfully initialized in 55ms (v0.3.10a.20190223) (97ms)
+99ms ║╔Execution stage started
+106ms ║║Comparison (datetime) 1591799639218 happens_daily_at (datetime) 1591799640000 = true (0ms)
+107ms ║║Time restriction check passed
+109ms ║║Cancelling condition #2’s schedules…
+110ms ║║Condition #2 evaluated true (6ms)
+120ms ║║Cancelling statement #2’s schedules…
+124ms ║║Requesting time schedule wake up at Wed, Jun 10 2020 @ 7:34:00 AM PDT
+127ms ║║Cancelling condition #1’s schedules…
+128ms ║║Condition group #1 evaluated true (state changed) (24ms)
+130ms ║║Cancelling statement #3’s schedules…
+135ms ║║Calculating (integer) 6 + (integer) 1 >> (integer) 7
+140ms ║║Executed virtual command setVariable (3ms)
+152ms ║║Fast executing schedules, waiting for 734ms to sync up
+895ms ║║Comparison (datetime) 1591799640006 happens_daily_at (datetime) 1591799640000 = true (0ms)
+896ms ║║Time restriction check passed
+897ms ║║Condition #2 evaluated true (5ms)
+899ms ║║Cancelling statement #2’s schedules…
+903ms ║║Condition group #1 evaluated true (state did not change) (11ms)
+905ms ║║Cancelling statement #3’s schedules…
+909ms ║║Calculating (integer) 7 + (integer) 1 >> (integer) 8
+914ms ║║Executed virtual command setVariable (3ms)
+916ms ║╚Execution stage complete. (817ms)
+918ms ╚Event processed successfully (917ms)
6/10/2020, 7:33:34 AM +846ms
+1ms ╔Starting piston… (v0.3.10a.20190223)
+369ms ║╔Subscribing to devices…
+464ms ║╚Finished subscribing (103ms)
+485ms ║Comparison (datetime) 1591799615329 happens_daily_at (datetime) 1591799640000 = false (1ms)
+487ms ║Cancelling statement #2’s schedules…
+490ms ║Requesting time schedule wake up at Wed, Jun 10 2020 @ 7:34:00 AM PDT
+505ms ║Setting up scheduled job for Wed, Jun 10 2020 @ 7:34:00 AM PDT (in 24.65s)
+517ms ╚Piston successfully started (516ms)

#2

Well, your piston does not match up with your logs…
If I assume that the only change you made was to the date… then

Your logs look good to me. There was one event scheduled, and only one execution processed.

What I think happened behind the scenes is, your piston fired one second early. (7:33:59)… and then did a:
Fast executing schedules, waiting for 734ms to sync up
to stall until the new minute crosses over before continuing.

I have two ideas for a solution… Either one may work, or you may have to use both.

  1. Drop the variable, and just use the date and time on line 23

  2. Add a 2 second WAIT once the piston starts before setting the variable.
    (this makes sure it is fully in the correct minute)

#3

image
image.png1178×583 53 KB

Yes, I added a 1500ms fudge factor and this “fixed” the problem… of course this depends on the execution speed of the processor so its not fool proof. I’ll check to see if putting the date/time directly rather than using a variable also addresses it.

#4

Note that your method forces the acceptable times it into a very tiny window…
(IE: 8:09:00.0 thru 8:09:01.5)

My suggestion above simply pushes back the execution a bit.
(which should be more reliable, with less processing done)

#5

Unfortunately,

  1. Dropping the variable in line 23 makes no difference.
  2. Adding a 2 second wait before setting the variable makes no difference.

image
image.png1178×583 53 KB

However,

Putting a 2 second wait at the beginning of the piston before the date/time test fixes the problem. Still a hack and I wonder depending on system delays when 2 seconds is enough … but works for now.

Seems like this should be logged as a bug in Webcore. Is it still being updated?

Thanks!

#6

Please update your last image. It is the same as before

#7

oops … here it is:

image
image.png1178×501 46.8 KB

#8

Perfect! This little trick makes sure that we are fully into the correct minute before going forward.

(webCoRE has a tendency to run a second early in my house, unless I have a lot of chatter on my network at the time)

Side Note:

I have never witnessed it firing two seconds early though, which is why the 2 sec buffer should do the trick.

#9

Thanks, do you know a way to report bugs to Webcore team? Are they still addresses bugs?

#10

If I may tease you for a moment…
Notice how your successful WAIT is definitely before the set variable line… :sunglasses:

#11

Its a hack no matter how you look at it :sunglasses:

#12

Yes, there is a bugs category here, with a very responsive crew…

True, as is most things SmartHome related, LOL

#13

I think it’s a bit cheesy taking credit for the Solution, when my first post clearly mentioned the 2 second wait…

Edit:

Upon closer inspection, I guess this is normal behavior for you…

75% of the time, you give yourself credit for solving your own threads…

I think perhaps my time is better spent helping others…

#14

I thought I remembered you :slight_smile:

#15

I help so many people here, I forgot who you were until the end of this thread, LOL