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


#1

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 dictate the wait time by setting the variable “Check_Time”

2) What is the expected behavior?
When variable the sets the scheduled time changes, webcore cancels previous schedule and schedules new time. So as example, if Check_Time was 90 the piston will schedule a check in 90 mintues, but during that time, conditions may have changed and Check_Time may change to 10 but the scheduled check will still fire after 90 minutes instead of 10.

3) What is happening/not happening?
continues previously scheduled event

4) Post a Green Snapshot of the pistonimage

5) Attach any logs (From ST IDE and by turning logging level to Full)
|+0ms|╔Received event [Home].test = 1546467318411 with a delay of 0ms|
|—|---|
|+266ms|║RunTime Analysis CS > 14ms > PS > 190ms > PE > 63ms > CE|
|+270ms|║Runtime (57057 bytes) successfully initialized in 190ms (v0.3.109.20181207) (269ms)|
|+272ms|║╔Execution stage started|
|+288ms|║║Condition #2 evaluated false (8ms)|
|+289ms|║║Condition group #1 evaluated false (state did not change) (10ms)|
|+304ms|║║Comparison (dynamic) dry changes_to (string) Wet = false (1ms)|
|+306ms|║║Condition #9 evaluated false (11ms)|
|+316ms|║║Comparison (dynamic) dry is (string) Wet = false (2ms)|
|+318ms|║║Condition #25 evaluated false (11ms)|
|+320ms|║║Condition group #100 evaluated false (state did not change) (25ms)|
|+321ms|║║Condition group #8 evaluated false (state did not change) (28ms)|
|+325ms|║║Cancelling statement #26’s schedules…|
|+335ms|║║Executed virtual command setVariable (4ms)|
|+342ms|║║Executed virtual command setVariable (3ms)|
|+349ms|║║Executed virtual command setVariable (3ms)|
|+379ms|║║Comparison (enum) dry stays (string) wet = false (2ms)|
|+382ms|║║Cancelling any timed trigger schedules for condition 22|
|+383ms|║║Cancelling statement #22’s schedules…|
|+385ms|║║Condition #22 evaluated false (16ms)|
|+386ms|║║Condition group #21 evaluated false (state did not change) (18ms)|
|+405ms|║╚Execution stage complete. (134ms)|
|+409ms|║Setting up scheduled job for Wed, Jan 2 2019 @ 6:39:32 PM EST (in 5054.011s)|
|+420ms|╚Event processed successfully (421ms)|


Timer scheduling and global variable offset
#2

No time to test this suggestion but I’d try to insert a ‘cancel all pending tasks’ right after your set variable Check_Time and see if reschedules. If not, try adding an Execute Piston calling the same piston right after the set variable.


#3

Tried both those before posting, sorry, I should have said that too. Neither cancelled the scheduled event. Only thing that I found that worked was to pause then resume the piston, but that seemed like a bad solution. Thank you for helping!


#4

Ah got it… will have to ponder and maybe try and setup something similar to play with.


#5

I really appreciate it, thank you so much!


#6

Line 51. Shouldn’t that also be within a Range?
Zero is presumably when you want the check time to be 90. But it also meets the criteria of that line.

I don’t know whether that is causing your issue, but perhaps it’s worth a look?


#7

Both should accomplish the same thing and return true is the value is betwen 0 and .098 I believe.


#8

So should be easy for someone else to verify with this. I am now sure this is just how WebCore behaves, since the same problem is exhibited here, with nothing else able to affect it.

Import this piston, and test it. It will set a timer for 5 minutes, then, you can change the variable “test” to a different number and test the piston again. The “Check_Time” variable will update, but not the scheduled time WebCore has set. Can’t figure out how to get it to behave!


#9

Good morning, I just got to playing with this today… I modified your example above a bit so I can feed the new Check_Time… this one seems to let the current Check_Time complete then uses the new value for subsequent runs… The wait of 5 secs can probably be removed, I just put it in there for good measure :slight_smile:


#10

Thank you for helping. This is the same behaviour I see and am trying to change. What I’m wanting is for a change in Check_Time to cancel the current scheduled time and start a new timer with the new value.


#11

What I think is the cause here, is just that a scheduled timer just can not be rescheduled. Is there something other than a timer that can be used here?


#12

Yeah, not sure if the block being asynch becomes independent of the ‘cancel all pending tasks’.


#13

Tried changing to a “wait” instead of a timer but that bright about all sorts of new troubles :confused: With a wait, it restarts the timer with each run off the piston. Throws using a variable set it “test” is changed that allows the wait to activate, but then next run negates that being a true statement as the variable didn’t change that cycle, and cancels the wait. Tried all sorts of combinations of subscribing, talk cancellation policy, everything I could think of. Someone much smarter than I can maybe come up with a solution.


#14

You might have to resort to a two-piston setup where one processes the info for Check_Time and passes and pauses the second piston for a few seconds to restart with the new value. Not as nice as your original setup but might save you from pulling hair lol. I have little left so I tend to go the easy route :wink:


#15

Might try this. Can just change Check_Time to a global variable and have another piston pause and resume. Gonna play some with that now.


#16

Well that actually works perfectly, although inelegantly. Thank you for all the help. I’m gonna leave this as unsolved for a little while to see if any other ideas may be suggested.


#17

As I see it, there is no simple solution to your issue. In the every loop, the every is the first statement. So each time the loop is run, the first thing it does (before you can modify the check_time variable) is schedule the next run. Changing check_time won’t cause it to go backwards and re-execute the repeat statement. If there was a {do xxx every check_time} syntax to execute your statement first and then schedule that is what you need but currently there is only {do xxx while}. This could be a suggestion for future enhancement to webCoRE but doesn’t exist yet. The inelegant work around or living with one cycle delay is your best bet for now.