having separate arrive home and leave home automations, I was trying to combine those into 1…
by leaving out the to: home and to: not_home in the triggers, and having a template tell me which the state was on the state change.
unfortunately this automations triggers every few seconds so took me through the notification limit within no time ;-(9
cant this be done? I seem to recall a double trigger notification, using these 2 states, but I cant find any more, and my efforts so far have not been succesful. Must be so simple, but I cant find it right now, please have a look with me ?
What you have seems fine. If it’s triggering every few seconds then the states of those device_trackers are changing that often. Is it possible they have more states than just ‘home’ and ‘not_home’, like zone names, other states like ‘moving’, etc.? I would look at the history of those device_trackers to see if they’re changing a lot unexpectedly.
if I look at the notifications, they are truly and constantly triggered by ‘home’. So its not even the trackers being ‘flapping’ between home and not_home, but a constant triggering of the state ‘home’. As if they’er checked to Be home, not change state to: home
Maybe add a for: statement? Looking at the stream of notifications, ruling out lets say 30 seconds would already make a huge difference.
think this was the automation I saw before, used for a group here, but could be used for separate identities i suppose:
- alias: presence_detection
initial_state: 'on'
trigger:
- platform: state
entity_id: group.family
from: 'not_home'
to: 'home'
- platform: state
entity_id: group.family
from: 'home'
to: 'not_home'
would turn into something like:
trigger:
- platform: state
entity_id:
- device_tracker.daughter1
- device_tracker.daughter2
- device_tracker.daughter3
- device_tracker.daughter4
from: 'not_home'
to: 'home'
for:
seconds: 30
- platform: state
entity_id:
- device_tracker.daughter1
- device_tracker.daughter2
- device_tracker.daughter3
- device_tracker.daughter4
from: 'home'
to: 'not_home'
for:
seconds: 30
This is my full automation for presence alerts. I don’t get any unwanted alerts with this one and it also handles transitions between zones, not just home / not_home.
- alias: Presence Tracking
trigger:
- platform: state
entity_id:
- group.group1
- group.group2
- device_tracker.device1
- device_tracker.device2
- device_tracker.device3
- device_tracker.device4
action:
- condition: template
value_template: "{{ trigger.to_state.state is not none }}"
- condition: template
value_template: "{{ trigger.from_state.state is not none }}"
- condition: template
value_template: "{{ trigger.to_state.state != trigger.from_state.state }}"
- service: notify.slack_notify
data_template:
message: >-
{%- if trigger.to_state.state == "not_home" -%}
{{ trigger.to_state.attributes.friendly_name }} left {{trigger.from_state.state}}
{%- elif trigger.from_state.state == "not_home" -%}
{{ trigger.to_state.attributes.friendly_name }} arrived at {{trigger.to_state.state}}
{%- else -%}
{{ trigger.to_state.attributes.friendly_name }} left {{trigger.from_state.state}} and arrived at {{trigger.to_state.state}}
{%- endif -%}
Ok, I stand corrected. Back to basics! Here is a snippet of the description of the state trigger from the docs:
Triggers when the state of a given entity changes. If only entity_id is given trigger will activate for all state changes, even if only state attributes change.
By “if only entity_id is given” it means to: and from: (and possibly for:???) are not specified. So, in this case, if any attribute changes (e.g, GPS position), this will also cause a trigger. Now that I read it again I do remember reading this before. D’oh!
ah yes, I think somehow that was causing the flood… stopped after changing that. Talk about staring in the eye.
wonder how this would have passed all config and yaml checkers…
and yes ive added this (@NotoriousBDG 's conditional value_templates) too now.
I try to avoid as many ‘unknown’ states as often as possible by adding conditional value_templates. What i don’t understand here, is how this would prevent the attributes triggering that aren’t value_templated.
I still believe that can only be done, by stating the triggering states in the trigger? and then value_template unknown states under the condition.
please correct me if im wrong.
btw @NotoriousBDG, how do you prevent the network (dis)connecting of the phones that constantly happens? Do you have set the consider_home: on the device_trackers? Since I see you dont have the for: trigger set in the automation?
this is what I have set:
interval_seconds: 20
consider_home: 60
but it still allows the automations to trigger when I havent left the house…
Well, technically speaking, they don’t stop the triggering. But they do prevent the actions from running. And it does this mainly by only allowing the actions to run for changes where the actual state changes (trigger.to_state.state != trigger.from_state.state).
Remember, triggering decides when the automation will run, and conditions decide if the automation’s actions will run (when triggered.) A state trigger will trigger when any of the entity’s attributes (including its state) change if “to” and “from” are not specified.
BTW, I would move the conditions from the action part to the condition part, and simplify it into one template:
trigger:
...
condition:
- condition: template
value_template: >
{{ trigger.from_state.state is not none and
trigger.to_state.state is not none and
trigger.to_state.state != trigger.from_state.state }}
action:
...
But that’s really more a matter of style than function.
ha, I suppose I didnt read @NotoriousBDG 's post closely enough cause thats exactly what I had done already, albeit in 3 separate conditions .
for security’s sake, and stop reaching the notification_rate limit, I include:
- condition: state
entity_id: input_boolean.notify_presence
state: 'on'
getting back to the double trigger: wouldn’t it save resources to limit the automation to listen to these triggers only?
my automation still triggers too often, apparently the iPhones continuous flapping (to save battery…) isnt tackled by the for: seconds: 30 i have set.
couldn’t any template be made calculating a time difference within which the automation is not to fire?
or, other approach, could any setting on the device_trackers be set to prevent this from happening? I can up the consider_home time frame, but fear the tracker would become unresponsive to being useless…
If you know you only want to trigger on certain state changes, then yes, it would make sense to use to and/or from. And that has the added benefit of not triggering when only an attribute (and not the state) changes. The end result would probably be that the automation triggers much less often, and hence should use less system resources that way. (Of course, behind the scenes, there’s still code running on every state/attribute change of every entity trying to figure out what should and shouldn’t run. So the benefit might not be as big as you might think.)
It’s kind of hard to know exactly what to do until you better understand how the states of these devices are actually changing. Is it just attributes that are changing often? Or does the actual state change often, too? I still think it would help if you used the grep example I provided. Maybe capture that output to a file and analyze it a bit. Once you know what the entities are doing, I think you’ll have a better chance of properly handling them. Or, better yet, somehow changing the way they behave in the first place.
Hope this is not too much asking, but could you provide the complete code for that please? this is new to me and ive not grepped text to a file before…
i take it for device_tracker.daughter1 it would be:
I primarily rely on Life360 and Google for location, so this isn’t an issue for me. I initially started with nmap, but I don’t really rely on it much anymore because it’s unreliable on it’s own.
I assume you’re using nmap or icmp based on your symptoms. I have consider_home set to 600 and it still fires false positives. I suggest adding a second or third method for tracking each device, then you can use a group to combine them. That should eliminate most of the flapping between zones.
The other thing that I did, was to increase the size of my zones to help weed out false positives from the gps methods. For example, my home zone has a radius of 400.
Agree, that would be a bit cleaner. The current state of that automation doesn’t need it in the action section.
Here is a snippet of the description of the state trigger from the docs: