Building a Smarter Home With Home Assistant Source

May 11, 2026 Markdown source

1---
2title: "Building a Smarter Home With Home Assistant"
3date: "2026-05-11"
4published: true
5tags: ["home-assistant", "homelab", "proxmox", "lxc", "automation", "iot", "solar", "smart-home"]
6author: "Gavin Jackson"
7excerpt: "My early notes from installing Home Assistant in a Proxmox LXC, discovering solar and media devices, adding AirTouch air conditioning, and thinking about where the smart home stack goes next."
8---
9
10# Building a Smarter Home With Home Assistant
11
12![Home Assistant logo](/assets/home-assistant-logo.png)
13
14I have finally started spending some proper hands-on time with [Home Assistant](https://www.home-assistant.io/).
15
16This is one of those projects I have known about for years, mostly from the edges of the homelab and self-hosting world. It has always had that slightly dangerous appeal: install it to solve one small problem, then gradually discover that half the house has turned into an automation surface.
17
18My goal for this first pass was modest. I wanted to get Home Assistant running in my existing Proxmox homelab, see what it could discover on the network, and work out whether it was worth becoming part of my normal home infrastructure.
19
20The short version: yes, it is.
21
22The longer version is that I was surprised by how quickly it went from "new service in the lab" to "this is now aware of my solar, TVs, air conditioning zones, and phone." That is a pretty compelling first hour.
23
24## Installing Home Assistant on Proxmox
25
26My homelab already runs on [Proxmox VE](https://www.proxmox.com/en/proxmox-virtual-environment), so I installed Home Assistant as an LXC container using my PVE Scripts Local setup, based on the [Proxmox VE Helper-Scripts community project](https://github.com/community-scripts/ProxmoxVE).
27
28I have written previously about why I like these scripts in a homelab context. They take common self-hosted applications and turn the initial deployment into something repeatable: create the container, install the application, set sensible defaults, and let me get on with evaluating the actual service.
29
30For a first Home Assistant deployment, an LXC container is a nice fit. It is lightweight, quick to provision, easy to snapshot, and it lives beside the other services I already run in Proxmox.
31
32The official Home Assistant story often leans toward Home Assistant OS, especially if you want the most appliance-like experience with add-ons managed from the UI. That may still be where I end up if Home Assistant becomes critical infrastructure in the house. For now, the LXC approach suits my current goal: learn it, test it, and keep it easy to rebuild.
33
34After the container came up, I opened the web UI, created an account, and stepped through onboarding. Nothing dramatic. No database to stand up, no giant configuration file to write before the first screen appeared, no weird ceremony. It felt refreshingly practical.
35
36## The first pleasant surprise: auto-discovery
37
38Once Home Assistant was running, it immediately started finding things.
39
40The most interesting discovery was my Enphase solar setup. Home Assistant has an [Enphase Envoy integration](https://www.home-assistant.io/integrations/enphase_envoy/) that can talk to the Envoy gateway and expose data from the system, including the microinverters behind the panels. That matters because solar monitoring is one of the most obvious places where local visibility is useful.
41
42Vendor apps are fine for checking status, but they are not the same thing as owning the data flow inside your own home automation system. If Home Assistant can see production data, then later it can become part of broader energy decisions: when to run appliances, when to prefer battery, when to charge something, or when to simply make the data visible on a dashboard I control.
43
44It also found my Sony TVs. Home Assistant's [Sony Bravia TV integration](https://www.home-assistant.io/integrations/braviatv/) supports auto-discovery for compatible models, and that is exactly the kind of integration that makes the platform feel useful quickly. Media devices are not the highest-stakes part of the house, but they are a good test of whether Home Assistant can become a single control plane rather than another isolated dashboard.
45
46At this point I had not done much configuration. I had a new container, a new account, and Home Assistant had already started building a picture of the network.
47
48That is a strong first impression.
49
50## Adding the air conditioner
51
52The next step was the one I actually cared about day to day: air conditioning.
53
54My ducted air conditioning setup uses AirTouch with a Panasonic unit behind it. Home Assistant supports AirTouch through integrations such as [AirTouch 4](https://www.home-assistant.io/integrations/airtouch4/) and [AirTouch 5](https://www.home-assistant.io/integrations/airtouch5/), depending on the controller generation. Once added, the useful part is that Home Assistant can represent the AC and its zones as climate entities.
55
56This is where Home Assistant started to feel less like "device monitoring" and more like home control.
57
58The AirTouch app already works, but bringing the AC into Home Assistant changes the shape of what is possible. Instead of the air conditioner being trapped inside its vendor app, it can participate in the same interface and future automations as everything else.
59
60That unlocks a few practical ideas:
61
62- Turn the AC off automatically when no one is home.
63- Pre-cool or pre-heat the house based on presence, weather, or time of day.
64- Avoid running climate control hard when solar production is low or battery reserve is important.
65- Create room or zone-based controls that match how we actually use the house.
66- Use voice control later without exposing every vendor account separately.
67
68I am not automating all of that yet. This first round was simply about getting the AC visible and controllable. But the important architectural step is done: the air conditioner is now part of the Home Assistant model of the house.
69
70## Areas make the model click
71
72One thing I liked more than expected was assigning devices to areas.
73
74It sounds like a small UI housekeeping task, but it matters. A smart home should not primarily feel like a list of vendors and device names. It should feel like a model of the house.
75
76So instead of thinking in terms of "Sony Bravia TV" or "AirTouch climate entity," I can start thinking in terms of:
77
78- living room
79- bedrooms
80- office
81- kitchen
82- outdoor areas
83- solar and energy
84
85That becomes more important as the system grows. One or two devices can live in a flat list. Twenty devices cannot. Once lights, sensors, switches, media players, climate zones, batteries, and automations are involved, the house model needs structure.
86
87Areas give Home Assistant a useful map. They also make dashboards, permissions, voice control, and automations easier to reason about later.
88
89## The phone app made it real
90
91The next step was installing the Home Assistant app on my phone.
92
93Home Assistant has an official [Mobile App integration](https://www.home-assistant.io/integrations/mobile_app/) for iOS and Android. Once connected, the phone becomes more than just a remote control. It can receive notifications, expose sensors, and eventually provide presence information for automations.
94
95For now, my immediate use is simple: I can control the air conditioner from Home Assistant on my phone.
96
97That sounds basic, but it is a useful threshold. A homelab service is only valuable in the house if it survives contact with normal life. If controlling the AC requires VPNs, bookmarks, awkward dashboards, or explaining which app to use, it will not stick. If it is just an app on the phone with the devices grouped by area, it has a chance.
98
99The Home Assistant app also hints at where this can go next. Presence detection, actionable notifications, mobile widgets, and location-aware automations all become possible once the phone is part of the system. I will be careful with that, because location data deserves a higher privacy bar than a light switch, but the capability is there.
100
101## Who is behind Home Assistant?
102
103Part of what makes Home Assistant interesting is that it is not just another smart home product from a large platform vendor.
104
105Home Assistant was started by [Paulus Schoutsen](https://www.nabucasa.com/about/) in 2013. Nabu Casa describes the origin nicely: it grew from a script that turned on lights at sunset into one of the major open source home automation frameworks. The project is written in Python, has a very large contributor community, and has become one of the most significant open source projects in the smart home space.
106
107Today, Home Assistant is a project of the [Open Home Foundation](https://www.openhomefoundation.org/), which focuses on privacy, choice, and sustainability for smart homes. That framing is important. The smart home industry has a bad habit of turning basic household functions into cloud dependencies, subscription opportunities, and abandoned-device problems.
108
109Home Assistant's bias is different: local control first, cloud when needed, and user ownership of the data. The official Home Assistant site puts that local model front and centre: Home Assistant communicates with devices locally where possible and falls back to cloud only when there is no other option.
110
111That is exactly the posture I want in a home lab and, frankly, in a home.
112
113There is also a commercial company involved: [Nabu Casa](https://www.nabucasa.com/about/), founded in 2018 by the founders of Home Assistant and Home Assistant OS. Nabu Casa funds development and offers Home Assistant Cloud, which provides conveniences such as remote access and easier voice assistant integration while still extending a local Home Assistant instance rather than replacing it.
114
115That balance is healthy: open source core, foundation governance, commercial support where it makes sense, and a product direction that does not require turning the whole home into someone else's cloud tenant.
116
117## What people use Home Assistant for
118
119The obvious use case is smart lights, but Home Assistant is much broader than that.
120
121The public [Home Assistant integrations catalog](https://www.home-assistant.io/integrations/) is enormous. It covers lighting, climate, media players, solar inverters, batteries, EV chargers, weather, presence detection, network devices, security systems, voice assistants, and a long tail of very specific hardware.
122
123The public [Home Assistant Analytics](https://analytics.home-assistant.io/) dashboard also gives a useful sense of scale. At the time of writing, the opted-in analytics dataset showed roughly 624,000 active installations, with averages around 13 automations, 28 integrations, and 357 states per installation. Those numbers are a good reminder that many Home Assistant users are not just turning on a bulb from a phone. They are building an operating layer for the house.
124
125The most common practical uses seem to cluster around a few themes.
126
127### Lighting and switches
128
129This is the classic smart home entry point. Smart bulbs, smart switches, dimmers, scenes, motion sensors, and schedules are all natural Home Assistant territory.
130
131The value is not just "turn light on from phone." The value is combining context:
132
133- turn lights on when motion is detected
134- dim lights in the evening
135- turn everything off when the house is empty
136- use physical buttons without being locked to one vendor
137- keep local control even if an internet service is down
138
139This is probably where I will expand next after the energy pieces.
140
141### Energy monitoring
142
143Energy is one of the more interesting uses because it connects directly to cost, resilience, and sustainability.
144
145Home Assistant has first-class [home energy management](https://www.home-assistant.io/) features, and my Enphase discovery is a good start. Adding the Tesla Powerwall would make this much more useful. Once solar, battery, grid import/export, and household load are visible in one place, dashboards become genuinely valuable.
146
147The longer-term opportunity is automation: shifting loads, avoiding unnecessary grid draw, and making smarter decisions about climate control.
148
149### Climate control
150
151This is now my first real use case.
152
153Air conditioning is expensive, comfort-sensitive, and easy to forget. It is also a perfect example of why a smart home should understand more than one device at a time. The AC should eventually be able to respond to presence, room usage, time of day, weather, solar production, and battery reserve.
154
155That does not mean building a fragile maze of automations. It means starting with a few simple, reliable rules and expanding only when they prove useful.
156
157### Media and notifications
158
159TVs, speakers, casting devices, and voice assistants are common Home Assistant integrations. Media control is convenient, but notifications might be more useful long term.
160
161I can imagine alerts such as:
162
163- solar production has dropped unexpectedly
164- Powerwall reserve is below a threshold
165- AC has been left running in an unused zone
166- a homelab service is down
167- a door, sensor, or device has changed state unexpectedly
168
169This is where Home Assistant can become a bridge between the house and the homelab.
170
171### Presence and routines
172
173Presence detection is where smart homes either become useful or creepy.
174
175Used carefully, presence can make automations feel natural: turn things off when everyone leaves, adjust climate before people arrive, send reminders only when someone is home, or avoid noisy notifications at night.
176
177Used carelessly, it becomes surveillance in your own house. My bias is to keep presence automations simple, visible, and easy to disable.
178
179## Next steps
180
181My first Home Assistant setup is now useful, but it is still early. The next phase is where it becomes interesting.
182
183### Integrate Alexa
184
185Alexa integration is high on the list because voice control is still one of the most natural interfaces for shared spaces.
186
187Home Assistant supports the [Amazon Alexa Smart Home Skill](https://www.home-assistant.io/integrations/alexa.smart_home/), but the manual path requires internet-accessible HTTPS, an Amazon Developer account, and an AWS Lambda function. The simpler route is Home Assistant Cloud through Nabu Casa, which avoids opening ports and handles the Alexa connection more cleanly.
188
189I need to decide which path fits my risk tolerance. For a family-facing control plane, Home Assistant Cloud may be worth it simply because it reduces the amount of custom internet-facing glue I have to own.
190
191### Add the Tesla Powerwall
192
193The [Tesla Powerwall integration](https://www.home-assistant.io/integrations/powerwall/) is probably the most important next energy step.
194
195Right now, Enphase gives me solar visibility. Powerwall would add battery state, grid status, load, reserve, and energy flow (fortunately I'm using Powerwall 2, which is supported). Once that data is in Home Assistant, I can build a much more complete picture of the house as an energy system rather than a collection of unrelated devices.
196
197That is the part I am most excited about. Solar data by itself is interesting. Solar plus battery plus load plus climate control is actionable.
198
199### Start adding smart lights
200
201Lighting is the obvious expansion path, but I want to be deliberate.
202
203The smart home graveyard is full of cheap devices that depend on fragile cloud services. I would prefer devices that work locally, support open standards, or at least have a strong Home Assistant integration. Matter, Zigbee, Z-Wave, Shelly, ESPHome, Hue, and local MQTT-based devices are all worth looking at.
204
205> **Smart lights without replacing the switches**
206>
207> One option I am particularly interested in is adding [Shelly](https://www.shelly.com) modules behind some of the existing light switches. A few work colleagues put me on to these, and I can see why they are popular with Home Assistant users.
208>
209> The appeal is that I may not need to replace every visible wall switch or commit to smart bulbs everywhere. A Shelly module can sit behind an existing switch or in the lighting circuit, making the circuit visible to Home Assistant while preserving the normal physical switch experience. That matters in a shared house. If the smart home layer is unavailable, visitors and family should still be able to use a light switch like a light switch.
210>
211> Home Assistant has an official [Shelly integration](https://www.home-assistant.io/integrations/shelly/), and the fit looks good for the kind of setup I want. Shelly devices can be auto-discovered, Home Assistant communicates directly with the device, and the cloud connection is not required. Depending on the device generation and configuration, relay devices can also be represented as light entities rather than generic switches.
212>
213> For me, Shelly modules look like a good middle ground:
214>
215> - keep existing wall switches and faceplates
216> - add Home Assistant control without making the house feel unfamiliar
217> - avoid relying on a cloud service for day-to-day switching
218> - gain energy monitoring on selected circuits if I choose the right modules
219> - build lighting automations gradually instead of replacing everything at once
220>
221> The caution is electrical work. Anything behind a wall switch is mains wiring, so this is not a "just tinker with it on the weekend" job. I will need to check the wiring, neutral availability, box depth, load type, dimming requirements, and local electrical rules, then use a licensed electrician where required.
222
223My likely pattern will be:
224
225- start with a small number of high-value rooms
226- prefer switches where possible so normal wall controls still work
227- trial Shelly modules on a couple of simple lighting circuits before standardising
228- avoid making lights unusable when Home Assistant is down
229- document what I install and why
230- keep automations boring until the basics are reliable
231
232Smart lighting should make the house easier to live in, not turn every room into a troubleshooting exercise.
233
234### Build dashboards that match the house
235
236The default Home Assistant UI is useful, but I will want dashboards that match how we actually think.
237
238I can see a few useful views:
239
240- a climate view for AC zones
241- an energy view for solar, battery, grid, and load
242- a living areas view for lights and media
243- a homelab view for infrastructure status
244- a mobile-friendly quick control view
245
246The trick will be restraint. Dashboards can easily become a cockpit. The best version should answer the obvious household questions quickly: is the AC on, what is using power, are the important things healthy, and what needs attention?
247
248### Add a few automations, slowly
249
250I do not want to start by automating everything.
251
252The first automations should be boring and reversible:
253
254- notify if the AC is left on too long
255- turn off selected devices when nobody is home
256- alert on unusual solar or battery behaviour
257- set climate defaults at predictable times
258- run simple evening or bedtime lighting scenes once smart lights exist
259
260The rule for home automation should be the same as production infrastructure: if nobody understands why it happened, it is too clever.
261
262## Early verdict
263
264Home Assistant has made a good first impression.
265
266The installation was quick, the auto-discovery was better than expected, the AirTouch integration gave me an immediate practical win, and the mobile app makes it feel like something the house can actually use.
267
268The bigger story is not that I can control an air conditioner from another app. The bigger story is that Home Assistant can become the local integration layer for the house: solar, battery, climate, lights, media, phones, notifications, and eventually voice control.
269
270That is why the project is interesting. It is not just a dashboard. It is a way to make the home understandable and programmable without handing the whole thing to a cloud platform.
271
272For a homelab person, that is a very appealing idea.
273

---
title: "Building a Smarter Home With Home Assistant"
date: "2026-05-11"
published: true
tags: ["home-assistant", "homelab", "proxmox", "lxc", "automation", "iot", "solar", "smart-home"]
author: "Gavin Jackson"
excerpt: "My early notes from installing Home Assistant in a Proxmox LXC, discovering solar and media devices, adding AirTouch air conditioning, and thinking about where the smart home stack goes next."
---

# Building a Smarter Home With Home Assistant

![Home Assistant logo](/assets/home-assistant-logo.png)

I have finally started spending some proper hands-on time with [Home Assistant](https://www.home-assistant.io/).

This is one of those projects I have known about for years, mostly from the edges of the homelab and self-hosting world. It has always had that slightly dangerous appeal: install it to solve one small problem, then gradually discover that half the house has turned into an automation surface.

My goal for this first pass was modest. I wanted to get Home Assistant running in my existing Proxmox homelab, see what it could discover on the network, and work out whether it was worth becoming part of my normal home infrastructure.

The short version: yes, it is.

The longer version is that I was surprised by how quickly it went from "new service in the lab" to "this is now aware of my solar, TVs, air conditioning zones, and phone." That is a pretty compelling first hour.

## Installing Home Assistant on Proxmox

My homelab already runs on [Proxmox VE](https://www.proxmox.com/en/proxmox-virtual-environment), so I installed Home Assistant as an LXC container using my PVE Scripts Local setup, based on the [Proxmox VE Helper-Scripts community project](https://github.com/community-scripts/ProxmoxVE).

I have written previously about why I like these scripts in a homelab context. They take common self-hosted applications and turn the initial deployment into something repeatable: create the container, install the application, set sensible defaults, and let me get on with evaluating the actual service.

For a first Home Assistant deployment, an LXC container is a nice fit. It is lightweight, quick to provision, easy to snapshot, and it lives beside the other services I already run in Proxmox.

The official Home Assistant story often leans toward Home Assistant OS, especially if you want the most appliance-like experience with add-ons managed from the UI. That may still be where I end up if Home Assistant becomes critical infrastructure in the house. For now, the LXC approach suits my current goal: learn it, test it, and keep it easy to rebuild.

After the container came up, I opened the web UI, created an account, and stepped through onboarding. Nothing dramatic. No database to stand up, no giant configuration file to write before the first screen appeared, no weird ceremony. It felt refreshingly practical.

## The first pleasant surprise: auto-discovery

Once Home Assistant was running, it immediately started finding things.

The most interesting discovery was my Enphase solar setup. Home Assistant has an [Enphase Envoy integration](https://www.home-assistant.io/integrations/enphase_envoy/) that can talk to the Envoy gateway and expose data from the system, including the microinverters behind the panels. That matters because solar monitoring is one of the most obvious places where local visibility is useful.

Vendor apps are fine for checking status, but they are not the same thing as owning the data flow inside your own home automation system. If Home Assistant can see production data, then later it can become part of broader energy decisions: when to run appliances, when to prefer battery, when to charge something, or when to simply make the data visible on a dashboard I control.

It also found my Sony TVs. Home Assistant's [Sony Bravia TV integration](https://www.home-assistant.io/integrations/braviatv/) supports auto-discovery for compatible models, and that is exactly the kind of integration that makes the platform feel useful quickly. Media devices are not the highest-stakes part of the house, but they are a good test of whether Home Assistant can become a single control plane rather than another isolated dashboard.

At this point I had not done much configuration. I had a new container, a new account, and Home Assistant had already started building a picture of the network.

That is a strong first impression.

## Adding the air conditioner

The next step was the one I actually cared about day to day: air conditioning.

My ducted air conditioning setup uses AirTouch with a Panasonic unit behind it. Home Assistant supports AirTouch through integrations such as [AirTouch 4](https://www.home-assistant.io/integrations/airtouch4/) and [AirTouch 5](https://www.home-assistant.io/integrations/airtouch5/), depending on the controller generation. Once added, the useful part is that Home Assistant can represent the AC and its zones as climate entities.

This is where Home Assistant started to feel less like "device monitoring" and more like home control.

The AirTouch app already works, but bringing the AC into Home Assistant changes the shape of what is possible. Instead of the air conditioner being trapped inside its vendor app, it can participate in the same interface and future automations as everything else.

That unlocks a few practical ideas:

- Turn the AC off automatically when no one is home.
- Pre-cool or pre-heat the house based on presence, weather, or time of day.
- Avoid running climate control hard when solar production is low or battery reserve is important.
- Create room or zone-based controls that match how we actually use the house.
- Use voice control later without exposing every vendor account separately.

I am not automating all of that yet. This first round was simply about getting the AC visible and controllable. But the important architectural step is done: the air conditioner is now part of the Home Assistant model of the house.

## Areas make the model click

One thing I liked more than expected was assigning devices to areas.

It sounds like a small UI housekeeping task, but it matters. A smart home should not primarily feel like a list of vendors and device names. It should feel like a model of the house.

So instead of thinking in terms of "Sony Bravia TV" or "AirTouch climate entity," I can start thinking in terms of:

- living room
- bedrooms
- office
- kitchen
- outdoor areas
- solar and energy

That becomes more important as the system grows. One or two devices can live in a flat list. Twenty devices cannot. Once lights, sensors, switches, media players, climate zones, batteries, and automations are involved, the house model needs structure.

Areas give Home Assistant a useful map. They also make dashboards, permissions, voice control, and automations easier to reason about later.

## The phone app made it real

The next step was installing the Home Assistant app on my phone.

Home Assistant has an official [Mobile App integration](https://www.home-assistant.io/integrations/mobile_app/) for iOS and Android. Once connected, the phone becomes more than just a remote control. It can receive notifications, expose sensors, and eventually provide presence information for automations.

For now, my immediate use is simple: I can control the air conditioner from Home Assistant on my phone.

That sounds basic, but it is a useful threshold. A homelab service is only valuable in the house if it survives contact with normal life. If controlling the AC requires VPNs, bookmarks, awkward dashboards, or explaining which app to use, it will not stick. If it is just an app on the phone with the devices grouped by area, it has a chance.

The Home Assistant app also hints at where this can go next. Presence detection, actionable notifications, mobile widgets, and location-aware automations all become possible once the phone is part of the system. I will be careful with that, because location data deserves a higher privacy bar than a light switch, but the capability is there.

## Who is behind Home Assistant?

Part of what makes Home Assistant interesting is that it is not just another smart home product from a large platform vendor.

Home Assistant was started by [Paulus Schoutsen](https://www.nabucasa.com/about/) in 2013. Nabu Casa describes the origin nicely: it grew from a script that turned on lights at sunset into one of the major open source home automation frameworks. The project is written in Python, has a very large contributor community, and has become one of the most significant open source projects in the smart home space.

Today, Home Assistant is a project of the [Open Home Foundation](https://www.openhomefoundation.org/), which focuses on privacy, choice, and sustainability for smart homes. That framing is important. The smart home industry has a bad habit of turning basic household functions into cloud dependencies, subscription opportunities, and abandoned-device problems.

Home Assistant's bias is different: local control first, cloud when needed, and user ownership of the data. The official Home Assistant site puts that local model front and centre: Home Assistant communicates with devices locally where possible and falls back to cloud only when there is no other option.

That is exactly the posture I want in a home lab and, frankly, in a home.

There is also a commercial company involved: [Nabu Casa](https://www.nabucasa.com/about/), founded in 2018 by the founders of Home Assistant and Home Assistant OS. Nabu Casa funds development and offers Home Assistant Cloud, which provides conveniences such as remote access and easier voice assistant integration while still extending a local Home Assistant instance rather than replacing it.

That balance is healthy: open source core, foundation governance, commercial support where it makes sense, and a product direction that does not require turning the whole home into someone else's cloud tenant.

## What people use Home Assistant for

The obvious use case is smart lights, but Home Assistant is much broader than that.

The public [Home Assistant integrations catalog](https://www.home-assistant.io/integrations/) is enormous. It covers lighting, climate, media players, solar inverters, batteries, EV chargers, weather, presence detection, network devices, security systems, voice assistants, and a long tail of very specific hardware.

The public [Home Assistant Analytics](https://analytics.home-assistant.io/) dashboard also gives a useful sense of scale. At the time of writing, the opted-in analytics dataset showed roughly 624,000 active installations, with averages around 13 automations, 28 integrations, and 357 states per installation. Those numbers are a good reminder that many Home Assistant users are not just turning on a bulb from a phone. They are building an operating layer for the house.

The most common practical uses seem to cluster around a few themes.

### Lighting and switches

This is the classic smart home entry point. Smart bulbs, smart switches, dimmers, scenes, motion sensors, and schedules are all natural Home Assistant territory.

The value is not just "turn light on from phone." The value is combining context:

- turn lights on when motion is detected
- dim lights in the evening
- turn everything off when the house is empty
- use physical buttons without being locked to one vendor
- keep local control even if an internet service is down

This is probably where I will expand next after the energy pieces.

### Energy monitoring

Energy is one of the more interesting uses because it connects directly to cost, resilience, and sustainability.

Home Assistant has first-class [home energy management](https://www.home-assistant.io/) features, and my Enphase discovery is a good start. Adding the Tesla Powerwall would make this much more useful. Once solar, battery, grid import/export, and household load are visible in one place, dashboards become genuinely valuable.

The longer-term opportunity is automation: shifting loads, avoiding unnecessary grid draw, and making smarter decisions about climate control.

### Climate control

This is now my first real use case.

Air conditioning is expensive, comfort-sensitive, and easy to forget. It is also a perfect example of why a smart home should understand more than one device at a time. The AC should eventually be able to respond to presence, room usage, time of day, weather, solar production, and battery reserve.

That does not mean building a fragile maze of automations. It means starting with a few simple, reliable rules and expanding only when they prove useful.

### Media and notifications

TVs, speakers, casting devices, and voice assistants are common Home Assistant integrations. Media control is convenient, but notifications might be more useful long term.

I can imagine alerts such as:

- solar production has dropped unexpectedly
- Powerwall reserve is below a threshold
- AC has been left running in an unused zone
- a homelab service is down
- a door, sensor, or device has changed state unexpectedly

This is where Home Assistant can become a bridge between the house and the homelab.

### Presence and routines

Presence detection is where smart homes either become useful or creepy.

Used carefully, presence can make automations feel natural: turn things off when everyone leaves, adjust climate before people arrive, send reminders only when someone is home, or avoid noisy notifications at night.

Used carelessly, it becomes surveillance in your own house. My bias is to keep presence automations simple, visible, and easy to disable.

## Next steps

My first Home Assistant setup is now useful, but it is still early. The next phase is where it becomes interesting.

### Integrate Alexa

Alexa integration is high on the list because voice control is still one of the most natural interfaces for shared spaces.

Home Assistant supports the [Amazon Alexa Smart Home Skill](https://www.home-assistant.io/integrations/alexa.smart_home/), but the manual path requires internet-accessible HTTPS, an Amazon Developer account, and an AWS Lambda function. The simpler route is Home Assistant Cloud through Nabu Casa, which avoids opening ports and handles the Alexa connection more cleanly.

I need to decide which path fits my risk tolerance. For a family-facing control plane, Home Assistant Cloud may be worth it simply because it reduces the amount of custom internet-facing glue I have to own.

### Add the Tesla Powerwall

The [Tesla Powerwall integration](https://www.home-assistant.io/integrations/powerwall/) is probably the most important next energy step.

Right now, Enphase gives me solar visibility. Powerwall would add battery state, grid status, load, reserve, and energy flow (fortunately I'm using Powerwall 2, which is supported). Once that data is in Home Assistant, I can build a much more complete picture of the house as an energy system rather than a collection of unrelated devices.

That is the part I am most excited about. Solar data by itself is interesting. Solar plus battery plus load plus climate control is actionable.

### Start adding smart lights

Lighting is the obvious expansion path, but I want to be deliberate.

The smart home graveyard is full of cheap devices that depend on fragile cloud services. I would prefer devices that work locally, support open standards, or at least have a strong Home Assistant integration. Matter, Zigbee, Z-Wave, Shelly, ESPHome, Hue, and local MQTT-based devices are all worth looking at.

> **Smart lights without replacing the switches**
>
> One option I am particularly interested in is adding [Shelly](https://www.shelly.com) modules behind some of the existing light switches. A few work colleagues put me on to these, and I can see why they are popular with Home Assistant users.
>
> The appeal is that I may not need to replace every visible wall switch or commit to smart bulbs everywhere. A Shelly module can sit behind an existing switch or in the lighting circuit, making the circuit visible to Home Assistant while preserving the normal physical switch experience. That matters in a shared house. If the smart home layer is unavailable, visitors and family should still be able to use a light switch like a light switch.
>
> Home Assistant has an official [Shelly integration](https://www.home-assistant.io/integrations/shelly/), and the fit looks good for the kind of setup I want. Shelly devices can be auto-discovered, Home Assistant communicates directly with the device, and the cloud connection is not required. Depending on the device generation and configuration, relay devices can also be represented as light entities rather than generic switches.
>
> For me, Shelly modules look like a good middle ground:
>
> - keep existing wall switches and faceplates
> - add Home Assistant control without making the house feel unfamiliar
> - avoid relying on a cloud service for day-to-day switching
> - gain energy monitoring on selected circuits if I choose the right modules
> - build lighting automations gradually instead of replacing everything at once
>
> The caution is electrical work. Anything behind a wall switch is mains wiring, so this is not a "just tinker with it on the weekend" job. I will need to check the wiring, neutral availability, box depth, load type, dimming requirements, and local electrical rules, then use a licensed electrician where required.

My likely pattern will be:

- start with a small number of high-value rooms
- prefer switches where possible so normal wall controls still work
- trial Shelly modules on a couple of simple lighting circuits before standardising
- avoid making lights unusable when Home Assistant is down
- document what I install and why
- keep automations boring until the basics are reliable

Smart lighting should make the house easier to live in, not turn every room into a troubleshooting exercise.

### Build dashboards that match the house

The default Home Assistant UI is useful, but I will want dashboards that match how we actually think.

I can see a few useful views:

- a climate view for AC zones
- an energy view for solar, battery, grid, and load
- a living areas view for lights and media
- a homelab view for infrastructure status
- a mobile-friendly quick control view

The trick will be restraint. Dashboards can easily become a cockpit. The best version should answer the obvious household questions quickly: is the AC on, what is using power, are the important things healthy, and what needs attention?

### Add a few automations, slowly

I do not want to start by automating everything.

The first automations should be boring and reversible:

- notify if the AC is left on too long
- turn off selected devices when nobody is home
- alert on unusual solar or battery behaviour
- set climate defaults at predictable times
- run simple evening or bedtime lighting scenes once smart lights exist

The rule for home automation should be the same as production infrastructure: if nobody understands why it happened, it is too clever.

## Early verdict

Home Assistant has made a good first impression.

The installation was quick, the auto-discovery was better than expected, the AirTouch integration gave me an immediate practical win, and the mobile app makes it feel like something the house can actually use.

The bigger story is not that I can control an air conditioner from another app. The bigger story is that Home Assistant can become the local integration layer for the house: solar, battery, climate, lights, media, phones, notifications, and eventually voice control.

That is why the project is interesting. It is not just a dashboard. It is a way to make the home understandable and programmable without handing the whole thing to a cloud platform.

For a homelab person, that is a very appealing idea.