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?
Thanks!
-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’.
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.
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.
bobbles,
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.
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.
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…
