Please ignore everything I said about the red flags above…
I ran a few tests, and in this case, your syntax holds up. 
Everything else I said was accurate…
Programatically changing piston subscription time
WCmore
#21
tankdeer
#22
Thanks. I wasn’t trying to be a dick or anything, but the calculation of the time was one part I was confident was correct. It was the scheduling/execution of the other piston I was questioning.
Anyways, further testing this morning. As recommended by guxdude, I experimented with using Time as the the trigger as can be seen below:
In this case, both "Test number 3" & "Test number 4" executed as expected, as can be seen by the logs
10/17/2019, 8:54:29 AM +159ms
+1ms ╔Received event [PRM].time = 1571327670000 with a delay of -841ms
+126ms ║RunTime Analysis CS > 29ms > PS > 73ms > PE > 24ms > CE
+129ms ║Runtime (42313 bytes) successfully initialized in 73ms (v0.3.110.20191009) (127ms)
+130ms ║╔Execution stage started
+159ms ║║Comparison (time) 32069315 happens_daily_at (time) 32040000 = false (1ms)
+160ms ║║Cancelling condition #8's schedules...
+161ms ║║Condition #8 evaluated false (5ms)
+165ms ║║Cancelling statement #8's schedules...
+170ms ║║Requesting time schedule wake up at Fri, Oct 18 2019 @ 8:54:00 AM PDT
+172ms ║║Cancelling condition #7's schedules...
+173ms ║║Condition group #7 evaluated false (state changed) (18ms)
+178ms ║║Comparison (time) 32069334 happens_daily_at (time) 32040000 = true (0ms)
+179ms ║║Time restriction check passed
+181ms ║║Cancelling condition #12's schedules...
+181ms ║║Condition #12 evaluated true (6ms)
+190ms ║║Cancelling statement #12's schedules...
+195ms ║║Requesting time schedule wake up at Fri, Oct 18 2019 @ 8:54:30 AM PDT
+197ms ║║Cancelling condition #11's schedules...
+198ms ║║Condition group #11 evaluated true (state changed) (23ms)
+200ms ║║Cancelling statement #13's schedules...
+205ms ║║Test number 4
+206ms ║║Executed virtual command log (1ms)
+231ms ║╚Execution stage complete. (101ms)
+238ms ║Setting up scheduled job for Fri, Oct 18 2019 @ 8:52:00 AM PDT (in 86250.604s), with 3 more jobs pending
+249ms ╚Event processed successfully (249ms)
10/17/2019, 8:53:59 AM +71ms
+1ms ╔Received event [PRM].time = 1571327640000 with a delay of -929ms
+121ms ║RunTime Analysis CS > 21ms > PS > 74ms > PE > 25ms > CE
+123ms ║Runtime (42315 bytes) successfully initialized in 74ms (v0.3.110.20191009) (122ms)
+124ms ║╔Execution stage started
+159ms ║║Comparison (time) 32039227 happens_daily_at (time) 32040000 = true (1ms)
+160ms ║║Time restriction check passed
+162ms ║║Cancelling condition #8's schedules...
+163ms ║║Condition #8 evaluated true (6ms)
+166ms ║║Cancelling statement #8's schedules...
+170ms ║║Requesting time schedule wake up at Fri, Oct 18 2019 @ 8:54:00 AM PDT
+173ms ║║Cancelling condition #7's schedules...
+174ms ║║Condition group #7 evaluated true (state changed) (18ms)
+176ms ║║Cancelling statement #9's schedules...
+181ms ║║Test number 3
+182ms ║║Executed virtual command log (2ms)
+188ms ║║Comparison (time) 32039256 happens_daily_at (time) 32040000 = false (1ms)
+189ms ║║Condition #12 evaluated false (4ms)
+195ms ║║Cancelling statement #12's schedules...
+199ms ║║Requesting time schedule wake up at Thu, Oct 17 2019 @ 8:54:30 AM PDT
+202ms ║║Condition group #11 evaluated false (state did not change) (17ms)
+226ms ║╚Execution stage complete. (102ms)
+233ms ║Setting up scheduled job for Thu, Oct 17 2019 @ 8:54:30 AM PDT (in 30.696s), with 3 more jobs pending
+243ms ╚Event processed successfully (243ms)
I believe this is because are now subscribed to the Time object, rather than relying on a schedule. So whenever Time changes and matches our condition, it fires.
I still question why the schedule didn’t work, but at least for my scenario where the schedule is changing daily, this other approach seems more reliable. I am going to implement this change into my lighting piston and see if it works. Based on my testing, I suspect it will.
Thanks again for your help
tankdeer
#23
Following up. I changed my code to use the following trigger and it’s been working perfectly since
Time happens daily at {@turnOnTime}
Thanks