I have created a bunch of automations doing all sorts on things on my RPi (running 0.99.2), but I’ve run into an issue I can’t figure out. I have an automation I am running every morning between 7:00 and 11:00 to remind me of something, using a shenzhen_neo as a toggle. If I am home, I make an announcement over a Sonos speaker. If not, I send myself an SMS message. It all works fine if i don’t leave the house during the announcing period. Today I waited for a couple of announcements on the Sonos and then left hoping I’d get text messages…but I received nothing.
Here’s my automation fragments:
When I am home:
trigger:
platform: time_pattern
minutes: "/15"
seconds: 15
condition:
condition: and
conditions:
- condition: time
after: '07:00:00'
before: '11:00:00'
- condition: state
entity_id: switch.shenzhen_neo_electronics_co_ltd_power_plug_12a_switch_2
state: 'on'
- condition: state
entity_id: person.steve
state: 'home'
When i am not home:
trigger:
platform: time_pattern
minutes: "/15"
seconds: 15
condition:
condition: and
conditions:
- condition: time
after: '07:00:00'
before: '11:00:00'
- condition: state
entity_id: switch.shenzhen_neo_electronics_co_ltd_power_plug_12a_switch_2
state: 'on'
- condition: state
entity_id: person.steve
state: 'away'
Any reason why the time_pattern won’t trigger any longer for the 2nd case?
You’re not the first to make that erroneous assumption. There are many threads here where people thought the same thing. Why? Probably because it’s quite natural to say you are ‘away’ when you are not home.
Although ‘not_home’ is perfectly logical, our vocabulary is sufficiently comprehensive to endow that state with its own name (as opposed to negating another term ‘home’ to create ‘not_home’).
For example, if a switch is not on we say it is off. What we don’t normally say is the switch is ‘not_on’.
I see what you’re saying, but that’s not really the issue here. The issue, and where many people trip up at first, is the UI doesn’t always show the actual state of the entity. It shows a “pretty/localized” version of it. So, in this case, when the state is 'not_home', the UI shows “Away.” Or for a binary_sensor whose device class is window, it shows “Open” when the state is actually 'on' and “Closed” when the state is actually 'off'. The important point here is, when writing automations, you need to use the actual states of entities, not just how they appear in the UI. The easiest place to see them (or, at least, the current states of the entities in the system) is on the States page. Also the documentation often explains this, too. E.g., for device_tracker entities, it’s explained here. It’s also indirectly explained on the Person doc page.
I’m suggesting the use of ‘not_home’ was a poor choice for Home Assistant’s vocabulary. It’s the negation of a positive state, like having switches and binary_sensors with: on not_on
That would be acceptable if there was no commonly accepted word for the opposite of being on or home. However there are and they’re off and away. Happily, off was adopted but unfortunately away was not.
Yes, the use of device_class can lead to end-user mistakes because the displayed state name differs from the actual state name (and typically both of the two states get translated: open/closed, connected/disconnected). Device_tracker doesn’t support device_class yet it still performs a conversion and just for one of its two states (‘not_home’). That’s awfully unique behavior and small wonder it leads to templating errors.
Ok, I see what you mean. But, actually, it does translate the home state; it translates it to “Home”. And since states are case sensitive, using 'Home' would not work. It needs to be 'home'. (And, although I haven’t tried it, and wouldn’t even know how if it was possible, I suspect when other languages are used, it won’t be “Home” anyway.)
Not sure changing a word’s case is in the same league as converting not_home to Away. Anyway, changing the state’s case is moot because it’s uniformly applied to all states for presentation purposes.
Heck, even a lock’s states are locked/unlocked as opposed to locked/not_locked.
location_name:
description: Name of location where device is located (not_home is away).
example: ‘home’
Anyhow, it’s all academic; this anomalous ‘negation of a positive’ has been around for so long that’s it’s entrenched. Let it stand as an initiation rite for future users of the device_tracker.
Tell someone that twice and they’ll look at you funny. I’m not away but I will be not home! A quantum state of presence?
I should’ve qualified my statement regarding zones but I think you understand the gist of my meaning: the UI won’t render not_home as Not Home, it will be Away. If this is its baseline behavior then away would’ve been an apt term for not being present at home (as opposed to not_home). It also happens to be the term that’s been used for decades by security systems. and its meaning is well understood.
Only if they ignored my previous post where I explained that ‘away’ means not at home and not in a predefined place. Whereas not_home covers both of these potential types of place you could be when you’re, ummm, not home.
The ui never displays not_home because the point of the ui in this instance is to say where you are, not where you’re not. I am home, I am at work, I am at Buckingham Palace, I am elsewhere (away). But the actual state refers to presence detection, for which we only need to know am I home, or not (regardless of whether it’s work, Buckingham Palace or anywhere else).
When you are elsewhere the device_tracker’s state is not_home yet could easily be away since that word aptly describes your current location: not at work, not at home, not at Buckingham Palace, simply away from home.
haha great discussion !
to illustrate this somewhat with a real life sensor in my setup (rather than it only being academic)
name_background_color:
value_template: >
{% set person = states.device_tracker.life360_name %}
{% set zones = states.zone | map(attribute='name')|list %}
{%- if person.state == 'home' %} #008000
{%- elif person.attributes.country_code and person.attributes.country_code != 'nl' %} white
{%- elif person.state in zones or person.state in ['moving', 'driving'] %} #643aac
{%- else %} #555B65
{% endif %}
sets colors for my buttons when being:
home
in a another country than homeland
in a zone, or moving/driving
else, being none of the above, also known as not_home
have these also for setting a picture,
{% set person = states.device_tracker.life360_name %}
{% set zones = states.zone | map(attribute='name')|list %}
{% set name = person.entity_id.split('360_')[1] %}
{% if person.state in zones %} /local/tiles/family/{{name}}_zoning.png
{% elif person.state in ['moving','driving'] %} /local/tiles/family/{{name}}_not_home.png
{% else %} /local/tiles/family/{{name}}_{{person.state|lower|replace(' ','_')}}.png
{% endif %}
and an overlay…
{% set person = states.device_tracker.life360_name %}
{% set zones = states.zone | map(attribute='name')|list %}
{% if person.attributes.country_code and person.attributes.country_code != 'nl' and
person.state not in zones and
person.state not in ['moving', 'driving'] %}
/local/flags/{{person.attributes.country_code}}.png
{% else %}
/local/zones/{{person.state|lower|replace(' ','_')}}.png
{% endif %}
and, if you must know, this is the button that uses it all:
Given that not_home can have more than one possible meaning (outside of home in either an unknown or known location), then the following nomenclature is equally functional:
I’m not at home nor in a defined zone:
State = away
UI = Away
I’m not at home but in a defined zone (Buckingham Palace):
State = away
UI = Buckingham Palace
A quantum state of presence?