☀️ Sun-Aware Shutter Control - Automatically close shutters based on sun position

[r3mcos3]

Sun-Aware Shutter Control

Version 1.19.0 | Automatically close your shutters when the sun shines on your house — and open them again when it moves away!

This blueprint is currently in a testing phase. It has been tested in a single environment. Feedback and bug reports are very welcome!

The problem this solves

Every day the sun moves from one side of your house to the other. In the morning it shines on the front, in the afternoon on the back. Without automation you have to remember to close and open your shutters multiple times a day — this blueprint handles that for you automatically.

Features

• Sun position tracking - Closes shutters when the sun shines on the front or back facade
• Automatic opening - Opens shutters once the sun moves away (optional)
• Only when nobody is home - Optional toggle to disable all shutter operations when someone is home; the automation only acts when the house is empty
• Door bypass - Optional door sensors per facade; while a linked door is open, the automation won’t close that facade’s shutters — useful when a shutter covers a door opening
• Presence-aware re-evaluation - Immediately re-evaluates shutter positions when the house becomes empty, without waiting for the next sun position update
• Smart manual override - Only triggers when a shutter is manually closed; a manual open never blocks the sun-close logic so the automation stays in control
• Presence-aware override - Configure up to 2 person entities: when someone is home, manual operations are respected; when nobody is home, the automation takes full control regardless
• Sunset reset - All overrides are automatically cleared at sunset so the next day starts fresh
• Cloud detection - Optional weather integration (supports two entities as cross-check): shutters stay open when overcast, close again when it clears up. When two weather entities are configured, both must agree before shutters close — prevents false closes caused by a single unreliable source
• Anti-oscillation cooldown - Minimum wait between moves, prevents rapid up/down on partly cloudy days
• Position awareness - Skips the command if shutters are already at the target position
• Stuck shutter protection - Optional per-facade toggle helper stops the automation from repeatedly commanding a shutter that failed to reach its target (e.g. frozen or jammed), protecting the motor — sends a notification and resets at sunset or once the shutter moves again
• Auto-open exceptions - Optionally exclude specific shutters per facade from automatic reopening (e.g. a bedroom shutter you want to keep closed at night); they still close automatically when the sun hits that facade
• Configurable sun window - Control how many degrees of margin counts as “sun on facade”
• Minimum elevation - Ignores low morning/evening sun below your threshold
• Flexible positions - Set custom close position (e.g. 50% for partial shade)
• Front and back separately - Independent shutter groups per facade side

How it works

The blueprint uses the sun.sun azimuth (compass direction 0–360°) and compares it to your house orientation. It fires automatically whenever Home Assistant updates the sun’s azimuth — event-driven, no polling needed. Each time it calculates whether the sun is within the configured angle window of each facade:

Angle difference = ((sun azimuth − facade direction + 180) % 360) − 180
Sun on facade    = angle difference < sun window AND elevation > minimum

This formula handles all compass directions correctly, including the North wrap-around (359° → 1°).

Decision logic per facade side

Sun on facade	Weather allows	Override active	Someone home	Action
Yes	Yes	No	—	Close shutters
Yes	Yes	Yes	Yes	Do nothing (respect manual override)
Yes	Yes	Yes	No	Close shutters (nobody home overrules)
Yes	No (cloudy)	—	—	Open shutters (treat as no sun)
No	—	No	—	Open shutters
No	—	Yes	Yes	Do NOT open (respect manual close)
No	—	Yes	No	Open shutters (nobody home overrules)
Sunset	—	any	—	Reset all overrides (daily reset)

Finding your house azimuth

Go to suncalc.org, find your house and determine which direction your front door faces. North = 0°, East = 90°, South = 180°, West = 270°. The back facade is calculated automatically (front + 180°).

Requirements

• Home Assistant 2025.12.0+
• Cover entities (shutters/blinds as cover domain)
• Sun integration (built-in, no setup needed)

Optional

• Input Boolean helpers — for manual override detection (one per facade side). Create via Settings → Helpers → Create Helper → Toggle.
• Person entities — for presence-aware override behavior.
• Door sensors — binary_sensor entities with device class door, for shutters that cover a door opening.

Configuration

Input	Description	Default
Front facade direction	Compass direction your front facade faces (0–359°)	180°
Front shutters	Cover entities on the front	—
Back shutters	Cover entities on the back	—
Sun window angle	Degrees left/right of facade that count	90°
Minimum sun elevation	Minimum sun height above horizon	10°
Close position	Shutter position when sun shines (0% = fully closed)	0%
Automatically open	Open when sun moves away	On
Open position	Position when automatically opening	100%
Override helper front	Input Boolean for front manual override	Optional
Override helper back	Input Boolean for back manual override	Optional
Person 1	First household member for presence detection	Optional
Person 2	Second household member for presence detection	Optional
Only when nobody is home	When on, the automation only acts when the house is empty	Off
Front door sensors	Door sensor(s) for front shutters that cover a door	Optional
Back door sensors	Door sensor(s) for back shutters that cover a door	Optional
Weather entity	Weather integration for cloud detection	Optional
Second weather entity	Second weather source as cross-check; both must agree before closing	Optional
When to close	Always / Sunny+partly cloudy / Sunny only	Sunny or partly cloudy
Cooldown between moves	Minimum minutes between two movements (0 = disabled)	20 min

