Depends how you want to look at it. The condition that is evaluated is whether the ‘presence’ is ‘present’ or ‘not present’. So ‘This member is at Home’ works for me. Yes it might only be evaluated when the presence changes (it depends on how many conditions you have and how the Automations are implemented) but then isn’t that exactly when you need to to be evaluated?
The problem with either of your use cases when implemented using an Automation (in the new app sense) is that time intervals don’t cause the Automation to run (in the sense of decide whether to activate the payload) at the start time. So if you are already at home at 7am or 8pm they aren’t going to work. That is not because there isn’t what you call REAL ‘presence’, it is because the Automation hasn’t looked to see if you are at home at that time.
I disagree, if a time-based interval is an ‘if condition’, which means it is considered a trigger, this should work.
Either it is a bug, or the wording is wrong, there’s no other way to look at this, presence is literally ‘the state of being present’, hence its nor really ‘presence’, but a ‘change of presence’, and this is not clarified as such, it is implied by the wording, and how the API sees your state every X seconds that it should be an actual ‘presence’ condition, but it then gets refuted by the selection of icons chosen for the if conditions).
They either should fix it to be real presence, or change the wording, I don’t see it as being correct.
In the new app, it is a condition, not a trigger (these are two separate things). Whether the time range should also function as a trigger at the beginning time could be argued, but that’s not the way it currently works. If you want a time trigger use a specific time instead of a range
Well that answers that then (that’s why I said ‘if’), there’s never a clarification on how things in the automation are treated (if its a condition on itself or a trigger),
I would definitely pay for having a proper FAQ with this small details answered.
It isn’t an ‘if condition’ in that sense though. That is clear by the requirement to have other conditions alongside time periods, and by the way they are grouped separately when you have two or more other conditions. It is what is often called a restriction, and in Automations a pre-condition. However it could be made a whole lot clearer if they actually just said so.
I don’t like the choice of icons and more effort could perhaps be made with the wording. I guess they are trying to cater for a broad audience. Some users don’t grasp that ST is an event driven system and so Automations aren’t going to run unless something has just ‘changed’. It seems ST are trying to lead them into thinking in terms of arrivals and departures, even though it isn’t quite what is happening and is downright misleading once you have multiple conditions. Personally I feel they should get the icons right and include notes that explain what the conditions actually mean.
