Lighting and Blinds in the Smart Home: What You Want to Achieve, and What Not to Break

Module 20 · Lesson 1

Lighting and Blinds in the Smart Home: What You Want to Achieve, and What Not to Break

We're starting a module about everyday light and blinds. Not by buying smart bulbs for every ceiling. We start with boundaries: what you want to achieve, what has to keep working manually, and what happens when Home Assistant goes down.

You already know automations, helpers, and dashboards from Modules 8 through 11. Now you're building the layer your household touches most often: the switch by the door, the lamp in the evening, the blind in the morning, the hallway light at night. This module is practical and purchase-focused, but in this lesson you're not buying hardware yet. You're settling on a philosophy, a Plan B, and a room map.

Plan on about 75 to 85 minutes. From here on, I'll shorten Home Assistant to HA.

The module's main rule
First manual control and a Plan B.
Then scenes.
Only at the end, automations.

A real-life problem: a smart home that's annoying

You bought smart bulbs for the living room and hallway. In the evening, a guest uses the plain wall switch. The bulb loses power. Home Assistant shows unavailable. In the morning, the "lights after sunset" automation doesn't work, because someone physically cut the power overnight. Your partner says, "I'd rather have a normal light."

Or the blinds: you set closing for 10 PM. On a Saturday, someone's sitting on the terrace. The blind rolls down, because the automation doesn't know about the open patio door. Or motion-activated bathroom lighting turns off after two minutes even though someone is in the tub, because the PIR sensor can't see motion behind the shower curtain.

This isn't "bad Home Assistant." It's a missing plan: what should be manual, what should be automatic, what works without HA, and how a household member can temporarily block an automation. In this module, we're not just asking "how do I add a light entity." We're asking: what to buy, what not to buy, how not to break manual control, and how not to build an automation that annoys people.

What you want to achieve, not what to buy

Before you open a store, write down three goals for your house. Not "I have Hue," but "I want to dim the living room and leave the kitchen underlight on with one button in the evening." Not "smart blinds," but "in the morning I don't want the sun shining straight in my face, but in the evening I don't want the blind rolling down over someone on the terrace."

Light and blinds touch every household member. A guest, a child, a partner, a roommate. If the only way to turn on a lamp is an app, the project is flawed. If the only way to stop an automation is editing YAML, the project is flawed too. A good smart home is one where a household member doesn't have to think about repetitive things, but can still easily take back control.

Convenience: evening scenes, a hallway light at night, blinds in the morning without walking through the house.

Safety: automation must never increase the risk of pinching, entrapment, or blocking an exit; the bathroom light shouldn't go out at the wrong moment.

A Plan B: when HA, the network, or a module fails, someone can still turn on the light and raise the blinds.

Household peace of mind: nobody has to learn your system just to walk through the hallway.

Three layers: manual, scenes, automations

Manual has to work from day one: a switch, a button, a remote, a dashboard tile. Scenes are a saved set of states across multiple lights (e.g. "Movie": living room 20%, kitchen 5%). You trigger them deliberately. Automations react to time, motion, or the sun without you being there. In Lessons 10 through 13 of this module you'll build lighting and blinds scenes and automations.

A beginner's mistake: starting with a "lights after sunset" automation across the whole house before the switch by the door even makes sense. First make sure every point can be turned on and off manually without frustration. Then add two or three scenes. Automations last, with a blocking helper.

Manual control versus a Plan B: two different concepts

Manual control is a deliberate action: a switch, a button, a remote, a dashboard tile. It may require working HA, a network, or a bridge. A Plan B is the answer to: what still works when HA, the network, a bridge, or a module doesn't?

A remote in the HA app is manual control, but not a Plan B. A switch that locally toggles a relay without a server is a Plan B. The fact that a remote is a physical device doesn't by itself mean it works without HA. A remote paired directly with the lamp, or handled locally by a bridge, may retain basic control. A remote whose clicks trigger only Home Assistant automations will stop working the moment the server does. You confirm this with an outage test, not by the product name.

A dashboard in HA is not a Plan B.
A wall panel, an app, and a dashboard all require a working server, network, and client device. A Plan B has to work without the app.

Important: detach mode isn't always a Plan B

In detach mode, a physical button can be disconnected from directly controlling the relay. A click then becomes just a signal to the device, a bridge, or Home Assistant.

