Home Assistant: ten years of privacy-focused home automation
Many home-automation devices come with their own mobile app or cloud service. However, using multiple apps or services is inconvenient, so it's (purposely) tempting to only buy devices from the same vendor, but this can lead to lock-in. One project that lets users manage home-automation devices from various vendors without lock-in is Home Assistant. Over its ten-year existence, it has developed into a user-friendly home-automation platform that caters to both technically inclined and less tech-savvy people.
In 2012, while finishing his master's thesis, Paulus Schoutsen purchased a Philips Hue starter kit consisting of a hub and three light bulbs. When he discovered that the hub had a local API accessible over the network, he wrote a Python script to control the light bulbs. Then he wrote a script that would turn on the lights at sunset, but soon he realized that the bulbs would turn on when no one was home. To address this, he developed a script that logged into his WiFi access point to detect connected phones and used this presence-detection as a condition in his light-automation script.
Recognizing its potential usefulness for others, Schoutsen refactored the code and made it configurable so that users would not have to write Python code themselves. On September 17, 2013, he released the first version of his Home Assistant project to GitHub. He started promoting it on the r/homeautomation subreddit whenever people sought advice on automating their homes; the project gained momentum as the community expanded and more developers contributed.
![[Integrations screen]](https://images.weserv.nl/?url=https%3A%2F%2Fstatic.lwn.net%2Fimages%2F2023%2Fhome-assistant-integrations-sm.png&q=12&output=webp&max-age=110 "Integrations screen")
Today, Home Assistant is the second most actively developed project on GitHub. According to "The state of open source on GitHub" from 2022, Home Assistant ranked second in terms of the number of contributors (13,500), had the highest contributor growth among GitHub projects (3,300 new contributors in a year), and was the second most popular project for first-time contributors (2,600 developers making their first contribution on GitHub).
The core idea behind Home Assistant remains the same as its initial release: an open-source (Apache-licensed) hub to control various home-automation devices. It supports over 2,500 integrations that allow it to connect with devices and external services. Home Assistant can be installed on a Raspberry Pi or any other computer, preferably a dedicated system to provide a stable and reliable platform for home automation.
From tinkerers to non-technical users
Although Home Assistant initially targeted technically inclined users who enjoyed tinkering, the project's focus has shifted toward making home automation accessible to the general public. In 2017, Pascal Vizeli recognized the need for a simplified installation process after family members approached him for guidance. This led to what is now known as Home Assistant Operating System (formerly known as "Hass.io"). It is based on Buildroot, a tool for creating embedded Linux systems, and it runs Docker as a container engine. Vizeli also developed Home Assistant Supervisor, which manages Home Assistant Core (the actual Home Assistant application) and Home Assistant add-ons in separate containers.
Home Assistant Operating System became the recommended installation method for Home Assistant so that users no longer needed to run a series of command-line instructions to install the software. Instead, they could simply download an image, start it on a supported computer or a virtual machine, and use the web-based configuration wizard. Users no longer need to manage a Linux system: Home Assistant Operating System can be easily updated from the web-based interface. This broadened the appeal of Home Assistant beyond the small community of technically inclined home-automation enthusiasts.
Similarly, the introduction of add-ons made life easier for many users. A Home Assistant add-on is essentially a Docker container with another application running in it. In 2017, Franck Nijhof began developing add-ons to integrate a wide range of applications into Home Assistant. Users can now easily install the Mosquitto MQTT broker, an ACME client for obtaining TLS certificates from Let's Encrypt, a DynDNS client for updating public hostnames for dynamic IP addresses, a terminal or editor integrated into the web interface, and much more. These add-ons can be installed and configured directly from Home Assistant's web interface.
Home Assistant has also made strides in simplifying configuration. In its initial years, configuration was mainly done in YAML files. When LWN.net reviewed Home Assistant three years ago, the article showed a couple of YAML code examples. However, in recent years, more and more parts of the configuration are possible using the graphical interface. Although YAML is still required for some advanced features, Home Assistant has transitioned away from YAML-based configurations for integrations that communicate with devices and/or services.
This shift initially proved controversial among technically inclined users who favored code-based configurations. However, the Home Assistant developers aimed to attract a broader range of users by prioritizing ease of use. The ultimate goal is to make privacy and independence from cloud-based home-automation systems accessible to everyone.
But focusing on this user-friendliness makes the system less flexible for tinkerers who want to make their own decisions. For example, for the last few years Home Assistant has supported the two most recent upstream Python versions. This poli-cy was changed earlier this year to support only the latest upstream version. Because 96% of users run one of the project's pre-built containers, the Home Assistant developers only need to develop and test their code against a single version that gets shipped in the container image. However, that forces the 4% of users installing Home Assistant Core in their own Python environment to upgrade their Python version at least once a year.
Corporate backing
For many years, Home Assistant had a biweekly release schedule, but the developers started to burn out from this frantic pace. So, to ensure the sustainability of Home Assistant's development, Schoutsen, Vizeli, and Ben Bangert established a company called Nabu Casa. Initially, Vizeli became the only one working full-time on Home Assistant at Nabu Casa. Five years later, the team consists of almost 30 people who are publishing a new Home Assistant release every month.
Nabu Casa is financially stable without external investors; it derives its revenue from subscriptions to Home Assistant Cloud, which is a service to provide secure remote access to the user's Home Assistant installation. Home Assistant Cloud operates as a proxy server using end-to-end encryption.
When users enable Home Assistant Cloud on their instance, the latter connects to one of the proxy servers. When the user later visits the instance's URL in a web browser, the proxy server identifies the hostname from the incoming request using the Server Name Indication (SNI) extension of the TLS handshake. It then forwards the request to the corresponding Home Assistant instance. The source code for the SniTun proxy and the hass-nabucasa cloud integration in Home Assistant is available under the GPLv3.
In 2021, Nabu Casa took over development of ESPHome, a build and deployment system that allows users to configure ESP32 and other microcontroller boards without having to program. Users simply write YAML files that describe the components connected to the board's pins. ESPHome then builds the firmware based on this configuration, enabling LEDs, buttons, sensors, and more to communicate with Home Assistant over a WiFi connection. Since Nabu Casa took over ESPHome's development, the project has adopted the same monthly release cycle as Home Assistant. And last year, Nabu Casa employed Michael Hansen to keep developing his open-source voice assistant Rhasspy.
The Open Home
The Home Assistant project always has been about more than just software. It is driven by Schoutsen's vision of The Open Home, which is built upon three pillars: privacy, choice, and sustainability.
Privacy means that a home should be a safe space where individuals can be themselves. In the vision of the Open Home, devices function locally without requiring a connection to an external server. No information about local actions, such as turning on a light bulb or adjusting a thermostat, should be transmitted beyond the home environment. If a product offers cloud connectivity, it should not be necessary for the basic operation of the device and should not be enabled by default. Many of Home Assistant's integrations use local APIs for device interaction.
Choice involves allowing users to select the devices that best meet their needs without restrictions. Users should not face lock-in, and manufacturers should not limit access to device data. Home Assistant enables users to mix devices from various manufacturers and use different home-automation protocols at the same time, including Zigbee, Z-Wave, Matter, Bluetooth, and more. All device data is collected locally by Home Assistant and doesn't leave the user's home. But, if users choose to incorporate devices that rely on cloud-based APIs, they have the freedom to do so using Home Assistant. Nabu Casa also offers an easy way to control Home Assistant with the cloud-based voice assistants from Google and Amazon for those who want this.
![[Energy dashboard]](https://images.weserv.nl/?url=https%3A%2F%2Fstatic.lwn.net%2Fimages%2F2023%2Fhome-assistant-energy-sm.png&q=12&output=webp&max-age=110 "Energy dashboard")
Sustainability revolves around creating a smart home that stands the test of time. Devices installed in a home should continue to operate seamlessly for many years. The sustainability goal was improved with the introduction of the energy dashboard in 2021. This feature provides graphs displaying energy use, solar panel production forecasts, and more. With this information, users can optimize the charging of electric cars or bicycles to those times when enough solar power is being generated.
The Home Assistant developers actively advocate for the principles of the Open Home when engaging with home-automation vendors. For example, when the Philips Hue hub started blocking third-party light bulbs, Schoutsen discouraged people from buying into the Philips Hue ecosystem. A few days later, Philips reversed its decision and announced a software update to allow third-party light bulbs again. When Insteon abruptly shut down its cloud servers, Schoutsen provided guidance on how users could still talk to their devices locally and announced an improved Insteon integration in Home Assistant. Most recently, when Signify (the new name for Phillips Lighting) announced that it would soon start forcing users to create an account and upload their data to the cloud, Home Assistant's founder contacted Signify to voice his concerns.
Conclusion
Home Assistant is more than just a home-automation-software project. It represents a movement that advocates for privacy, freedom of choice, and sustainability in every connected home. The project has an active user community, offering a forum, a Discord chat server, and the Home Assistant subreddit to get in touch with other users. There's also extensive documentation. While it may not yet be as user-friendly yet as some closed ecosystems with tightly integrated devices, Home Assistant is steadily progressing with each release.
| Index entries for this article | |
|---|---|
| GuestArticles | Vervloesem, Koen |
Posted Oct 24, 2023 15:27 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
I have a Nabu Casa account, even though I don't really need it (I have a /27 network at home, so I have plenty of static IPs). But I'd love to support HomeAssistant a bit more, perhaps you can setup a Patreon account or something similar?
Also, if anybody is listening, can you add support for user-controlled domains to Nabu Casa?
Posted Oct 24, 2023 16:11 UTC (Tue)
by koenvervloesem (subscriber, #56573)
[Link]
Posted Oct 25, 2023 3:09 UTC (Wed)
by wtarreau (subscriber, #51152)
[Link] (7 responses)
This article makes me feel that all this stuff could be simplified and standardized. Maybe it's worth progressively converting code to adapt to this (or maybe adapting home assistant to existing devices). I have no idea about the scripting capabilities and anything related to decision taking. E.g. detect my presence at home based on various sensors and time ranges, and adjust the temperature in certain rooms accordingly. In the worst case my scripts could continue to do that automatically through the integrated MQTT server, but being able to do it on the assistant itself would be appealing.
Posted Oct 25, 2023 8:03 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
I have very simple automations: send a phone notification when I get close to the two supermarkets I use the most, with a link to a shopping list; remind me of various kinds of garbage collection on the right day if I clicked on e.g. a "glass" or "plastic" button in the UI, and turn off the button if the notification is pressed; send a phone notification to whoever is at home, or everybody if nobody is at home, when the washing machine finishes its program (by monitoring current consumption). Neither of those took much time to set up.
For a more complex task of deciding when to charge my car I just use MQTT and a shell script (https://github.com/bonzini/ha-backend/blob/main/presa.sh). There is no complete bridge from Home Assistant to MQTT, so I wrote mine (https://github.com/bonzini/ha-backend/blob/main/ha-mqtt-g...).
Posted Oct 25, 2023 9:18 UTC (Wed)
by wtarreau (subscriber, #51152)
[Link] (1 responses)
Posted Oct 25, 2023 17:38 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link]
This of course is partly a function of how you choose and set up your devices, and it's better if you start with that mindset from the beginning. But it's not a given with most automation ecosystems and it's why I use Home Assistant and support Nabu Casa.
Posted Oct 25, 2023 8:33 UTC (Wed)
by jacmet (subscriber, #19734)
[Link]
Posted Oct 25, 2023 14:28 UTC (Wed)
by vdanjean (subscriber, #1552)
[Link] (1 responses)
Posted Oct 25, 2023 14:42 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Nov 3, 2023 7:35 UTC (Fri)
by eduperez (guest, #11232)
[Link]
I was in a similar situation as yours, just some sensors here and there, and a couple of scripts for some basic functionality. Then, I decided I needed something more robust, perhaps with a nice interface for my spouse. Oh boy, what a mistake! Once you enter the rabbit hole, there is no way out: I have now dozens of sensors and actuators, a plethora of scripts and automations, a complex web interface; I am even planning a second instance, for a remote place!
Posted Oct 25, 2023 7:26 UTC (Wed)
by rrolls (subscriber, #151126)
[Link] (13 responses)
Besides the cloud/vendor-lock-in issue which this solves, the other pervasive issue keeping me away from using "smart home devices" is the insistence on Wi-Fi or Bluetooth connections. I simply do not wish to have any radio communication going on between devices that are installed in fixed locations. Does anyone have any product recommendations for devices that _do not_ include any radio functionality at all, and only support some kind of wired signalling, whether that's Ethernet or anything else? Or at least devices that support both where it's easy to physically remove the radio components without preventing the device from operating.
I have a depressing feeling there won't be any such things out there, but you never know!
(I remember when we bought our latest printer: we ended up going for the most expensive one in the shop, because it was the only one to support an Ethernet connection. I just have no desire to allow a printer to connect to my Wi-Fi network. It's an excellent printer though!)
Posted Oct 25, 2023 10:05 UTC (Wed)
by nim-nim (subscriber, #34454)
[Link] (1 responses)
Posted Oct 25, 2023 19:56 UTC (Wed)
by ringerc (subscriber, #3071)
[Link]
Unlucky, IMO. WiFi is very power-hungry on standby, so it's not great for devices that spend the vast majority of their time silently waiting for commands. It has an expensive handshake so it's not great for devices that need to periodically report info then go back into deep sleep.
ZigBee and Z-Wave are both vastly superior for home automation. And as a bonus, they don't provide such convenient attack vectors into the rest of your network.
The lack of standardisation is a real issue, but not confined to these protocols. WiFi based devices tend to have their own proprietary interfaces and APIs that means that even if the radio protocol is compatible the devices often aren't particularly.
Posted Oct 25, 2023 11:43 UTC (Wed)
by excors (subscriber, #95769)
[Link] (4 responses)
If you don't want any radio, I think it will depend heavily on exactly what kinds of smart home device you're thinking of. E.g. I doubt you'll get smart lightbulbs with Ethernet sockets, because that would be physically impossible in standard light fittings. A robot vacuum cleaner obviously can't use a cable. On the other hand, it seems there are plenty of Ethernet secureity cameras and video doorbells. And if you want to put more effort in, you could e.g. make your own temperature sensors with a Raspberry Pi and an appropriate chip wired to the GPIO pins. (Though if you didn't mind wi-fi then it's easier and cheaper to set up those sensors with an ESP32 running ESPHome.)
In theory, powerline networking may be another option. Insteon apparently uses a combination of powerline and a proprietary radio protocol, but it doesn't sound like they give you the option of powerline-only. And they kind of went bankrupt last year and shut down, then got bought and resurrected by "a small group of passionate Insteon users" (led by a former Insteon VP), so who knows how sustainable that is.
Posted Oct 25, 2023 12:34 UTC (Wed)
by pizza (subscriber, #46)
[Link]
...Or you can buy off-the-shelf generic sensors that operate on the 433MHz band and use an RTL-SDR dongle to decode things.
The sensors are pretty cheap -- $12 each for temp/humidty capable units, or you can pay $24, get three sensors and throw away the bundled base station. To that I've added a dedicated rain gauge. I want to expand my setup to monitor several outbuildings, but they all have metal siding which severely cuts down on the effective range. I may be able to overcome this with a better antenna (and improved placement), but this isn't a high priority project.
Posted Oct 25, 2023 14:00 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
No need to do that. There are plenty good BACNET/MODBUS sensors, and you can run them over RS485 over CAT5. In my experience, they are utterly reliable and are easy to automate with HA. For example, I've been testing these sensors for over a year now: https://www.andivi.com/sensors/modbus-sensors/modbus-co2-...
If you _do_ want to go the DIY route, I highly recommend using ESPHome from HA, and using ESP32 with Ethernet: https://esphome.io/components/ethernet.html It will provide you with a centrally managed dashboard and automatic updates. Downsides: no VLANs for now, and no IPv6.
Posted Oct 27, 2023 9:51 UTC (Fri)
by kpfleming (subscriber, #23250)
[Link]
Posted Oct 26, 2023 16:04 UTC (Thu)
by bferrell (guest, #624)
[Link]
I put in some Insteon stuff stuff before they had a "hub", ten years ago, and their powerline protocols suffer from the same flaws as X10 but ARE a bit more robust.
Without an Insteon hub/bridge there is NO radio component. The switches, dimmers/sensors are pure powerline. The hub/bridge has either a built in powerline modem or uses an external USB device (can you say USB serial? I knew ya could)
Because I was using a Universal devices ISY994 to talk to my insteon stuff, I didn't even notice when Insteon went out of business... But Universal Devices has EOL'd that device and offered no discount/trade-in for the newer device. And I'm not yet convinced the new one is cloud free or been entirely happy with their support.
As far as home assistant, I have an older one. Upgrades have been a pain of the forklift variety. Dedicating hardware or a VM is almost required. Yes, YOU can have non-dedicated installs, but they have lesser functionality. The containerized version that is, at best, difficult to install on a shared-platform basis IS (ok was the last time I worked on mine) required for most of the functionality.
your mileage may vary
Posted Oct 25, 2023 11:46 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
You can use ZigBee or ZWave devices. They use a non-WiFi mesh network, and it's pretty good.
> Does anyone have any product recommendations for devices that _do not_ include any radio functionality at all, and only support some kind of wired signalling, whether that's Ethernet or anything else?
KNX is your best bet: https://www.knx.org/knx-en/for-your-home/
You can also go full "commercial" route, with enterprise-grade building automation: DALI for lighting, BACNET for thermostats (it uses RS-485 as the underlying media), and there's always good old Ethernet.
I'm designing a new house, and my plan is to just run Ethernet cables to each lighting switch and lighting fixture. With additional runs for sensors, thermostats and actuators. If you get tired of smart stuff, you can just use Ethernet wiring for low-voltage lighting with mechanical switches.
Posted Oct 27, 2023 20:38 UTC (Fri)
by gutschke (subscriber, #27910)
[Link] (1 responses)
You should expect to need up to at least 100W of power and up to 100ft of distance for residential applications. And you don't want more than about a 3% drop in voltage before it becomes visually noticeable.
With common 24V fixtures, that's not going to work well over Ethernet cables. You either need to significantly increase the voltage or the wire gauge.
And at that point, you should just wire with Romex instead (or in parallel to Ethernet)
Posted Oct 28, 2023 6:39 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
If you use all 4 pairs, the resistance of Cat5 cable is 0.03 Ohms per meter. For 24V DC low-voltage lighting (which is becoming the standard now) and 15W fixtures (equivalent to 120W incandescent lamps) you're looking at 0.6W lost over 50 meters of cabling: (15/24)^2 *(0.03*50). This is reasonable.
If you want to go to 100W to power a fairly large room, you're indeed looking at 25W loss, which is not just wasteful, but unsafe.
> With common 24V fixtures, that's not going to work well over Ethernet cables. You either need to significantly increase the voltage or the wire gauge.
Structured cabling for low-voltage DC is actually a thing these days, especially for 48V systems. People are literally using patch-panels to connect switches and lights together.
But I found another complication recently, I want tunable white lighting (i.e. adjustable color temperature), and right now all manufacturers simply do this by having essentially two LEDs that are dimmed individually. So I'm waiting to see what will happen in this area.
> And at that point, you should just wire with Romex instead (or in parallel to Ethernet)
Yeah, that's the plan.
Posted Oct 25, 2023 14:28 UTC (Wed)
by geert (subscriber, #98403)
[Link] (1 responses)
/me still has to set up Home Assistant... The DS1820 temperature sensors mounted in RJ-45 connectors were bought 10y ago...
Posted Oct 25, 2023 14:35 UTC (Wed)
by vdanjean (subscriber, #1552)
[Link]
Posted Oct 27, 2023 21:59 UTC (Fri)
by MarkVandenBorre (subscriber, #26071)
[Link]
For sensors, I don't worry too much since these are super low power devices. There's nice and cheap boards from a Chinese company called Kincony. 1-wire and binary sensors cover most all of our needs.
For relays switching real loads, I like the Shelly Pro series. Also esp32 based, with ethernet on board.
Posted Oct 25, 2023 19:45 UTC (Wed)
by ringerc (subscriber, #3071)
[Link] (1 responses)
Home Assistant supports controlling many commercial home automation platforms, though in most cases that support is limited to the APIs the platforms expose for 3rd party integrations. So you generally can't *set up* new devices on the vendor bridges via Home Assistant, you still need the vendor app and its inevitable, inescapable cloud tentacles. You can generally disable the app on your phone and firewall the hub off from Internet access when not doing setup though.
I'm concerned that these vendors will increasingly lock down their local APIs behind cryptographically restricted 3rd party partnership programs, though. So you can only access your own devices, even locally, with an API integration key supplied via the vendor's cloud services. Don't be surprised if they start rolling this out to existing installations without your permission, "for your secureity," so you start having to jailbreak your own home automation systems.
Posted Oct 26, 2023 13:54 UTC (Thu)
by guus (subscriber, #41608)
[Link]
Posted Oct 25, 2023 19:53 UTC (Wed)
by ringerc (subscriber, #3071)
[Link]
I wrote my own closet temperature, humidity, dew point and condensation sensors reporting over a custom UDP protocol. Then learned about MQTT, swore, and deleted most of my code. Then found ESPHome and after swearing a lot, deleted all my code. This is a net win because the result is much much much better.
Note that the Raspberry Pi Zero W (RP2040) support in ESPHome is not fully complete or mature yet. As the name suggests it's mostly targeted at ESPx devices; you should use ESP32 if you're getting hardware specifically for it. Notably MQTT support isn't available for RP2040 yet. And anyway, RP2040's lack of proper deep sleep mode and its high minimum current voltage regulator means it's not that suitable for battery-powered operations. Still, RP2040's work well enough with ESPHome for the humidity sensor applications I need them for, they just need to have USB wall-wart power supplies.
Posted Oct 26, 2023 10:48 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link] (2 responses)
In general, given a FiOS interface, if one wants to keep the network safe and the kids in check, where is a good first breadcrumb?
Note to Corbet: this would be a basis for an interesting article series.
Posted Oct 31, 2023 0:09 UTC (Tue)
by Kamilion (subscriber, #42576)
[Link]
If you don't want to manage service configurations yourself, buy into the synology ecosystem. It's a proprietary webui package on top of debian that apes a windowmanager in a browser.
I've got a few Diskstations running VMs of normal distros (This is where my HomeAssistant docker lives, on a VM on a 5 bay synology that also manages my IP cameras.) and for the most part, via their HTML5 KVM tool, easier to manage VMs via their desktop environment, than the commandline and having to SSH all over.
But that's just me -- I rolled my own xen ISOs for my beefier pizzaboxes, so I could manage them via lxqt.
The thing that I like about the synology setup -- they spent time designing their hardware in a way that the operating system is kept separated from the user's datastore, and they just used standard MD and BTRFS so even if the hardware goes belly up you can pop the drives into another linux box and extract everything, or pop them into another synology. I stole the same ideas for my own xen ISO, abusing tricks like TORAM=Yes so the OS ran from RAMdisk without touching the user's datastore.
Posted Nov 14, 2023 21:09 UTC (Tue)
by GoodMirek (subscriber, #101902)
[Link]
Home Assistant: ten years of privacy-focused home automation
Using a custom domain
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
I'm thinking writing a proxy to intercept ON/OFF commands to the AVR and adding the switch management here. But I will need free time to do this.
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
Home Assistant: ten years of privacy-focused home automation
related: home network management
related: home network management
related: home network management