Garage Door Automation Problems

Configuration
1

Hi There,
I am trying to automate my garage doors to automatically close and open on Life360
Device tracking, I am using a switch to set the the state of Door open or closed and Ultrasonic detector for car presence,using a ESPhome on NodeMCU, the ESPHome setup seems to work perfectly, the desired states for the entity’s are sent to HA . I have set up two groups for our two life360 tracking accounts, one group is AllAway it changes from home to not_home when we are both away correctly. the other group is OneAway which changes to not_home when just one person is away.
However I cant get the automation’s for open and close to work, I have read and tried all sorts of ideas to no avail, Can some one look at me automation’s and tell me what I am missing, Cheers

- id: '1580612369371'
  alias: Garage 1 Door Close
  description: ''
  trigger:
  - entity_id: group.allaway
    from: home
    platform: state
  condition:
  - condition: or
    conditions:
    - condition: state
      entity_id: binary_sensor.johns_car_2
      state: 'off'
    - condition: state
      entity_id: binary_sensor.rosalies_car
      state: 'off'
  action:
  - entity_id: switch.garage_1_control_2
    service: switch.toggle

- id: '1580622081620'
  alias: Garage 1 Door Open
  description: ''
  trigger:
  - entity_id: group.oneaway
    from: not_home
    platform: state
  condition:
  - condition: state
    entity_id: binary_sensor.garage_1_status
    state: 'off'
  - condition: or
    conditions:
    - condition: state
      entity_id: binary_sensor.johns_car_2
      state: 'off'
    - condition: state
      entity_id: binary_sensor.rosalies_car
      state: 'off'
  action:
  - entity_id: switch.garage_1_control_2
    service: switch.toggle
2

I would recommend using ‘to:’ instead of, or in addition to, ‘from:’.

3

Try putting the state “home” and “not_home” in quotes… I’m sure someone will comment and say it doesn’t matter… but I’ve always had better luck putting the state in quotes…

4

I got it working, the “” seemed to fix it even though they dont appear to save in the Automations.yaml file
Thats all I did and it goes, Thanks
Now i get the following error in the log

Invalid config for [automation]: required key not provided @ data[‘trigger’][0][‘platform’]. Got None. (See /config/configuration.yaml, line 16).

I cant see why as line 16 in config is

16  group: !include groups.yaml  
17  automation: !include automations.yaml
18  script: !include scripts.yaml

the only groups I have set up are the ones above AllAway & OneAway, and they work
in the automation

5

Post your automations.yaml or look for an automation with no “platform” … sometimes the actual problem is just above or below what is actually referenced… do you only use the automation editor or some manually as well?

6

Wow that was so fast and right on the mark. Somehow had deleted Platform from the door close automation.
It all works now, but the Life 360 states are slow to change and go from Home thru moving driving and then away when you stop. the same but opposite order coming back home. This makes the automation slow to respond, Is there any way to get Life 360 to just publish home and not_home or HA to interpreter
the various states to just home and not_home?

7

Use the person component and put multiple trackers in it… maybe a router based one or ping so it truly knows if you are home or not

Also you will want to use “consider_home: 180” or something like that so if your phone goes to “sleep” for a minute it doesn’t mark you away and open your door

8

Consider_home is a device tracker setting though not person

9

Thanks will work on that over the next few days. Cheers

10

I think you might miss initial_state: true… if it is not present in automation it needs to be first triggered manually to work. Here is sample of my working automation for coming home:

- alias: 'Mirek returns home'
  initial_state: true
  trigger:
    platform: zone
    entity_id: device_tracker.life360_mirek
    zone: zone.near_home
    event: enter
  condition:
    - condition: state
      entity_id: sensor.mirek_car_presence
      state: 'Garage is empty'
    - condition: state
      entity_id: sensor.garage_mirek
      state: 'closed'
  action:
    - service: script.toggle_mirek_garage_door

Please note that I’m checking following conditions:

  • I’m not home (quite obvious)
  • my garage is empty (so if I’m coming home with my wife it does not trigger opening my garage)
  • garage is closed (I can only toggle garage door, so if by accident these are already opened, I do not want to close them while driving in).

Also for triggering automation I rather use event: enter from Life360 integration than changing state of sensor or device tracker.

11

Thanks or the different ideas on this, I will try it out soon,

12

I believe the whole “initial_state: true” thing being required with a new automation was some sort of a bug (trying to find the post on it ) but it has to do with the restore of the state after reboots… any automations I create are enabled normally even without that… the only downside to that is if you disable an automation due to an issue… then restart a week or two later and forget you disabled it, it will now be on again…

13

That is entirely incorrect.

you don’t need the initial_state: at all unless you absolutely want it to always be turned on after a HA restart no matter what the state was prior to the restart.

If you leave it out the automation will default to ‘on’ at inception and then will always be restored to the state it was in prior to a restart.

There is no need to at all to manually trigger anything without the initial_state: option set.

14

@finity I might be wrong (English is not my native language), but this flag relates to enabling or disabling automation not its internal state (e.g. it does not force automation to start without proper trigger after home assistant restart). As documentation explains:

When you create a new automation, it will be enabled unless you explicitly add initial_state: false to it or turn it off manually via UI/another automation/developer tools. In case automations need to be always enabled or disabled when Home Assistant starts, then you can set the initial_state in your automations. Otherwise, the previous state will be restored.

So obviously I was wrong stating that automation without this flag needs to be triggered manually. I should say it might need to be enabled manually.

To me it means you can enable/disable automation using this flag and sometimes automation might be disabled after home assistant restart. This is exactly the case I experienced in the past, spending days troubleshooting one automation that did not triggered whatever I did… all was sorted out after adding this flag to code. Perhaps I not intentionally I disabled it and this state was preserved between restarts. Anyhow, unless you want to have additional level of control over your automations, adding this flag should not hurt…

15

I kind of agree…

The “state” of an automation is either ‘on’ or ‘off’ so it depends on what you mean by “internal state”.

If by that you mean whether or not the automation is in the process of actively running actions or whether the automation is ‘on’ or ‘off’ (IOW, if it is in the enabled/disabled state and can be triggered to run) then I can agree with you.

The flag makes no difference at all to whether the automation is actively running it’s actions or if it can be run (state = on or off).

It only has to do with determining the state of the automation on HA restart. That’s it. It has no other effect at all on the automation after the restart is completed successfully.

True, but only on a restart of HA (or on reloading the automations which I haven’t really mentioned).

Once HA has completed the restart/reload then that flag has no effect. It isn’t used to enable/disable the automation during run time.

only if the automation was disabled before HA restart.

agreed as long as you fully know what the effect that this flag has on the functioning of the automations.

if you always expect the state of your automations to survive restarts then you shouldn’t add the flag.

If you always want them to be on or off after a restart then you should use the flag with the appropriate option (true/false).

Now, all of that said, there was a time when automations would all be set to a default state of “off” if the restart of HA didn’t complete successfully. I’m honestly not sure if that’s still the case or if that “bug”/result was changed or not.

So if your automations don’t work as expected, especially after a HA restart, then it’s always prudent to check that the state of the automation is ‘on’.

But, especially in the later HA versions, this shouldn’t typically be a problem.

16

So I had something like this set up once before and my biggest issue was the times I have driven past the house and then had to close my door. I have even had the door open when I would enter my home zone and close if I left the zone within a min.
Does anyone know of a simple way to have HA send a notification when a person enters a specific zone that then asks if you would like to trigger the door or ignore it? I know it’s an extra step but I feel like it would still be useful. Also, it would avoid some of the extra drives I’ve done in the past just to avoid my home zone. haha