ratgdo garage door opener obstruction sensor automation not working

[sand pivot]

This should auto close a ratgdo connected garage door opener.

triggers:
  - trigger: state
    entity_id:
      - cover.ratgdo32_9a35fc_door
    to: open
    for:
      hours: 0
      minutes: 0
      seconds: 30
  - trigger: state
    entity_id:
      - binary_sensor.ratgdo32_9a35fc_obstruction
    to: "off"
    for:
      hours: 0
      minutes: 0
      seconds: 30
conditions:
  - condition: state
    entity_id: cover.ratgdo32_9a35fc_door
    state: open
    for:
      hours: 0
      minutes: 0
      seconds: 30
  - condition: state
    entity_id: binary_sensor.ratgdo32_9a35fc_obstruction
    state: "off"
    for:
      hours: 0
      minutes: 0
      seconds: 30
actions:
  - device_id: 34e0f....
    domain: cover
    entity_id: d19e....
    type: close
  - delay:
      hours: 0
      minutes: 1
      seconds: 30
      milliseconds: 0
  - repeat:
      until:
        - condition: state
          entity_id: cover.ratgdo32_9a35fc_door
          state: closed
      sequence:
        - action: notify.email_notify
          metadata: {}
          data:
            message: Garage Door has not yet closed.
            title: Garage Door Not Closed
        - delay:
            hours: 0
            minutes: 1
            seconds: 0
            milliseconds: 0
  - action: notify.email_notify
    metadata: {}
    data:
      message: Garage Door Has Closed
      title: Garage Door has Closed
mode: single

The goal is to close the garage door if all the following conditions are met:

• the door has been open for 5 minutes
• the obstruction sensor has not been bothered for 5 minutes.

As I try to implement this, I face some problems. :

• Setting up the automation seems to work if the door is opened and then left alone. Then, it will close on its own after the 5 or so minutes.

• However, if the door is open, and then I bother the obstruction sensor so that its state changes to Problem, and then Problem Cleared, then the door will not close 5 minutes later, and seemingly doesnt close at all. However, at the same time it seems like my Action automation logic is hit, and although the Action of the Door Close is not activated, I get the Action notification that the door is not closed. It is odd to me that my actions are being hit even though the door is not closing.

IF I look at the ha -> ratgdo device logs then I see this:

• ratgdo Door open
• ratgdo Obstruction detected problem (i did this by standing in front of sensor)
• ratgdo Obstruction cleared (no problem detected)
• At this point, even 5 minutes later, the door has not closed

If I look at the ha -> ratgdo device -> obstruction entity log

