shutter_pilot

KO | EN

gitlite — search

#javascript #ai #typescript #golang #rust #macos #java #awesome #kubernetes #vue #awesome-list #ios #mcp #openai

(★ 14)

Automatic shutter and blind control for Home Assistant – time, brightness or sun position, with window sensors, lock protection and sun shading. Configured entirely from a sidebar panel, no YAML.

shutter_pilot Latest Version Download

Download Latest Version (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Shutter Pilot

> **Automatic shutter/blind control for Home Assistant**

[![hacs_badge](https://img.shields.io/badge/HACS-Custom-41BDF5.svg)](https://github.com/hacs/integration)
[![GitHub Release](https://img.shields.io/github/v/release/fschubi/shutter_pilot)](https://github.com/fschubi/shutter_pilot/releases)
[![License](https://img.shields.io/github/license/fschubi/shutter_pilot)](https://raw.githubusercontent.com/fschubi/shutter_pilot/master/LICENSE)
[![PayPal](https://img.shields.io/badge/Donate-PayPal-00457C?logo=paypal&logoColor=white)](https://paypal.me/fschubi)

[Deutsche Version / German version](README.de.md)

---

Shutter Pilot is a Home Assistant custom integration that automates your shutters, blinds, and roller shutters based on **time schedules**, **brightness sensors**, or **sun position**. It adds a dedicated **sidebar panel** for easy management directly within Home Assistant.

## Features

- **Three control modes** per area: Time-based, brightness-based (lux sensor), or sun position (sunrise/sunset)
- **Sidebar panel** with Dashboard, Areas, Shutters and Awnings tabs for full management
- **Window/door sensors** – automatically opens shutters when windows are opened
- **Lock protection** – prevents full closing when a door is open
- **Sun protection with compass direction** – shades only when the sun is within the elevation range **and** actually facing the windows
- **Drive-after-close** – catches up scheduled movements when a window was still open
- **Per-shutter positions** – configurable open, closed, and sun-protection positions
- **Slat control** – optional tilt angle for venetian blinds
- **Workday sensor** – handles public holidays, vacation and shift work instead of a fixed Saturday/Sunday rule
- **Presence simulation** – random ±X minute offset on scheduled times
- **Light actions** – turn on a light/switch when shutters close
- **Auto-mode switches** – enable/disable automation per area via HA switches
- **Own entities** – next scheduled action and sun protection state as sensors for dashboards and automations
- **Multi-language panel** – automatically adapts to your HA language (11 languages)
- **Weekday/weekend schedules** – separate time windows for weekdays and weekends (time mode and brightness mode)
- **Sun info on dashboard** – shows next sunrise/sunset, configured offsets, and calculated trigger times for sun-mode areas
- **Awnings** – their own tab, shading without any schedule, with **wind, rain and frost protection** (applies even with automation switched off) and optional sun tracking of the extension

## Screenshots

Click an image to open it **full size** on GitHub (thumbnails are scaled down in this page).

Dashboard · Areas · Shutters

## Installation

### HACS (Recommended)

1. Open HACS in Home Assistant
2. Click the three dots menu (top right) → **Custom repositories**
3. Add `https://github.com/fschubi/shutter_pilot` as **Integration**
4. Search for "Shutter Pilot" and install
5. Restart Home Assistant

### Manual

1. Download the latest release from [GitHub Releases](https://github.com/fschubi/shutter_pilot/releases)
2. Copy the `custom_components/shutter_pilot` folder to your HA `config/custom_components/` directory
3. Restart Home Assistant

## Setup

1. Go to **Settings → Devices & Services → Add Integration**
2. Search for **Shutter Pilot** and click to add
3. After setup, "Shutter Pilot" appears in the sidebar

> **Note:** The panel is available to every user in the sidebar, but **only an administrator can configure it**. Without administrator rights the panel shows the dashboard with the control buttons (up, down, stop, sun protection, ventilate); the tabs for areas, shutters and settings as well as the master and auto switches are hidden. Every write command is checked server-side on top of that.

## Configuration

All configuration is done through the **Shutter Pilot sidebar panel**:

### Areas (Tab "Areas")

Click **"Add area"** to create a new area. Choose a control mode:

| Mode | Description |
|------|-------------|
| **Time** | Shutters go up/down at fixed times with separate weekday/weekend schedules |
| **Brightness** | Driven by a lux sensor with configurable thresholds and allowed time windows |
| **Sun position** | Uses Home Assistant's sunrise/sunset tracking with configurable offsets |

Each area can also have:
- **Sun protection** – drives shutters to a mid-position when the sun is within the elevation range **and** facing the windows
- **Extra shading conditions** – up to two sensors that must also be satisfied (see below)
- **Light action** – turns on a light/switch entity when shutters close
- **Drive delay** – seconds between individual shutters (prevents circuit overload)

### Shutters (Tab "Shutters")

Click **"Add shutter"** to assign a cover entity to an area:

- **Cover entity** – your `cover.*` entity
- **Window sensor** – optional `binary_sensor.*` for window open/tilt detection
- **Extra sensor for "tilted"** – only needed if your window exposes two separate entities, one for open and one for tilted. Leave empty for a single 3-state contact
- **Window state "open"** – which state of the entity means "the window is open". A `binary_sensor` only ever reports `on` or `off`, and which of the two means open depends on the contact, so the state it currently reports is shown below the field. The usual spellings (`on`/`open`/`true`) count as the same, as do `off`/`closed`. A 3-state `sensor` is read directly
- **Area Up / Area Down** – which area controls this shutter for up/down movements
- **Position sliders** – open, closed, and sun protection positions (0-100%)
- **Lock protection** – minimum position when a door is open (prevents lockout)
- **Drive after close** – catches up a missed close command when the window was still open. Since 2.7.0 the note survives a Home Assistant restart; it is discarded after 24 hours, because a drive from two days ago says nothing about what should happen now
- **Drive reports no position (blind)** – for one-way radio such as Somfy RTS. Those drives never answer, and every check that needs a position used to give up, which silently disabled window triggers and automatic ventilation for them. With this ticked, Shutter Pilot reasons with the position it last sent instead. Verification skips such shutters anyway, since there is nothing to verify
- **Close delay** – how long "closed" has to hold before the shutter drives back (0–30 s, default 5 s). Turning the handle from tilted to open drags the contact through "closed"; without a wait the shutter drives back immediately and never reaches the open position. `0` disables the wait

### Dashboard

The Dashboard tab shows all areas as cards with:
- Current shutter positions (live)
- Room temperature, if the area has a sensor set for it (display only)
- Auto-mode toggle per area
- **Sun info panel** for sun-mode areas: next sunrise/sunset, offset, calculated trigger time, current elevation
- Quick action buttons: **Up**, **Stop**, **Down**, **Sun protection**

## Services

| Service | Description |
|---------|-------------|
| `shutter_pilot.open_group` | Open all shutters in an area |
| `shutter_pilot.close_group` | Close all shutters in an area |
| `shutter_pilot.sun_protect_group` | Move all shutters in an area to sun protection position |
| `shutter_pilot.ventilate_group` | Move all shutters in an area to the ventilation position |
| `shutter_pilot.retract_awnings` | Retract every awning at once – no stagger, for an announced storm warning. `area_id` is **optional** here |

All services except `retract_awnings` accept an `area_id` parameter (e.g. `living`, `bedroom`). Every shutter moves to its own configured position.

## Entities

Besides the panel, Shutter Pilot creates entities you can use on regular dashboards and in your own automations:

| Entity | Description |
|--------|-------------|
| `switch.shutter_pilot_system` | Master switch for all automation |
| `switch.shutter_pilot_auto_<area>` | Automation per area |
| `switch.shutter_pilot_rollladen_<name>` | Automation per shutter (named after the **Name** field) |
| `sensor.shutter_pilot_<area>_next_action` | Timestamp of the next scheduled movement, attribute `direction` = `up`/`down` |
| `binary_sensor.shutter_pilot_<area>_sun_protection` | `on` while shading is active |
| `switch.shutter_pilot_markise_<name>` | Automation per awning (wind and rain protection still applies) |
| `binary_sensor.shutter_pilot_<name>_sperre` | `on` while the awning must not extend. Attributes: `reasons`, `release_in_seconds` |

## Switching automation off

Automation can be paused on three levels, independently of each other:

| Level | Effect |
|-------|--------|
| **Master switch** | the whole integration stops driving |
| **Area** | only this area pauses |
| **Shutter** | exactly this shutter stays put, the rest of its area keeps going |

The shutter level is meant for a shutter that must not move for a while – a broken drive waiting for a spare part.

It can be toggled in three equivalent places:

- on the **dashboard**, right in the shutter row of its area
- in the **Shutters** tab list
- through the `switch.shutter_pilot_rollladen_<name>` entity, from your own automations too

The **Automation active** checkbox in the shutter form sets the initial value. A disabled shutter also gets an icon on the dashboard, so nobody has to guess why it stays put.

Note that only **automation** is switched off. Manual control keeps working – the dashboard buttons, the `open_group`/`close_group` services and the cover entity itself. Otherwise you could not even test the shutter after repairing it.

## Event

Every automated movement fires `shutter_pilot_cover_moved` on the event bus:

```yaml
automation:
 - alias: Notify when shutters close
 trigger:
 - platform: event
 event_type: shutter_pilot_cover_moved
 condition: "{{ trigger.event.data.position < 20 }}"
 action:
 - service: notify.mobile_app
 data:
 message: >
 {{ trigger.event.data.entity_id }} to
 {{ trigger.event.data.position }}% ({{ trigger.event.data.reason }})
```

Fields: `entity_id`, `position`, `tilt_position`, `reason`, `area_id`, `source`.

## Troubleshooting

For bug reports, download diagnostics: **Settings → Devices & Services → Shutter Pilot → ⋮ → Download diagnostics**. The file contains configuration, runtime state and sun data; home coordinates are redacted.

## Supported Languages

The Shutter Pilot panel automatically adapts to your Home Assistant language setting:

| Language | Code | |
|----------|:----:|---|
| Deutsch (German) | `de` | :de: |
| English | `en` | :gb: |
| Français (French) | `fr` | :fr: |
| Español (Spanish) | `es` | :es: |
| Italiano (Italian) | `it` | :it: |
| Nederlands (Dutch) | `nl` | :netherlands: |
| Dansk (Danish) | `da` | :denmark: |
| Svenska (Swedish) | `sv` | :sweden: |
| Polski (Polish) | `pl` | :poland: |
| Português (Portuguese) | `pt` | :portugal: |
| Norsk Bokmål (Norwegian) | `nb` | :norway: |

If your language is not listed, the panel falls back to English. Want to contribute a translation? PRs are welcome!

## Awnings

Since 2.12.0 there is a dedicated **Awnings** tab. An awning is not an upside
down shutter, even though the drive path is the same – two things are
fundamentally different, and both are covered here.

### It runs on no schedule

Clock times, brightness and sunrise/sunset do not move an awning. Only shading
extends it. Shading uses exactly the same rules as for shutters – sun
elevation, window direction, up to four extra conditions, shading season, hold
time – which is why an awning gets only *one* area: the one whose sun
protection should apply.

It therefore has just two positions:

| Position | Meaning | Default |
| --- | --- | --- |
| Rest position | retracted, when no shading is needed | 0% |
| Shading | extended to shade | 100% |

Window contact, lock protection, slats, alternative closing position, frost
position and automatic ventilation do not exist on an awning – the form does
not even show them.

### Wind, rain and frost protection

The part without which an awning controller is not safe to run.

All three sensors – wind, rain and temperature (frost) – are configured under
**Settings** and apply to every awning in the house.

For **wind**, a single awning may deviate: its own sensor (a balcony behind the
house sees a different wind than the terrace), or just its own thresholds (a
small folding arm awning has to come in earlier than a cassette one on the same
sensor). **Rain and frost are global only** – they fall the same way over the
whole house, and a second field for them would only be one more line to
overlook.

How it behaves:

* **Above the retract threshold** the awning comes in at once and must not
  extend again.
* **It is released** only below the second threshold **and** after a lockout
  (default 20 min for wind, 30 min for rain). A gust is over in twenty seconds
  – the awning still must not go straight back out. Every new exceedance
  restarts the clock.
* **Reaction is in seconds, not on the minute tick:** protection listens to the
  sensors directly; the minute tick is only the safety net.

> ⚠️ **Protection applies even with the switches off.** Master switch off, area
> automation off, awning automation off: it still retracts. This is a
> deliberate departure from the order that governs everything else. A
> protection that can be switched off by accident is not a protection –
> switching it off on purpose means removing the sensor.

**Dead sensor:** if the sensor reports `unavailable` or `unknown`, nobody knows
what the wind is doing. Extending is barred from the first second. An already
extended awning is pulled in only after a grace period (default 10 min) – a
sensor blinking out during a restart should not retract the whole house.

### Extending further as the sun sinks

Optional, off by default. A high sun needs little projection; as it sinks, the
same area needs more. Two anchor points with a straight line between them:

```
Sun is high at 60°  →  extend to  60%
Sun is low  at 20°  →  extend to 100%
```

Plus a **minimum change** (default 10%). Without it the motor would run a few
percent every single minute – the surest way to wear out a drive.

### Entities, service and event

| Kind | Name |
| --- | --- |
| Binary sensor | `binary_sensor.shutter_pilot_<name>_sperre` – on while extending is barred. Attributes: reason and remaining time |
| Switch | `switch.shutter_pilot_markise_<name>` – automation per awning (protection still applies) |
| Service | `shutter_pilot.retract_awnings` – retract every awning at once, no stagger. For an announced storm warning |
| Event | `shutter_pilot_awning_retracted` with `entity_id` and `reasons` – for your own notifications |

### Converting an existing shutter

If you set an awning up as a shutter first: pick the same cover entity in the
Awnings tab and a **"Convert to awning"** button appears. Window, slat and
closing settings are deleted rather than left behind, and the two positions are
set to the awning defaults.

### Drives without position feedback

Many awning motors only know open, stop and close. Shutter Pilot falls back to
"fully open" / "fully closed" by itself there. Partial positions and sun
tracking do not work on such a drive – that is logged once as a warning.

## Shade only on real sun and real warmth

Elevation and compass direction only tell you **where** the sun is – not whether it is actually shining, or whether it is warm enough to matter. In spring and autumn the solar warmth is usually welcome.

That is why each area can carry up to **four extra conditions**. Shading only runs while all of them hold:

| Source | Behaviour |
|--------|-----------|
| **Binary sensor or switch** (`binary_sensor`, `input_boolean`, `switch`, `schedule`) | Satisfied while it is `on`. No thresholds needed – the hysteresis lives in your sensor |
| **Numeric sensor** (lux, W/m², °C – `input_number` too) | Satisfied from "Shade above", releases only below "Release below" |
| **Text state** (`weather.*`, `input_select`, scrape sensor) | Satisfied when the reported state is one of those you picked. Several are allowed |

The gap between the two thresholds stops the shutters from bouncing when clouds pass. Leave "Release below" empty to use the same value.

**Helpers work just as well.** A house mode as an `input_select` (home / away / holiday), a cleaning-service flag as an `input_boolean` – both appear in the picker and need no template sensor. For a select helper the form offers its own options as buttons.

An empty field means no condition. An unavailable or broken sensor never blocks shading.

### Weather and forecast

Set your `weather.*` entity in the **Settings** tab. Shutter Pilot then fetches the daily forecast itself and provides three sensors:

| Sensor | Content |
|--------|---------|
| Forecast high temperature | expected daily high, as the source reports it right now |
| Forecast high today (peak) | the **highest** value reported today |
| Forecast condition | expected condition, e.g. `sunny` |

Pick any of them as an ordinary condition. A typical setup is **forecast high, shade above 24 °C** — so nothing is shaded on cool days and the sun warms the house.

**Which of the two temperatures?** A daily forecast is revised as the day runs, and most sources lower it once the peak has passed: at 21:00 "high for today" may read 25 °C on a day that reached 28 °C at three. For decisions taken during the day — shading — use the live value. For decisions taken in the evening — partial close, night ventilation — use the **peak**; it only rises until midnight.

An unreachable weather backend never blocks shading; the last known value is kept.

### Sensors with a text state

Conditions can compare **states** instead of numbers. That lets you use a `weather.*` entity or your own scrape sensor directly: simply pick the conditions that should trigger shading. For weather entities the standard conditions are offered as buttons.

### Shading season

Each area can be limited to certain months, e.g. April to September. Ranges may wrap across the new year, such as October to March.

A temperature condition usually makes this unnecessary: if the winter forecast stays below the threshold, no shading happens anyway.

### Shading only during certain hours

Elevation, window direction, conditions and the shading season all describe
*the sun*. Sometimes the rule is about the household instead: "during the
school holidays the child's room has to stay dark until nine".

Two fields cover that, **each optional on its own**:

| Field | Meaning |
| --- | --- |
| Shade no earlier than | no shading before this time |
| Shade only until | released after this time |

So "only from 09:00" is a valid setting by itself; no upper bound is needed.
Configurable **per area and per shutter** – empty on the shutter means the
area's value applies. It is meant for the one room that needs a different rule.

Two things worth knowing:

* When shading ends at this boundary it is **released immediately**. The hold
  time does not apply – that exists for passing clouds, and a clock boundary
  does not come back within the hold.
* A window **across midnight does not exist**. If the second time lies before
  the first, the setting is discarded and logged, rather than silently read as
  a wrap-around.

> 💡 For "the shutter should **open** later in the morning" this is not the
> right field – use the area's **special-days sensor**, see below.

### Opening later on holidays and school breaks

The **special-days sensor** per area (formerly "workday sensor") switches
between the weekday and weekend schedule. It applies in **all three modes** –
time, brightness and sun position.

That covers public holidays, vacation, shift work **and school holidays**. The
recipe for holidays:

1. Build a binary sensor that reports `on` while school is on – and `off` on
   holiday **and** weekend days
2. Set it as the area's special-days sensor
3. Set "weekend up" to `09:00` and **leave "weekend down" empty** (empty
   weekend values fall back to the weekday ones)

The shutter then stays down until nine during the holidays and closes in the
evening exactly as before.

If this should apply to **one room only**: give that shutter its own **up
area** and keep the shared down area. Up and down areas may differ. Shading is
unaffected – that is decided by the down area.

### Sensors per window instead of per area

Conditions can live on the **area** and on the **individual shutter**. The rule is simple:

> The area provides the default. Whatever is set on the shutter wins for that window.

The fallback works **per condition**, not all or nothing. A typical setup:

- **Area:** condition 1 = forecast high above 24 °C, applies to every window
- **South window:** condition 2 = brightness sensor at the south window
- **West window:** condition 2 = brightness sensor at the west window

Both windows inherit the temperature condition while keeping their own brightness sensor. A room temperature can be set per shutter the same way.

For a **text condition** — the weather situation, say — the form offers the states as buttons. With a `weather.*` entity those are Home Assistant's 15 standard conditions. An ordinary sensor only ever reports its *current* state, so the others can be typed in by hand there instead of waiting for the next rain.

Each window keeps its own hysteresis, so a cloud in front of one window does not release the shading of another.

## Drive by sun position, but not too early

In sun mode the computed moment can be clamped into a clock window:

| Setting | Effect |
|---|---|
| Up earliest 07:30 | In summer the sun rises at 5 a.m. – the shutters still wait until 07:30 |
| Up latest 09:00 | In winter daylight comes late – the shutter opens at 09:00 at the latest |

Weekends have their own values. Left empty, the weekday values apply. Empty fields generally mean no limit.

All times are local time — the timezone from your Home Assistant settings. The dashboard shows next to each drive time why it differs from the sun time: "· no earlier than 07:30" when a bound applies, or "· Presence: +4 min" with presence simulation enabled.

## Minimum gap between drive commands

Radio receivers — 433 MHz, HmIP and relatives — swallow commands that arrive at the same moment. The **per-area delay** only helps so far: it staggers the shutters *within* one area, but every area drives in its own task. When two areas start at the same time in the evening, their commands still collide.

The **Settings** tab therefore offers a **minimum gap between drive commands** (0–10 s). It applies at the single place every drive passes through — automated or manual — and spaces them out across all areas. Throttling here means waiting, not dropping: every shutter still gets its command, just one after another.

`0` disables the throttle; that is the behaviour before version 2.7.0.

## Verifying drives

Radio-driven shutters occasionally drop a command. Without a check nobody notices, and the integration keeps working with a position the shutter never reached.

The **Settings** tab therefore offers verification. After each automated drive, the position is checked after a configurable delay and the command repeated if needed.

On final failure the stored value is corrected and `shutter_pilot_cover_failed` is fired — with `entity_id`, `requested`, `actual` and `reason`:

```yaml
automation:
  - alias: Shutter not responding
    trigger:
      - platform: event
        event_type: shutter_pilot_cover_failed
    action:
      - service: notify.mobile_app
        data:
          message: >
            {{ trigger.event.data.entity_id }} is at
            {{ trigger.event.data.actual }}% instead of
            {{ trigger.event.data.requested }}%
```

Shutters that only report open/closed without a position are skipped automatically.

## Rooms with windows facing several directions

Elevation and compass direction normally apply to the whole area. If one window faces a different way than the others in the same room, enable **Own orientation** on that shutter and set its elevation and azimuth there.

South and west windows of the same room are then shaded at different times of day, without maintaining two areas with duplicated schedules.

## Closing only part way in the evening

To keep certain shutters from closing fully on hot evenings so the room can keep ventilating:

1. In the **area**, under *Partial closing*, set a condition — the obvious one is the **Forecast high today (peak)** sensor Shutter Pilot provides itself
2. Optionally a **second condition** — both then have to hold. A typical pair is “the day was warm” **and** “somebody is home”
3. On the relevant **shutters**, set a partial position, e.g. 50 %

Only shutters with a partial position deviate; all others close normally. A dead sensor counts as *not met* here, so the shutters close normally rather than standing part way open all night.

## Copying settings from another shutter

Configuring ten windows the same way should not mean typing the same thing ten times. The shutter form has a **Copy settings from** picker right below the name — choose a template, click **Apply**, done.

Copied are positions, slat angles, shading with geometry and conditions, frost and ventilation values, and the window settings.

Deliberately **not** copied is what makes a shutter itself:

- cover entity and name
- area for up and down
- window and tilt sensor

Those are exactly the fields that tell two otherwise identical shutters apart — copying them would leave you with the same window twice.

## Brightness mode with a sun bound

A thunderstorm in the afternoon pushes the lux below the threshold — and the shutters close in broad daylight. Clock windows only help so far, because sunset moves by hours through the year.

Brightness mode therefore offers two extra bounds:

| Setting | Effect |
|---|---|
| Down no earlier than X min. before sunset | Nothing closes before then, however dark it gets |
| Up no earlier than X min. before sunrise | Nothing opens before then |

Example: sunset at 21:10 with "60" means closing starts at 20:10 at the earliest. Both bounds apply **on top of** the clock windows — the tighter one wins.

Empty means no bound. The value `0` is not the same as empty — it means "exactly at sunset".

## Fixed time when the lux threshold is never reached

In the dark half of the year it stays overcast for days and the up threshold is never crossed. The clock windows do not help: they only **permit** a drive, they never trigger one.

Each area therefore has two deadlines that can be switched on:

| Setting | Effect |
|---|---|
| Open at the latest at | Opens at this time regardless of the brightness value |
| Close at the latest at | Closes at this time regardless of the brightness value |

Both are **off by default**. Switched on they run once a day, outside the clock windows as well. Each has its own weekend value; left empty, the weekday value applies.

What a deadline does **not** do: move a shutter that already went that way. If the lux value opened it in the morning, nothing happens at 09:00. Shading and a manual position still win, and a deadline that has already passed is not caught up after a restart.

## Chasing clouds up and down

Sensor noise is already handled: separate on and off thresholds, hysteresis per condition, and only one movement per direction and phase. A drifting cloud is not noise though — it genuinely ends the condition, and the shutter opened right away.

The area therefore offers **Hold shading** (0–120 minutes). The shading stays up for that long even once the condition no longer holds. If the sun returns before then, the clock starts over next time.

Two things stay immediate on purpose:

- **Shading itself.** When the sun hits the window, the shutter should not wait an hour first.
- **The end of the day.** Once the sun drops below the configured elevation, shading is over and the normal evening schedule takes it from there, without delay.

`0` keeps the previous behaviour.

## Shading from brightness sensors alone

With brightness sensors around the house, elevation and compass direction are not needed — the sensor already knows whether the sun hits the window. No separate mode required:

1. Enable sun protection in the **area**
2. **Turn the compass direction off** — the azimuth is then not checked
3. **Turn "check the sun's height" off** — the elevation then plays no part at all
4. Add the brightness sensor as an **extra condition**, with a switch-on and a switch-off threshold

Brightness alone then decides. The two thresholds matter more here than elsewhere: they keep a passing cloud from releasing the shading right away.

Because conditions can be overridden **per shutter**, each window gets its own sensor while the rest of the settings stay in the area.

## Automatic ventilation

Ventilating used to be manual only — the dashboard button or the service. In the **area**, under *Automatic ventilation*, you can now say when it should happen by itself:

1. Enable **Ventilate automatically**
2. Name up to two conditions that **both** have to hold — e.g. a presence sensor "on" and a room temperature above 24 °C

While all conditions hold, the area's shutters move to their **ventilation position** (the same one used for a tilted window). When one drops out they move back to where they stood before — not to "open", which would be wrong at night.

Ranking when several things apply at once:

| Priority | Reason |
|---|---|
| 1. Window contact | reacts to what somebody physically did at the window |
| 2. Shading | heat comes first |
| 3. Automatic ventilation | only touches shutters that are otherwise sitting still |

With no condition configured nothing happens. Master, area and per-shutter switches apply as everywhere; switching the area off mid-ventilation still drives the shutter back rather than leaving it part way open.

## Frost protection

In frost a fully closed shutter can freeze to the frame. Leaving a gap prevents that:

1. In the **area**, under *Frost protection*, set a condition — the obvious choice is the **Forecast low** sensor Shutter Pilot provides itself once a weather entity is configured
2. On the relevant **shutters**, set a frost position, e.g. 10 %

Unlike every other condition this one compares **downwards**: frost protection kicks in *below* the first value and stays on until the second is exceeded. The hysteresis keeps it from toggling around freezing point.

Frost protection wins over partial closing — protection beats comfort. Both apply in time, sun and brightness mode. A shutter without a frost position still closes fully, even when the area's condition is met.

## Support me

Shutter Pilot is built in my spare time and is — and stays — free and open source. If it makes your day a little easier and you'd like to say thanks, I'd appreciate a coffee:

Just as helpful and completely free: leave a ⭐, [report a bug](https://github.com/fschubi/shutter_pilot/issues), or contribute a translation.

## Minimum Requirements

- Home Assistant **2024.6.0** or newer

## License

MIT – see the [LICENSE](LICENSE) file for details.

shutter_pilot

shutter_pilot Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

shutter_pilot

shutter_pilot Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

Download README