Manual override explained

Home Assistant records who initiated every state change. When a user manually closes a shutter (via app, dashboard or physical switch), the context contains a user_id — the blueprint detects this and activates the override, preventing the automation from re-opening it.

A manual open does not set the override by default. This means: if someone opens a shutter in the morning when it’s cloudy and later the sun comes out, the blueprint will still close the shutter automatically. Exception: if a presence entity is configured and someone is home, a manual open also sets the override (the automation won’t fight the user).

Override lifecycle

Event	Override
User manually closes shutter	→ ON (always)
User manually opens shutter while someone is home	→ ON
Shutter returns to the open position	→ OFF
Sun sets (sun.sun → below_horizon)	→ OFF (daily reset)

Presence-aware behavior

Configure Person 1 and/or Person 2 (optional) to make the override presence-aware:

Situation	Close?	Open?
Override OFF	✓	✓
Override ON + someone home	✗	✗ (manual operation respected)
Override ON + nobody home	✓	✓ (automation takes full control)

Note: Voice assistant commands (Alexa/Google) don’t carry a user_id and won’t trigger the override.

Door bypass explained

Link a door sensor (binary_sensor with device class door) per facade if a shutter on that side covers a door opening. While the door is open, the automation will not close that facade’s shutters — as soon as the door closes, it re-evaluates immediately and closes the shutters if the sun is still on that facade. Only closing is blocked; automatic opening always works normally, since an open shutter never obstructs a door. Not needed for windows.

GitHub

Full documentation, examples, and troubleshooting: GitHub Repository

Changelog

• 1.19.0 - Added auto-open exceptions: optionally exclude specific shutters per facade from automatic reopening (e.g. a bedroom shutter you want to keep closed at night) — they still close automatically on sun, only the auto-reopen is skipped
• 1.18.0 - Added stuck shutter protection: optional per-facade toggle helper stops the automation from repeatedly commanding a shutter that failed to reach its target (e.g. frozen or jammed), protecting the motor — sends a notification and resets at sunset or once the shutter reaches a target position again
• 1.17.0 - Added door bypass: optional door sensors per facade block automatic closing of that facade’s shutters while the door is open — useful when a shutter covers a door opening. Closing resumes automatically once the door closes; automatic opening is unaffected
• 1.16.0 - Added presence-aware re-evaluation: when a configured person entity changes state, the automation immediately re-evaluates — no waiting for the next sun update when the house becomes empty
• 1.15.0 - Added “Only when nobody is home” toggle: when enabled the automation skips all shutter operations whenever someone is home — occupants stay in full control
• 1.14.0 - Added optional second weather entity as cross-check: when both are configured, shutters only close when BOTH agree (AND-logic) — prevents false closes from a single unreliable weather source
• 1.13.0 - Override is now also bypassed on auto-open when nobody is home (mirrors close behaviour)
• 1.12.0 - Added sunset trigger: all overrides reset at the end of each day so the next morning starts fresh
• 1.11.0 - Fixed: override was reset too early when shutter was still closed, causing the automation to reopen a manually closed shutter
• 1.10.0 - Two separate person inputs (Person 1 + Person 2) replace the single presence entity
• 1.9.0 - Presence-aware override: when nobody is home the automation ignores the override and closes on sun
• 1.8.0 - Manual override only triggers on manual close (not open), so automation can still close after a manual open
• 1.7.0 - Added anti-oscillation cooldown and position check to prevent unnecessary motor activations
• 1.6.0 - Auto-open no longer fires at night — shutters closed in the evening stay closed
• 1.5.0 - Added optional weather/cloud detection: shutters stay open when overcast
• 1.4.0 - Replaced 5-minute polling with event-driven sun azimuth trigger
• 1.3.0 - Fixed: manually closing shutters at bedtime no longer causes them to be re-opened
• 1.2.0 - Translated all labels and descriptions to English
• 1.1.0 - Manual override detection with input_boolean helpers, auto-reset when sun moves away
• 1.0.1 - Added suncalc.org tip to description
• 1.0.0 - Initial release

[jchh ((not John))]

Nice. I have a similar package but it doesn't have the manual override part.

It's a single automation that is triggered by a custom_template sensor which provides the opening % for each shade (so the automation is very simple as the logic is in the custom_template sensor). This sensor also manages closing/opening the shades at night/morning.

[st95]

I started trying to implement something similar before I found this blueprint. Great idea and implementation! I have one idea for improvement: Currently, only two sides of the house can be configured. I have shutters on each wall of the house so it would be great to have the left&ride sides as well.

[r3mcos3]

you can use the blueprint multiple times, because if you have shutters on multiple walls the azimuth for those walls is different.

[wagnst (Steffen)]

