A practitioner's checklist for getting your smart home right from the start: before bad habits become hard-to-fix automations.
This is the only sequence you have to follow. Everything after it is explanation. The checklists later in the guide are the same path in a different shape, not competing plans.
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 App is the easiest path if you have neither. | Optional | You'll use the Google Drive Backup App instead |
Flash the HAOS image to your drive. balena.io/etcher: Windows, Mac, Linux. Download before you start.
For the Google Drive backup integration. Any existing Google account works, though you will set up API credentials during the integration flow.
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 benchnotes.net/vol-1.
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.
The Golden Path again, as a tick-box list for your first hour. If this and the Golden Path ever disagree, the Golden Path wins.
Optional. A way to pace the Golden Path across a 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.
There are two supported ways to run Home Assistant. Older guides list four. Ignore them: Home Assistant Core (a Python environment) and Home Assistant Supervised both became unsupported after the 2025.12 release. They still technically run, but they get no support and no issue reports accepted. Do not start a new install on either one.
| Method | What It Is | Apps? | 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 |
| Container (Docker) |
Just the HA core in a Docker container. You run companion services (Mosquitto, Zigbee2MQTT, ESPHome) as their own containers. | No managed Apps | People already comfortable running a Docker stack | ✓ Good, with effort |
| Supervised (Core, Python venv) |
Both became unsupported after Home Assistant 2025.12 | — | Nobody starting today | ✗ Don't |
Full disclosure: I run Container. Home Assistant sits in Docker on a NUC, with Mosquitto, ESPHome, go2rtc, and AdGuard as their own containers beside it. So when people say Container "can't do Apps," that isn't quite right. Container can't do managed Apps. The software still runs; you just own every piece of it: separate containers, separate configs, separate updates, separate backups.
That tradeoff suits me because I was already running a Docker host and I want one update workflow I control. It will not suit most people reading a guide called 10 Things to Do First. If you want Home Assistant to behave like an appliance, where Apps install with a click and backups and updates are handled for you, install HAOS and never think about this again. Choose Container only if managing the whole stack sounds like a feature rather than a chore.
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 App 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 it early so the interface and new entities read the way you expect. Home Assistant converts many compatible units automatically, so changing it later is not the catastrophe it is sometimes made out to be, but individual integrations and per-entity overrides can still report their own 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 Settings → 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.
Settings → 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, Apps, 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.
Now an official integration, not the old third-party App: Settings → Devices & services → Add integration → Google Drive. Setup asks for Google API credentials, so it takes a few more minutes than the old App did. Backups are stored encrypted. Capacity is whatever is left in that Google account, which is usually plenty 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 disaster recovery on fresh hardware, do not click through onboarding first. Install Home Assistant and stop at the welcome screen: it offers Upload backup right there. Choose your backup file and supply the encryption key from your backup emergency kit when prompted. Home Assistant restores users, configuration, Apps, and integrations before onboarding continues.
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 integration added but not authenticated. No backup schedule set: only a manual snapshot.
Settings → System → Backups → confirm at least 1 backup exists. If using Google Drive App, open it → check the last sync timestamp is recent. Confirm the backup has a recent timestamp, a nonzero size, and at least one off-device location. Test an actual restore only on spare hardware or a throwaway VM, never on your live system.
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. Settings → 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.
Reserve: the Home Assistant host · network-connected (Ethernet/Wi-Fi) Zigbee or Z-Wave coordinators · IP cameras · smart TVs and media players · your NAS or server · anything an integration asks you to enter an IP for.
Do not bother: USB coordinators (they plug into the HA box and have no IP of their own) · Zigbee and Z-Wave end devices (they speak to the coordinator, not your network) · Bluetooth devices · phones tracked by the Companion App · cloud-only integrations. Devices found by mDNS discovery often survive an address change anyway, though a stable address still makes troubleshooting easier.
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.
Pick a naming convention for your 192.168.1.x range and stick with it. Assign blocks by device type: cameras in one range, servers in another, IoT devices in a third. When you look at a log entry or a ping, you'll 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.
Avoid one long flat list of individual entities on your main dashboard. Group by room, then put rooms on the dashboard, and use individual tiles inside a room section when a device deserves direct control. 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.
Paste each of these into Settings → Automations & scenes → Create automation → Create new automation, then the three-dot menu → Edit in YAML. Save, and Home Assistant assigns the internal ID that traces depend on.
Do not paste these straight into the automations.yaml file. That file is managed by the UI editor, and hand-editing it is how you end up with automations that exist but cannot be traced or edited.
What it does: turns the porch light on 15 minutes before sunset.
Replace: light.porch with your own entity ID.
The one above only turns the light on. Without this companion, your porch light burns until you notice. Two small automations are easier to test and fix than one clever one.
What it does: turns off selected lights five minutes after the last person leaves.
Needs: at least one person entity with a working tracker.
Replace: the area IDs.
Leaving is simple: nobody is home, turn things off. Returning is where people get clever and get burned, because "restore what was on before" means remembering brightness, color temperature, and which of six lights were on. Do not try to reconstruct an arbitrary past. Apply a known scene instead.
Use a person entity, never a raw device_tracker. A person entity combines phone GPS, router presence, and BLE into one reliable answer. Settings → People → edit each person → add tracking sources.
What it does: turns the kitchen light on at 7:00 AM on weekdays only.
Replace: light.kitchen and the time.
Run actions proves your actions work. It does not prove the trigger fires, and that is the failure people misdiagnose for hours. To test the trigger: temporarily set it a few minutes ahead, save, wait for it to fire for real, then open Traces and read what happened at each step. Traces tell you whether the trigger fired, whether each condition passed, and exactly where an action failed.
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.
Before designing a hierarchy, prove a notification can reach your phone at all. Install the Companion App and open it once so it registers. Then go to Settings → Developer Tools → Actions, switch to YAML mode, and run this:
Replace notify.mobile_app_your_phone with the action created for your phone. If it does not appear in the list: open the Companion App and confirm it is connected to this server, check notification permission in the phone's OS settings, then restart Home Assistant so the action is registered.
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.
A leak sensor is the best first alert in the house: it is unambiguous, it is rare, and it is expensive to miss. This is what a Critical notification actually looks like.
Needs: a leak sensor and the notify action for your phone.
Replace: the sensor entity and notify.mobile_app_your_phone.
Test it the only way that counts: wet the sensor per its manufacturer's test procedure and confirm the alert lands on your phone. An untested alert is a promise you have not kept.
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 Settings → Developer Tools → Actions → 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.
Settings → Developer Tools → Actions → 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.
A tunnel needs two addresses, and confusing them is the single most common reason this does not work: a public hostname (ha.yourdomain.net) and a private service URL that the cloudflared process can actually reach.
http://localhost:8123 only when cloudflared and Home Assistant share a network context. If cloudflared runs on a different machine, or in an isolated container, localhost means that machine or container, not Home Assistant, and the tunnel will fail with a connection error that tells you nothing. Otherwise use the LAN IP you reserved in Thing 04: http://192.168.1.101:8123.Restart Home Assistant, then test from a phone with Wi-Fi off. If it loads on Wi-Fi but not on cellular, you tested your LAN, not your tunnel.
My own tunnel config has both patterns in it, which is the clearest way to see the rule. Home Assistant runs in Docker with network_mode: host on the same NUC as cloudflared, so its service URL is http://localhost:8123 and that genuinely works. But the services on a different box in the same config point at http://192.168.68.60:2283 and similar. Same tunnel, same file, different addresses, because localhost is only ever true relative to the process saying it.
And I do have use_x_forwarded_for with trusted_proxies set. Not because I planned ahead: because I hit the wall first, got a login page that refused every correct password, and went looking.
The chooser above offers Tailscale, so here is what it actually is. Cloudflare Tunnel publishes Home Assistant to the public internet behind Cloudflare's edge, and anyone with the URL reaches the login page. Tailscale does the opposite: it builds a private network between your own devices. There is no public hostname and nothing to find by scanning. Home Assistant is simply reachable from devices you have enrolled, as if you were at home.
Only you and your household need access, everyone will install a client on their phone, and you would rather nothing be publicly reachable at all. It is the safer default for a system that controls your locks and cameras.
You need a normal public URL: sharing with someone who will not install anything, webhooks from an outside service, or a dashboard on a device you cannot enroll. Pair it with an Access policy so the world cannot reach the login page.
Tailscale can advertise your whole home subnet, so an enrolled phone reaches every device on your LAN, not just Home Assistant. That is genuinely useful and it is a much larger grant of access than "let me check my thermostat." If you only need Home Assistant, do not advertise routes. If you do enable it, understand that you have effectively given that phone a seat on your home network.
Network Security & Zero Trust at Home covers Tailscale subnet routers, ACLs, exit nodes, and how to replace an exposed port with a private path safely.
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. Apps release even more frequently. Not everything should auto-update, but some things absolutely should.
Low-risk Apps (Samba, File Editor, and similar) where a bad update is easy to undo. That is the whole list. Note what is not here: Home Assistant OS and Apps are managed by Supervisor, and Watchtower does not update them (it swaps Docker container images, which is a different thing entirely). HACS integrations sit outside Core's compatibility guarantees, so review them by hand. Keep databases, radio stacks, and tunnels on manual review: those are the ones that take the house down.
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 Apps 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 → Apps → 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. I stopped trying to reconstruct an arbitrary previous state. An input_boolean remembers yes or no. It cannot remember brightness, color temperature, or which four of your six lights were on, so it was never going to solve this. Now I store the durable house mode I actually care about, and when the alert clears I apply a known scene. Less magical, entirely predictable across a restart.
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 made arrival detection noticeably faster in my house, and it keeps working when one source goes quiet. Actual timing depends on the phone OS, tracker update intervals, BLE coverage, and how big your Home zone is, so treat any specific number you read (including mine) with suspicion.
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. Docker: docker logs cloudflared. There is no systemd on HAOS, so the systemctl command will simply not exist there
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
ha core restart --safe-mode. There is no Shift-key trick. Safe mode loads HA with custom integrations, cards, and themes disabled
3If Safe Mode loads: a custom integration is the culprit. Disable HACS integrations one at a time to identify it
4Check home-assistant.log (only exists if you enabled duplicate-file logging; otherwise use ha core logs: 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.
This guide gets the foundation right. The rest of the Bench Notes Home Lab Series goes deeper on the parts that bite people later: the server underneath it, backups that actually restore, and remote access that does not open a hole in your network.
v1.2.0 · Last updated July 2026