Close Garage Automation

[arrrghhh]

Hello! I have an automation for closing garage doors after a set period of time - 1 hr for one house, 4 hr for another house. This works great at the house with 4 hr configured, but the 1 hr house it does not work very well at all… Looking at the logs it appears the entities at the 1 hr house keep showing ‘unavailable’. These doors are all managed through the MyQ app, and I’m guessing the house with 1 hr door close is having problems with WiFi connectivity while the 4 hr door close house is not… I will look at possibly adding some repeaters, but I’d rather not purchase more hardware as the garage doors work fine; at least I’ve never had a problem opening or closing them with the MyQ app or the Home Assistant app. This is the YAML for the automation:

alias: Close Left Door After 1hr
description: ""
trigger:
  - platform: state
    entity_id:
      - cover.left_door
    to: open
    for:
      hours: 1
      minutes: 0
      seconds: 0
condition:
  - condition: state
    entity_id: cover.left_door
    state: open
action:
  - service: cover.close_cover
    data: {}
    target:
      entity_id: cover.left_door
mode: single

Is there a way I can more gracefully handle the garage doors becoming ‘unavailable’ and then reconnecting? It seems this is resetting the amount of time Home Assistant thinks the doors have been opened.

[Rofo (Ro)]

personally, I’d try to look at why the devices are becoming unavailable, but in the meantime, one approach you could take is to change the trigger

trigger:
  - platform: state
    entity_id:
      - cover.left_door
    to: open

To

trigger:
  - platform: state
    entity_id:
      - cover.left_door
    from: closed

Using from closed will effectively ignore the unavailable states, and assume any state thats closed not (such as unavailable) is open.

[Holdestmade]

Wouldn’t that trigger if the door went from closed to unavailable ?
What about

trigger:
  - platform: state
    entity_id:
      - cover.left_door
    from: closed
    to: open
    for:
      hours: 1

EDIT: Actually it might not work as it goes to opening first

trigger:
  - platform: state
    entity_id:
      - cover.left_door
    from: opening
    to: open
    for:
      hours: 1

[Rofo (Ro)]

Yes it would, but I’m assuming that the device isnt unavailable for more than an hour, as your trigger only fires after an hour of waiting. If it does remain unavailable for that long, then this approach wont work.

Your other suggestion is also fine, but I think also need a continious period of one state change to another for the period, to be effective, and if ‘unavailable’ happens in that time period, you get the same problem.

[Holdestmade]

Yes, I think you’re right, maybe add a state_not: unavailable somewhere, or add an input_boolean helper that turns on when the door opens and do the trigger based on that

[Rofo (Ro)]

Input boolean is not a bad idea, but the other problem you have is that whether you use that approach or from: closed, is that if the device is genuinely that flakey, then the command to close the door might also happen when the device is unavailable, and the door stays open anyway!

I have this issue sometimes with a couple of devices and discussed how to go about ‘retrying’ if a device is unavailable here:

Time an entity was in its 'on' state

I’m using the following simple trigger to action when an entity state is in that state for a certain duration: trigger: - platform: state entity_id: - binary_sensor.lumi_lumi_sensor_magnet_aq2_opening to: "on" for: hours: 0 minutes: 5 seconds: 0 But my understanding is that will only trigger once, when the 5 minute threshold has passed. I’d like to turn this into a template trigger, which effectively keeps trying the automation until the template evaluat…

Very similar use case. In my example, it was a light I wanted turning off after 5 minutes.

[arrrghhh]

Thanks for the replies - I was thinking a boolean as well, which the boolean would persist its state throughout the ‘unavailable’ times…

I think the root cause is the garage doors are far from the router, and get crappy WiFi connectivity as a result. I’ve considered putting in another repeater, but the garage doors have always worked when I ask them to open or close from the MyQ app or the HomeAssistant app - and looking at the history the ‘unavailable’ state it seems to only last for 15 seconds. So there is potential for the request to fail if I make one during those short windows, but pretty low. I only noticed when the doors were open for more than an hour and did not close automatically.

[mekaneck (Rick Auch)]

Another option would be to create a trigger-based template binary sensor that reflects the last confirmed state of the garage door.

template:
  - trigger:
      - platform: state
        entity_id:
          - cover.left_door
        to:
          - "closing"
          - "opening"
          - "open"
        id: open
      - platform: state
        entity_id:
          - cover.left_door
        to:
          - "closed"
        id: closed
    binary_sensor:
      - name: Left Garage Door Last Communicated Status
        unique_id: left_garage_door_last_communicated_status
        device_class: garage_door
        state: >
          {{ 'on' if trigger.id == 'closed' else 'off' }}

Disclose: I haven’t tried out that template and it could have errors.

Then you can set up your automation to look at that new `last_communicated_status’ entity id

[exx]

I KNOW you said you weren’t interested in purchasing more hardware, BUT –

It may not be a problem with your wifi, and could be an issue with the cloud integration.

There exists a piece of hardware (here: https://amzn.to/3PhRAEg) that will allow you to control the doors LOCALLY, via the HomeKit integration.

When I first started on the HomeAssistant path, I was also using the cloud integration - and it was horrible. Bought one of those and switched to local control, and no more problems. Not to mention there’s no delay, AND I can still control my garage door if for some reason my internet connection is down.