A feature to bypass this based on door state (open/closed) would be nice, since sometimes we have a door opened and then this automation kicks in and closes the shutter. Should not do it until the door is closed again. For windows it doesn’t matter obviously.

[r3mcos3]

Good news — this is now available!

Version 1.17.0 adds an optional Door Bypass feature: link a door sensor (binary_sensor, device class “door”) per facade, and the automation will skip closing that facade’s shutters while the door is open. As soon as the door closes, it re-evaluates immediately and closes the shutter if the sun is still on that facade. Doesn’t affect automatic opening, so windows are unaffected as you mentioned.

Update the blueprint to get it, and check the Door Bypass section under the input settings.

Thanks for the suggestion!

[marcelbrueckner (Marcel Brückner)]

Nice, was about writing an automation to do the same, but luckily found your blueprint which saves me some amount of work

While setting up your blueprint I came up with some questions. Treat them as feature requests if the answer is no

1. Can the automated shutter opening be limited on a subset of the covers? E.g. I want to keep the kids room’s shutters closed even if the sun has set. At the moment, I only can come up with setting up your blueprint twice with different shutters assigned to the facade.
2. I have two doors on a single facade (front door and balcony), but I can only add a single door sensor.
3. Override per-shutter instead of per-facade?
4. In winter, my roof shutters tend to freeze, thus I’m locking them on KNX-level. Will the automation try to open/close them repeatedly when they obviously don’t react to an open/close command?

[r3mcos3]

Thanks for the detailed feedback! Went through all 4

1. Auto-open exceptions — added in v1.19.0. New optional “ Auto-Open Exceptions” section lets you pick specific shutters per facade that should stay closed even when auto-open would normally trigger (kids room stays closed, rest of the facade still opens as usual). No need to run the blueprint twice for this anymore.
2. Multiple door sensors per facade — this is already supported, the front/back door sensor fields accept multiple entities. Just add both your front door and balcony door sensor to the same field, either one being open will block closing. If you don’t see the multi-select option, you’re probably on an older imported version — re-import to get the latest.
3. Per-shutter override — for now the cleanest way is still running the blueprint multiple times (one instance per shutter instead of grouping several under one facade), same as suggested earlier for the 4-sides question. Each instance then gets its own override helper. True per-shutter override inside a single instance would need a pretty big rework (looping per cover instead of per facade), so holding off on that unless there’s more demand.
4. Stuck/frozen shutter protection — added in v1.18.0. New optional “ Stuck Shutter Protection” helper per facade: after one close/open command fails to actually move the shutter (e.g. locked on KNX-level), the automation stops sending further commands to that facade and fires a notification — so it won’t keep pulling on a locked shutter. Resets at sunset, or flip the helper off manually once it’s unlocked again.
   Re-import the blueprint to grab v1.19.0

[Sushi]

Is it possible to add a solar sensor? In my case, a value that allows me to determine with my solar panels whether the sun is shining.
The two weather integrations often agree with each other, but this is still not the reality when there are many scattered clouds.

[r3mcos3]

Hi @Sushi, thanks for the suggestion — it’s a solid idea and the underlying logic (checking a numeric sensor against a threshold, similar to how the weather entity check already works) isn’t complicated at all.

That said, I don’t have solar panels myself, so I have no way to actually validate this against real data. I’d rather not ship an unverified condition into a blueprint other people rely on — even a small bug in the threshold logic could silently keep everyone’s shutters open or closed at the wrong time.

Good news: the blueprint is fully open on GitHub, and adding this yourself is a fairly small change — an optional entity input for your power sensor, a number input for the threshold (Watts), and adding it as an extra AND-condition next to the existing weather check.

Repo: blueprints/sun_shutter_control at main · r3mcos3/blueprints · GitHub

If you end up building it and want to share it back, feel free to open a PR — since you actually have the hardware to test it, that’d make it far more solid than anything I could ship blind. Happy to help review if you go that route!

[Sushi]

Hi @r3mcos3, Good idea! I’m going to test it and get back to you! The only thing is, I’m not very familiar with creating/modifying blueprints yet, so I’ll have to dive into that.
By the way, it isn’t an AND next to the weather entities, but rather a replacement (OR), because it can actually provide an opposite value to both weather entities.

If you can/will create a YAML that I can test, I would really appreciate it!

Edit: Gemini was so kind to help me edit the YAML for me.
I’m testing now and get back to you!

[r3mcos3]

Thanks for giving it a try! Just to be clear on my end: I’m not planning to build or release this into the official blueprint myself right now — I don’t have solar panels, so I have no way to validate the threshold logic against real data myself. So this stays on hold for now from my side. If your own test ends up working well for you, feel free to open a PR with it later — since you’re the one who can actually validate it against real hardware. Good luck with the testing, and thanks again for the suggestion!

[Walli]

Hey - good work. Thanks for it. Because I need the control via a lux sensor, I’m testing “Sun-Aware Roller Blind Control with Lux & Timed Manual Override” but I think it is based mainly on your work.