Time triggers don't appear to work

[jeppsenc]

1) Give a description of the problem
Time triggers of any sort don’t work

2) What is the expected behavior?
When the time reaches 11:15pm the office lights should go out. This is just a test piston.

3) What is happening/not happening?
Nothing is happening. Most of the time the expected time passes without any notation in the logs. When there is a notation it says that the happens_daily_at test failed. Other pistons with time triggers and other different triggers (ie, motion or contact closure) work fine for all but the time triggers. If I use “Wait” statements they don’t work, either.

4) Post a Green Snapshot of the piston

5) Attach any logs (From ST IDE and by turning logging level to Full)
|+1ms|╔Received event [Jeppsen Home].execute = recovery with a delay of 1410ms|
| — | — |
|+1293ms|║RunTime Analysis CS > 1058ms > PS > 203ms > PE > 34ms > CE|
|+1296ms|║Runtime (37994 bytes) successfully initialized in 203ms (v0.3.108.20180906) (1292ms)|
|+1298ms|║╔Execution stage started|
|+1314ms|║║Comparison (time) 84124387 happens_daily_at (time) 84060000 = false (2ms)|
|+1317ms|║║Condition #2 evaluated false (9ms)|
|+1326ms|║║Cancelling statement #2’s schedules…|
|+1333ms|║║Requesting time schedule wake up at Fri, Sep 7 2018 @ 11:21:00 PM MDT|
|+1344ms|║║Condition group #1 evaluated false (state did not change) (37ms)|
|+1385ms|║╚Execution stage complete. (88ms)|
|+1394ms|║Setting up scheduled job for Fri, Sep 7 2018 @ 11:21:00 PM MDT (in 86335.529s)|
|+1405ms|╚Event processed successfully (1406ms)|

|9/6/2018, 11:19:36 PM +42ms|
|+2ms|╔Starting piston... (v0.3.108.20180906)|
|+404ms|║╔Subscribing to devices...|
|+500ms|║║Subscribing to Office Lights...|
|+501ms|║╚Finished subscribing (109ms)|
|+530ms|║Comparison (time) 83976569 happens_daily_at (time) 84060000 = false (1ms)|
|+534ms|║Cancelling statement #2's schedules...|
|+539ms|║Requesting time schedule wake up at Thu, Sep 6 2018 @ 11:21:00 PM MDT|
|+555ms|║Setting up scheduled job for Thu, Sep 6 2018 @ 11:21:00 PM MDT (in 83.404s)|
|+572ms|╚Piston successfully started (571ms)|

REMOVE BELOW AFTER READING

[jeppsenc]

I notice that the snapshot says I am using a sensor rather than office lights. That is NOT true. Whenever I take a green snapshot that sensor appears on that line, but not in the actual piston. I have no idea how that’s happening.

[eibyer]

This may be related to the issue being discussed here…

Pistons with waits failing

I have a bunch of pistons with waits that are not executing. I’m seeing red ovals in the trace gutter with times incrementing instead of decrementing. Anyone else having this issue? [image] On further review, it seems like those with short waits (3 seconds or so) are fine, where ones that request a wake-up further in the future (45, 60, 90 seconds etc) do not execute.

[WCmore]

Instead of an IF TIME, I would do something like this instead:

---

Also, I am not sure this next bit applies to you, but if I am writing code like this:
every hour at 21 minutes past the hour
and if I edit & save the code at 11:01, it will not run until 12:21.
(for some reason, the current hour is ignored, but it works from there on out)

EDIT :
I just retested this, and it no longer makes us wait an hour! Thanks to whomever fixed this old issue!!

[jeppsenc]

I created a piston using the statement you suggested and ran it a couple of times. In both cases it executed 1 minute 40 seconds after the scheduled time. I also created a rule in both Smart Things and using Smart Rules. The ST rule ran at 53 seconds past the target time and the Smart Rules rule ran with about 5 seconds of the scheduled time.

I still think this has somethlng to do with Webcore.

|+1ms|╔Received event [Jeppsen Home].execute = recovery with a delay of 71ms|
| --- | --- |
|+297ms|║RunTime Analysis CS > 22ms > PS > 253ms > PE > 21ms > CE|
|+299ms|║Runtime (37993 bytes) successfully initialized in 253ms (v0.3.108.20180906) (297ms)|
|+301ms|║╔Execution stage started|
|+372ms|║║Cancelling statement #2's schedules...|
|+1480ms|║║Executed physical command [Office Lights].off() (1103ms)|
|+1482ms|║║Executed [Office Lights].off (1105ms)|
|+1492ms|║╚Execution stage complete. (1192ms)|
|+1495ms|║Setting up scheduled job for Sat, Sep 8 2018 @ 3:01:00 PM MDT (in 86289.935s)|
|+1506ms|╚Event processed successfully (1505ms)|
|9/7/2018, 2:57:15 PM +66ms|
|+1ms|╔Starting piston... (v0.3.108.20180906)|
|+464ms|║╔Subscribing to devices...|
|+584ms|║║Subscribing to Office Lights...|
|+585ms|║╚Finished subscribing (133ms)|
|+644ms|║Setting up scheduled job for Fri, Sep 7 2018 @ 3:01:00 PM MDT (in 224.291s)|
|+661ms|╚Piston successfully started (661ms)|

[WCmore]

it executed 1 minute 40 seconds after the scheduled time

Your logs first line (RunTime Analysis) took 0.3 seconds to run (297ms)
Your office light took an additional 1.2 seconds to turn off. (1482 - 297 = 1185ms)
Total start to finish time was about 1.5 seconds according to your log above.

This delay is a tad long, but not impossible if there is a lot of congestion on your network at the time .
(Video streaming / gaming / Windows updates etc).

[WCmore]

For what it’s worth, mine usually runs about 0.8 seconds EARLY as seen here:

---

Although, to be completely honest, the time that SmartThings sees is actually about 35 seconds off from my atomic clock.

[WCmore]

the snapshot says I am using a sensor rather than office lights. That is NOT true. Whenever I take a green snapshot that sensor appears on that line, but not in the actual piston. I have no idea how that’s happening.

For some reason, SmartThings thinks that your Office Light is a type of motion sensor.

If it’s working, I would not sweat it, but if that bulb has unexpected things happening, I would turn your attention to resolving that.