"Wait" not working

#1

1) Give a description of the problem
Wait is set to 60sec, it does 20sec wait and then nothing happens.

2) What is the expected behaviour?
When level is xxx then turn activity on, wait 60sec and turn activity off.

3) What is happening/not happening?
Instead of 60sec wait trace shows it’s waiting 20secs and then does absolutely nothing.

**4) Post a Green Snapshot of the piston![image|45x37]

image
image.png735×615 32.5 KB

5) Attach logs after turning logging level to Full
17.7.2020 klo 8.39.10 +91ms
+0ms ╔Received event [Koti].time = 1594964351815 with a delay of -1724ms
+101ms ║RunTime Analysis CS > 48ms > PS > 35ms > PE > 17ms > CE
+103ms ║Runtime (37637 bytes) successfully initialized in 35ms (v0.3.110.20191009) (102ms)
+104ms ║╔Execution stage started
+105ms ║╚Execution stage complete. (1ms)
+106ms ╚Event processed successfully (106ms)

17.7.2020 klo 8.38.25 +692ms
+2ms ╔Received event [Bulb Phantom Blinds].level = 1 with a delay of 76ms
+60ms ║RunTime Analysis CS > 16ms > PS > 27ms > PE > 17ms > CE
+63ms ║Runtime (37633 bytes) successfully initialized in 27ms (v0.3.110.20191009) (60ms)
+63ms ║╔Execution stage started
+72ms ║║Comparison (integer) 1 enters_range (integer) 73 … (integer) 77 = false (0ms)
+73ms ║║Cancelling condition #2’s schedules…
+74ms ║║Condition #2 evaluated false (6ms)
+75ms ║║Cancelling condition #1’s schedules…
+76ms ║║Condition group #1 evaluated false (state changed) (9ms)
+82ms ║║Comparison (integer) 1 enters_range (integer) 78 … (integer) 83 = false (1ms)
+83ms ║║Condition #12 evaluated false (5ms)
+84ms ║║Condition group #11 evaluated false (state did not change) (6ms)
+86ms ║╚Execution stage complete. (23ms)
+87ms ╚Event processed successfully (87ms)

17.7.2020 klo 8.38.11 +628ms
+1ms ╔Received event [Bulb Phantom Blinds].level = 75 with a delay of 61ms
+58ms ║RunTime Analysis CS > 18ms > PS > 20ms > PE > 20ms > CE
+60ms ║Runtime (37638 bytes) successfully initialized in 20ms (v0.3.110.20191009) (58ms)
+61ms ║╔Execution stage started
+70ms ║║Comparison (integer) 75 enters_range (integer) 73 .. (integer) 77 = true (1ms)
+72ms ║║Cancelling condition #2's schedules...
+73ms ║║Condition #2 evaluated true (7ms)
+74ms ║║Cancelling condition #1's schedules...
+75ms ║║Condition group #1 evaluated true (state changed) (9ms)
+77ms ║║Cancelling statement #7's schedules...
+180ms ║║Executed physical command [Cool down upstairs 20c low fan [Harmony Activity]].on() (99ms)
+181ms ║║Executed [Cool down upstairs 20c low fan [Harmony Activity]].on (101ms)
+185ms ║║Executed virtual command [Cool down upstairs 20c low fan [Harmony Activity]].wait (1ms)
+186ms ║║Requesting a wake up for Fri, Jul 17 2020 @ 8:39:11 AM EEST (in 60.0s)
+191ms ║╚Execution stage complete. (129ms)
+192ms ║Setting up scheduled job for Fri, Jul 17 2020 @ 8:39:11 AM EEST (in 59.995s)
+201ms ╚Event processed successfully (201ms)
#2

With your trigger, the piston will run every time the ‘Bulb Phantom Blinds’ changes level so it can check if it is within one of the desired ranges. That is why it runs again because it sees the level change to 1 which now is no longer in the desired range so, when the timer is up, it runs as scheduled but does nothing because the conditions are no longer met.

What you need to do is set the task cancelation policy (TCP) to ‘never’ on that ‘with’ and then it will still execute the turn off even though the conditions have changed.

It is curious, that the level changes to 1 in the middle of your operation but I’m not sure exactly what you are doing.

#3

Just an observation. Your piston may run each time the level changes within the range of 73 to 83. That means this piston could be triggered at level 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83. Not sure for your Bulb Phantom Blinds device, but changes could be rapid, potentially changing every second (up and down), and then firing your piston every second.

Would it be better to use rises above ?

If Bulb Phantom Blinds level rises above 72   <----- Trigger
Then
If Bulb Phantom Blinds level is below 78      <-----  Condition
Turn on;
Wait 60 seconds;  (TCP set to Never)
Turn off;

If Bulb Phantom Blinds level rises above 77   <----- Trigger
Then
If Bulb Phantom Blinds level is below 84      <----- Condition
Then Turn off;

I’m not sure if enters range behaves like rises above. Someone else here may be able to clarify…

EDIT:
I guess my question here is…Does enters range behave as a single trigger? For instance, if your device changes to 73%, that will trigger your piston. Now, if your device changes to 74%, will that trigger again? Or is it already within the range of 73% and 77% and no trigger will occur?

#4

Hi, @guxdude is definitely right and my problem is that piston is missing TCP “never”. I changed it now and it works.

I did not remember that I have another piston which waits 15seconds after bulb level changes and sets it to 1. Sorry guys. :frowning:

That piston is created because I’m using Hue switches to control my ST connected blinds. Hue switch can’t be paired to ST hub but bulbs can. So I created bulb that does not exist and set switch buttons to control level of that phantom bulb. If level is for example 75 then open living room blinds. If 80, then close living room blinds. I have also timers for the blinds and if timer opens blinds it does not change phantom bulb level in Hue because bulb is “unreachable” (because it does not exist). So because of that there has been situations where pressing hue switch button to open blinds …nothing happens. That is why I need to reset that phantom bulb level always to “1” so that all my hue switches works with timers, with harmony application and with ST and pistons.

@Pantheon I need to use range of level because even though I have set button press level for example 75% it is always something between 73 - 77. Sometimes it could be 73, sometimes 77 and mostly that 75. Enters range works well now that I tested. After button is pressed level will not change anymore.

#5

I understand. YOU are changing the device %. That makes sense now. :slight_smile: