We are in an apartment block so auto lights - not under our control !
I scanned the existing answers (didn’t read in depth, though) and I don’t think they’re answering your question. Or at least they struck me as too complicated. (But, again, I didn’t really read them, so maybe I drew the wrong conclusion.)
In any case, I would implement what you want like this:
- trigger:
platform: state
entity_id:
- device_tracker.me
- device_tracker.wife
to: home
condition:
condition: template
value_template: >
{{ trigger.entity_id == 'device_tracker.wife' or
not is_state('device_tracker.wife', 'home') or
as_timestamp(now()) - as_timestamp(states.device_tracker.wife.last_changed)
< 5*60 }}
action:
service: light.turn_on
entity_id: light.hall_light
This is triggered by either of you arriving home. However, the condition will let the action run (i.e., turning on the hall light) only if one of the following is true:
- Your wife is the one who arrived home.
- If not the above (i.e., you arrived home), and your wife is not home.
- If not the above (i.e., you arrived home and your wife is home), but she arrived home within the last 5 minutes.
Note that, as far as HA is concerned, you both can’t arrive home “together.” Each entity changing state will create a separate event, and each event will be processed separately. So if you do arrive (approximately) together, the automation will be triggered twice, once for each of you. But the condition should handle these events properly, no matter which one is processed first.
1 Like
Hi,
the way i solved it:
- Put both device_trackers in a group
- trigger: group state changes from ‘not home’ to ‘home’
Works nicely for coming home and leaving home.
Im on mobile right now, will post the yaml code tonight
Thanks for this, re-read your notes and looks good. Now to try it.
Phil, I love the elegance of your proposal but I cannot get it to compile. I find the error messaging most hyeroglyphic so am lost as to the necessary change. I get "Invalid config for [automation]: required key not provided @ data[‘action’]. Got None required key not provided @ data[‘trigger’]. Got None. "
The issue is in the condition section, if I remove it it’s fine.
While sometimes these nested automations are the tersest way to accomplish things, they’re not always the easiest, most human readable format.
Personally, and this is a biased opinion, I’d go take a look at my solutions above where I have individual sensors for each my wife and I (home / not_home), as well as a joint sensor that judges which (if any / both ) of us are home and reports accordingly.
With these in place, it’s then SUPER easy to put in place quick rules to do what you’d like…
This is very easy to do with node red, have you used it? If not, you should try it.
Sorry about that. Typo. I’ll fix it. (The action section is indented incorrectly.)
1 Like
I don’t disagree that simpler is better. However, I took a quick look at what you provided, and I fail to see how it meets the requirements. I.e., it doesn’t answer the original question.
Ian, I see that @pnbruckner has already solved this but …
I was going to give you a solution that you could read, understand and adapt as your needs grow.
Also Phil is a jinja ninja (the code formatting inside the standard yaml passed to the jinja interpreter at run time).
I’m afraid I don’t understand ‘that’ a first or even second glance (I shall take it away and store it with ‘my precious’ and study it in great detail)
Anyway here you go : -
input_boolean:
ib_occupancy_teresa_in_bed_bit:
name: Ian Just Too Late
#initial: 'off'
icon: mdi:hotel
automation:
### hall light trigger for arrival
- alias: au_occupancy_hall_light
trigger:
- platform: state
entity_id: person.ian
to: 'home'
- platform: state
entity_id: person.teresa
to: 'home'
condition:
- condition: state
entity_id: input_boolean.ib_occupancy_teresa_in_bed_bit
state: 'off'
- condition: state
entity_id: sun.sun
state: 'below_horizon'
action:
- service: light.turn_on
entity_id: light.hall
- condition: template
value_template: "{{ trigger.entity_id == 'person.teresa' }}"
- service: script.sc_occupancy_teresa_in_bed_delay
### reset teresa in bed bit
- alias: au_occupancy_leaves_house
trigger:
- platform: state
entity_id: person.teresa
to: 'not_home'
action:
- service: input_boolean.turn_off
entity_id: input_boolean.ib_occupancy_teresa_in_bed_bit
script:
#script to allow variable delay between your wife coming home and your presence NOT putting the light on
sc_occupancy_teresa_in_bed_delay:
alias: Delay To Ignore Ian Coming Home Script
sequence:
- delay: "00:05:00" ### time in hours:minutes:seconds
- service: input_boolean.turn_on
entity_id: input_boolean.ib_occupancy_teresa_in_bed_bit
if you’ve read up on packages then you will know that you would need to put something like the below in your configuration.yaml (the below points to a directory called ‘packages’ (in this case) which you would also have to create (please yourself as to naming). I tend to use a LOT of brackets so I’ll stop now. The line, with two spaces before it must go under homeassistant as shown, if you have other things under homeassistant just place it where you like but UNDER homeassistant and ABOVE the next line in the file that is NOT indented, This will tell HA to look at ALL packages under this folder (and recursively through any sub-folders underneath it so you can organise your stuff, I’d call this ‘occupancy.yaml’ (see naming of it’s entities, I kown I said I’d stop … ) : -
homeassistant:
packages: !include_dir_named packages
So the package, explanation : -
An Automation is triggered by stated conditions becoming true and runs through until either something doesn’t process correctly or a condition stops it’s execution.
The Automation is triggered by either (and both) the person.ian entity and/or the person.teresa changeing one/both states to ‘home’
With a condition that the “teresa in bed bit” MUST be off
And the condition that the sun must be below the horizon
So conditions met let’s see the actions
It now puts the light on light.hall
Then it checks another condition, aborting if not true
was teresa the trigger that caused it to fire ?
If so start the timer ### so go to the script
run a delay of 5 mins
Then set a bit to say teresa is in bed
This set the bit (right at the top of the file that stops the light coming on
This ‘may’ cause some disruption if teresa goes out the front door to come back but she’d have to be ‘away’ to come back anyway
Going away triggers the other automation that resets teresa’ in bed bit
You see how much smaller phils automation is ?
But, as @Markus99 says it’s less easy to understand and maintain as a consequence.
You pays your money you takes your choice.
Anyway I did what I said I’d do
Enjoy both
Cheers
Just noticed that Phil’s solution puts the light on day or night. (he likes to feed me these crumbs so I don’t feel completely worthless :-
)
Edit: Sorry, noticed a couple of errors, corrected it now
Except, if teresa comes home before sunset, the in bed bit doesn’t get set - Dang, more thought needed.
And this is a good example of when using packages for something relatively straightforward (tho using a modestly complex template) tends to get out of hand. Because now you have a complete package file that is going to be used for literally one automation. If you go down that road then suddenly you have 500 package files to keep track of. Of course, it’s personal preference to a degree but packages aren’t a one-size-fits-all solution to every problem.
Hello @finity,
I would just use this as the basis for any occupancy related requirement.
But its completely up to the user. If they want 500 files then they can.
Me, I can only count upto 68 and 3/4’s
As a matter of interest, how is your HA deployment structured ?
And has it changed any over the last couple of years ?
I’m not blowing smoke as I think it would be of interest for aspiring HAers to glimpse a possible goal.
They may decide not to go that way, again their choice.
Reply to the OP (this may be a 24 hours too late).
I think the idea of putting both you and your wife in a “group” as per @rapht0r’s post is such a brilliant, simple idea. I use this for other automations
I’ll tell you how I overcame a similar issue (when I had no idea what ‘data_template’ and ‘input_boolean’ s were). Note that it relies on your wife activating something when she goes to bed. This could be a Google/Alexa command, light switch, no motion for x minutes, Android phone on charger, NFC, etc. That could be a deal breaker!
Option 2A:
It centred around “sleep time” status. i.e. if one of us were in bed then we would activate “sleep time on” this was a script that disabled motion sensor triggered lights, lowered brightnesses on night lights, turned off all lights in the house, and other useful. Then the script “sleep time off” would do the reverse (turn on motion automations, etc).
Option 2B
If I had my time again, I would have used input_boolean for sleep time (input_boolean.sleep_time) and had this as a condition for the bedroom motion sensors. For you, it would look like: (excuse the lack of code, it’s just a concept)
trigger:
- husband goes from not_home to home
- wife goes from not_home to home
condition:
- input_boolean.sleep_time state is ‘off’
action:
- hall lights turn on
Okay, so she arives home in the day.
When Sunset Occurs (well 5 mins before so I can reuse the same trigger but adjust to suit yourself) it triggers the script to ignore Ians light turn on
Revised package : -
input_boolean:
ib_occupancy_teresa_in_bed_bit:
name: Ian Just Too Late
#initial: 'off'
icon: mdi:hotel
automation:
### hall light trigger for arrival
- alias: au_occupancy_hall_light
trigger:
- platform: state
entity_id: person.ian
to: 'home'
- platform: state
entity_id: person.teresa
to: 'home'
condition:
- condition: state
entity_id: input_boolean.ib_occupancy_teresa_in_bed_bit
state: 'off'
- condition: state
entity_id: sun.sun
state: 'below_horizon'
action:
- service: light.turn_on
entity_id: light.hall
- condition: template
value_template: "{{ trigger.entity_id == 'person.teresa' }}"
- service: script.sc_occupancy_teresa_in_bed_delay
### sun sets trigger teresa is in bed anyway
- alias: au_occupancy_sunset
trigger:
- platform: sun
event: sunset
offset: "-00:05:00"
condition:
- condition: state
entity_id: person.teresa
state: 'home'
action:
- service: script.sc_occupancy_teresa_in_bed_delay
### reset teresa in bed bit
- alias: au_occupancy_leaves_house
trigger:
- platform: state
entity_id: person.teresa
to: 'not_home'
action:
- service: input_boolean.turn_off
entity_id: input_boolean.ib_occupancy_teresa_in_bed_bit
script:
#script to allow variable delay between your wife coming home and your presence NOT putting the light on
sc_occupancy_teresa_in_bed_delay:
alias: Delay To Ignore Ian Coming Home Script
sequence:
- delay: "00:05:00" ### time in hours:minutes:seconds
- service: input_boolean.turn_on
entity_id: input_boolean.ib_occupancy_teresa_in_bed_bit
Petro would hate someone having to set a bit so as not to be disturbed and I certainly agree in this case, someone comes home tired they are not going to go to an interface to do this, just fall in bed.
There is a thread here about bed occupancy, but I find that a bit weird.
I use an entry directly in the configuration.yaml file for things that are one-off integrations that need (or I want - and most things I want…
) to be configured manually.
this is the basic structure of that file with most of the sub-entries removed:
homeassistant:
packages: !include_dir_named packages
customize: !include_dir_merge_named customizations/
lovelace:
hacs:
map:
frontend:
config:
http:
discovery:
ssdp:
zeroconf:
history:
recorder:
logbook:
logger:
weather:
zwave:
zha:
mqtt:
python_script:
google:
panel_custom:
mqtt_statestream:
system_health:
life360:
speedtestdotnet:
For things that require multiple of the same entries (automations, scripts, groups, etc) I use !includes in the configuration.yaml like these:
group: !include_dir_merge_named groups/
automation: !include_dir_merge_list automations/
sensor: !include_dir_merge_list sensors/
switch: !include_dir_merge_list switches/
script: !include_dir_merge_named scripts/
shell_command: !include_dir_merge_named shell_commands/
panel_iframe: !include_dir_merge_named panel_iframe/
timer: !include timers.yaml
binary_sensor: !include binary_sensors.yaml
light: !include lights.yaml
zone: !include zones.yaml
device_tracker: !include device_trackers.yaml
alexa: !include alexa.yaml
intent_script: !include intent_scripts.yaml
camera: !include cameras.yaml
media_player: !include media_player.yaml
cover: !include covers.yaml
input_boolean: !include input_booleans.yaml
input_number: !include input_numbers.yaml
input_select: !include input_selects.yaml
input_datetime: !include input_datetimes.yaml
cloud: !include cloud.yaml
notify: !include notifications.yaml
weblink: !include weblinks.yaml
history_graph: !include history_graphs.yaml
input_text: !include input_texts.yaml
geo_location: !include geo_location.yaml
person: !include persons.yaml
climate: !include climate.yaml
proximity: !include proximity.yaml
and then I break those individual files out into a single file in the root config directory.
but also as you can see from that list for the things that need a multitude of entries I use a directory for those and split those up into multiple yaml files based on the function of each entry. For example here is my directory structure for my automations directory:
and lastly for the things that need multiple different platforms that logically work together to form a system then that’s where I use packages. This is my packages folder with the associated naming convention (ignore the *.old stuff):
And yes my config has changed a bit over the last couple of years but not much. I started using packages about a year and a half ago. But generally my structure has stayed very consistently the same since the beginning. If it works then why change it? 
1 Like
I have learned a lot in this thread and really like Phil’s short solution which makes sense to me (indented it compiles!) and because it’s so short it fits on one screen there is room to add comments to further increase clarity and not even have to scroll.!
I like Mutt’s file management and packages a lot and will be deploying those ideas very soon.
Thanks to all.
PS A small contribution - I see the use of sunset plus a few minutes quite often. I much prefer to use sun elevation which caters for the longer twilights of summer and short winter ones.
My intent is to use this data. It’s fairly obvious when day and night genuinely are from this data. Solar panel voltage.
Cool, however I want to watch the sunset and then turn the lights on and close the blinds.