If the response to a click is handled exclusively by an automation in HA, the button may stop controlling the light once the server fails. A Plan B only exists once the device carries out the response locally, or has a direct output-control mode.

A mandatory test: turn off Home Assistant and check whether the physical switch still turns the light on and off. Don't assume this from the feature's name in the manufacturer's app alone.

The safest explanation: relay mode means the wall input locally controls the module's output. Detach mode means the input sends a signal, but doesn't necessarily switch the output directly. A Plan B only exists once the button's response has been confirmed with HA turned off. The mere presence of a physical switch doesn't yet mean independence from HA.

A Plan B: check specific kinds of failures

The sentence "it'll work in an emergency" is too vague. A system can behave differently with no internet, an HA failure, a lost Zigbee network, a router outage, or a damaged module itself. That's why you check every important light and every blind separately.

1. No internet

The home network and HA can still work. Local lighting shouldn't depend on access to the manufacturer's cloud.

2. Home Assistant is off

Check whether the wall switch still controls the light, and whether the blind's local button can still stop it, raise it, and lower it.

3. Wi-Fi, Zigbee, or a bridge is down

A device can disappear from HA. Manual control of a basic function should stay available, if the installation is built to allow it.

4. A module in the box has failed

A switch wired to a failed module can also stop working. The user shouldn't attempt any wire-bridging themselves. The emergency plan is documenting the circuit, noting the module's model, and calling an electrician to replace the device or temporarily restore normal switching.

5. No power in the building

Neither a plain lamp nor a smart relay will work. You need a flashlight, emergency lighting, or another solution independent of the lighting installation.

What takes priority when commands conflict

In a well-designed system, not every command carries equal weight. When a household member manually stops a blind or turns on a light, an automation shouldn't immediately fight that decision.

  1. Device and installation safeguards.
  2. A household member's manual command: a switch, an up/down/stop button.
  3. An active block: the terrace, cleaning, guests, automation disabled.
  4. A deliberately triggered scene.
  5. An automation: time, motion, lux, the sun.

In later lessons, we'll add a manual-override window, so an automation doesn't immediately try to undo a household member's decision. Example: an automation closes a blind, a household member presses STOP. The system shouldn't close it again five seconds later just because the condition is still met.

Light versus blinds: different risk levels

A lighting automation mistake usually doesn't create the kind of mechanical hazard a moving blind can, but it can still be dangerous. A light can go dark on the stairs, in the garage, during a bath, or exactly when a household member needs good visibility. It can also suddenly switch to full brightness at night or hinder an evacuation. That's why lighting automation also has to leave easy room for manual takeover.

A blind adds another risk category: a motor, moving mechanical parts, limit switches, obstacles, an open patio door, kids, and pets. That's why you roll it out more slowly and test it separately. In Lesson 7 we'll cover terrace locks and calibration.

A door sensor doesn't replace a mechanical safeguard

A patio door contact sensor can block automation while the door is open, but it isn't a human or obstacle detection system. It can have a dead battery, lose connection, or report a bad state. Automation in HA is an extra layer of caution, not a substitute for the motor's own safety functions and a properly installed blind.

Missing data doesn't mean it's safe

If a door, presence, or blind-position sensor reports unknown or unavailable, the automation shouldn't guess. For blinds, the safer response is skipping the automatic move and leaving control to the household. We'll cover this in Lessons 7 and 13.

Ordinary points and critical points

Not every point needs the same level of reliability. A decorative strip behind the TV occasionally not responding may have no serious consequences. Lighting on stairs, at the entrance, in the garage, the boiler room, the bathroom, or by an emergency exit should keep simple manual control even when the smart layer isn't working.

Likewise, a terrace blind carries more risk than a blind in an unused room. On your map, mark critical points with an exclamation mark. For these, require simpler control, fewer dependencies, and a mandatory test after every major configuration change.

230V installations

This course doesn't teach electrical wiring work. Don't remove fixtures, touch wires, identify them by color alone, or take measurements without proper qualifications. Diagnosing the installation, selecting protective devices, and mounting modules is a job for a qualified electrician, following the device's and the installation's documentation.

What this module is, and what it isn't

It is: a practical buying and design guide. Bulb versus relay, scenes, motion, the sun, blinds, a dashboard.

It is: a comparison of hardware categories (relay, dimmer, roller-blind module, remote, smart bulb) with brand examples in Lesson 2.

It isn't: an electrical wiring course.

It isn't: a "buy this" list. What matters is fitting your own installation.