• I notice that before an Obstruction detected problem is manually triggered, the Obstruction shows an OK state. After there is no longer an Obstruction, it takes a minute or two before the Obstruction sensor is back in an OK state (Maybe it is in a cleared (no problem detected) state until it gets to the OK state, I am not sure because these logs dont show much more.

If I go to the interal IP address of the ratgdo device, outside of HA, then the status that the obstruction sensor can have is OFF and PROBLEM

If I go to my automation and try to set up a trigger for the state-> entity -> obstruction (through the gui), then I see that the following states are available:
Any State
Problem
OK
Unavailable
Unknown

[buoyant lotus]

Forget about what the GUI shows, a binary_sensor entity can only be on or off (besides unavailable and unknown).

The GUI does some translation of states based on the device class of the sensor so that it why you can see “problem detected” or other states. But the yaml code for the automation will always use the real on or off states

When you go to developer tools -> states, you can look up any entity and it will show you the real (not translated) state

As to your actual issue, can you post the trace from a run where the door didn’t close but you did receive a notification?

You may have an issue where the automation is still running and it’s trying to be triggered again (which it can’t be, because you have mode: single). I’m not sure that is the issue, but I always recommend avoiding long-running or “stateful” automations. An automation should run and complete quickly. Long delays are not good

[sand pivot]

Im noticing a few different places where logs can be found. Can you elaborate as to which logs I should share?

[buoyant lotus]

If you are editing the automation, there are 3 dots in the upper right. Click that, and one of the menu options is “traces”

[sand pivot]

got it, will test in a bit and get back to you

[buoyant lotus]

That will list each of the last few times the automation ran. Pick the one where it didn’t do what you wanted

[sand pivot]

Okay so in this trace I can see that both conditions were met and yet the action was not Actioned, not sure why. The trigger was that the obstruction was clear for 30 seconds

[buoyant lotus]

Can you download the trace (upper right dots again) and share? If it’s too big to paste here you can use a site like dpaste.org

[sand pivot]

sure

[buoyant lotus]

Another suggestion is to avoid devices when picking triggers, conditions, or actions. Use entities instead. I know the GUI lists devices as the first option but it’s best to not use it.

https://community.home-assistant.io/t/why-and-how-to-avoid-device-ids-in-automations-and-scripts/605517

[sand pivot]

https://pastebin.com/gftuFV5q

[buoyant lotus]

"script_execution": "failed_single",

You have mode set to single, and the automation was already running when it was triggered again

You’re probably receiving a notification from the already-running automation and not the new one.

[sand pivot]

I will have to read up furthr on this single mode.

But, if the Actions part of the automation is being hit (evidenced by the notifications being sent), then why is that earlier automation run not closing the door, which is the first action in the Actions. (Note that without bothering the obstruction sensor, the automation works fine to close the door)

[buoyant lotus]

That’s a good question. Can you share the trace previous to the one you just shared?

Btw, here are the docs on the modes: https://www.home-assistant.io/docs/automation/modes/

[sand pivot]

second to last:
https://pastebin.com/EppEyJ5P

It runs one second prior the the latest that I sent earlier, and the trigger is also the obstruction sensor

The one previous to this^ is triggered by the Open door, runs during the same minute, and fails due to a condition failure. <- and the one previous to this is triggered by the open door as well(first one), and runs a minute earlier. Only this first one seems to complete its logic.

[buoyant lotus]

Ya I would need to see one that isn’t “failed single”

This is one of the issues with long-running automations. You can end up with an absolute mess of automations. You could at least change the mode to “restart” for now, so at least the debugging is easier. Long term you need to eliminate the delays

[sand pivot]

sure

For this first run of the automation, which succeeded, I find it odd that the door is closed in reality, but it seems like the loop in the action seems to run for 3 iterations (and also sends 3 failure emails despite the automation closing the door effectively in reality):

https://pastebin.com/dtLd9nna

[buoyant lotus]

A “repeat until” will always execute the loop once, and will check the conditions after the first loop. So you’ll always get the “door not closed” notification. Conversely, a “repeat while” loop will check the conditions first, and only execute the loop if the conditions are true

The loop ran once/minute and it took 2 minutes (3 loops) for the state to change to closed

[sand pivot]

I see, I guess I will have to change the loop structure, and change the entity to use 'motor stopped after door starts closing' or something similar. That is the reason I added the delay by the way, to ensure the door is in a closed state.

That being said, any idea why the door did not close once the obstruction sensor is hit? Or any suggestions on what to try next?

[buoyant lotus]

From the traces you shared the only reason the obstruction sensor wouldn’t trigger is because the automation was already running. If you didn’t have one running it should work

[sand pivot]

Alright thanks, I guess I will somehow update that to a different mode and try again.

You earlier mentioned to remove the delay, however if the garage door was left open after the close command is sent, then i need a notification. Is there a better way to handle this that you recommend?\

[buoyant lotus]

If you go to developer tools->states and find the automation, you will see it has an attribute called current. That will be the number of instances of that automation currently running. Since the mode is single it can’t ever be more than 1

Yes, so to confirm: your goals are to:

• auto-close when both are true:
  • door is open for at least 90 sec
  • obstruction is clear for at least 90 sec

Then you want a notification when:

• door is still open 3 minutes after auto-close triggered

Is that right?

[sand pivot]

yes, essentially the notification is supposed to tell me that something happened and the door didnt close as expected

[buoyant lotus]

Ya. A few different ways you can solve it depending on your preferences. My first suggestion: create an input date/time helper. In your automation, you’d close the door and then set the date time helper to 3 minutes from now. For the notification you can either create a new automation or else add a trigger to this one and put your actions in a choose block

You’d trigger off the new date time helper, and check if the door is closed. If not, send a notification and then add a few minutes to the helper.

You could also use a timer instead of a date time helper. That might be easier

[sand pivot]

so if im understanding this, the trigger for the date-time helper based automation would be something like if now()== date.time helper?

[buoyant lotus]

You can just use a time trigger and select the entity. You don’t need a template

But you will need a template to set the datetime helper to the new value. {{ now() + timedelta(minutes=3, seconds=30) }} or whatever delay you want

[sand pivot]

alright thanks, I learned a lot here. Will update with results when I (hopefully) get this working

[hoary lodge]

In case the door closes within 90s you have created an endless loop which will prevent the execution of the automation completely in case the mode remains set to single

[sand pivot]

are you talking about the opening post, or what has been discussed since then?