This lesson closes out Module 20: a Home / Technical / Service dashboard, a project status with a date, a four-room mini project, separated failure tests, backup versus Plan B, and handover without technical jargon. Further on I'll shorten Home Assistant to HA.

Plan on about 120 to 130 minutes. We close the module with a hands-on test, Plan B documentation, and a date for the next review: not a flashy "one more automation."

A real-life problem

A tablet packed with power, update, and restart buttons: nobody can find the patio lockout. Or: a "ready" dashboard status clicked without any testing. Or, in a badly designed setup: no panel means no control. In this module you're making sure that isn't the case: local light and STOP work even if HA goes down.

Project status: a declaration, not a certification

input_select:
  lighting_blinds_plan_status:
    name: Lighting and blinds plan status
    icon: mdi:clipboard-check-outline
    options:
      - designing
      - testing
      - ready
      - needs_review
      - disabled

input_datetime:
  lighting_blinds_last_review:
    name: Last lighting and blinds review
    has_date: true
    has_time: false

Semantics: designing → testing → ready; needs_review after a hardware change, an update, a bug, a season change, or a battery swap; disabled means a deliberate withdrawal. Describe the scope (e.g. living room, hallway, bathroom, bedroom): not "the whole house." Every meaningful change goes back to needs_review. Keep the status and date only on the Technical view: not on the Home screen; only the administrator changes the status. Don't use the project status as a condition controlling a light or a blind, and don't block manual functions based on it. Alongside the date, in documentation kept outside HA, record: the test's scope, the result, and notes (who checked it). A notification fired after setting "ready" verifies nothing.

Basically ready is not the same as fully tested in both summer and winter. An untested season stays disabled, or runs in observation mode. A system can be correctly finished with the blinds master off, the patio blind still manual, or no mmWave sensor at all.

Three views instead of one screen full of entities

• Automation and lockouts: not "fuses" (that's not electrical protection).
• Rooms: organized by room, not by manufacturer.
• Scenes: Evening, Movie, Guests, Night; with a description of scope.
• Status: only problems that need a response.

Separate the helper types: permissions (lighting_automation_enabled: labeled "Permission for...," not "running"); local lockouts (the patio, the hallway, the bathroom: not one global switch for motion across the whole house); override timers (timer.manual_override_...); servicing (cleaning mode with a clear scope: everything / one window); the project status, only on Technical. light_mode is the last deliberately chosen logical mode: not confirmation that a scene fully executed.

For the patio: "Lock out automatic patio closing": manual opening and STOP still work; the helper doesn't detect a person; closing the door doesn't remove the lockout. Show active restrictions at the top as text, not just as a color. STOP matters more than a 0-100 slider; STOP on the dashboard still depends on HA: a local button has to exist too. Master on plus a door sensor that's unavailable doesn't equal "automation is working": show "Automatic patio closing unavailable" instead.

Scenes: which rooms, whether blinds are involved, which mode. Movie = a mode/script with conditions, not "scene active." Don't turn off every light in the house for a movie: use Movie mode plus a local override. The hallway timer: show it in Technical during rollout; on Home only if household members actually use it. Hiding an entity from a child isn't a mechanical safeguard. Reminders about long-active modes: not an auto-expiring patio lockout.

A dashboard shows HA's model: not always the physical truth. When they don't match: use local control, don't repeat a command over and over, turn off automation, and report the problem.

A four-room mini project

Four rooms done well beats a whole house done halfway. Fill in the rows you actually have: answers are yes / no / not applicable.

Living room: Evening only in an acceptable mode; Movie/Guests = a mode or a script; a manual override; the blind handled separately with the patio lockout and the door state; the light scene doesn't hide a blind inside it.

Hallway: a local motion lockout: Movie mode in the living room doesn't turn off the bathroom.

Bathroom: a sensor matched to the room; a realistic, longer test behind the shower screen or in a zone the PIR can't reach: not "the bathtub is mandatory"; test with: a motionless person, an empty bathroom, the fan running, unavailable, and manual on/off. mmWave isn't a magic fix.

Bedroom: mainly Night and Wake-up, a manual override, and limiting noisy movement: not "sunset equals isolation." A child's room: clearly defined hours, no movement during sleep, local control; hiding the card isn't mechanical safety.

Backup is not Plan B

A backup restores your configuration: it doesn't turn on a light during a failure. Run full backups suited to your own setup; keep at least one copy off the HA device. Git versions your YAML and documentation: it doesn't replace a full backup. After a restore, check the critical entities; a changed entity_id isn't a "normal" side effect of a restore: it shows up when a device gets re-added, or after a failed migration. Do you know the password? Can you actually restore it?

Plan B works during a failure: a switch, STOP, a remote. For every new automation, ask: what if it misfires? How do I stop it? What still works without HA? Can it safely just not run at all?

Don't test by randomly powering off the whole router: separate the failures and control them deliberately (stopping HA, cutting WAN, a specific access point, the coordinator). A tablet going offline isn't the same as a home-wide failure.

A maintenance schedule

• Monthly: availability of critical devices, batteries, and lockout visibility.
• Quarterly: local control without HA, blind STOP, the patio procedure.
• Before summer and winter: temperature/lux thresholds, seasonal profiles, mechanics, icing/wind protection for awnings.
• After every major change: automations, integrations, firmware, hardware swaps, restores.

After a battery swap: run a full functional test, not just checking the percentage. RSSI isn't the only Zigbee criterion. Mechanics: noise, resistance, guide rails, STOP, travel time: without dismantling the drive yourself. A qualified person handles the wiring and covers.

Documentation kept outside HA (offline, printed, or on a phone): helpers, the patio procedure, STOP, light control without HA, test dates, and service contact info: no passwords or tokens. Instructions kept only in the cloud can be unreachable during an internet outage. Keep the patio procedure where the blind is actually controlled: not just in the closet with the router.

After spotting "blind unavailable": don't repeat the command → check the path is clear → use local control → turn off automation → record it → check power/the integration → call for service if you hear noise or resistance.

Handing the system over to a household member

Two practical markers of the project's maturity: a realistic bathroom test, and a test of working without HA.

When you can mark the project as ready

What to check after rollout

Common dashboard mistakes

Hands-on exercise: closing out Module 20

Key takeaways from this lesson and the whole module

• A dashboard is for everyday control, but it isn't Plan B.
• Global permissions, local lockouts, servicing modes, and the project status are different kinds of entities.
• The most important lockouts and problems have to be visible without scrolling.
• STOP and manually opening a blind matter more than a position slider.
• The Home and Technical dashboards are required for the exercise; Service is optional once there are more technical settings.
• A "ready" status is a manual declaration after testing, not an automatic certification.
• You record a date and scope alongside the status for the last review.
• Every significant hardware or logic change means another review.
• Testing internet, Wi-Fi, HA, the coordinator, and the module are different scenarios.
• A backup helps restore HA, but doesn't replace control that works during a failure.
• Git can version YAML and documentation, but doesn't replace a full HA backup.
• One unavailable critical entity should produce a clear message and safely limit automation.
• A household member has to be able to operate the lights, STOP, and lockouts without technical jargon.
• Functions untested in a given season stay off, or run in observation mode.
• The module is complete once the system is predictable, stoppable, and documented: not once every automation is switched on.

That's the end of Module 20. Next comes maintenance, seasonal reviews, and further expansion only where testing justifies it. Module 21 takes this same map-first, safety-first approach outdoors: garden and driveway lighting, gates, irrigation, and outdoor cameras.