Four hardware categories: separate them from the start

We come back to this split throughout the module. It helps with purchases and with Plan B. We'll compare specific models in Lesson 2.

1. Battery-powered: remotes, wireless buttons, PIR sensors. They don't touch 230V. A battery remote doesn't replace a switch in the 230V installation.

2. 230V in the box: relays, dimmers, modules behind the switch. Require an electrician.

3. Blind motors: roller-blind modules, blind switches, drive units. This is mechanics, not a lamp.

4. Light sources: smart bulbs, LED strips, lamps, LED controllers (e.g. WLED from the ESPHome module).

Manufacturer names will appear in Lesson 2 as examples of each category. Don't buy a device based on the family name alone. Within a single line, there can be versions requiring a neutral wire, versions without N, different protocols, and different load limits.

Three starting levels in every room

Level 1: don't touch the installation: a smart bulb, a smart plug, a remote, a battery sensor. Watch out for the wall switch (Lesson 3).

Level 2: a module in the box: a relay behind the switch. Needs a neutral wire, room in the box, and an electrician (Lesson 4).

Level 3: a purpose-built installation: momentary buttons, a dimmer, a staircase circuit done with an electrician, LED strips with a dedicated power supply.

The room map: the foundation of the whole module

The map isn't a list of entities in HA. It's a document outside the system: a notebook, a text file, a table. For every point, you record: how you turn on the light today, the starting level, a Plan B for various failures, risks, and the date of the last test. The map survives an entity_id change, a module swap, and an integration migration.

Lighting and blinds map template

Room Point / circuit How it works today Starting level Planned device Without HA Without the radio network After a power outage Risks Test date
Living room Ceiling Switch by the entrance 2 A relay after consulting an electrician The switch should still work Local control Light off Guests use the switch To fill in
Hallway Ceiling Three-way (2 locations) 2 A relay + electrician Both switches work Locally Dark ! stairs, a fall To fill in

Copy the table into a notebook and fill in the rows for your own house. The ! symbol marks a critical point.

Map examples: living room, hallway, bathroom

Living room: a ceiling light with a switch by the entrance, blinds on the terrace. Ceiling starting level: 2. Blinds: manual for now, automation after Lesson 7 with a terrace lock. Plan B: the ceiling switch works without HA (once tested); the blind has a manual up/down/stop switch.

Hallway: one light, a three-way switch. A critical point. Plan B: both switches must turn on the light without the app and without HA.

Bathroom: moisture, short visits, longer baths. Plan B: the switch by the door always works. Motion automation only comes later, with a timer and a lock (Lesson 11).

The module's helpers: the main automation permissions

Before you add your first lighting or blinds automation, add two toggle-type helpers. Leave them off for now. The helper by itself blocks nothing until an automation checks its state as a condition. In Lessons 10 through 13 of this module, every automation in the automated layer will do exactly that.

An important rule: the lighting_automation_enabled helper blocks actions triggered automatically, for example by motion, time, or sunset. It shouldn't block a plain switch or a scene deliberately triggered by a household member. The same goes for blinds: manually pressing up, down, or stop takes priority over a schedule.

Method 1: creating helpers in the UI

  1. Go to Settings → Devices & Services → Helpers.
  2. Choose Create Helper.
  3. Choose the Toggle type.
  4. Create a separate helper for lighting automation and one for blinds automation.
  5. Once they're created, check their actual entity IDs in Developer Tools → States.

Method 2: configuring in configuration.yaml

In this approach, you paste the block below into your configuration.yaml file, check the configuration, and restart Home Assistant. Don't create the same helpers simultaneously in the UI and in YAML.

input_boolean:
  lighting_automation_enabled:
    name: Lighting automation enabled
    icon: mdi:lightbulb-auto
    initial: false

  blinds_automation_enabled:
    name: Blinds automation enabled
    icon: mdi:blinds
    initial: false

The initial: false parameter means the helper returns to the off state after every Home Assistant restart. At the module-building stage, this is safe: automations won't start acting after a restart without your deliberate consent.

After every restart, the helpers' status has to be visible on the dashboard. There should never be a situation where the automation is silent and a household member doesn't know why.

If, after finishing the module, you want to restore the pre-restart state, remove the initial: false line. We'll come back to that decision in Lesson 14.

The helper by itself doesn't block anything yet. Every automation has to include a condition checking its state.

The main permission and local locks

