WebCoRe "wait" problem

I created a piston that after turning on an outlet it waits 45 minutes, and then turns the outlet off. I cannot get the piston to work correctly. If I put the “wait” time to 30 seconds, or even a few minutes, it works correctly. However, if I set it to 30 minutes it never turns off the outlet. Why would the “wait” function work for a few minutes, but fail if set to a longer period of time?


-update- this has been updated to set TCP to ‘never’. This fixed the problem, but it was the fault of the power switch that it didn’t work before. My other power switches (of a different brand) work perfectly with the piston even when TCP is not set to ‘never’.


Seems odd, your “With” statement in the action doesn’t specify a device…should look something like this:

52 AM

I had an issue with using triggers and wait…

I build them like this now

If X changes
–If is on
–Then wait

Danabw, thanks for helping out. When you do the anonymized screenshot it removes that information. My piston does have that information.

rontalley, thanks to you too. I’ll try building a piston like you showed.

I tried this in CoRe as well, and I had the same results. :frowning:

So waiting 4.5 minutes 10x is not an option? :slight_smile:

All kidding aside, I’d be curious what the full logs showed. Maybe it is timing out getting tired of waiting…or maybe it feels the condition changed so it does not need to continue. Without the logs it’s all just guessing.

What should happen is that the piston should set an event for itself which will wake it back up 45 minutes in the future. Odd that it wouldn’t work…because things like “Every day at sunset” do work and they operate on the same principle.

Thanks Mike1616 for chiming in!

I’m going to run the piston again with a full log, and see what I can see.

I ran it again with the logs, and this is what I got…

‎1‎/‎18‎/‎2018‎ ‎2‎:‎55‎:‎01‎ ‎PM +242ms
+4ms ╔Received event [Home].time = 1516308902286 with a delay of -1053ms
+275ms ║RunTime Analysis CS > 148ms > PS > 98ms > PE > 36ms > CE
+284ms ║Runtime (36281 bytes) successfully initialized in 98ms (v0.2.102.20180116) (268ms)
+289ms ║╔Execution stage started
+291ms ║╚Execution stage complete. (5ms)
+310ms ╚Event processed successfully (313ms)

‎1‎/‎18‎/‎2018‎ ‎2‎:‎54‎:‎33‎ ‎PM +942ms
+10ms ╔Received event [Garage IR Heater].switch = on with a delay of 145ms
+116ms ║RunTime Analysis CS > 36ms > PS > 53ms > PE > 21ms > CE
+122ms ║Runtime (36282 bytes) successfully initialized in 53ms (v0.2.102.20180116) (110ms)
+126ms ║╔Execution stage started
+140ms ║║Comparison (enum) on changes_to (string) on = false (0ms)
+141ms ║║Condition #5 evaluated false (7ms)
+142ms ║║Condition group #1 evaluated false (state did not change) (9ms)
+145ms ║╚Execution stage complete. (22ms)
+149ms ╚Event processed successfully (149ms)

‎1‎/‎18‎/‎2018‎ ‎2‎:‎39‎:‎33‎ ‎PM +572ms
+7ms ╔Received event [Garage IR Heater].switch = on with a delay of 144ms
+109ms ║RunTime Analysis CS > 34ms > PS > 51ms > PE > 19ms > CE
+114ms ║Runtime (36276 bytes) successfully initialized in 51ms (v0.2.102.20180116) (105ms)
+118ms ║╔Execution stage started
+130ms ║║Comparison (enum) on changes_to (string) on = false (1ms)
+131ms ║║Cancelling condition #5’s schedules…
+132ms ║║Condition #5 evaluated false (6ms)
+133ms ║║Cancelling condition #1’s schedules…
+134ms ║║Condition group #1 evaluated false (state changed) (8ms)
+153ms ║╚Execution stage complete. (39ms)
+158ms ╚Event processed successfully (158ms)

‎1‎/‎18‎/‎2018‎ ‎2‎:‎25‎:‎02‎ ‎PM +126ms
+6ms ╔Received event [Garage IR Heater].switch = on with a delay of 187ms
+108ms ║RunTime Analysis CS > 38ms > PS > 49ms > PE > 17ms > CE
+113ms ║Runtime (36282 bytes) successfully initialized in 49ms (v0.2.102.20180116) (106ms)
+118ms ║╔Execution stage started
+128ms ║║Comparison (enum) on changes_to (string) on = true (1ms)
+131ms ║║Cancelling condition #5’s schedules…
+131ms ║║Condition #5 evaluated true (8ms)
+133ms ║║Cancelling condition #1’s schedules…
+133ms ║║Condition group #1 evaluated true (state changed) (10ms)
+136ms ║║Cancelling statement #2’s schedules…
+151ms ║║Executed virtual command [Garage IR Heater].wait (4ms)
+157ms ║║Requesting a wake up for Thu, Jan 18 2018 @ 2:55:02 PM CST (in 1800.0s)
+173ms ║╚Execution stage complete. (59ms)
+183ms ║Setting up scheduled job for Thu, Jan 18 2018 @ 2:55:02 PM CST (in 1799.981s)
+194ms ╚Event processed successfully (194ms)

What about modifying your IF to just “Switch Changes to On”?

WB70, I’m new to this, so maybe that would work, but from the log it seems like it does know when the switch is turned on. So, I’m not sure that would fix it.

In your WITH change TCP (task Cancellation Policy) to never.
To do this, click on the WITH.
Scroll down to the settings cog and click on it.
Change TCP to never.

1 Like

I saw that somewhere else, and that was my next thought too. I will try that, and I’m guessing that will fix it. However, I don’t understand why it’s getting canceled in the first place.

Taking some of the other suggestions and for testing within a contained time parameter, implement the changes and then modify your time to 5 minutes. If that works, increase to 10 minutes, just so you can see that the results are working/successful. That along with Logging set to Full and cleared for each test.

If those shorter timed tests work, then go Full Monty with the 30 minute test.

WB70, that’s a good idea. That will tell me exactly how long it has to wait before it fails. I did try it at 5 minutes, and I believe I also tried it at 10 minutes, and they both worked. I believe it was after 15 minutes that it started to fail, but that was a week ago when I did those tests, so I might be remembering wrong. I could try it again and see.

Because the condition state has changed.
Here is the sequence of events.

The switch changes to on.
The condition becomes true.
Wait timer starts.
After a short period of time, I think it is 10 seconds, the condition will become false as you are requesting switch changes to on. The piston starts to look for it to change to on to become true again. It has to be like this as otherwise if a switch was to change to on and remain like this it would never ever change to on again. It has to go false to look for it to change to true again.
With TCP set ‘Cancel on Condition state change’ after 10 seconds the condition becomes false and the tasks cancel.
With TCP set to never, the tasks will never cancel UNLESS the switch changes to ON again.
I hope my ramblings make sense. :slight_smile:

I think that makes sense, but then why does it work if I set it to 5 minutes?

So that’s good. Do this. Modify to what @bobbles stated with the Task cancellation policy and change it back to 15 minutes. If that works then go 30. If that fails, I have a feeling that “Physically switched on” no longer applies and I would remove physically from the IF qualification. And run again.

Sounds good. I actually already started a 30 minute test awhile ago with TCP set to never, so I’ll let it finish. I’ll report back with the results.

Thanks again for all the help guys!

1 Like

Must admit I missed the ‘physically’ bit.
Just read it to changes to ON.
My ramblings might not be true then in this case.

1 Like

Let’s wait and see. :slight_smile:

The TCP set to ‘never’ test is still running, but just FYI the ‘physically’ part actually has already been removed, and it had still failed. Here’s a screen shot as it currently is setup…


1 Like