I am trying to setup a rule in which certain lights come on dependant on people arriving.
Scenario one - first person to arrive back, the hall, kitchen and outside lights come on
Scenario two - when anyone else arrives, with someone already at home, only the outside lights come on.
There does not appear to be any options in the presence side of things that allows for "first person back" be used in a rule.
I have tried using the following, but the only lights that come on are the outside lights. I think this is because whenever someone arrives, it changes mode to home, so trying to use mode change or a mode is redundant. I also used both sensors not present and that didnt work either.
You need to use variables to keep track of the situation, not mode.
Suppose you have a rule that uses presence to keep track of how many people are present. For every "present" event (arrival) you increment a variable, and for every "not present" event (departure) you decrement the same variable. Use a second variable to keep track of the prior value of the first variable.
After tending to the variable values, you have some logic depending on the variable values. If priorVar = 0 and currentVar = 1, that's the first person home. If prior var > 0 and currentVar > 1, that's a subsequent person home. Etc.
What this is doing is looking at whether a presence has arrived or departed, without regard to who it was, or who else may be home or not.
Notice that the starting condition for the variables should be that both are 0 if no one is home, and the rule will restore them to those values if everyone leaves. In my case, 2 of the 3 presence sensors are home, so the initial values are 1 and 2.
I just put in Log actions to show where the actions for first person arriving goes, and where actions for subsequent people arriving go.
Below, I made the third presence sensor (a virt contact) arrive, and you can see how it set the "arrival" variable to "present", and bumped up both currentVar and priorVar values.
I guess it doesn't need to set priorVar to 0 in the ELSE part, as it will become 0 when the first person arrives. So that one Simple Conditional action could be removed. What matters is that when the rule is first set up that currentVar reflects how many presence sensors are home at that moment. And the test in the ELSE-IF could be simplified, and only test currentVar > 1, since we know someone has arrived, and its not the first person.
Blimey!!!
That is some rule. Might need to read this a few times to get my head around that.
What I have discovered, which may just be a glitch of some format;
If I create a simple lighting rule to turn on the 3 lights on someones arrival, restricted between Sunset and sunrise and with mode is away, it works, and the all 3 lights come on, only for the first person home. When second person arrives it does nothing, as mode is "home" once first person is back. I then put a second simple lighting rule in to turn on the outside light on arrival of anyone, only restricted between sunset and sunrise.
How come it works in the Simple lighting app, but not when constructed as a rule? I am rather confused by that one.
You could do the same two things as rules, and the logic would work the same way, except for one gotcha (below). So, you may not need a complex rule like this at all.
The thing is that there is some indeterminacy about who does what first. For example, if Mode Manager uses arrival to change the mode from Away to Home, and Simple Lighting is testing if mode is Away and someone arrives, which gets done first? No guarantees on that. If Simple Lighting gets loaded fast enough, before the mode changes, then it works. If Rule Machine takes longer to load, then it would fail because mode has already changed.
The logic in the rule above gets around all of that, because it is not dependent at all on mode, and when it changes relative to when someone arrives and when an app runs. The other way has simultaneous things happening all caused by the same event (an arrival).
If you do use the rule above, you would want to put the test for time of day down in the middle of the rule, so that the rule continues to count how many are home irrespective of the time of day.
Another way to do this would be to have a small custom app that creates two virtual presence devices, one that reports present for the first person home, and the other that reports present only for subsequent people arriving. That little custom app would have similar logic to this rule.
If that existed, then you'd have one rule that fires on the first-home arrival, and a different rule that fires on the other arrivals. Those could be Simple Lighting or RM rules. I may whip such a thing up and put it in our public repo.
@john.wingfield
You're also not tracking 'presence' per se, as that is only concerned about whether a particular person is home or not. Instead you're trying to track 'how many' people are home, which is a totally different metric, which is why that isn't built in to existing presence. That is where Bruce's rule comes in though to store and track that number for you, so you can use it to adjust your rule accordingly.
For me, there are a couple of types of presence:
individual - is John present at the house,
general - is anyone present at the house,
In this scenario, I am after the later, which technically is the same as modes, away= no one in, home = someone in, but as above depending on processing it may change before the rule fires, so cannot use mode as a condition.
In theory using mode changes as a trigger should also work, as the first person back would cause a change from away to home, and the second person back, mode would not change as the mode is already home, but for some reason, that isn't working either. (not sure if this is because mode manager is set to change to home when "any" of the sensors arrives.
