You’re mixing things a little – and I think I also led you a little astray.
Let’s work through it from one side: You want to trigger on the person state, as you’ve been doing, and then use a condition on the activity (assuming the activity state won’t change as fast as the person state which is usually the case, but just remember the assumption).
In your latest post, you need to use a template condition – you’re mixing a state condition with a template condition. It should be (that comparison at the end leads to a binary value):
- condition: not
conditions:
- condition: template
value_template: "{{ state_attr('sensor.wife_iphone_activity', 'Types') | first == 'Automotive'}}"
But you can also do:
- condition: not
conditions:
- condition: template
value_template: "{{ states('sensor.wife_iphone_activity') == 'Automotive'}}"
This is where I probably confused you, and I unfortunately can’t remember why I went for the one over the other. The sensor’s state will be only one value, but it is possible for iOS to think there is more than one activity (and hence there are also confidence levels). In that case, there will be a list of activities under the Types
attribute.
The most robust check is probably to do this, checking that the list contains Automotive
as an activity:
- condition: not
conditions:
- condition: template
value_template: "{{ 'Automotive' in state_attr('sensor.wife_iphone_activity', 'Types') }}"
See the Apple developer docs:
For example, if the user was driving in a car and the car stopped at a red light, the update event associated with that change in motion would have both the automotive
and stationary
properties set to true
.
Note that you need to check for Automotive
and not automotive
, because that is what the Home Assistant values would be – capitalised. Always best to check under HA’s developer tools what the actual state values are. I know this one is counter-intuitive, because normally that actual state will be lower case and when presented on the UI it will be capitalised – that is not the case here.
In my case, because I think it helps with readability and reuse, I define sensors and binary sensors to use in my automations.
Two of my template sensors:
pieter_activity_type:
value_template: "{{ state_attr('sensor.ceres_activity', 'Types') | first }}"
icon_template: "{{ state_attr('sensor.ceres_activity', 'icon') }}"
pieter_activity_confidence:
value_template: "{{ state_attr('sensor.ceres_activity', 'Confidence') }}"
icon_template: >-
{% if state_attr('sensor.ceres_activity', 'Confidence') == 'High' %}
mdi:speedometer
{% elif state_attr('sensor.ceres_activity', 'Confidence') == 'Medium' %}
mdi:speedometer-medium
{% elif state_attr('sensor.ceres_activity', 'Confidence') == 'Low' %}
mdi:speedometer-slow
{% else %}
unknown
{% endif %}
And a template binary sensor for driving:
pieter_driving:
friendly_name: "Pieter Driving"
value_template: >-
{{ is_state("input_boolean.pieter_driving", "on") }}
Used like this in an automation:
- alias: "Open Garage Door When Arriving By Car"
initial_state: true
trigger:
- platform: state
entity_id: binary_sensor.pieter_present
to: "on"
condition:
- condition: and
conditions:
# prevent a glitch in case the cover was recently closed
- condition: state
entity_id: cover.rhs_garage_door
state: "closed"
for:
minutes: 5
- condition: time
after: "07:00:00"
before: "23:00:00"
# i must be arriving by car
- condition: state
entity_id: binary_sensor.pieter_driving
state: "on"
# my cover for my car
- condition: state
entity_id: binary_sensor.rhs_garage_occupied
state: "off"
# proxy for the alarm being off
- condition: state
entity_id: binary_sensor.rouve_present
state: "on"
for:
minutes: 5
action:
- service: cover.open_cover
entity_id: cover.rhs_garage_door