A practitioner's checklist for getting your smart home right from the start — before bad habits become hard-to-fix automations.
Don't want to read the whole guide right now? Do these 8 things in order. No decisions. No branching. Just the path that works.
room_device_qualifier.Read the full sections when something isn't working, when you're ready to go deeper, or when you hit a decision that isn't obvious. The guide is designed to be a reference — not a linear read.
Get this list sorted before you start. The guide assumes you have a host device, a router you can log into, and a phone. Everything else is optional or addable later.
| Item | What to Get | Required? | Skip If... |
|---|---|---|---|
| HA Host DeviceThe machine HA runs on |
Budget (~$35–60): Raspberry Pi 4 (4GB) or Pi 5 — great for most homes Mid (~$100–200): Intel NUC, Beelink mini PC — more headroom, runs other services too Repurposed: Any old PC or laptop (x86-64) — see Vol. 1 for full setup guide |
Required | You already have a machine you plan to dedicate to HA |
| StorageWhere HA lives |
Pi: High-endurance microSD (32GB min) — or better, a USB SSD boot drive NUC/mini PC: Any SSD already inside the machine is fine. 32GB minimum free. |
Required | Your host already has adequate storage installed |
| Zigbee CoordinatorUSB dongle for Zigbee devices |
Recommended: SONOFF Zigbee 3.0 USB Dongle Plus (~$20) or Electrolama zzh! Only needed if you're using Zigbee devices. Skip entirely if using Wi-Fi smart devices. |
Optional | All your smart devices use Wi-Fi or you have no smart devices yet |
| Ethernet CableWired connection for HA host | Any Cat5e or Cat6 cable long enough to reach your router or switch. HA on Wi-Fi works but is less reliable for automations and remote access. | Required | Your host is physically next to your router already |
| USB Drive or NASOff-device backup target | A USB drive (32GB+) plugged into the HA host works fine. A NAS or second server is ideal. Google Drive via add-on is the easiest path if you have neither. | Optional | You'll use the Google Drive Backup add-on instead |
Flash the HAOS image to your drive. balena.io/etcher — Windows, Mac, Linux. Download before you start.
For the Google Drive Backup add-on. Any existing Google account works — you don't need a new one.
Needed for Cloudflare Tunnel remote access. Register at Cloudflare Registrar. Optional if using Nabu Casa instead.
If you don't have any smart devices yet: start with one Zigbee smart bulb (IKEA TRÅDFRI or Sengled, ~$10) and a Zigbee contact sensor (~$8). These validate your coordinator, give you something to automate on Day 1, and are cheap enough to replace if something goes wrong during setup.
You don't need to be a network engineer. But you do need your network to be set up correctly before HA will behave reliably. Here's exactly what matters and why.
| Requirement | Why It Matters | Covered In |
|---|---|---|
| Wired connection for HA host | HA polls devices constantly. Wi-Fi packet loss causes phantom "unavailable" states and unreliable automations. Run a cable if at all possible. | This guide |
| DHCP reservation for HA server | Every integration references HA by IP. If the IP changes, the Companion App, remote access, and tunnel configs all break simultaneously. | Thing 04 |
| mDNS / local hostname resolution | Allows homeassistant.local to resolve on your network. Enabled by default on most routers. Required for easy initial setup. |
This guide |
| No port forwarding needed | HA does not require open inbound ports if you use Cloudflare Tunnel or Nabu Casa. Never forward port 8123 to the internet — that's a security risk. | Thing 09 |
| VLANs for IoT devices | Isolates smart devices from your main network. Not required for basic HA, but recommended as your device count grows. Requires a managed switch. | Vol. 1 |
| SSH access to your HA server | Needed for advanced config editing, log access, and recovery. Not required to get started, but becomes essential for a serious setup. | Vol. 1 |
The Bench Notes Home Lab Playbook (Vol. 1) covers SSH setup, VLANs for IoT isolation, AdGuard Home for network-wide DNS filtering, Cloudflare Tunnels in depth, and running a dedicated server alongside HA. If you're planning a full homelab alongside your HA setup, Vol. 1 is the companion guide. Available at the HomeLabGuides shop on Etsy.
This is the shape of a well-configured Home Assistant setup. Every component in this guide maps to something in this diagram. Keep this page handy during setup.
Everything flows through the HA server. Devices connect locally (Zigbee or Wi-Fi). Remote access goes out through Cloudflare, never in through an open port. Backups go both local (NAS) and cloud (Google Drive). Your phone talks to HA both directly on your home network and remotely through the tunnel.
This is your first-hour checklist. Don't skip ahead. Each item enables the next one. Check these off in order before exploring anything else.
A day-by-day plan for your first weekend with Home Assistant. Follow this sequence and you'll have a stable, backed-up, secure setup by Sunday evening.
Add one new thing at a time, test it fully, take a backup, then add the next. The people who end up with a broken HA and no idea why are always the ones who added 12 things in 90 minutes on a Saturday afternoon.
Skip the decisions. Follow these 8 steps in order and you'll end up with a solid, working system. Everything else in this guide is context and optimization.
There are four ways to run Home Assistant, and the choice matters more than most guides admit. Two of them will quietly limit you later. Here's the honest breakdown.
| Method | What It Is | Add-ons? | Best For | Verdict |
|---|---|---|---|---|
| HAOS (Home Assistant OS) |
Dedicated OS image — runs HA and nothing else on the machine | Full | Dedicated hardware (Pi, old PC, NUC) | ✓ Best |
| Supervised | HA supervisor on top of an existing Debian OS | Full | If you need other services on same machine | ✓ Good |
| Container (Docker) |
Just the HA core in a Docker container | None | Experienced Docker users only | ⚠ Limited |
| Core (Python venv) |
Raw Python install in a virtual environment | None | Developers / advanced users | ⚠ Advanced |
I ran HA Container for six months before switching to HAOS. The moment I wanted to add the Zigbee2MQTT add-on, I hit a wall — Container doesn't support the Supervisor or add-on ecosystem at all. I had to migrate my entire config. Start on HAOS and you never have to make that call later.
For most people — especially if you have a spare Raspberry Pi, Intel NUC, or old mini PC — HAOS is the correct choice. It gives you full add-on support, automatic OS updates, and the official snapshot backup system.
Before you walk away — go into your machine's BIOS and set Power Restore Behavior to "Always On" (sometimes called "Restore AC Power Loss"). Without this, a single power blip takes your entire smart home offline and keeps it there until you physically press the power button.
This sounds trivial. It isn't. Half of all "my automation fires at the wrong time" complaints trace back to this step being skipped or set incorrectly during onboarding.
Home Assistant uses your location for two things that power a massive chunk of useful automations: sun position (sunrise/sunset triggers) and time zone (time-based conditions). If either is wrong, your "turn on the porch light at sunset" automation fires in a different time zone, or at the wrong time because HA is using UTC internally.
Settings → System → General → Home location. You'll see a map. Drop the pin to your actual address — not a city center. HA uses this pin to calculate precise local sunrise/sunset times.
Set to your actual home address. HA uses this for sun calculations, weather integrations, and zone automations like "when I get home."
Set this even if HA seems to detect it. Confirm it matches your local time. All automation triggers, logs, and history are stamped with this zone.
US Customary vs Metric. Set this before adding temperature sensors — changing it later means all your historical data logs with mixed units.
Used by the Energy dashboard if you track electricity costs. Set it now so the energy panel shows correct cost-per-kWh math from the start.
Once your location is set correctly, sun.sun becomes one of your most reliable automation triggers. "Turn on outdoor lights 30 minutes before sunset" will work perfectly and automatically adjusts every day of the year without any maintenance.
The HA overview shows your local time correctly. Sunrise/sunset times in Developer Tools → States for sun.sun match your actual local times.
Automations trigger at the wrong time. Sun-based triggers are off by hours. HA logs show UTC times while your clock shows something different.
Developer Tools → States → search sun.sun. Check next_rising and next_setting — they should match today's actual sunrise/sunset for your city.
Seriously — this is Thing 02 because it should happen before you add a single integration. HA's built-in backup system is excellent, but it only helps if you set it up before you need it.
Home Assistant OS has a first-party backup system that creates complete snapshots of your entire installation — config files, integrations, automations, add-ons, dashboards, everything. The default configuration stores backups locally on the HA machine. That's a single point of failure. You need at least one copy elsewhere.
Install from the Add-on Store. Authenticates with your Google account. Copies every backup automatically to Drive. Free up to 15GB — more than enough for years of HA backups.
If you already have a NAS or another server on your network, add it as an SMB network location. Backups write there directly without cloud dependency.
I learned this the hard way. I had weeks of integration config, Zigbee device pairings, and dashboard layouts in HA when my SD card on a Pi died. No backup. I had to re-pair every single Zigbee device from scratch — that alone took a full Saturday. Backups with Google Drive took 10 minutes to set up. That SD card failure would have been a non-event if I'd done this on Day 1.
Settings → System → Backups → pick your snapshot → Restore. For a full disaster recovery on a fresh install: complete the onboarding wizard (just click through), then immediately go to Backups and restore your snapshot before configuring anything else.
At least one backup exists in Settings → Backups. A second copy lives somewhere other than the HA machine itself. Auto-backup schedule is active.
Only local backups exist. Google Drive add-on installed but not authenticated. No backup schedule set — only a manual snapshot.
Settings → System → Backups → confirm at least 1 backup exists. If using Google Drive add-on, open it → check the last sync timestamp is recent. Try a manual restore flow on a test backup.
Before building anything, understand the shape of your system. This is what you're creating — and why each step in this guide matters.
HA supports 3,000+ integrations. The instinct is to add everything you own immediately. Resist it. Add these on Day 1, then slow down and be deliberate about everything else.
Don't add cloud-dependent integrations (SmartThings, Google Home, Alexa) until you understand your local setup. They add polling overhead, can cause HA to slow down if their cloud APIs are flaky, and often duplicate entities you already have from local integrations. Add them later, intentionally.
Companion App shows phone as a device in Settings → Devices. Weather entity is populated with current conditions. No integrations showing yellow warning badges.
Companion App device_tracker shows "unavailable." More than 5 integrations added on Day 1. Any integration showing a persistent auth or connection error.
Settings → Devices & Services — count your integrations. If more than 5, stop and evaluate. Developer Tools → States → search your phone name — confirm device_tracker shows "home."
This is infrastructure work, not HA work — but it's the most common reason automations mysteriously break weeks after you build them.
Home Assistant references devices by IP address in many integrations. When your router's DHCP lease expires and reassigns addresses, the device at 192.168.1.42 is suddenly at 192.168.1.87 — and HA loses it silently. No error. Automation just stops working.
Every router has a DHCP reservation feature — it permanently assigns a specific IP to a specific device's MAC address. This is better than setting a static IP on the device itself because the router's DHCP server still manages the address, and it works even if you reflash or reinstall the device.
Home Assistant server itself · All Zigbee/Z-Wave coordinators · Smart TVs and media players · IP cameras · Any device with an HA integration · Your NAS or server
Phones and laptops (HA uses the Companion App, not IP) · Guest devices · Devices with no HA integration · Battery-powered sensors on Zigbee/Z-Wave (no IP at all)
Once you're assigning IPs, make a simple reference list. A text file, a spreadsheet, a note — anything. Recording the device name, MAC address, assigned IP, and what it does takes 2 minutes per device and saves hours of debugging later.
I use a naming convention of 192.168.68.x for everything. All my cameras are in the 50s, servers in the 60s, IoT devices in the 70-90s. When I look at a log entry or a ping, I know immediately what category of device it is. Takes 20 minutes to plan upfront and saves a lot of "wait which device is that?" moments later.
HA server has the same IP after a reboot. Your router's DHCP reservation list includes at least HA + any devices with integrations. You have a reference list of reserved IPs.
HA server IP changed after a router restart. Devices show "unavailable" in HA after a network event. You're not sure what IP your HA server is on right now.
Log into your router's DHCP reservation page and confirm HA's MAC address is listed with a fixed IP. Ping that IP from another device. Reboot HA and verify it comes back on the same address.
Entity names are the bones of your HA setup. Renaming them after you've built automations and dashboards is tedious — HA doesn't cascade-rename entity IDs. Do this once, do it right.
When HA creates an entity, it generates an entity ID from the name. light.living_room_lamp_3 happens automatically if you don't intervene. If you rename the entity later, the entity ID stays the same — and now you have a lamp called "Living Room Lamp" with ID light.living_room_lamp_3 forever.
Settings → Devices & Services → Entities. Search for any entity, click the gear icon, and set both the Display Name and the Entity ID. Do this before you reference the entity anywhere.
Settings → Areas, Zones, & Labels. Create a room for every room in your house before adding devices. When you add a device, assign it to an area immediately. This enables area-based voice commands ("turn off the bedroom"), and keeps your dashboard organized as your device count grows.
Every entity ID follows your chosen pattern. No entities named with MAC addresses, auto-incremented numbers, or default integration names. All devices assigned to an area.
Entity IDs like light.0x00158d001 or switch.smartplug_1_2. Multiple devices assigned to "No area." Friendly name and entity ID don't match your convention.
Settings → Devices & Services → Entities. Sort by entity ID. Scan for anything that doesn't match your naming pattern — fix it now before it gets referenced anywhere.
The default "Overview" dashboard HA auto-generates is fine for testing. Build your own before you get attached to it, using principles that won't make you rebuild it in three months.
Never put individual entity cards directly on your main dashboard. Group everything by room, then put rooms on the dashboard. When you add a 20th light to a room, you update one card. Not twenty.
Main, Upstairs, Basement. Each view is a tab. Start here before getting more granular.
One "Room Card" (entities card) per room per view. Lights, switches, sensors all in one card per room.
A glanceable strip: outside temp, alarm status, presence (who's home), and one important sensor.
My first dashboard had 47 individual entity cards. It took 30 seconds to scroll through. I rebuilt it with 8 room cards and a 4-entity status strip at the top, and that's been stable for over a year with no major changes despite adding dozens of new devices. Simple structure scales. Complex structure explodes.
Your custom dashboard is the default view. It loads in under 2 seconds. You can control any light or switch without scrolling more than one screen. It looks usable on mobile.
Still using the auto-generated "Overview" dashboard. More than 12 cards on a single view. Dashboard broken after adding a new device because cards reference individual entities.
Open your dashboard on a phone screen (or shrink your browser window). Can you see and use everything without scrolling excessively? If not — consolidate into room cards first.
Every house benefits from these three automations on Day 1. They're simple, reliable, and demonstrate every major automation concept you'll build on later.
Every automation has the same three-part structure. Understanding this shape makes every automation easy to read and write.
Turn on outdoor or porch lights 15 minutes before sunset. Turn them off at a fixed time (or sunrise). This is the "hello world" of HA automations — and it's genuinely useful.
When everyone's phone leaves home, turn off unnecessary lights and lower the thermostat. When anyone returns, restore normal state. Uses the Companion App's device_tracker.
Use a person entity, not a device_tracker directly. A person entity combines multiple trackers (phone GPS + router + BLE beacon) and is more reliable. Settings → People → edit each person → add tracking sources.
At a fixed weekday time, gradually increase a light's brightness to simulate sunrise, or just turn on the kitchen light when motion is detected in the morning. Use a time condition to prevent it firing on weekends.
At least one automation has run successfully and is visible in the Logbook. You can see the last triggered timestamp in Settings → Automations for each one you've built.
Automation was created but never triggered. "Last triggered" column shows never. Automation is enabled but the entity it controls shows "unavailable."
Settings → Automations → find your sunset automation → press the ▶ Run button manually. Verify the light turns on. Check Logbook — you should see the triggered entry with a timestamp.
HA can notify you about almost anything. The skill is restraint. A smart home that cries wolf every 10 minutes is worse than no notifications at all.
Works out of the box once the app is installed. Sends to specific people's phones. Best for presence-aware alerts — "the garage door has been open for 30 minutes while you're away."
Self-hosted push notification server. Works on any device without a phone app requirement. Good for server health alerts, automation summaries, and non-time-critical status updates.
New HA installs almost always over-notify. It feels useful — until your phone buzzes 15 times in an hour and you start ignoring everything. Build the habit of categorizing each notification before writing it. If it's not something you'd actually act on at 2am, suppress it or roll it into a daily digest.
You can send a test notification from Developer Tools → Services → notify.mobile_app_yourphone and it arrives within 30 seconds. Every planned alert is categorized in your hierarchy.
Test notification never arrives. Companion App shows notification permissions as blocked. You're already getting more than 5 notifications per day from HA after day one.
Developer Tools → Services → search notify → select your phone → send "HA test notification" as message → confirm it arrives. If not, check phone notification permissions for the Companion App.
Before reading Section 09, answer these questions in order. Most people land on one clear answer within 60 seconds.
You need access to HA when you're away from home. The wrong way is opening port 8123 on your router. Pick one of the two right ways below — then follow the steps.
Do not forward port 8123 on your router. Your HA is then directly reachable from the open internet with nothing in front of it. Both Nabu Casa and Cloudflare Tunnel avoid this entirely — that's the point.
ha.yourdomain.net) pointing to localhost:8123. That's it — no open ports, full TLS, Cloudflare's WAF in front.The Bench Notes Home Lab Playbook covers Cloudflare Tunnel setup end-to-end, including running multiple services (not just HA) behind a single tunnel, Cloudflare Access for authentication, and DNS configuration. If you're also running a homelab server, Vol. 1 covers this as part of your full remote access architecture.
HA only loads on home Wi-Fi. Cloudflare tunnel shows as "inactive" in Zero Trust dashboard. Certificate error or HTTP (not HTTPS) in browser when accessing remotely.
Turn off Wi-Fi on your phone. Open your HA URL in mobile browser. It should load with HTTPS and no warnings. Then open the Companion App — it should connect and show your dashboard.
HA releases updates every month. Add-ons release even more frequently. Not everything should auto-update — but some things absolutely should.
Add-ons (Mosquitto, MariaDB, Samba, etc.) — minor updates rarely break things and security patches matter. HACS integrations — most are safe on auto. OS updates — Watchtower handles this if you run containerized services alongside HA.
Home Assistant Core — take a snapshot, read the release notes, then update. Minor versions (2025.x.y → 2025.x.z) are usually safe. Major version jumps occasionally have breaking changes. Zigbee2MQTT — read the changelog first.
HA 2024.x had a breaking change in how entity categories work that silently broke three of my automations — they still ran, but the wrong entities were targeted. Reading the release notes took 5 minutes. Finding the bug took 2 hours. I now skim the breaking changes every update before applying. Also: do not update the night before a vacation.
You have a clear policy: which add-ons auto-update, which require manual review. A backup exists that was taken within the last 24 hours. You know where the release notes live.
Everything set to auto-update including HA Core. No backup taken before the last update. You've applied an update and something broke but you can't roll back.
Settings → Add-ons → confirm auto-update is only enabled on safe ones. Settings → System → Backups — confirm a recent backup exists. Bookmark home-assistant.io/blog for release notes.
What a power outage, three hardware failures, and two years of automation debugging taught me about setting up Home Assistant right the first time.
My first Intel NUC was running HA perfectly for weeks. Then a brief power blip — probably 3 seconds — took the whole setup down. Not because anything broke. Because the BIOS "Power Restore" setting was on "Last State," which meant a machine that was on when power was cut would stay off when it came back. I came home to a dark house and zero automations running. The fix took 2 minutes in BIOS. The lesson cost me an afternoon.
I built a weather alert automation that flashed lights red, then "restored the previous state" when the alert ended. What actually happened: if HA restarted during the alert, it lost the "previous state" context entirely and left every light stuck in whatever state it was in at restart. The fix was storing pre-alert state in an input_boolean before the alert fires, and restoring from that. Restore-on-restart logic needs a persistent anchor, not just runtime memory.
Phone GPS alone is unreliable. My "everyone is home" trigger would sometimes not fire for 10 minutes after arriving because iOS aggressively batches location updates. I ended up with a three-source presence detection setup: phone GPS (primary), router-based detection (faster, local), and BLE beacon (instant, passive). Combining all three into a single person entity through HA gives you sub-30-second detection that's still reliable when one source goes quiet.
I have an entity still called light.0x00158d0001a23f from a Zigbee bulb I added in year one. That's its MAC address, which HA used as the default name because I didn't intervene. It's referenced in 4 automations. Renaming the entity doesn't change the ID, and changing the ID means updating every automation by hand. It's not catastrophic — but every time I look at that automation YAML I regret the 10 seconds I didn't spend naming it properly. Ten seconds. That's what it costs to do it right.
The most common HA problems, each with a specific diagnostic path. When something stops working, start here before asking in forums.
notify.mobile_app_yourphone → send a manual test notification first
2If manual test fails: open Companion App on phone → check Settings → Notifications → confirm enabled
3Check phone OS settings — iOS and Android both have per-app notification permissions that override HA
4If manual works but automation doesn't: add a Logbook card to your debug dashboard and check if the automation ran at all
5Check the notify service name exactly — entity names are case-sensitive and device name changes break the service name
systemctl status cloudflared — confirm service is running, check for errors
3For Nabu Casa: Settings → Home Assistant Cloud → check subscription status and connection indicator
4Try accessing from a browser (not the app) first — this isolates whether it's a Companion App config issue
5Check configuration.yaml — the homeassistant.external_url must match your tunnel's public hostname exactly
home-assistant.log — the first ERROR line is almost always the root cause
5If all else fails: restore your pre-update backup from Settings → Backups. This is why you take a backup before every Core update.