I'm just new to this and I'm reading the documentation, but I just want to be sure that my statement building is correct. In this statement On the ELSE-IF, do I need to do the presence stuff again, or could I just do the "ELSE-IF Mode=Home" and that would be good since I already qualified presence to start the IF statement? I built this, then thought "I probably don't need the presence stuff again", and then thought it probably doesn't hurt? Or is there a better way to do it entirely?
Your rule only triggers when one of those three sensors becomes present, and both your conditionals check, in part, for "AJ Present OR Heidi present OR Jonathan present" (i.e., one being present--or more, but at least one). Your rule actions wouldn't be running if at least one weren't present since you're triggering on one of those three becoming present. Therefore, not only can you eliminate the "AJ Present OR Heidi present OR Jonathan present" from your ELSE-IF, you can eliminate it from your IF THEN, too. (But this depends on your triggers; had you use "changed" instead of "arrived," this would be a different story.)
To directly answer the ELSE-IF question, it's not clear to me where the question comes from here, but this explanation may help: in an IF THEN ... ELSE-IF ... ELSE block (where you can have zero or more ELSE-IFs and ELSE is optional), only at most one of those (the IF, one of the ELSE-IFs, or the ELSE) will execute, the first one that matches (i.e., where the condition evaluates to true; the green or orange "TRUE" and "FALSE" is RM telling you the current evaluation as a hint, by the way). So, sometimes, you can leave conditions out of an ELSE-IF because they don't matter or that condition would have been "caught" by a previous IF or ELSE-IF. But as is often the case, the answer here depends on exactly how you wrote your rule--the entire rule, including triggers and actions ... and, of course, what you actually want to happen under what conditions.
1 Like
Well... durr (on my part). I thought I had the trigger as ANY arrives. I wasn't even looking at the trigger when I posted this and your answer is obvious because of my oversight. Redundancy aside, is the action formatted correctly if my trigger is "ANY arrive home"?
I hate feeling stupid. 
I updated it. Now does the action make more sense as is?
Quick question, is there any condition where one of you "arriving" would not result in them being "present". I ask this because to me the check to see if one of you is present is completely redundant if the rule is being run. To me it seems that the only if checks should be mode.
Now if you want individual and personalized notifications then you can check for the individual person, but that will get complicated pretty quick.
I think you are both right. :\
You did, basically. A "Sensor 1, Sensor 2 any arrives" trigger should be identical to "Sensor 1 arrives OR Sensor 2 arrives." In fact, I might prefer the second: there was a bug (?) a while back where the first trigger would still match--thereby running your actions--when any sensor changed and one happened to still be present (e.g., had last arrived), or at least this was true for some attributes.
Looks like the conditionals are the same as the original? Possible bug aside, these should still only be running when any of the sensors are present, so the "AJ Present OR Heidi present OR Jonathan present" portion of the condition can be eliminated--if you want to save clicking. If you don't, it's harmless to leave in. You know it's true already or the actions wouldn't be running in the first place, but it doesn't hurt to check. (And again, given the "single 'any' trigger' issue, you actually might want to leave it if you keep that trigger...)
The "arrived" trigger matches the "presence" attribute becoming "present." (It's a bit confusing that the name doesn't match either the attribute or its value, but I suppose it's an intuitive description of what's happening.) So, a trigger of Sensor 1 arrives OR Sensor 2 arrives will always result in a condition of Sensor 1 present OR sensor 2 present being true in the actions, if that's the question being raised here.
Yeah. after I read it when I was editing it, I thought a lot of this. I modified it to not include the people arriving again. I'm coming from SmartThings and I'm not used to this kind of flexibility (or needing WebCore to get close to it). Here's what I changed it to.
That seems good to me. Is it working as intended? You can check by manually manipulating the presence sensors. Also you may want to control the mode control not manually like you are doing here, but rather via the mode manager.
I also would take a look at this app which will make your life easier and/or improve presence detection:
For your use case you could combine the three presence sensors into an "Overall" presence and then use that abstracted "Overall" presence in rules.
How can i manipulate the presence sensors?
That looks good to me, too! I'll repeat the warning others have said about not relying on presence to automate things like locks or garage doors, but (if your sensors work reliably) I trust your own judgement there. 
(EDIT: On that note, it looks like you're unlocking a door and opening the garage when you leave? EDIT 2: D'oh, nevermind, not really, just depends on the mode...)
1 Like
I don't think so, this rule only handles when someone arrives, just depending on the current mode it does different things.
I've never had Life 360 false positive on me and my phone would blow up if the garage opened when i want there. Add to the fact that it is a condo complex where i know all my neighbors, and I'm ok with the risk! 
Thanks everyone for helping me think straight!
No this is on arrival.
Yep, I got confused! 
(Moments after twice stating myself what the trigger was? Yes.)
1 Like
If i do that, do i have to put them all back in sync after?
Does not really matter in my experience, they will be fixed next time the geofence is triggered (in or out), but yes for best practice return them to the state they should be in. Remember these are just Hubitat abstractions of the L360 data, not the L360 data itself.
There is another subtlety that you should be aware of. Triggers are events, not conditions, such that no two triggers will happen simultaneously.
So, after one trigger event happens, while a process thread is running the rule on that first trigger, another of the trigger events could occur, such that you now have multiple process threads running the rule concurrently. You have no control over the scheduling, no control over which thread will finish first, etc.
Just bear this in mind.
If I am understanding this correctly, then he may have this rule running up to three times when he just wants it to run once correct?
If this is the case, you can get around this with the community app I listed above to combine the presence sensors.
Yes.
I probably, I haven’t studied that app. The point I was trying to make is that triggers are independent events that can trigger the rule, independently.
1 Like