The two helpers from this lesson are the main permissions for the whole automated layer. Turning off the lighting helper should block new automatic actions from starting (motion, time, sunset, lux), but it can't block a manual switch, a remote, or a deliberately triggered scene. It also shouldn't always interrupt an already-started, safe cycle in progress: for instance an active shutoff timer (we'll develop the semantics of finishing a cycle in Lesson 11).

In later lessons you'll also add local locks, for example a lock on bathroom motion lighting or a lock on the terrace blind. That way you don't have to turn off automation across the whole house for one exceptional situation.

An automation template: just the main-permission condition

The example below shows only where to place the helper's condition. It's not a complete hallway automation.

- id: hallway_motion_only_when_automation_enabled
  alias: Hallway - motion only when automation is enabled
  description: >
    An example showing how the lighting automation's main permission works.
    The full automation with shutoff and a timer arrives in Lesson 11.
  mode: restart

  triggers:
    - trigger: state
      entity_id: binary_sensor.hallway_motion
      to: "on"

  conditions:
    - condition: state
      entity_id: input_boolean.lighting_automation_enabled
      state: "on"

  actions:
    - action: light.turn_on
      target:
        entity_id: light.hallway_ceiling
      data:
        brightness_pct: 30

This example isn't yet a complete hallway lighting automation. It only shows where to place the main-permission condition. A timer, re-detecting motion, night mode, lux, and manual override are added in later lessons.

What's actually the risk

Cutting power to a smart bulb at the switch: HA loses contact, a household member loses trust.

Detach with no local test: the switch looks normal, but does nothing once HA fails.

Automatically closing blinds with no door sensor or lock: the terrace, kids, pets.

Motion lighting with no night mode and no manual lock: it goes out at the wrong moment.

Buying with no map: a pack of bulbs, then a problem with the three-way switches.

What can go wrong

A map made "in your head" disappears after a week. Helpers get added but never used in an automation's conditions: the lock does nothing, since there's nothing for it to lock. A Plan B described only as "I'll turn it on from the app." Starting level 2 written in for every room without consulting an electrician: you might discover a missing neutral wire in half the house. After an HA restart, helpers with initial: false go back to off and automations fall silent, even though a household member thinks everything's still on.

What not to do

Don't buy a pack of bulbs before the map and the bulb-versus-relay decision.

Don't open electrical boxes or touch 230V wires without an electrician.

Don't treat a dashboard, an app, or an HA-dependent remote as a Plan B.

Don't assume detach alone guarantees the switch will work after an HA failure.

Don't plan blinds automation without a safety section (Lesson 7).

What you can plan yourself, and what's an electrician's job

You: the map, choosing a hardware category, helpers, scenes, automations, the dashboard, paper outage tests.

You: smart bulbs, remotes, battery sensors, plugs (without opening boxes).

Electrician: diagnosing the neutral wire, mounting a relay, dimmer, or roller-blind module, a staircase circuit.

You, after installation: the HA integration, entity names, testing the switch with HA turned off.

Lesson 1 final check

☐ I added the two main helpers and left them in the off state.
☐ I understand a helper blocks nothing until an automation checks its state.
☐ I understand that initial: false resets a helper after an HA restart.
☐ For every main light point, I wrote down how it's manually controlled today.
☐ For every blind, I noted whether I have local up, down, and stop buttons.
☐ I described behavior for no internet, an HA failure, a radio-network failure, and a module failure separately.
☐ I didn't count a dashboard or an app as a Plan B.
☐ I marked critical points: the terrace, stairs, bathroom, children, older household members.
☐ I noted which scenes will be triggered deliberately, and which actions might someday be automated.
☐ I established that a household member's manual command takes priority over automation.
☐ I'm not planning any 230V installation work without an electrician.

Key takeaways

The order: manual and a Plan B, then scenes, then automations.

A Plan B ≠ a dashboard: test specific failures, don't assume from the word "detach."

The room map: a document outside HA, with failure columns and a test date.

Helpers: a main permission, not a scene lock; initial: false deliberately, during the learning stage.

Priority: safeguards, a household member's hand, a lock, a scene, only then automation.

What's next

In Lesson 2, you'll go through lighting hardware: smart bulbs, relays, dimmers, LED strips, remotes, and sensors. Every category comes with an explanation of how it works, its HA entities, and a comparison of market examples. If you have your room map, you'll assign categories to specific rooms right away.

Finished this lesson?