I found a nice easy one that takes two XYZ sets and converts them to an arbitrary distance, i’m using it in a universal garage controller app I’m working on.
It will likely work for rotation, particularly if you use the change in acceleration to snap the start and end coordinate sets…
1 Like
OK, good call I see your point, however…
Now the piston evaluates the condition as true but the light still went off even with me walking around
Rick
Just thinking and looking through the app how about setup 1st action to turn on light, then 2nd action to wait 1 minute then turn light off and select option to “Execute on piston status change only” on 2nd action? Not sure what that feature does yet because I haven’t tested it out yet but wondering if it will see the change in the condition and process it after 1 minute.
A lot of motion sensors send a active event and then send a inactive after 15 seconds of inactivity so as long as you continue moving, it’s not going to send another active event and reset your 1 minute wait.
Couldn’t you put the wait 1 minute, turn off as the else action so that the light won’t turn off until it switches back to no motion?
1 Like
Good point, didn’t even think about separating it into the else section.
1 Like
Motion sensors 101 - have a latching piston, if motion changes to “motion” then turn light on.
But if motion sensor changes to “inactive” then wait 1 minute and turn off. Lots of motion sensors will not send a second “active” event…
Or you can do that, yes, condition “is” and use both action groups, one to turn on, one to wait and turn off. You could also make sure the actions only run on piston state change, in case you get repeated events from the sensor over long periods of time
I have like 4 different types, and none of them will send an active, unless they’ve gone inactive first.
3 Likes
Mine do the same. They send an active whenever motion started and then an inactive some seconds after the motion stopped. Has to do with battery preservation…
if using a simple piston, the “wait” and “turn off” tasks need to be set under “else”.
If this is the approach you go with then you would have to use the on piston change option no? Otherwise it will still turn off after 1 minute or you could use the else section and do a wait 1 minute then turn light off. I’m just trying to figure out the proper way myself to set this up when i setup the kids rooms to turn off their lights when they’re not in their rooms. Whether using a Simple piston with if motion is active then action 1 turn light on, action 2 wait 1 minute turn light off with piston state change. Simple piston with if motion is active then turn light on, else wait 1 minute turn light off. Latching piston if sensor changes to active then turn light on but if sensor change to inactive wait 1 minute turn light off. Maybe there is no correct way and all 3 will work because of all of the capabilities you’ve put into this app.
Reporting is a little more complicated because the motion sensor device class includes both battery operated (sleepy) and mains powered sensors. The reporting behavior is typically different.
Wi-Fi sensors and some mains powered mesh sensors do continuous monitoring. They don’t have to worry about battery power, so they don’t.
Most battery powered sensors are “sleepy devices.” They use what is called “sampling.” They sleep most of the time, wake up, measure and compare that to a Delta parameter which defines their reporting level. If they’ve exceeded the Delta, they report, then go back to sleep. If they haven’t exceeded the Delta, they just go back to sleep.
There is a difference between different sensor manufacturers in how they handle Delta evaluation. Fibaro, for example, has a customizable pulse counter. The sensor itself detects motion but does not report it unless it detects two Motion events (“pulses”) within a set time. The number of pulses and the length of time are both customizable parameter settings. So the default for Fibaro is two detected motion events equal one motion report. But even there, there is a sleep period Where motion events will be ignored all together. (Fibaro calls this the blind Period because their sensor detects more than just motion)
On the other hand, I don’t think the WeMo motion sensor uses sampling at all. Since it’s a plug-in Wi-Fi sensor, it’s just a different reporting structure.
All of which is a long way of saying that different brands of sensors report in different ways.
1 Like
There are many ways to do it… None is “the right one”. Pick one, if the end result matches the requirements, you did it “right”
So as @bamarayne appropriately noted, he feels sorry for the non-programmer… well that’s me. And I am more confused than ever right now.
So we can all learn from this, let’s start with the end goal in mind
Door opens > turn on light
If door stays open or closes, light stays on
If motion is detected, leave light on
If motion is not detected for a period of time (15 mins) turn light off
If motion is detected during the 15 mins, leave light on and wait for no motion then reset timer
After 15 mins of no motion, turn off light
Maybe it’s time to develop an Excel doc or something similar that can be filled out that everyone can follow. This will general consistency with terms, actions, conditions… Honestly, when the developers get talking about nesting, looping, latching… it’s like your speaking Greek 
Thoughts?
Rick
3 Likes
OK. Let’s review the logic and see if we can simplify what you put.
If door stays open or closes, light stays on
Well, you can remove this since the door will either stay open or close, so this will always be true.
All of these:
If motion is not detected for a period of time (15 mins) turn light off
If motion is detected during the 15 mins, leave light on and wait for no motion then reset timer
After 15 mins of no motion, turn off light
Can be simplified to:
After 15 mins of no motion, turn off light
So, you end up with:
Door opens > turn on light
After 15 mins of no motion, turn off light
4 Likes
Hey BoSTon,
So you are validating my point. While the logic is simple and I totally agree and understand how you broke it down, how does that translate into a new Piston? Simple, Latching… Else-If, And-If or…
I gave the details I did b/c my first post about this yesterday came back with a question, what happens when the door closes… I was trying to give the complete use case.
I’m not trying to be difficult or argumentative, I just don’t get how to build the Piston and since this one is so simple, how are we going to get more complex w/o loosing, non-programmers?
Rick
edited my post because I missed the last bit of @boston 's post with the simplified rule…
This has become a serious power users’ UI, which will be very valuable to a small group of people but pretty confusing to many others. Hopefully this will follow the usual SmartThings model, where people from that small group will be willing to do peer assistance for others. In fact, you might want to go ahead and set up the peer assistance thread soon even though it’s still in Alpha, just to keep this thread more clear for what @ady624 is doing with feature development and testing.
Correct. That’s why the first line is:
Door opens > turn on light
1 Like
My sunset “-” timer isn’t working. If a set sunset or a custom time things work. When I set something like sunset “-50” no luck. Any ideas?
Yes @JDRoberts , you are correct and I do see the first line as door opens > turn on light which BoSTon pointed out. And to JD’s point, how does that translate into a Piston?
Here is what I was talking about with regards to an Excel doc or something similar
As you can see, I have 3 very basic Pistons and so far, Sunset didn’t trigger tonight and the Dirt Room Door/Light isn’t working. Haven’t tested the mode change yet on a schedule
Speaking of which, I don’t see anything as being scheduled in the IDE like I do for Rule Machine scheduled events, not sure why. I have refreshed each SmartApp with no luck
Thanks guys for the help
Rick