One time Date/Time trigger

Ryan780 · 2018-03-08 21:47:00 UTC

Okay…I still think I have to have it in a separate piston because This will still be true days after the event happens and I want it to happen at that specific date/time not every time the piston fires after that time.

Nezmo · 2018-03-08 21:49:47 UTC

Sometimes the simplest of things confound me in webCoRE. I have an anomaly in one of my pistons that I have spent hours trying to correct. I bet if I posted here someone would give me the answer immediately, lol. But this time I’m determined to work it out myself.

Good luck!

pnbruckner · 2018-03-08 22:28:46 UTC

I haven’t tried this, but if what you say is true (that a “happens daily at” will recur each day at the time of the datetime - seems reasonable from the name of the trigger ) then maybe something like this:

Ryan780 · 2018-03-08 23:54:01 UTC

Yeah, I looked into that too…just gets very comicated since I have other functions that the variable off if it’s manually turned on.

Ryan780 · 2018-03-09 14:00:25 UTC

So, had problems with thus again. Put a restriction based on location mode and evidently that triggered my piston to run again this morning even though the date was yesterday. I think I also need to add a restriction of time not after 5 mins after the variable.
This seems like it would be the easiest trigger to create.

This is the piston as I have it now. If anyone can think of a better way, I’m all ears.

pnbruckner · 2018-03-09 15:09:09 UTC

I think that will do what you want, although it will cause the piston to run twice (at @SABackOn and three minutes later), although the second time the condition should be false so it shouldn’t turn the switch on again.

Here’s another idea:

Of course, on the other hand, this will run daily, so maybe yours is a better solution overall.

Ryan780 · 2018-03-09 15:13:40 UTC

Yeah, that’s kind of my whole point… Once only, not daily. And why would this trigger twice?

pnbruckner · 2018-03-09 15:25:23 UTC

Because the condition specifies two times - the beginning and the end. This is just like “Time is after noon”. In that case the piston runs at noon and then midnight. This shows what I’m talking about:

You can see here that it runs at 9:20 and then again at 9:23:

3/9/2018, 9:22:59 AM +103ms
+0ms	╔Received event [Doral Ct].time = 1520608980000 with a delay of -898ms
+96ms	║RunTime Analysis CS > 19ms > PS > 58ms > PE > 19ms > CE
+98ms	║Runtime (38178 bytes) successfully initialized in 58ms (v0.3.000.20180224) (96ms)
+100ms	║╔Execution stage started
+107ms	║║Cancelling statement #1's schedules...
+116ms	║║Calculating (string) Ran at + (string) Fri, Mar 9 2018 @ 9:23:00 AM CST >> (string) Ran at Fri, Mar 9 2018 @ 9:23:00 AM CST
+119ms	║║Calculating (string) Ran at Fri, Mar 9 2018 @ 9:23:00 AM CST + (string) . >> (string) Ran at Fri, Mar 9 2018 @ 9:23:00 AM CST.
+123ms	║║Ran at Fri, Mar 9 2018 @ 9:23:00 AM CST.
+124ms	║║Executed virtual command log (2ms)
+132ms	║║Comparison (datetime) 1520608979230 is_between (datetime) 1520608800000 .. (datetime) 1520608980000 = false (3ms)
+133ms	║║Cancelling condition #6's schedules...
+134ms	║║Condition #6 evaluated false (7ms)
+135ms	║║Cancelling statement #6's schedules...
+138ms	║║Requesting time schedule wake up at Fri, Mar 9 2018 @ 9:23:00 AM CST
+140ms	║║Cancelling condition #3's schedules...
+141ms	║║Condition group #3 evaluated false (state changed) (14ms)
+143ms	║║Fast executing schedules, waiting for 754ms to sync up
+908ms	║║Cancelling statement #1's schedules...
+919ms	║║Calculating (string) Ran at + (string) Fri, Mar 9 2018 @ 9:23:00 AM CST >> (string) Ran at Fri, Mar 9 2018 @ 9:23:00 AM CST
+922ms	║║Calculating (string) Ran at Fri, Mar 9 2018 @ 9:23:00 AM CST + (string) . >> (string) Ran at Fri, Mar 9 2018 @ 9:23:00 AM CST.
+927ms	║║Ran at Fri, Mar 9 2018 @ 9:23:00 AM CST.
+928ms	║║Executed virtual command log (1ms)
+938ms	║║Comparison (datetime) 1520608980036 is_between (datetime) 1520608800000 .. (datetime) 1520608980000 = false (4ms)
+940ms	║║Condition #6 evaluated false (8ms)
+941ms	║║Cancelling statement #6's schedules...
+944ms	║║Condition group #3 evaluated false (state did not change) (12ms)
+947ms	║╚Execution stage complete. (848ms)
+948ms	╚Event processed successfully (949ms)
3/9/2018, 9:19:59 AM +112ms
+0ms	╔Received event [Doral Ct].time = 1520608800000 with a delay of -889ms
+106ms	║RunTime Analysis CS > 29ms > PS > 54ms > PE > 24ms > CE
+108ms	║Runtime (38159 bytes) successfully initialized in 54ms (v0.3.000.20180224) (107ms)
+109ms	║╔Execution stage started
+116ms	║║Cancelling statement #1's schedules...
+123ms	║║Calculating (string) Ran at + (string) Fri, Mar 9 2018 @ 9:20:00 AM CST >> (string) Ran at Fri, Mar 9 2018 @ 9:20:00 AM CST
+126ms	║║Calculating (string) Ran at Fri, Mar 9 2018 @ 9:20:00 AM CST + (string) . >> (string) Ran at Fri, Mar 9 2018 @ 9:20:00 AM CST.
+132ms	║║Ran at Fri, Mar 9 2018 @ 9:20:00 AM CST.
+133ms	║║Executed virtual command log (3ms)
+140ms	║║Comparison (datetime) 1520608799248 is_between (datetime) 1520608800000 .. (datetime) 1520608980000 = true (3ms)
+141ms	║║Time restriction check passed
+143ms	║║Cancelling condition #6's schedules...
+143ms	║║Condition #6 evaluated true (8ms)
+148ms	║║Cancelling statement #6's schedules...
+151ms	║║Requesting time schedule wake up at Fri, Mar 9 2018 @ 9:23:00 AM CST
+153ms	║║Cancelling condition #3's schedules...
+154ms	║║Condition group #3 evaluated true (state changed) (19ms)
+156ms	║║Cancelling statement #4's schedules...
+164ms	║║Calculating (string) True at + (string) Fri, Mar 9 2018 @ 9:20:00 AM CST >> (string) True at Fri, Mar 9 2018 @ 9:20:00 AM CST
+166ms	║║Calculating (string) True at Fri, Mar 9 2018 @ 9:20:00 AM CST + (string) . >> (string) True at Fri, Mar 9 2018 @ 9:20:00 AM CST.
+172ms	║║True at Fri, Mar 9 2018 @ 9:20:00 AM CST.
+173ms	║║Executed virtual command log (2ms)
+175ms	║╚Execution stage complete. (66ms)
+177ms	║Setting up scheduled job for Fri, Mar 9 2018 @ 9:23:00 AM CST (in 180.712s)
+184ms	╚Event processed successfully (184ms)
3/9/2018, 9:17:59 AM +314ms
+1ms	╔Starting piston... (v0.3.000.20180224)
+178ms	║╔Subscribing to devices...
+330ms	║╚Finished subscribing (158ms)
+368ms	║Comparison (datetime) 1520608679671 is_between (datetime) 1520608800000 .. (datetime) 1520608980000 = false (8ms)
+377ms	║Cancelling statement #6's schedules...
+383ms	║Requesting time schedule wake up at Fri, Mar 9 2018 @ 9:20:00 AM CST
+397ms	║Setting up scheduled job for Fri, Mar 9 2018 @ 9:20:00 AM CST (in 120.29s)
+405ms	╚Piston successfully started (405ms)

