I can’t get this to work consistently. I think it may be because of the “motion stays inactive for 10 minutes” condition. If I leave the room at 3pm for instance, the motion will be inactive for more than 10 minutes by the time it’s 4pm. Is there a “times greater than” option for this condition?
How about changing condition 2 to motion is inactive.
Then put in a wait 10 minutes before the Turn off.
If you want the piston to cancel if motion is detected during the 10 minute window set the the TCP to Never.
I had to look up TCP first! I am a little confused about setting TCP to Never. Doesn’t this mean that it will continue waiting 10 minutes then execute the turn off even if the conditions changes, i.e. motion becomes active?
The default option description, on the other hand, makes it sound like that it will cancel the action if the condition changes.
I have a very similar need for this. May I sneak in here and ask what TCP is please? (or just point me in the general direction)
I see you have a “With (N)” in the ‘then’ statement, I assume this is something to do with the mystical TCP.
The Never is in the action part so as long as the if is true, it will continue.
If the conditions change, motion is active, then the conditions become false and the 10 minute timer stops.
I agree it does sound confusing but it works.
You can actually watch the timer if you open the piston. If the piston hasn’t run yet, click on test.
You will then see a ‘Trace’ button.
On the left hand side you will then see the timer kick in at 4pm if there is no motion.
Let it run down a couple of minutes and then activate motion.
When motion is active you will see the timer disappear and then restart when motion is inactive.
Just to give an example.
If you had the following:-
IF
Lux is greater than 50
AND
Switch 1 is ON
THEN
Using Switch 1
Wait 5 minutes
Turn Off.
In the above one and TCP is left to default (Cancel on Condition state change) then when lux changes to greater that 50, say 60, the condition is true and the 5 min timer starts.
If after 2 minutes the lux value reports it is now 70, the piston is re-evaluated and there HAS been a condition state change and will cancel the THEN.
As it is true and the timer starts again. If this keeps happening then it may never turn off. This does depend on the piston though.
If you change TCP to never for the THEN, then if the lux keeps changing to a value above 50, it will NEVER cancel the task UNLESS it drops below 50 in the 5 minute window.
I hope this makes sense!!!
Interesting example. I can see how that could be a problem with lux values that could have a range of values that could go above the threshold you set. Would it be different if there is only two states: active and inactive?
I was just testing out my piston with TCP set to never, and it appeared to be working ok but did notice a problem.
Based on my original piston. It is after 4pm and there is no motion and my ac switch is on. The timer starts. A moment later the motion detector detects motion (active state). Because the TCP is set to never, the action continues and the counter still counts down based on what I observed. If the motion remains in an active state during the entire duration of the countdown timer, the switch will turn off once the timer reaches 0! So even though there is motion it will still turn off! But if motion stops and becomes inactive, then the counter actually resets (this confuses me also because the TCP is set to never). This doesn’t seem obvious at first because there will always be inactive times even if you are in the room.
But say we set TCP to default, if motion is inactive countdown timer starts. I don’t believe that the motion detector throws out multiple inactive state if it remains inactive or another level of inactivity to reset the counter. Unlike the changing lux levels, the counter shouldn’t constantly reset causing the switch to never turn off in this situation then. If motion detector does change to active then the countdown timer stops. The counter only restarts if it becomes inactive.
To be honest that makes sense. With this piston it would probably still work OK with TCP set to default.
It’s when you have an example like I quoted above.
Or you have
IF
xxxx
THEN
xxxx.
Or
IF
xxxx
THEN
xxx
ELSE
xxxx.
Then it matters more about the ‘Never’ in the THEN and the ELSE.
This is really getting confusing.
I just need an “inactive greater than X minutes” option!
I think the regular core had it. Though webcore could probably do something like this somehow, with the inactive greater than x minutes option if there was no motion at starting at say 3pm, the second it hit 4pm, then the switch would turn off, instead of 4:10pm.
Try this.
Because we are mixing Triggers and Conditions, you have to select always subscribe in the settings for the conditions. Hence the ‘+’ signs.
Personally I have never tried this but give it a whirl. It might work. Hopefully.
EDIT: Also if you look at the left hand ‘gutter’ you will see lightning bolts. This tells you if the condition/trigger has subscribed to the piston. Don’t know why I didn’t think of this to start with when I saw your original piston.
The last version with the default TCP seems to work pretty well I think. I’ll test it for a while first. I hate going into the room in the morning and seeing that the AC is still on. The ac is set to ECO mode where it goes into a sleep state pretty often. When I leave the room I forget the ac is not actually off because it’s often in that sleep state.
I will now have to look into subscriptions! I can’t seem to find how to activate that + symbol in the conditions settings… I’m probably looking in the wrong spot. I do notice that the conditions are already subscribed on the piston though.
