🚗 Smart Garage - Control Doors, Lighting, and Alerts

[Ltek]

Smart Garage - Door, Lighting, and Alerts

Comprehensive Garage Automation for Door States, Notifications, Alerts, Lighting, and Auto-Close/Open

🚀 Version 2026.05.26.12c

- ADDED: Extensive Auto-Close Notifications and Action Buttons. (see Features for more info)

📖 Community Discussion, Help, and Details... https://community.home-assistant.io/t/smart-garage-control-doors-lighting-and-alerts/967636

source_url: https://gist.github.com/Ltek/f58bbbde02471437ef863c334572a320

Important Note: this made to work with garage doors that report as Covers entities. 

**FEATURES**
🚪 Monitors all 5 garage door states - open, opening, closed, closing, stopped
📢 Notifications per door state with configurable title, message, icon, color, and interruption level (iOS/Android)
📢 Notification Action Buttons - Bypass Toggle, Close Now, Custom Action for Open, Repeat, Alert, and Stopped. Bypass button logic on those notifications to toggle the auto-close bypass entity directly from the notification.
🔁 Repeat notifications per state with configurable delay and max repeat count
🚨 Alert notifications when door opens during restricted schedules or when a monitored entity is in a specific state
🛡️ Notification bypass - suppress alerts by entity state or time schedule
⚙️ Custom actions for each door state, alert, and lighting trigger
⏱️ Auto-close default timer - 24/7, no schedule required
with a configurable warning delay, so users get a heads-up before the door auto-closes. 
📅 Door Schedules to automatically open or close at specific days/times
💡 Independant Indoor and Outdoor lighting controls - lights, triggers, brightness, color temp, disable schedule, and timer bypass
🔦 Lighting triggers include door states (opening, open, closing, stopped, closed) and additional entities (motion sensors, switches, locks, covers)
⏲️ Light Off Timer resets on every new trigger - works correctly with motion sensors and mode:restart
🐛 Debug notifications to Persistent UI with per-trigger-type filtering and optional variable dump

[Didgeridrew]

garage_door_entity needs to be defined as a trigger variable to work in a template trigger.

[Ltek]

I just looked and see the garage_door_entity variable defined in the variables section. I thought garage_door_entity is available as a variable in templates. Is there something else I’m missing?

variables:
  # GARAGE DOOR ENTITY (STANDALONE)
  garage_door_entity: !input garage_door_entity

[Didgeridrew]

Trigger_Variables - variables that are available when attaching a trigger

First, this is not meant to be a replacement for the section in the HA Docs about this. Please read and refer to that as the official word on this subject. Automation Trigger - Home Assistant. When I mention Triggers here I am referring to the main key trigger: used to activate an automation, and not necessarily the triggers found in key action: statements. What the Docs don’t say is the reason that there are 2 kinds of variables. Regular variables used in Automations and the ‘trigger’ varia…

[Ltek]

what I gathered from that post and the doc…

trigger_variables should not be used for a blueprint’s main triggers . According to the doc page; they are specifically for…

1. Templating trigger definitions (like MQTT topics or event names)
2. Static values that don’t change after the automation loads
3. Supporting blueprint inputs in triggers (but only in specific templated parts)

My blueprint triggers on dynamic entity states (open , opening , closed , closing , stopped ), which I do not thing qualify?

I appreciate the help, this is the large blueprint I’ve attempted. I have 2 others to post soon but are not as large.

Blueprints/yaml/templates/etc are complex and very nuanced; not as straight-forward as traditional scripting or programming.

[Didgeridrew]

@Ltek

trigger_variables should not be used for a blueprint’s main triggers .

I don’t know what you mean by that… only trigger_variables can be used in triggers. All other variables are loaded after the automation’s trigger fires.

@Ltek

My blueprint triggers on dynamic entity states (open , opening , closed , closing , stopped ), which I do not thing qualify?

The value of the input garage_door_entity is not dynamic. Once the automation is created from the blueprint it’s a static entity ID.

---

The bottom line is:

If you are using a value from an input in a template in a trigger, that variable needs to be set up in a trigger_variables block. Variables set up in the normal variables block are not available to triggers.

[Ltek]

I fixed a few bugs and released 13d a sec ago. I didnt use trigger variables as it seems that the code works fine without it… at least so far. If I should change to use them cool, but when I tried today I just got errors so gave up.

I tested a bunch on the current release of 13d, seems to work fine for all door events/states for me

[petro]

Yeah… it’s not going to work. You should really listen to drew

[Ltek]

removed my brain freeze moment

[petro]

literally just put it in trigger_variables instead of variables… just like drew said. You’re over thinking this.

[Ltek]

ah, sorry ok, I changed the garage door state entoty – should I change others?

Why was the automation was working (triggering on the garage door states) without that being a trigger_variable?

[petro]

Well, whatever you’re testing, you aren’t testing that trigger.

[Ltek]

of course I was… its the main trigger… the garage door. It had to be working… 1/ I was getting mobile notifications 2/ the zwave lights were being turned on. Both only controlled from that blueprint/automation.

[petro]

Nope, that’s not the main trigger.

  # Template trigger - CORRECT approach
  - trigger: template
    value_template: >
      {{ states(garage_door_entity) not in ['open', 'opening', 'closed', 'closing'] }}
    for: !input stopped_duration_before_alert
    id: trigger_stopped

[Ltek]

@petro

garage_door_entity

that is the Garage Door as defined by the blueprint selection box

here’s the trigger definition now (was just ‘variables:’ before)…

trigger_variables:
garage_door_entity: !input garage_door_entity

[petro]

right, but it’s not your main trigger and it (that trigger) would not have worked at all if the variable was under variables.

[Ltek]

@petro

right, but it’s not your main trigger and it would not have worked at all if the variable was under variables.

I meant by ‘main trigger’ that it is the most used/needed and the primary reason for the automation/blueprint. For 2 days the automation has been 100% working as a ‘variable’. Triggered 4 times today for garage door open/closed and a few times for the lighting triggers

[petro]

We are talking about only the variable inside your triggers. Nothing else, this is where your confusion lies.

The only variables that work inside any template in any trigger, is variables provided by trigger_variables. So to reiterate, this exact trigger does nothing:

  # Template trigger - CORRECT approach
  - trigger: template
    value_template: >
      {{ states(garage_door_entity) not in ['open', 'opening', 'closed', 'closing'] }}
    for: !input stopped_duration_before_alert
    id: trigger_stopped

Unless you put garage_door_entity inside trigger_variables

So, it’s very clear you have not been testing that exact trigger.

[Ltek]

AH… following you now.
Thx for the help. I did think trigger: template was kind of a shortcut (maybe optimization) on processing inputs and guess I can use it correctly now!

[Ltek]

Version 2026.01.27.21d posted … squashed a few important bugs, added Debug notifications, and some code optimizations (runs faster now)