But, again, this isn’t an issue, because the second time the condition is no longer true. This is more a comment about how WC works (as I understand it), and the efficiency of your solution vs mine.

Ryan780 · 2018-03-09 21:10:22 UTC

Even if it did, happening twice that close together is fine. I’m trying to avoid it happening the next day.

pnbruckner · 2018-03-10 17:16:25 UTC

So, FWIW, I tried this:

It only triggered the one time (yesterday at 10:00:00 AM.) It did not trigger again today at 10:00:00 AM. In fact, the piston did not run at all after the first trigger.

So, not sure if it might somehow trigger again in a more complex piston with other subscriptions, but at least in the simple case it appears to trigger just the one time when using a datetime variable.

Ryan780 · 2018-03-10 22:25:19 UTC

Okay… this sketch ran just now.

3/10/2018, 5:24:22 PM +439ms
+0ms ╔Received event [Home].time = 1520720663735 with a delay of -1297ms
+102ms ║RunTime Analysis CS > 18ms > PS > 59ms > PE > 25ms > CE
+104ms ║Runtime (37622 bytes) successfully initialized in 59ms (v0.3.000.20180224) (103ms)
+105ms ║╔Execution stage started
+122ms ║║Comparison (time) 62662552 happens_daily_at (datetime) 1520634263735 = true (5ms)
+124ms ║║Time restriction check passed
+125ms ║║Cancelling condition #4’s schedules…
+126ms ║║Condition #4 evaluated true (13ms)
+127ms ║║Cancelling statement #4’s schedules…
+133ms ║║Requesting time schedule wake up at Sun, Mar 11 2018 @ 6:24:23 PM EDT
+136ms ║║Cancelling condition #1’s schedules…
+137ms ║║Condition group #1 evaluated true (state changed) (25ms)
+139ms ║║Cancelling statement #2’s schedules…
+276ms ║║Executed physical command [Office speaker].speak([Test]) (129ms)
+277ms ║║Executed [Office speaker].speak (131ms)
+280ms ║╚Execution stage complete. (175ms)
+282ms ║Setting up scheduled job for Sun, Mar 11 2018 @ 6:24:23 PM EDT (in 86401.015s)
+290ms ╚Event processed successfully (290ms)

You can clearly see at the begging of the log that it’s only comparing the time and not the date. So, I dunno what your logs look like but clearly it’s not looking at the date in mine.

pnbruckner · 2018-03-10 22:36:20 UTC

You have “Time happens daily at …” instead of “Date & Time happens daily at …”. If you look at my piston, it has “Date & Time happens daily at …”. I think that’s your problem.

Ryan780 · 2018-03-10 22:37:48 UTC

OMG…that is what I was looking for from the beginning!!! UGH! THANK YOU!!!

gwiddison · 2018-09-11 17:56:57 UTC

Just for info (if anyone is still interested in the topic!), I also spent ages trying to get a date\time trigger to work, what I ended up doing was creating a virtual switch then used smart lighting to toggle this off\on at a certain time, this could then be used in webcore to trigger sending a mail.

Ryan780 · 2018-09-17 05:20:54 UTC

The problem that I had was that I was choosing Time instead of Date/Time. Time repeats the same function every day at that time while Date/Time is one-time-only.