🚗 Smart Garage - Control Doors, Lighting, and Alerts

Blueprints Exchange
1

:red_car: Smart Garage - Door, Lighting, and Alerts

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

🚀 Version 2025.01.05.16d

– 16d fixes lighting triggers
– 15d code tweaks for schedules and ‘Stopped’ state trigger fix; should work for GDOs that report % open.

Author: LTek

📖 Community Discussion, Help, and Details... https://community.home-assistant.io/

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

Important Note: this made to work with garage doors that report as Covers entities. Currently only tested with Konnected BlaQ. If you door only report on/close, and not a % Open, the 'Stopped' trigger will not work but all others should.

FEATURES
:loudspeaker: Custom Notificatios per garage door state - open, opening, closed, closing, stopped
:rotating_light: Alert notification schedules for door state - for when door should not be opening but are
:stopwatch: Auto-close default timer - does not use schedule
:date: Three customizable door schedules - open or close at specific times
:shield: Bypass schedule for open notifications
:repeat: Repeat notifications with configurable limits
:gear: Custom actions for each door state and light trigger
:bulb: Lighting control based on garage door states and other triggers

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

2

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

4

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
5
6

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.

7

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.

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.

1 Like
8

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

9

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

1 Like
10

removed my brain freeze moment

11

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

12

ah, sorry :frowning: 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?

13

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

14

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.

15

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
16

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

17

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

18

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

19

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.

1 Like
20

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!