Timer scheduling and global variable offset

[allrak]

I have a global variable (@my_offset) which is a number set dynamically by a piston based on weather.
In another piston, I want lights to turn on at $sunset - @my_offset.
My question is, how often is my “turn lights on” piston evaluating @my_offset and making adjustments to the scheduled timer?
I’ve tried coding this piston multiple ways and had some success… it would work for a few days, then just quit working and not turn any lights on.
Is the key to put a dummy timer block at the end of the piston that does nothing but will force a re-evaluation of the @my_offset and adjust as necessary?

[guxdude]

You would need to post your pistons for us to fully understand what you have and how it might be working but you do need to understand that, once scheduled, Channing your offset will not update the schedule. The next time your turn lights on is run, it will schedule the next run using the current value of your offset. So there is a one cycle delay to get the offset you want. There is another thread I read which I probably can’t find now but I think they did come up with a work around I think using cancel all tasks and then rescheduling but I don’t remember for sure.

[eibyer]

Someone was working on a similar issue a few weeks back. I think we ended with a kludge that when the variable is updated, it pauses and resumes, after a few seconds, the piston dependent on the offset so it will use the new values.

[allrak]

@eibyer, Can you elaborate on this a bit? Here’s a possible workaround I was using, and it seemed stable for a couple days then just kinda quit working… (assume @my_offset is currently at “-90”):

[eibyer]

I found the post I was talking about, looking at it now – that one was a local variable that’s changing.

Scheduled wait time set by variable, not changing scheduled time if variable changes

A workable, but not ideal solution has been found, thanks to eibyer but would appreciate any other ideas still. Thank you. 1) Give a description of the problem In the piston, a variable controls the time for an action to occur. This variable can be updated when conditions change. If this happens, the scheduled time dose not update, it keeps the previously scheduled time then will correct next cycle. The line that schedules the time is line 92 via the variable “Check_Time”. Lines 43-91 are what…

Anyways… off topic, your import code is the longest one I’ve seen I think? lol

When you say it fails, does the variable not get updated anymore after a couple of days?

[allrak]

The variable looks fine… it just kinda quit working… Unfortunately the logs got written over due the timer being so quick… I’m gonna adjust my times and test it right now to see what happens.

EDIT: Can’t really test with arbitrary times… choosing a specific time value doesn’t let me set an offset. Have to use a built-in “$sunset” in order for the offset to be visible in the GUI.

[allrak]

Well the piston worked this time… I guess the only downside to it is that if a light it manually turned off between $sunset -$my_offset & $sunset, it’ll probably get turned right back on within 5 minutes.

