The Max/Min is an interesting idea, and maybe something I’ll have to explore. I was up way too late last night working on this…but feel like I’m close. I’ll add in the few remaining ideas I had this AM and post my latest before heading to work. Thank you, all, for the extra brain power!
Dog Door Tracking - Restricting Triggers
logeox
#11
My other thought if you are using a ST open close sensor(which has an Accelerometer). Maybe log the state of the close on the sensor. I suspect that if it roles past the sensor it wont log a closed state again until it comes to rest. So if the sensor was closed and axis went above 400 then you know he went out. And vice versa. It might be an option but you will have to play with it and see what the sensor registers. You will most likely have to put the closed state in a variable as its a condition and the trigger will be the axis move. The piston will only look a the condition state after the trigger. So just write a separate or part of this one where when the sensor comes to rest(closed) change variable to true.
RosTeHea
#12
Does anyone know how the integer value of $now works? It was positive yesterday evening, but now it’s negative. I thought maybe it starts negative at midnight and advances to 0 at noon, but that doesn’t appear to be the case. I’m struggling to make the comparison between the two events consistent because of this…
RosTeHea
#13
For example:
I just opened the door - pushing it out, which should make @dogDoorAbove record a “lower/earlier” number than @dogDoorBelow (the return swing). This is what I get:
integer@dogDoorSwingAbove -1783772633
integer@dogDoorSwingBelow -1783773581
RosTeHea
#14
And here is my latest:
I went with @logeox’s recommendation of creating two pistons: one to store the separate swings and store as two variables: @dogDoorSwingAbove and @dogDoorSwingBelow for swings outside and inside respectively. It then executes a second piston which compares the two values looking for the “oldest” (read: first) swing, and uses that to determine whether the door was first pushed out or in.
The issue I ran into last night (and spent hours trying to troubleshoot) is that the door may not always swing both directions, and therefore may have an old “date/time” value stored, which would throw everything off.
I therefore had to reset both variables to zero after each run.
But then a new issue: if one variable registers a swing, but the other doesn’t and remains at zero, my comparisons are off. So I had to tell the piston to check, and if the “SwingAbove” variable is not zero, but the other is, to make the other variable a value relative to the “real” variable, such that it would read that the door opened first in the direction it did. (I’m sorry—if you followed that explanation, I’m impressed. Short on time).
I think I’m down to just figuring out the proper way to store the $now variable and run conditional logic to see which event happened first - the open out (@dogDoorSwingAbove) or open in (@dogDoorSwingBelow).
Variable-Controlling Piston:
Master/Control Piston:
RosTeHea
#15
I do believe I’ve figured it out…took some learnings from a post from @HDGuy here: How to properly handle duplicate events?
See the following. Thank you for your help!
bigalpha
#16
How are you tracking the movement of the dog door? Do you have a multipurpose sensor on it?
RosTeHea
#17
Correct—I have a ST multipurpose sensor attached to the upper-portion of the door. It’s secured by Velcro so I can easily remove it and slide in the locking panel when we are out of town. I’ll upload a photo later tonight.
bigalpha
#18
That would be great, thanks! Are you simply using the tilt and not the contact portion?
RosTeHea
#19
Correct—I’m using the accelerometer and measuring the x axis to know whether it opened in or out (the door swings both ways), hence the reason for not using the contact sensor. I need to not just know if the door opens, but which way it opens.
bigalpha
#20
That’s a pretty good idea. I also have a dog door and tracking this would be pretty handy. Thanks again for the extra info!
RosTeHea
#22
The piston still isn’t working, and after further research, I realize it’s because the 3-axis numbers are not consistent. Long story short, I think I may be able to make it work using something similar to what you suggested, @WCmore, but I’m having a hard time figuring out how to store a list of values to a variable.
What I want to do is this:
- On events from the Multi-Purpose sensor, store all x-axis and z-axis values in a list. Any time the door opens, it should register around 10 values.
- Find the average, max, and min values of the x-axis and the z-axis of that “batch” of numbers for further use
Can’t find anything in the forums…
WCmore
#23
SmartThings is not so great at capturing 10 events from a single device within 3 seconds…
(I was thinking the first 4 swings at most - or outside the range of -150 and +150)
Perhaps more importantly, there is no guarantee that the device will only report the highest part of each swing…
RosTeHea
#25
Could you shed some light on how I get Webcore to store a list of sensor data into a variable?
For example:
IF
[door moves out of “static” range]
THEN
[Capture all events that Webcore receives for the X-axis for the next 10 seconds?]
Thoughts?
WCmore
#30
I whipped up a quick piston to show these mathematical formulas at work:
(Note, this example has no negative numbers, so it made more sense to make the last line subtract, instead of add)
I am a bit backed up with clients at the moment, so I will let someone else chime in for the capturing question you had.