Planning on getting those up today.
1 Like
Nice. I will be your first tester. BTW, will my rule work if let’s say one lock is unlocked for 5 minutes and another lock is unlocked for 2 minutes? I want each lock to lock automatically after 5 minutes after being unlocked, not all at the same time if two are unlocked.
Not really, it would lock both as soon as one of them reaches the 5 minute mark. You will need to combine that with was conditions and do individual actions on each. Or split it into two pistons, one for each door. I’ll show you when it’s done.
1 Like
I am using the 12727 (on/off, not dimmer) with the new physical feature and it’s working just fine. (Using the default Z-Wave Switch device type to allow local apps)
1 Like
That is great news. They probably fixed the problem. I assumed they didn’t…
@bamarayne I think you were trying to get power meter working for some pistsons a while back, did you ever get one to work properly consistantly?
I have a few pistons that require a “is less than” or “is greater than” before they go true, those seem to work fine. I can’t use one to validate an else or but if action though. It seems every time the value changes, even if it’s still true from the restriction perspective, it causes a re-evaluation. The closest I got to success more than a random one or two going through, was with “was inside range.”
Example:
But If:
Motion is inactive
Mike power was inside range 0w-120w for at least 1 minute
Motion Off switch is off
Then: (Cancel on piston change) Tried task override of local, action, global, and none.
Wait 2 min
Turn off
I had this one trigger correctly a few times but it’s very random. Logging shows the power switch involved NEVER going above 120w, so it makes no sense as it should be a historical evaluation.
This is using an Aeon smart strip, similar experience with the Lowes smart outlet with the native ST DHT.
1 Like
Do you need to enable “Only execute on piston state change”? 
Added to the Then… right? Will test when I can go home for lunch. So with that option, help me with the logic…
- Light turns on due to motion from initial If statement (state change)
- But If… Motion stops and power is in range of 0-120w and my “disable” switch is off (state change)
- Then statement checks if state has changed, which state? From the first If or the But If?
Seems having the cancel on piston change would cancel the But If, if the primary If goes back true (motion-we know this works), but the But If state change is a change BEFORE it gets to the Then statement, so if the secondary goes true, the Then won’t activate unless ANOTHER state change occurs? Or is the Then intrinsically tied to the evaluation of only the But If (secondary) to begin with, when set to Execute on piston status change only?
Edit: Should TOS still be local?
1 Like
Please share when you get it to work I have 4 similar use case and would be nice if I don’t have to do the work 
Loool
PS I am fighting the zwave 101 err, so I cannot do crap these days.
1 Like
The piston state. That’s where all different kind of pistons come into play. The state is calculated differently depending on the piston type. For the latching piston:
State changes to TRUE when state is FALSE and IF evaluates TRUE.
State changes to FALSE when state is TRUE and BUT IF evaluates TRUE
In essence, if both IF and BUT IF are true, the piston state flips (changes to TRUE if it was FALSE and vice-versa), if only one of the two condition sets is true, then the piston becomes the state associated with that one, if none of the two is true, the piston state does NOT change.
With this information in hand, you can plan for state changes.
If you are using measurements that change in time, every measurement change will result in an evaluation. Assuming that the state is currently TRUE, and the IF is true and the BUT IF is false, the state remains TRUE, the THEN actions execute, except those that have “Only execute on piston state change”. Those only run ONCE, when the piston state becomes true.
The TOS (Task Override Scope) does something else. If you have multiple actions controlling the same device (one in the IF’s THEN, one in the BUT IF’s THEN for example), you can choose to “override” all other pre-existing scheduled (pending) tasks for the involved devices, or you can just add to the schedule (by using TOS = None). If the IF THEN says Light turn on in 10 minutes and 2 minutes later, the BUT IF says light turn off, then this will happen:
TOS: None >>> light turns off, 8 minutes later, light turns on
TOS: Action >>> light turns off, 8 minutes later, light turns on (the two tasks were added by two distinct/different actions)
TOS: Local >>> light turns off - the turn on is canceled
TOS: Global >>> same as Local, but across all pistons (if any other piston was planning on doing something with that light, it won’t anymore) - the Global is not yet implemented, acts just like Local
To give you an example on when TOS Action is helpful:
You have an action that is executed on motion becoming inactive: Wait 10 minutes, Turn light off.
Motion becomes inactive, light is scheduled for turn off in 10 minutes. Motion becomes active again, and inactive again after 5 minutes. At this point, there is a scheduled turn off in the remaining 5 minutes. If TOS is Action (or above), that turn off in 5 minutes is canceled and replaced with a brand new one that will run in 10 minutes. Effectively resetting the timer. Use Action if you don’t want to interfere with commands from other actions. The action would then only override it’s own (Action scope) tasks. When using Local, an action asking a device to do a task overrides all tasks for the same device done by any action within the Local scope - the piston itself.
The Cancel on state change is different from TOS because it does NOT require another action to run to cancel it. The piston itself will cancel it if the piston state changes BEFORE the task is due. So this is - in a way - self contained, does not require another action. The TOS will not do anything unless the same or another action runs AGAIN and has the proper scope.
Hope this helps
2 Likes
That definitely clarifies things. The TOS examples help me get my head around that, and the “only execute on piston state change” was something I’ve completely overlooked. Will report back my results, thank you again!
1 Like
Yrs, I got it to work. I finally figured out that it was my dth causing all of my problems. Once I received the device and added the such dth it worked great.
2 Likes
So when using TOS Local, and Execute on Piston Change Only, I should not need TCP of Cancel on Piston State Change correct?
They don’t mutually exclude each other.
TCP is a way to cancel an already existing task
OEPSC is a way to prevent a new task from being scheduled
TOS is a way to cancel an already existing task WHEN a new task is added
2 Likes
Can you explain to me in words what you’re trying to do? And I’ll explain the piston you need with the reasons and all.
@bamarayne there was also an error in the “enters/exits” triggers where the old value was not properly cast to the right type, causing that JavaCast error. The numerical triggers need the previous value in order to work correctly (i.e. detect the entering or the exiting or the drop or the raise, etc.)
Ok, well hold on. I’ll try this with another meter that I did not reset the dth on.
That would be awesome!
My office has a motion sensor, smart light, a virtual “disable motion switch” and an Aeon power strip with virtual power outlets for each outlet I monitor.
I want my light to come on when there’s motion obviously, but because I have a workbench out of view of my motion sensor I don’t want the light to turn off if power is above a certain threshold which means I’m actually working in the room. Once power drops below 120w and there is no motion, it’s safe to assume I’m not in there doing anything, so turn off the lights.
I originally tried with two outlets, one specific to my workbench, so there would be two that need to be under a certain limit to turn off, workbench<40w and computer<120w.
I have a second piston, called Game Time that will dim my light to 1% when the computer is using over 165w and the disable motion switch is off.
Everything validates If and Then against the disable motion switch so if I flick that, nothing will turn on or turn off.
What I’ve got so far:
Mike’s Office:
Game Time:
I just changed the piston I posted above to a different power meter and it works with no errors.
I guess it wasn’t just the dth…
1 Like