1/29/2019, 4:10:47 PM +422ms
+1ms ╔Received event [Home].time = 1548796247508 with a delay of -87ms
+182ms ║RunTime Analysis CS > 26ms > PS > 63ms > PE > 93ms > CE
+186ms ║Runtime (43302 bytes) successfully initialized in 63ms (v0.3.109.20181207) (184ms)
+188ms ║╔Execution stage started
+213ms ║║Cancelling statement #5's schedules...
+225ms ║║Executed virtual command setVariable (4ms)
+322ms ║║Calculating (string) Kitchen & Couch lights on + (string) Tue, Jan 29 2019 @ 4:10:00 PM EST >> (string) Kitchen & Couch lights on Tue, Jan 29 2019 @ 4:10:00 PM EST
+326ms ║║Executed virtual command setState (1ms)
+350ms ║║Comparison (time) 58247752 is_between (time) 1548801600000 .. (time) 1548801600000 = true (15ms)
+352ms ║║Time restriction check passed
+354ms ║║Cancelling condition #15's schedules...
+356ms ║║Condition #15 evaluated true (25ms)
+357ms ║║Cancelling condition #14's schedules...
+358ms ║║Condition group #14 evaluated true (state changed) (29ms)
+361ms ║║Cancelling statement #16's schedules...
+378ms ║║Executed physical command [Couch 1].on() (11ms)
+379ms ║║Executed [Couch 1].on (14ms)
+393ms ║║Executed physical command [Couch 2].on() (12ms)
+395ms ║║Executed [Couch 2].on (14ms)
+410ms ║║Executed physical command [Couch 1].setLevel([100]) (11ms)
+411ms ║║Executed [Couch 1].setLevel (13ms)
+422ms ║║Executed physical command [Couch 2].setLevel([100]) (9ms)
+424ms ║║Executed [Couch 2].setLevel (11ms)
+428ms ║║Cancelling statement #19's schedules...
+446ms ║║Executed physical command [Dinner Table #1].on() (11ms)
+447ms ║║Executed [Dinner Table #1].on (14ms)
+463ms ║║Executed physical command [Dinner Table #2].on() (12ms)
+465ms ║║Executed [Dinner Table #2].on (15ms)
+483ms ║║Executed physical command [Dinner Table #3].on() (13ms)
+485ms ║║Executed [Dinner Table #3].on (17ms)
+503ms ║║Executed physical command [Dinner Table #4].on() (14ms)
+505ms ║║Executed [Dinner Table #4].on (17ms)
+522ms ║║Executed physical command [Kitchen Sink].on() (13ms)
+524ms ║║Executed [Kitchen Sink].on (16ms)
+544ms ║║Executed physical command [Dinner Table #1].setLevel([50]) (14ms)
+546ms ║║Executed [Dinner Table #1].setLevel (16ms)
+564ms ║║Executed physical command [Dinner Table #2].setLevel([50]) (16ms)
+565ms ║║Executed [Dinner Table #2].setLevel (18ms)
+580ms ║║Executed physical command [Dinner Table #3].setLevel([50]) (12ms)
+581ms ║║Executed [Dinner Table #3].setLevel (15ms)
+597ms ║║Executed physical command [Dinner Table #4].setLevel([50]) (13ms)
+599ms ║║Executed [Dinner Table #4].setLevel (16ms)
+611ms ║║Executed physical command [Kitchen Sink].setLevel([50]) (10ms)
+612ms ║║Executed [Kitchen Sink].setLevel (12ms)
+618ms ║╚Execution stage complete. (430ms)
+620ms ║Setting up scheduled job for Tue, Jan 29 2019 @ 4:15:47 PM EST (in 299.467s)
+629ms ╚Event processed successfully (629ms)
1/29/2019, 4:05:47 PM +112ms
+1ms ╔Received event [Home].time = 1548795947508 with a delay of -396ms
+197ms ║RunTime Analysis CS > 42ms > PS > 98ms > PE > 56ms > CE
+200ms ║Runtime (43303 bytes) successfully initialized in 98ms (v0.3.109.20181207) (198ms)
+201ms ║╔Execution stage started
+215ms ║║Cancelling statement #5's schedules...
+223ms ║║Executed virtual command setVariable (3ms)
+316ms ║║Calculating (string) Kitchen & Couch lights on + (string) Tue, Jan 29 2019 @ 4:10:00 PM EST >> (string) Kitchen & Couch lights on Tue, Jan 29 2019 @ 4:10:00 PM EST
+320ms ║║Executed virtual command setState (1ms)
+346ms ║║Comparison (time) 57947436 is_between (time) 1548801600000 .. (time) 1548801600000 = false (15ms)
+349ms ║║Condition #15 evaluated false (24ms)
+350ms ║║Condition group #14 evaluated false (state did not change) (26ms)
+354ms ║╚Execution stage complete. (153ms)
+356ms ║Setting up scheduled job for Tue, Jan 29 2019 @ 4:10:47 PM EST (in 300.041s)
+366ms ╚Event processed successfully (366ms)

[eibyer]

I’m playing with an idea in my head that involves the bulbs/lights being stored in a dynamic device variable where if one bulb/light is turned off manually then it gets removed from the device list so that the timer doesn’t try to turn it on again

Edit: Also need a time of day when to reset the list of course… hmm

[WCmore]

Is the key to put a dummy timer block at the end of the piston that does nothing but will force a re-evaluation of the @my_offset and adjust as necessary?

Yes, this is the key. Ideally that dummy timer will trigger at:
sunset - maximum possible offset - 5 minutes

This will ensure it has the latest possible data, and schedule the real event appropriately.

[allrak]

This will ensure it has the latest possible data, and schedule the real event appropriately.

@WCmore - Yeah… I was initially using this (dummy timer block) and it seemed to work well for some time, then everything just kinda quit working… nothing valuable seemed to be in the logs either to explain it.

@eibyer - Your idea sounds interesting

[guxdude]

Note for the dummy timer back you can’t use every day at x since that will only run what is in the every block. If you us an if time is x, the. It will run through the entire piston.

Piston executes from top to bottom?

this is a common one i see in posted examples, so thought a short note on it might be useful. pistons execution almost always starts at the top and stops at the bottom, unless there is an exit statement somewhere in the piston that gets executed conditionally or unconditionally. there is one exception to this, that is a timer statement. when executing a timer, the piston execution starts with the every and stops at the end every. as an example if this is the piston: if contact changes to ope…

[allrak]

Note for the dummy timer back you can’t use every day at x since that will only run what is in the every block. If you us an if time is x, the. It will run through the entire piston.

I was using a dummy block at the bottom of the piston as a timer to run every hour, hoping that would force a re-evaluation of the other timer which sets when the lights come on. Really seemed hit or miss… working for awhile, then not.
According to the post you’re referencing, it doesn’t look like a dummy block timer will force a re-evaluation of the other timers in the piston.

[WCmore]

For what it’s worth, I can confirm that a dummy block like this:

will definitely update the real schedule based on a global time

(as long as the dummy block fires before the real event takes place)

[bangali]

this will work fine so long as time value used is static and not a variable that is updated in the piston.

[WCmore]

Good point @bangali. I use one piston to change the global time twice a day, and a different piston (shown above) to fire 75 seconds after the event.