I am having trouble understanding how to modify my “someone_home” sensor to ignore the ‘unavailable’ or ‘unknown’ states. I am using Life360 for location tracking and whenever the service is unreachable, the sensor switches to no one is home. Here’s the sensor template code. What is the right way to identify both sensors (me and my wife) and ignore unavailable or unknown?
The intent is to not change the state of the someone_home sensor if either tracker is ‘unknown’ or ‘unavailable’. If there’s a better way to do this, I am open to ideas!
platform: template
sensors:
someone_home:
friendly_name: Someone Home
icon_template: >-
{% if is_state('binary_sensor.someone_home','on') %}
mdi:home-account
{% else %}
mdi:home-outline
{% endif %}
value_template: >-
{%- if (states('device_tracker.me') not in ['unavailable','unknown']) and (states('device_tracker.wife') not in ['unavailable','unknown']) -%}
{{ is_state('device_tracker.me','home') or is_state('device_tracker.wife','home') }}"
{%- else -%}
{{ states('binary_sensor.someone_home') }}
{%- endif -%}
Just an idea, but your issue is that your template will react to all states in the parent sensor the way it is setup.
You need to make it react only specific states, but it still needs to have a state for unavailable, like when HA is starting up.
My proposal is to make a helper_boolean for each person you want to track and then use automations to set the states of that one.
The automations will only react to the states you want on the parent sensor.
That way you can have it change only on the states you want, but still preserve the unavailable state of the input_boolean and set it to what value you would like.
Thanks Wally. That’s an idea … I wanted something a little cleaner than creating additional helpers for each person. But it sounds like it would be more reliable than what I am doing.
I am playing with various methods of tracking (Life360, HA phone app, maybe some others) so I wanted to have a tracker for each person fed by various tracking methods and filter out the states I don’t want. I also have multiple zones created so it gets a bit confusing when filtering. For example, home, not_home, Amy’s House, Work are OK … unavailable and unknown not OK.
Did the service go down for you this morning? Mine went down. Triggered the Home Empty routine which wasnt a big deal cause it just turns off all the lights and they were already all off. But then when service came back up and turned off Home Empty, it turned on a bunch of lights.
I use node-red, but heres how I am trying to avoid changes to my Home Empty boolean if the status is unknown. I dont know if it’ll work though and I cant seem to fake an unknown status (thought turning my phone off would do it, but it doesnt). Left side is how it used to be. Right side is my change.
Interesting … yes, this morning a little while before I posted the original thread here, I was having problems with the service (or access to) bouncing.
In the morning, I will review your node red flow and see if I can use that same logic in my environment.
So I think it will work. I disabled my life360 entity and status went to unknown and the flow did not continue once it saw my person status was unknown.
So now if either myself or my wifes status is unknown, the home empty boolean wont change.
Yep, I’m working on that fix right now. It will cause the entities to go back to their correct state as soon as the Life360 server query works (instead of the next time the Life360 server has new data for the entity, which could be as soon as 10 seconds later.)
This issue of temporarily switching to unavailable has been mentioned a few times now. This is definitely due to converting to the newer entity-based device tracker design.
The “usual” way (I would think) to deal with this is not to use device_tracker entities directly, but rather to use something else “on top of” them that ignores unavailable and unknown states. The typical (and I would say recommended) thing is the Person integration. Then you can use those Person entities in your automations, etc.
FWIW, an alternative to the Person entity is my Composite custom integration. (I actually just updated it to also ignore unavailable & unknown states.) IMHO it has some benefits over the built-in Person integration.
Actually, after looking at the implementation of other device tracker integrations, it’s pretty clear that device_tracker entities should NOT change their state to unavailable in the first place. Rather they should simply retain their current state until they are able to update successfully.
So my original post started because I was seeing network issues as well as occasional loss of contact with the Life360 service. Sometimes I would see unavailable and/or unknown for various sensor states. TBH, I can’t remember if I ever saw a Life360 based tracker entity ever go to unavailable, but I have seen unknown.
So after all the above, I decided to try and filter out unavailable and unknown for state transitions for any of the template sensors. For example, when the network has a problem, I am seeing my Shelly devices go to unknown. That’s what led to my starting this thread.
I did manage to get a filtering in place for the template sensors:
platform: template
sensors:
someone_home:
friendly_name: Someone Home
value_template: >-
{%- if (states('device_tracker.steven_meisner') not in ['unavailable','unknown']) and (states('device_tracker.barb_meisner') not in ['unavailable','unknown']) -%}
{{ is_state('device_tracker.steven_meisner','home') or is_state('device_tracker.barb_meisner','home') }}
{%- endif -%}
I haven’t tested this extensively yet, but initially it seems to work using fake “false” states (setting location to not_home or unknown manually).
First, the PR I reference above was rejected. The standard is for an entity’s state to become unavailable when the source of that data (e.g., the Life360 server) becomes inaccessible for whatever reason, even though not all integrations follow that standard.
Second, there was a bug that prevented the Life360 entities from going back to “normal” immediately after the connection to the server was reestablished, even though they would eventually. That bug was fixed and should be in the 2022.8.1 release.
Regarding your template sensor, I don’t think it’s a good idea for the template to render nothing in some cases, which this template would. Why not just:
value_template: >
{{ is_state('device_tracker.steven_meisner','home')
or is_state('device_tracker.barb_meisner','home') }}
Or do you know for a fact the sensor won’t get updated if the template renders nothing? (I would think it could cause an error, or at least set the state to a blank string or something.)
Maybe you should use a trigger-based template instead???
Also, since this template effectively only returns true or false, wouldn’t it be better to use a binary template sensor?
