I’m blown away how developers here design these programs! Hats off to you guys. Your like mad scientists.
It’s fun to watch how things progress for sure!
OK, hats off to @ady624 you’re doing an amazing job! Been going through your code as well (from the ones in various posts on this thread) and its well laid out. If I could spare a bit more time I would love to help (although a bit busy currently… ok make that 20 hour work days due to a few projects I am in charge of).
I’ve updated the code. It can now do simple evaluations. No triggers yet, but all simple conditions should work. All “is” kind of conditions, at least. The “was” conditions are not there yet.
I wish ST allowed a list of options in an input where I could specify id/value pairs instead of just strings for display - they make it into settings and we won’t be able to change the names later…
Since it takes no actions yet, results are in the live logging.
Link for the lazy?
Btw I saw you bragging about stable your system was in another thread. I don’t know whether to be jealous or challenge you. I see my system doing some things it forgot how to do for 4 weeks or so, but I am traveling so I don’t have time to check in on the details yet. Maybe things have gotten better. I hope.
Yeah, it is running great… I’m just pissed off at the way Amazon has screwed up the echo…n
Progress report: For whomever wants to test condition evaluation, find the code at https://github.com/ady624/HomeCloudHub/blob/master/smartapps/ady624/smartthingers.src/smartthingers.groovy
No actions can be added yet, but conditions can be built with or without triggers. All conditions should work, and simple triggers should work too. Simple means “changes …”, “drops…”, “raises…”, “enters…”, “exits…”. Timed triggers do not work as of now (no trigger of the “…stays…” form), so please don’t use those yet.
Triggers are shown with a full dot, regular conditions (non-triggers) are shown with an empty dot.
if you DO NOT use any triggers, any change into any of the devices involved in the condition will lead to an evaluation of the condition. If you DO use triggers, only those devices involved in the triggers are monitored and only their changes lead to evaluations.
The “was” conditions refer to the immediately previous state/value. If you have a single condition “if door was open for at least 3 minutes” and the door closes, the evaluation will run (because we have no triggers) and will return true (provided the door was indeed open for at least three minutes before it got closed). Makes more sense when paired with triggers and the door state doesn’t change, but you’ll get it.
Let me know if things should be changed. Anything. I have done minimal testing on this, I haven’t tested the advanced option in a group (negate group) - but it should work. Evaluation seems to take around 200ms for a low number of conditions. Haven’t gone berserk on conditions yet. The “was” conditions are much heavier on resources since they rely on lists of events to figure out if state/value changed and if it did within the comparison conditions.
Last but not least, every evaluation ends in a sendPush which will put the condition, event and result in the Notifications page in the ST app. Live logging gives a bit more info, including time it took to process the event.
Please note: I’ve updated the app to make the push message easier to read. Also included event delay time (time to received) and event processing time. The processing time displayed in the live logs includes the time it takes to send the push notification, whereas the push message obviously doesn’t. This leads to some apparent discrepancies, they’re normal.
I am watching 13 temperature sensors throughout the house and for example, last event was received 606ms after it was generated, was processed (up to and not including the notification sending) in 440ms. Live logging reports 1253ms - this includes one action, the sendPush().
There were some type casting issues I resolved, not sure if many more will arise, they may. I also have to handle several data types. Currently handling “number”, “decimal”, “string” and “enum”. Need to handle “color” (a map I haven’t yet studied), “hexcolor” (technically a 24-bit value) , “three-axis” (a map of three numbers, apparently ranging 0-1024) and time.
Here’s one for those who like to tinker:
The three axis is a map of three numbers: X, Y and Z, each describing a position on one axis, relative to the start position, which is defined by the device manufacturer. There is no way currently that I know of to trigger things based on this, so we’re covering new territory here. Let’s brainstorm on a list of possible and useful comparisons.
Should we go the “easy” way with:
X axis is
X axis is less than
X axis is less than or equal to
X axis is greater than
X axis is greater than or equal to
X axis is in range (possibly the most useful one to figure out if the device rotated along the X axis)
X axis is outside of range
and repeat them for Y and Z, or figure out some more complicated comparisons?
For example, the device is “moved” or “rotated” if any of the three moves, which would require three OR’ed comparisons. Not user friendly.
Here’s an example of a trigger:
"rotated along X by " - parameter1 is a number representing a threshold to look for, in degrees (or radians for those who fancy them ha ha)
"rotated along Y by " - parameter1 is a number representing a threshold to look for, in degrees
"rotated along Z by " - parameter1 is a number representing a threshold to look for, in degrees
"rotated in any direction by " - parameter1 is a number representing a threshold to look for - this would help because you don’t have to place the device in a certain way, it will work in any direction - say you’re monitoring your dog’s door, you just attach the device to the door in any position you can.
Let the ideas pour in
Offset from a baseline, since the current values are based on the location of the sensor and are not normalized in any way. In other words the absolute values are of no use, and in order to make use of these values, one must snapshot a baseline from which to compare…
I would then trigger on a single value selection of 1 to 100%, for any single axis or trigonometric relation change between each set or two.
I just had an epiphany I was driving to Jamaica… wait, that’s not it LOL
What if the SmartThinger is smart enough (as it claims) to provide the user with a list of all devices used for threeAxis purposes. Then, for each of them, the user can go and “reset” the device, meaning that the rule itself stores information about what the “resting” position is for the device. With these three offsets in hand, I can then make much more meaningful comparisons like:
"X rotation is " so many degrees
"Y rotation is " so many degrees
"X rotation is in range "… etc. you get the idea
Also, for triggers, “rotates along X by so many degrees”, or “rotates by so many degrees” and I’d be looking at all three axis.
Yeah, I just came to the same conclusion. Absolute values are meaningless. But I’d not go with 0-100%, I’d go with degrees, 0-359. And I’d still give the power user the choice to go with each individual axis, but yeah, the normal user should be able to not care in which direction it rotates.
seriously, skip the enumeration and presentation of each axis to the users (even advanced), its not like these sensors have axis arrows on them…
how are they going to figure out which movement direction is x/y/z?, I think they’ve pulled the axis display from the dth, and even if it were there, system latency is way too long to make much sense between physical movement and the tile display update.
@Mike_Maxwell how about triggers, where if I say “rotated by so many degrees”. That would compare to the previous known position. I’d need some more, like "rotated into range " 90 to 180 degrees. This would compare to the resting position. The first one, "rotated by " 90 degrees may never happen if I get too many data points during the rotation: 0 > 30 > 60 > 90 > 120. It never actually rotated by 90 degrees, when comparing to previous value. So would this be useful at all? Should I just stick to the range?
Kinda makes sense. I’ll leave only one rotation then. What trigonometric function do you see in calculating the “rotation”? Any idea before I pull my dusty geometry book out?
movement by degrees sure, but you’re going to need do the trig to abstract the axis from the ui
I’m sure there’s a 3 axis rotation formula out there, I don’t have it pasted to my forehead currently…
I think this is a pretty good starting point http://www.nh.cas.cz/people/lazar/celler/online_tools.php?start_vec=1,0,0&rot_ax=90,0,0&rot_ang=90
Since values range between 0 and 1023, each axis would have a vector size of sin(value * π / 512)
Then the three need to somehow get mixed together to figure out the relative rotation.
X, Y, Z – I’m assuming this is an accelerometer?
If so, have you had a chance to look at mood cube? That’s a smart app where you put a multi sensor inside a six sided cube, and then each time you change to a different face, a different scene is triggered.
This is a published smartapp, quite popular. I can’t personally read the code, but it would be a SmartThings code solution to what I think is the problem you’ve described. The only thing is that it may be limited to a 90° axis change, but along any of three axes.
Anyway, it might give you some ideas:
That’s awesome. Yeah, if I am to only use one rotation, I won’t be able to do that. Provided, it is one thing to figure out which face is up and another one to calculate a relative rotation from a resting position, and the fact that the intentions are completely different, I guess we could merge the two options for an even merrier rule. One single “relative rotation” seems a bit underwhelming since it won’t give you any idea of spacial direction. If I say it’s rotated 90°, it might have faced up, down, left, right or at any angle between them. I think I need to get both ideas combined