Home Assistant Blinds: The Practical Setup I Actually Use

I try to keep my Home Assistant setup boring in the best possible way. My blinds are not driven by a giant all-knowing automation. Instead, I use a few small pieces that are easy to understand, easy to disable, and easy to restore.

This post describes the pattern I use at home and how I expose it to Keeper, my Home Assistant assistant agent. If you want something you can reproduce, this is the important part: keep the physical covers, the room-level toggles, and the higher-level automations separate.

What the setup looks like

I have four rooms with blinds, each exposed as a normal cover. entity in Home Assistant. In my case they are Shelly-controlled covers, but the pattern does not depend on Shelly specifically.

For each room I also keep a small set of helper entities:

  • one input_boolean that says whether room automation is allowed
  • one input_number for the target blind position
  • one input_number for the target tilt angle
  • one optional input_boolean for shading mode

This gives me a simple contract. The real cover entity moves hardware. Helper entities store intent.

The core idea: automation is a toggle, not a trap

The most useful thing I added was a watchdog automation per room. The watchdog listens to a room toggle such as input_boolean.automatika_zaluzie_loznice and does only two jobs:

  • when the toggle is turned on, it enables the room automation
  • when the toggle is turned off, it disables the room automation, waits four hours, and enables it again

That sounds trivial, but it solves a real problem. Manual override stays manual for long enough to matter, but I do not forget to restore the default behavior the next day.

In practice, each room has a tiny watchdog automation that turns one real automation on or off. That is much easier to reason about than embedding override logic into every rule.

Room rules stay separate and practical

The room automations themselves stay focused.

Examples from my setup:

  • bedroom and kids room use thermal-comfort automations with a default “down + tilt” target
  • kitchen has a late-afternoon sun rule that keeps the view usable and also checks cloud conditions
  • living room has its own thermal and comfort rule, and I can disable it independently when I want full manual control

I also use one helper script for the annoying real-world detail: sometimes position and tilt must be applied in sequence. The script script.blinds_ensure_position_then_tilt makes that idempotent and adds a timeout, so the higher-level automations can call one stable interface instead of duplicating movement logic.

How Keeper fits into this

Keeper does not need to know every low-level rule. It only needs a safe control surface.

In my setup, that means Keeper works with Home Assistant domains such as:

  • cover.* for open, close, or set position
  • automation.* for turning room logic on or off
  • script.* for the reusable “ensure position, then tilt” action
  • input_boolean.* and input_number.* for room intent and defaults

That separation matters. If I change an implementation detail inside Home Assistant, I do not need to redesign Keeper. I keep the same room-level interface and update only the HA internals.

If you want to reproduce it

Start with one room only.

  1. Expose your blind as a cover.
  2. Add one boolean helper that means “automation enabled”.
  3. Create one actual room automation.
  4. Add one watchdog automation that turns the room automation back on after a few hours.
  5. If tilt is unreliable, wrap it in one reusable script instead of solving it differently in every room.

That is enough to get a system that is practical, debuggable, and friendly to both manual control and agent-driven control.

The main lesson is simple: do not make your blinds smart in one big step. Make them composable. That is what made the setup usable for me.

k@homeassistant  k@automation  k@smarthome 

See also