How I Use Home Assistant in 2025
vpetersson.com
vpetersson.com
For me the flow design feels very natural and is easy to modify and monitor. And it's pluggable with custom nodes so if functionality is missing you can add it in. Like I installed a node that handles OAuth2 so I can have it log into a web service and check a status page.
(this can also be seen on our roadmap update https://www.home-assistant.io/blog/2024/11/15/roadmap-2024h2... )
In the past I've had issues with forgetting to add triggers for states that are used somewhere as a condition or switch. This leads to lost updates and frustation.
React state hooks, which I'm deeply familiar with, will result in a linter warning if any of their dependencies are missing. I'd really like something similar for automations.
The core problem with a smart light is that it very likely has a switch somewhere. If someone turns that switch off, that smart light just lost power and became dumb. Turning it back on now involves a trip to the switch.
A smart switch is smart so long as utility power is running and you never find yourself in a position where the managed device is in an unknown and/or uncontrollable state.
And to parent question: Lifx still has the best color/brightness of any smart bulb and they’re IMO the best. Just make sure your WiFi can handle it.
Home assistant works amazingly well with zigbee devices, and these are plentiful and cheap etc, and don't rely on working wifi/IP infrastructure. When I sell up, my zigbee switches will work just fine as plain-ole light switches even with all my Home Assistant infra ripped out, leaving no issues for next buyer.
You can add zigbee support to pretty much any Home Assistant setup with a 20 buck USB adapter, Home Assistant even make an official one:
https://www.home-assistant.io/connectzbt1/
The also sell Home Assistant servers with zigbee radios built in:
https://www.home-assistant.io/yellow/
The light switches are often cheaper than wifi equivalents too. Wifi bulbs should really only be considered by renters IMO - people who can't easily replace wall switches or similar.
This might not matter if you're pushing everything through a hub like HA, but if you want to connect directly with other devices and remotes then it likely won't work.
Zigbee access to the bulb is great for stuff like changing whitebalance etc though. In my own home I have the bulbs and the switch on ZigBee so I can do this, but power on/off is solely preserve of the automated switch.
* I don't trust any company to use my Wi-Fi and not attempt to access the broader internet. A Zigbee or Z-Wave device isn't going to be able to stealthily update itself in anti-user ways, nor is it going to be hijacked into serving as part of a Bitcoin botnet.
* There are way too many devices, which can cause issues if they're all using Wi-Fi at the same time. Smart homes take a router that would normally be dealing with 2-4 phones and 2-4 laptops and add N bulbs, M switches, P contact sensors, Q motion sensors, and assorted random sensors. Not a chance am I hooking that much up to my Wi-Fi.
Z-Wave LR has worked very well for me—no mesh to worry about, just a controller and devices. The only downside is that it's not as broadly supported as zigbee or Wi-Fi.
My devices can't reach the internet at all, but I have easy access to them the other way.
I agree in principle that this is much nicer in theory. Just like wired is more reliable than wireless. However, retrofitting all that is also much more difficult.
If you own a property but don't live there (eg, you're a landlord), it's essentially never legal. The best answer is to contact the local AHJ.
Now you benefit from both, like being able to make the lights fade off/on.
Also, in case it doesn’t always respond instantly, you should be able to bind the Zigbee devices directly to each other so that it doesn’t need to travel to the Zigbee coordinator (or mesh?) first. Haven’t had the need for this myself though.
Dimmable smart switch plus dimmable standard bulbs accomplish this. No color (though Phillips has a line that tints red when dimmed.)
That seems like the best of all worlds.
Networked smart switch. Switch in absolute authority of light. Switch still able offer advanced light features (e.g. hue set).
https://sonoff.tech/product-review/product-insight/zbmini-ex...
I assume they hack what little power they need from the AC wobble? How do they do that without triggering a current leakage cutout though? Perhaps they “charge” when current flows for the first time?
The way it works is you put a bypass capacitor to neutral in the light fixture, and then it lets the switch be powered - no flicker or low energy requirements needed.
They're not open source so I thought maybe their other stuff isn't either. I didn't even know they made switches in fact.
Several of my friends have the homey, they're very popular here because athom is a Dutch company and they market here a lot. But I prefer the openness of home assistant.
Edit: Aah I see the confusion. The athom that makes the esphome devices is a Chinese copycat company that has nothing to do with the real athom but is trying to get a free ride on their name.
They've just received an injunction banning their sales in the EU and have to take back all their products sold here. https://community.homey.app/t/athom-wins-lawsuit-against-chi...
I had never heard of the Chinese company before.
Putting significant return current through ground means anything in the environment can be part of the path of least resistance. You will see small voltages across your house depending on what loads are on and there will be load-dependent noise conducted and radiated everywhere. This also puts the system one open circuit away from making nearly every conductive part of your house a shock hazard (if the wrong place in the ground network goes open circuit).
What is done in modern times is to have the current return on a neutral wire then monitor the ground wire for current and open the circuit when current is flowing back through ground (a fault).
Returning current through ground is impossible in Europe anyway due to residual current breakers. More than 30mA and the whole system shuts down.
And none of the light switches have ground either by the way.
Try putting a 50 mA fault and see if the GFCI does anything. It won't if you don't have a second line for return current.
This is different from ground. Neutral is the way the return is meant to go. Ground is a safety feature. Connected to the enclosure in some devices.
So sockets here have 3 wires: Live (Brown), Neutral (Blue) and Ground (Green with Yellow stripe). But the switches only have Live and the Switching wire (Black, the wire that goes to the light). The light then receives the switching wire and has Neutral. Because the power is consumed in the light and returns via neutral.
The switch doesn't need the neutral normally because it doesn't use any power. It just switches it on and off on the way to the light. But the wifi switchboxes do need it because they need to remain connected even when the switch is off.
Though I’ll admit, it might be worth the hassle if you have guests often or many people living at your place.
https://www.home-assistant.io/integrations/flux/
This works with almost any smart light you can get connected to HA (most smart lights have white balance adjust), it's brand agnostic etc. I have lights from several different vendors working together this way.
Look at this stuff as "progressive enhancement". Make the simple things work, then build on top of that. Don't replace the simple things with complicated, elaborate things. You don't want to live without lights for a week because a SD card died in a Raspberry Pi somewhere or something.
The overly complicated setup I'm using to run my smart home automation stuff shit the bed and I was too busy with work to really spend the time fixing it so... I just didn't. For six months. The only major complaint I heard was that the outside lighting was no longer turning itself on and off with the sun.
Even in the worst case scenario, all of the lights still have switches that can be turned on and off as long as there's power. It's all zwave, and I've made use of the scenes / direct associations / etc such that most of the stuff people actually care about happens without being mediated by Home Assistant. Or requiring any sort of network. When I move out of this house, I could leave it all behind and it would keep working as-is without my server, access point, active internet connection, or anything else. If there's power, it works.
All my living room lights (three dimmers) are controlled by a single dimmer.
The three way switches in our bedroom are now dimmers. One controls the lights, the other acts as a remote control for it.
The pantry light turns itself off after 20 minutes because people always forget it on.
Both the kitchen light switches turn on and off with the single, easily accessible switch.
The switch for the porch lights also turns the string lights on the gazebo a hundred feet from the house on and off.
My kid's too small to reach the regular switches, so there's a battery-powered remote switch mounted on the wall at her height in her bedroom and the bathroom. Those still work and are still able to dim the lights in her room.
Etc, etc. All without anything but electricity.
I said only _major_ complaint--my kid definitely had some complaints. We have one switch that has a couple of those RGB projector bulbs hooked up to it. When you turn that on, an automation turns off all the rest of the lights and starts playing some dance music. Her party lights still turned on, but it no longer made the music start.
If you want colour control then get smart bulbs to go downstream of your smart switches. Set them to always go to "on" when power's restored, and build that _on top_ with your automation. You'll always have a working light, your automation can always turn them on even when someone's turned the switch off like a normal person would, but when everything else is working you'll _also_ get colour control.
Also, I too wanted to extend to you a really big THANK YOU from a very happy member of the HASS community. I came over from OpenHAB a handful of years ago and I couldn't be happier. Please keep up the good work! Good luck with all the hardware sales and Nabu Casa stuff!
edit: clarified that I used to run OpenHAB
In real terms though, it not that bad. I've got about 25 such devices always online and the traffic really is negligible. Most devices aren't sending anything while nothing is happening except for the periodic heartbeat like once a minute. Its not noticeable, even on my 20MHz wide network.
i'm personally avoiding wifi devices now and holding out for matter/thread variants
I’ve managed to bind them using Matter bindings, so even if HA is offline, the switches can still on/off and dim the bulbs.
No UI supports this yet (though I think HA is working towards it), but the underlying protocol support exists, and products are starting to come to market that take advantage of it.
I think it 2-4 years, it’ll probably be ironed out and working well, but if you really want it, you can have that now with matter/thread.
I think Zigbee devices also have bindings, and those should probably be a lot more mature, but I haven’t played with those yet.
I have 100% Zigbee lights, and each lighting circuit has a Shelly Plus 1 with the relay in "detached" mode (so the shelly will sense the light switch changing from open to closed and send a command to HA to turn on the lights via Zigbee). Most (all?) smart bulbs have a setting for "what do I do when power is restored" and you can set it so that they come on when power is restored.
You can then create a script that uses the MQTT HomeAssistant up/down topic and if HA is down, when the switch changes position operate the relay.
It's not perfect - if you have a powercut during the night all of your lights will come on when power is restored.
Will look into Shelly
Perhaps have a look! Thanks for all your work again, I love HA
I'd love to be able to add a device and describe it (where it is, what it does, etc.) and have HA automatically integrate it with existing automations or fuse it with other sensors. Maybe leveraging LLMs for this.
e.g.:
I buy a new leak sensor and add it to HA. I should just tell HA it's a leak sensor and it's in my laundry room and have it create an automation to send alerts, etc. when there's a leak.
Or I add a temperature sensor in my living room and have it automatically be fused with other sensors to update my living room average temperate.
I find HA joyously easy to use. I have my garage door, lights all around the house, thermostats, hot water recirculation system, doorbell, lutron blinds, and ceiling fans. The automations are easy to make, and have been getting easier over the last few years with HA improvements. (and same as others in this discussion, I use zigbee smart switches. The GE brand ones are great).
Thanks for all your great work!
Now the community should be able to create such things, as our automation engine is very powerful.
I think the challenge in general with room presence detection is that these systems are not very common/reliable yet for us to aim to standardize.
I am wondering if you've ever considered a change to your release rules. Monthly releases are great, but having breaking changes in every release can get to be a bit of a burden. I think it would make end users lives easier if you were able to limit breaking changes to only once (or twice) per year.
I try to read the breaking changes list every time, but sometimes I don't mess with HA for a few months as it's all running smoothly. Then when I do log back in I have a large backlog of breaking changes to review. Usually at this point I just don't upgrade and the problem keeps getting worse. If instead I knew that certain upgrades do no include breaking changes I could more easily keep up to date, and only look more closely at the yearly (or bi-yearly) update that includes the breaking changes.
Some backwards incompatible changes like requiring a new Z-Wave JS version are also able to be managed automatically by Home Assistant. However, because of choice, there are many ways Home Assistant can be installed and we're not always responsible for the installation.
I believe that we can do better in knowing what integrations you use, and mapping that against the integrations that require changes.
Second, I'm curious, how often do you guys have to deal with negative actions taken towards you by those same data harvesting giants? I'd imagine they aren't huge fans of this technology. Any Cease and Desist or other fun examples you guys have had to defend yourselves from?
Where we see the most pushback is from industries adjacent to the smart home, as they don't appreciate the openness. Think garage doors, cars, or cloud data providers for info that can be useful in the home.
When someone complains, like Mazda [1], we pull their integration and communicate their stance to our shared users, and people considering buying into their products. We don't fight for access, as a manufacturer with a cloud service will always be able to find a way. If it is a local device though, our community tends to find a way[2]
[1]: https://arstechnica.com/cars/2023/10/mazdas-dmca-takedown-ki... [2]: https://www.home-assistant.io/blog/2023/11/06/removal-of-myq...
I suppose in some ways, it’s a good thing. It shows me what companies I should support, and which I shouldn’t.
I used to think that way too. Now, I think that all it takes is one bad quarterly report leading to a new CEO, and even the most open of companies can instantly switch to being closed, lock off all their APIs, stop working with open source projects like HA.
I don't know any solution to this, and if I'm honest, being bitten a couple of times has stopped me from experimenting with anything like home automation that requires me to buy physical hardware.
If it requires a cloud to function, you’re at the mercy of a company changing attitudes. If it runs entirely locally, the company can’t get in the way even if they want to.
It’s one of the aspects I really like about matter (or any other device that operates on a purely local protocol). If Inovelli decides to take a turn, it just means I won’t buy any new products from them, but the switches I already put in my wall will continue to function the way they do today.
Even if you don't use Home Assistant, their site is really good for helping with this--every integration lists a "class" like "Local Polling" or "Cloud Push".
Another shortcut is picking up a Zwave/Zigbee dongle (~$30 when I got mine) and buying products that work with that. If the only radio in the device is one that can pair to a local controller, it's a relatively easy way to ensure it's meant to work locally without a cloud integration. (If Kwikset has a bad quarter I'll never know--my door lock only communicates as far as my utility room.)
Besides "the company can't screw me over", if everything is running locally it also immediately limits the privacy and security implications. And ensures your house doesn't break if the internet goes out.
The way the world works, you need to be either a company or a non-profit to be able to partner with the industry. Just being an open source project is not enough.
Since the launch of the foundation, we see a large uptick in companies and universities reaching out to partner with Home Assistant. A lot of manufacturers are very happy to see that an independent platform is being established as alternative to the big tech platforms. Universities want to collaborate on energy and privacy research for the smart home. We've also seen some industry donations (ie DuckDuckGo) to support our work.
- Home Assistant Cloud (paid) - VPN - Port forwarding
Is there any plan to make something like Home Assistant Cloud available for self hosting? Like a simple docker container to put on a VPS?
I don't want to deal with DynDNS to expose my home network but would prefer a Server component on a VPS with a static IP which connects to my home server and allows remote control.
Or is there already a way to do this?
What would be the correct way to DIY it? You would need a VPN to connect you home network to the Proxy and then expose the web interface on the proxy, right?
You set up a reverse proxy (including websocket proxying) for your HA subdomain on your VPS and you're done.
It would be an issue if you’re stuck behind double NAT, but I think tailscale can help with that.
I have to run it on my phone all the time effectively routing all mobile traffic through my home VPN which is not ideal for bandwidth and battery life.
I end having to manually turn it off and on.
Instead I wish home assistant had a way to make mobile notification resources easily accessible without VPN - say behind a short lived access token so that I could quickly view the notification media without having to expose local HA install or having VPN always on
You can use an exit node. In that case it will route all your traffic to your home network.
But tldr is that you don’t need any cloud VM or other service for remote access. Works great.
this is my friciton log. i am left with a $60 brick. hope your folks can use this to improve the experience.
it says right on their sales page it is a "voice assistant" and that it is "built for home assistant". [1]
then you didnt want to buy the HA green that is a home assistant appliance with HAOS already setup for people who don't want to diy it (like you didnt).
next you downloaded a .vdi and didnt research what it is or how to install it.
then you complain about docker images, although it is absolutely possible to run in docker as long as you understand the limitations [2]. did you even read this?
> hmm. new macs dont have apt-get anymore.
they never did. why dont you read whats in all of your screenshots? it says right above "if your OS don't have that, look for alternatives".
> Installing Virtualbox and double clicking the .vdi file i downloaded from earlier gives.... nothing
well, what do you expect? it's a disk image, not a executable. again, the installation instructions for macOS can help you here, you should read it [3]
> anyway, it looks like the default vdi ships with some well known bugs but ALSO its now just straight up missing the \EFI\BOOT\BOOTx64.efi file it expects to load. I found one you can download here and learned that you can import them into the vm via shared folders.
you found a post from 2021, it is not relevant today. then you started replacing files... oh man!
your actual issue is that you didn't configure the vm like the installation guide showed you.
next you got it running in docker. advice to you: don't. you will not be able to use addons and thus no hacs.
> of course it just expects the networking to work when of course it wont fucking work
> i tried ngrok to setup a tunnel but it just resulted in a bunch of bad 400 bad request errors
you must learn how docker networks work to progress here. docker only listen locally by default and you need to instruct it otherwise if that's what you want.
TLDR: you should have just started by reading the installation instructions, it explains to you:
> Home Assistant offers four different installation methods. We recommend using Home Assistant Operating System.
then you should follow the recommendation and be done long ago.
you seem frustrated and not keen on reading or learning.
not sure who you expect to take action based on that rant.
1: https://www.home-assistant.io/voice-pe/
2: https://www.home-assistant.io/installation/#advanced-install...
The so called issues you've encountered appear to be due to insufficient knowledge and experience. It might be a good idea to learn more to better understand what's going on. What you've done is similar to complaining about being last in a swimming competition without learning how to swim properly first and without proper practice for several years.
Every time I visit the big box stores, I see Wi-Fi as the primary means of connecting to the smart home ecosystem. Do you see this trend changing in the future, why from the average consumer prospective? Especially with thread?
I regularly test disconnecting my HA server from the network and make sure nothing home critical stops working.
I do have a few internet integrations (weather, upcoming sports events, etc) and those all stop when I do a “no internet” test, but Home Assistant runs just fine without any network access.
The Internet should only needed to download the image. You could download and flash it manually. The setup shouldn't require the Internet. What needed the Internet?
Yes, there are resources loaded from the Internet. The map tiles are loaded from a third party in the initial setup and every time you view the map. Icons are loaded from https://brands.home-assistant.io/. https://github.com/home-assistant/frontend/issues/18549 is the issue.
This thing isn't as private and as local as it is claimed to be. It's very tied to services provided by Nabu Casa, including the very visible cloud integration of theirs. They've expanded it now to backups.
It's very likely they'll take the infrastructure down if they sell their business or go out of business. Home Assistant OS will be completely useless in such a scenario.
The more likely scenario is that someone installs Home Assistant OS, sets it up with the current version and uses it as it is to avoid breaking changes. Their storage or the entire device breaks down. They'll want to install the same version to restore a backup. They'll learn the hard way that it's not possible to bring up what they had before.
Using the Docker image is the only choice which mitigates this risk.
The Home Assistant core container relies on resources hosted at https://brands.home-assistant.io. Those are cached in the browser for a while. Your mobile phone and web browsers still load the icons. They can do whatever they like with these bits of information. This includes selling allegedly anonymous Home Assistant usage data. The people who host their infrastructure can still do that without their knowledge since they claim it's a CDN.
The use of this CDN means that an existing Home Assistant core based setup can stop displaying some icons if those icons are removed. This can happen if someone decides to use a specific Home Assistant core version.
Home Assistant may be developed with financing from Nabu Casa. Nabu Casa receives money from partners, from people who buy their products and from those who pay for their cloud subscription. They also rely heavily on countless other Python packages developed and maintained by people they don't pay. Other people make significant contributions to Home Assistant and to its web UI.
I'd expect them to run this project as an open source project and handle such situations with a bit more grace, even more so for someone with such a high profile such as frenck.
They'd have the right to get angry if someone distributed a paid product which didn't include FOSS code from third party contributors or FOSS dependencies. This isn't the case. They use a lot of FOSS code from countless people already for the Home Assistant core, for the frontend and for the Home Assistant OS.
All of the time spent dealing with such needless drama could be better spent living one's life and doing something more meaningful for everyone.
> For me, this was not about licensing specifically. However, that point unfortunately is missed and got lost. Which is unfortunate. A lot blew up on the route, which just sucks for both parties.
> In the end, I think the way this project distributes Home Assistant (and its integrations, including Ambee) is not providing the intended working and thus may surprise the end user. In the end, those users are likely to knock on the doors of the Home Assistant project and their integration maintainers, not this project. As a matter of fact, most of my packages in this project are outdated and don't match the distributed version of Home Assistant.
"I release my code under FOSS license, but if anyone distribute it in a way I consider not nice, I will re-license it just to screw them over." [1]
When I was considering using HA and was casually browsing community discussions, there were many posts gave me similar feeling like above case. There were other technical reasons that I decided to not to use HA, but this certainly left a really bad taste in my mouth.
1. https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-86...
[1]: https://github.com/VictoriaMetrics-Community/homeassistant-a... [2]: https://github.com/VictoriaMetrics-Community/homeassistant-a...
They'd be the unquestioned king of the space if us local only people could reliably convert them to ESPhome, and they're the way a lot of brands end up making things "smart".
Home Assistant's dashboards and UI have regressions in every single release. Many such regressions aren't fixed quickly or remain that way permanently. Github issues get closed by the bot. New features ship in every release without fixing these bugs. This gave me the impression that the developers employed by Nabu Casa have very little time to focus on bugs and that there's no pre-release QA. The graphs and their history had plenty of bugs in the 2025.1 release. Are there plans to improve the development process to improve quality?
Home Assistant is described on its home page as "Open source home automation that puts local control and privacy first.". A Home Assistant OS download is useless offline and without the Nabu Casa infrastructure. A download of a Home Assistant OS image obtained today would be completely useless in 5 years for now. These are completely useless if Nabu Casa's infrastructure goes away for any reason. Do you have plans to address this?
Another point related to Home Assistant being local and making privacy a priority, Home Assistant downloads all icons from [1]. The GitHub issue [2] has been open for a while without any involvement from the developers. The Home Assistant container image doesn't include all the assets required for it to provide a Home Assistant deployment in a container. Is this something you plan to address or should it be handled in a fork of Home Assistant meant to be run completely locally?
Home Assistant bundles numerous dependencies [3]. The Home Assistant container bundles and has all of these available. Are there any plans to let users disable all cloud only integrations? What's done to assess the security of these numerous packages? This matters because people allow Home Assistant to access their indoor cameras, door locks and other potentially sensitive devices. Some malicious code run from one compromised dependency's __init__.py could have serious consequences.
Home Assistant is a Python monolith. Adding something as simple as a shell command to my configuration requires a restart of Home Assistant. Are there any plans to split this up or to improve the architecture to not have such issues anymore?
The energy dashboard is extremely limited. Are there plans to make this more flexible?
Why are you forcing people to use encryption since 2025.1? I was including these backups in my encrypted backups anyway.
The voice functionality for Home Assistant and voice PE require a cloud service or a local machine with a GPU for good performance. Are there any plans to address this to provide higher performance local voice control? The old Rhasspy (the version released before Nabu Casa hired its developer) seemed to work a lot better with defined sentences and was faster.
I've seen Home Assistant become faster over the last three years. My YAML had to be updated a few times. New features have been introduced to the dashboards. Old issues and limitations are still there. The dashboards gain new features while the number of bugs and regressions also increases. The custom resources for custom cards don't always load in the mobile app. The UI still loads all the icons from the Nabu Casa icons site [1]. Home Assistant frequently stops updating my location (home vs away) and requires deletion of the device from HA to get it to work again. Entities don't update in the dashboard sometimes.
Home Assistant is described as being an open source project which has been donated or moved to the Open Home Foundation. Why does it still require a CLA to be signed, just like corporate open source projects?
Setting up Home Assistant for someone who's non-technical is a terrible idea. This is an even bigger issue if they want it set up and left alone without updates/maintenance. The mobile app would probably stop working properly with this installation or they'd break it at some point by installing updates.
I'll wait for a bit longer while I prepare to migrate away from Home Assistant and Home Assistant OS. I'm considering a setup which uses Home Assistant core to trigger automations and to display a dashboard. All the automations and device integrations would be done with other tools. This would reduce exposure to Home Assistant's regressions and avoid Home Assistant OS's limitations.
[1] the Nabu Casa run icons site - https://brands.home-assistant.io
[2] https://github.com/home-assistant/frontend/issues/18549
[3] Home Assistant Python requirements https://github.com/home-assistant/core/blob/dev/requirements...
Nada.
Particularly annoying is automated issue closure on GitHub. Imagine spending your free time debugging an issue and describing it meticulously only to see it ignored and closed a few months down the line. I can’t but think about all the burned users who’d inevitably stop reporting anything at all. How does that affect project’s quality?
The automated issue closure and ignored issues are pretty much the last straw for me. I appreciate the work done. I can't help but see that this how things are going to be forever without any significant change. The only option is to migrate away from Home Assistant.
It has access to security cameras and having to trust a ton of code downloaded with Docker is a no go.
It's enough for just a single direct or indirect dependency to be compromised to have a botnet or turn it into something used for surveillance against the users.
Preventing it from exfiltrating data by isolating it from the network with Internet access is the only option if you want to run it. This requires local only devices.
Accessing it through the web UI or through the mobile app will still load icons from https://brands.home-assistant.io. The details are in this ticket https://github.com/home-assistant/frontend/issues/18549
The frontend has its own dependencies.
YAML instead of pure Python is a hell. Trying to push things to be configured via WebUI is a big discomfort because well... Generic users do like clicking around, but generic users will not use HA simply because it's not and will not be possible in future to create a no-code usable IoT. All low-code/no-code stuff COMPLICATE life instead of simplify. External deps like InfluxDB to just prune past data and keep them as I wish it not much nice, having a built-in option to state how to prune and for how long to keep each specific sensor or default policy would be very nice.
Essentially the RANT could be condensed in: please consider designing for people who know how to code, because they will anyway be the most common users. IoT OEMs will only be hostile for most because they still fails to understand how to makes business in an open world, so professional integrator will not much choose HA anyway since it's way too time consuming to really customize and keep it up. A pure code approach with NO energy wasted in config WebUIs/low code/no code on contrary could makes HA an interesting "base for system integrators" in a much broader sense. NanoKVM PCIe, JetKVM show the start of a feature-rich light-out management for anything, they will be the bridge between home IoT and classic homelabs/IT. HA could play a very nice role there, essentially offering a platform to bridge the not-really-IT-ready world of ModBUS and co appliances to the TCP-enabled and digitally controlled stuff. A future where small devices could be fitted in most appliances to "makes them smart" like being in the middle of a washing machine control panel connected to home p.v. system to start programmatically depending on available p.v., a connected oven pre-loaded with food the user start when he/she knows the time he/she will be at home.
This is a potentially nice niche market who could explode in the relatively near future. It's not possible as low code/no code/pre-packaged black box stuff. Being a component anyone could easily plug in a larger system is needed.
YAML might be ok if we limit HA to some smart bulb, just having a Victron battery inverter with some 40+ sensors demanding a significant load of YAML it's nightmarish. In python native it's HYPER quick.
Discovering what has to be selected to use as an action in the automation GUI is another nuisance. The most recent example is with a light I wanted to set to 20% brightness. I had no means to find something with the keyword "brightness" or anything similar. It turned out that this was exposed as turn light on.
Breaking changes are their own source of friction. My only advantage has been that many of my automations are now just GUI automations with some custom YAML where it can't be avoided.
All of these things are far beyond what a non-technical user could be able to do. It can be difficult even for someone who knows how to look things up, read documentation and update everything when breaking changes are made.
Home Assistant isn't the kind of tool one can put in someone else's hands to use it without additional maintenance or supervision. It's also not the tool to use in any commercial setting due to its countless problems.
That's the power of automation, of code, of end-users programming. Harnessing it means reduce all efforts after the first implementation and speed up anything breaking changes as well.
The current setup for automations isn't good for anyone - not for end users, not for developers. I've resorted to using the UI because it seemed to be less likely to break across releases.
Having the light switch on the smartphone does not make it any smarter, just more complex.
The following automations are the most valuable for me:
- automatic blinds. Go down when too much sun hits the facade, go down when dark outside, go up with too much wind. No concern leaving for work, and coming back to an overheated living room (no AC needed). But still automatically collect the direct sun in winter/spring.
- motion sensors, turn on lights when dark and motion in the room, every room
- night mode - low level motion-activated light in all bedrooms, corridor and bathroom. No automatic lights in bedroom, orientation lights on, night light sockets on, blinds down
This brought me to rarely touching a button/switch, twice a day, maybe?
And then there is toys
- blinds can fully close when room is empty, but go to half tilted with presence, angles following the sun, for maximum natural light without direct sun
- TV lowers the blinds behind that would give a reflection
- opening the terrace door opens the blinds and turns off indoor lights, to not attract mosquitos (idk if that even helps)
- shower motion sensor turns ventilation on high
- some sockets go on/off for Christmas lights
- logging of appliances, water, ventilation, heating.
I like that the low level stuff in KNX does not need/have a central hub. But the higher level requires extra smarts. I plan to migrate those to Home Assistant this year.
My sense is that with independent dumb motion sensors you achieve much of a smart house with less cost, wifi dependency.
> That said, using it has put me hard on the side of preferring home devices with open management platforms.
I feel like this is the true purpose of HA and the ecosystem around it. Similar to how matter is forcing IPv6 adoption on micro-controllers, really.
Every holiday season, I go looking for a bunch of cheap stuff on Ali express to tear down. Every year there's new LED light controllers and 2024 was the first year where the manufacturers were almost _bragging_ about how they label the GPIO pins and expose the programming interface so you can throw your own firmware on there if you want. Seriously, never before have I seen these controllers BRAG about how they support WLED natively. The FOSS / DIY / I'm not using _your_ cloud, I have one at home, already movement is ... actually being catered to!? That's _new_.
I have a couple of hundred devices connected to it now, and the _only_ cloud integration I use is Spotify, for obvious reasons; I have been careful when buying smart things that they're completely offline, and anything I buy that _is_ smart but isn't offline-only gets hobbled into a "dumb" appliance; e.g. my new dishwasher has "smart" stuff, if I connect it to Wi-Fi, I found the maintenance menu and disabled the network interface entirely and it's just a regular dishwasher now, which is how I like it.
The solution, as I understand it, is a little device which talks the protocol of the door opener that gives you fully local access the way it should be.
I'll try and dig out the link now in case it's of use to you.
EDIT: Here you go https://www.home-assistant.io/blog/2023/11/06/removal-of-myq... Hopefully that can point you towards a solution for your opener (and the state of affairs).
I imagine if you're driving into the garage from outside you have a physical button in the car with you to open it, and if you don't run home automation, the "automation" part is likely not very useful.
I got one for my decade-old not-smart opener around the time the manufacturer was shutting down API access for their fancy new smart models. Works like a dream. Why would anyone want to spend $$$ buying a fancy new cloud-smart appliance when a simple little chip can make the old one local-smart?
This is carefully planned.
Yes, ideally the local user should just hit the local hub directly, but it’s double the development effort for negligible benefit.
Said vendors and I have a disagreement about what constitutes acceptable failure modes...
Failing that, I'd settle for manufacturers adding an option in their app of wherever suitable, that will let me change the server URL and leave me to it, I'll reverse engineer then protocol, or if they're feeling generous they can open source or provide an API doc.
Unfortunately, my experience reverse engineering lots of devices over the years is that they're often sharing more than they should, and subsidising the devices they sell you with your data.
There is also an overwhelming number of hardware manufacturers who just have piss poor software with atrocious security who should probably be embarrassed to release their code.
We already know what it's like in home WiFi router world.
That way you get all the "this is just integrated with Siri and it's easy for non technical people to control" as well as much more powerful automations.
For example, my home presence detection is actually powered by HomeKit automations which flip binary sensors I've exposed from HA.
In particular:
1) there are light switches that work as expected
2) you can adjust the temp on the TRVs
3) if the HA instance blows up, shit should still work
What this means in practice:
1) I have motion sensors in some rooms that might turn on the main lights or some smaller lamp in a corner if it's past midnight (eg in kitchen), but the light switch will always turn on/off the main lights. If no motion is detected for X minutes all lights turn off.
2) if my mom comes to visit and feels cold in the evening, she can just turn a dial like she did her entire life. No app, no touch buttons on the TRV, no "hey Google... Or was it sori? Siri? Son, help me out!" The smartness lies in having a general schedule, and then again motion detectors that reset the TRVs back to that schedule if they were adjusted manually and no motion was detected for 15 minutes.
3) This means I don't have smart bulbs, but relays in the light switches that do not run in detached mode. For TRVs this obviously works since they have dials.
I might have to add that our house is really old and has shitty insulation, so having a schedule that lowers the temp at night or when at work is also important. Keeping the temp up at acceptable levels 24/7 would be rather expensive. So when you unexpectedly are at home during those down times it's nice to be able to adjust directly at the TRV. I'm still thinking about whether I want to automate this more via motion, but since heating is not instant like turning on or off lights, you don't want to toggle the trv all the time as you enter or leave rooms...
Problem we have at work is people that are cold temporarily adjusting the heating setpoint too high (above the cooling setpoint), now when it goes back to normal operation after the override expires, the temp of the space is above the cooling setpoint, so the cooling turns on. And now people are wondering why it's in cooling in the winter.
But I agree that's not the desired operation.
It's not the end of the world, we generally have them off until we need to turn them on, and then it's not too warm, and after the winter they're off again for 9 months.
In my experience, many good smart bulbs have the option to act like dumb bulbs on regular light switches. Some just return to the state they were last in when power returns, others to a "default boring light". It's one of the things that keeps me buying the more expensive smart bulbs because they are easier to configure between such options (and the third option: stay off when power returns; avoid the "bright flash wakeup" in overnight power outages in bedroom lights, for instance).
You can also emulate that somewhat easily enough in software, even if the bulb doesn't support it right, if your hub notices a light disappeared from the network and then came back, it can default the light to some useful state.
I've got one bulb that occasionally loses connection. Then I have to turn it off on the switch, and the next time I go to turn it on with the automation I've got to turn the switch on again and let it connect first. This is not a seamless system.
My home office for example I set the Aqara switch to uncoupled and toggling it switches on/off the desk lamp, ceiling, bookshelf LEDs, Uplight and wall-strips behind my SKADIS, all of which are smart lights. Since it's _my_ home office, if HA is down and I can't toggle any of them using that switch, I'm probably not worried.
Areas of the house which are used by the rest of the family, have the spring-toggle switches and operate non-smart bulbs so they will function just like a normal switch/light if HA happened to be down and I'm not home to fix it.
It's not always a seamless system, and it varies so much in actual practice on hardware. I definitely understand why so many prefer smart switches over smart bulbs.
I also know that the silly things I want to do with colors across a day/week push me to wanting fun smart bulbs more than smart switches.
The one thing I really want is covers for some of my dumb switches, and I've seen them for cheap on places like Amazon, but haven't actually bought any or installed them, because I'm also in a situation where I don't really need SO/friend/guest buy-in/confusion-saving having people over so rarely in the last few years.
(I had to look that up)
Right now I have expensive (at the time) GU10 LIFX bulbs you can no longer get. They’re not operating on and off at the wall, because my wifi settings changed and I couldn’t be arsed having to reconfigure 14 bulbs by manually resetting them, unscrewing them, and then slowly and painfully register g them on the wifi. I’ve probably created a lot of my own pain here because I could have used a dedicated SSID for that infra that never changes… oh well.
Also, in the time the smart bulbs have become idiot bulbs, I’ve never needed to really dim them, change their colour, or do anything smart.
I sort of feel like the idea is a good one but really it’s overthinking a really simple idea: turning a light on.
I don’t know. Maybe I’m under thinking this? Would love some thoughts.
Too bad so many of these "smart" devices insist you talk with a server in China (or anywhere other than your own LAN!) to turn on the lights.
Monitoring can be really useful and some subtle scheduled controls can be a nice touch, but people go very dumb and very overboard.
I am using HA for something else. I'm building some ESP32 based "smart" thermostats to collect temperature and humidity data as well as exert some control over my minisplits. The only viable interface is IR so that's taking a little work to place a transmitter and receiver appropriately s.t. my wall mounted device meshes well with the existing remote control. The end goal is to integrate with the hydronic backup to create a hybrid heat system.
It's frustrating I have to build all this myself. This shit should all just work that way out of the box, without the "GE Cloud" or whatever. But I'm glad it's made relatively easy by tools like HA and microcontroller dev boards.
The use case I have is to turn off lights when I'm not there. My wife frequently leaves lights on when exiting a room, so it is often useful to turn the lights off remotely. Voice control is nice too, for the situations when my hands are full and I can't hit a switch.
Sibling comments suggest automatically turning on/off lights if someone is expected to arrive or depart, but wouldn't that person just think "weird, they left the lights on"?
i went with precense sensors instead, stuff light up as i move across the house, and will be removing the switches.
It’s literally one extra if clause in the logic
Sure, you can manage an increasingly programmed logic path for every conceivable option, but it's way easier to just hit the light switch.
There’s a point where you're spending a multiple of the cost on equipment and a huge amount of time, to save you a net amount of... zero effort. It becomes a waste.
> to save you a net amount of... zero effort
This is just not true. I have 7 lights in the room I'm in right now, and I want them to all turn on and off together. This was a huge pain before I had smart lights.
A smart home should predict my needs dynamically rather than do stuff based on predefined conditions and is more than just "turn living room red."
Just move the phones and laptops onto a fresh 5ghz ssid
Then the old 2.4ghz becomes the iot one
Their $99 hardware works great. Some devices are chatty but it's two lines in the startup config to filter the bulk of it, with no useful functionality lost.
If the data being generated by your living room is overwhelming SQLite on an eMMC, wow.
Home Assistant is one of the few recent products to delight me during setup. The sheer number of weird things it found on my network was impressive. The number of them that are dropping off as various cloud vendors try to lock things down, even more so. It has definitely motivated my future purchase choices and pushed me to simplify.
Interesting that Google Nest and Tesla are pissing everyone off at the moment. The forum is a leading indicator of brands to avoid.
I've probably spammed this comment an obnoxious number of times already, but I think a lot of the problem is that IIRC HA still writes logs as they happen. Filesystems don't like small frequent writes, it makes write amplification happen.
I handle logging by buffering everything in RAM, and optionally only saving min/max/avg data, on top of only logging points that are specifically configured.
I have a script to set up /var/log as a ramdisk, along with a few other things things I've found can occasionally go wrong and write a bunch of stuff.
But I don't use HA, or have any idea how hard it would be to do this kind of thing in HA.
For this use-case, you can even likely implement own writer queue for every sensor type, and then batch insert them.
Maybe the problem was having the database on a super-slow micro-SD card?
Also, even on the best SD cards, you will eventually break them if you write this much.
I love the possibilities, it's often calming and nice to show off, but like with all things personal infrastructure, I have an increasing nausea and regret, along with the sunken cost fallacy.
I'm HA-curious, but I use HomeKit (with Homebridge) and rarely touch it between device additions/reconfigurations.
So the tapo bulbs are getting replaced with more Ikea bulbs and I won't be buying Tapo again.
Yes, there are exceptions, like non-local-control devices. But fingers crossed, those have not given me much grief yet.
WebAssembly seems like it could be a reasonable possibility for making plugins that don't need constant maintenance.
I've been using HA a little longer than yourself and took the exact same steps a few years ago. It's good to see we ended up at the same "conclusion".
I decided to buy dedicated hardware for HA as opposed to the VM approach as I wanted it to be completely independent from my home servers running non-critical tasks. I bought a Minisforum mini-PC with far-far overkill performance, RAM and storage for HA, but that's just how I roll.
With well over 100 devices, I switched to MariaDB and Influx too, I also solved the heating a couple of years ago, here's a quick summary:
I have a BLE temperature sensor in every room of the house (Switchbot Meter Plus), and I have a Z-Wave TRV on each radiator, I grouped the values into upstairs and downstairs for day/night with some exceptions for home offices, and calculate a sort of "average" temperature.
With some scripts to create a hysteresis, I turn the overall heating on/off when the "average" temperature is below set temperature - 0.2C or above set temperature + 0.3C, each room has an individual set temperature and I turn off the TRV if that room goes above the set temperature and back on if it drops below, again with some light hysteresis.
I then have some automations to switch to day/night/away modes with different set temperatures and rooms on/off depending on the situation.
As for lighting, I use "Circadian Lighting" which _does_ allow light groups, so I just specify the groups in yaml and it takes care of the group as a whole. I think it's probably lacking some functionality of the Adaptive Lighting plugin, but I haven't had to worry about differences in bulb types, I have a mix of Hue (80% of my bulbs) and IKEA (white only and colour).
Until you discover the generic thermostat helper :)
I use the helper to manage the overall heating, by giving it my calculated "average" as the target sensor, and I use the home/away/sleep values.
The complexity in my setup is managing individual rooms which I control independently of the overall heating state; it's a fairly large home for the UK and an old one, some rooms come up to temperature much quicker than others and I want them at different temperatures too, so each room is switched as a separate zone using its TRV and sensor.
Author here. Interesting. I wasn't able to make the groups work either with Flux or with Adaptive Lighting. Not sure why, but I didn't spend too many cycles on it tbh.
Also, good ideas on the heating. Will look at that.
- Wireless plant water sensors
- Blind/curtain management
- Ventilation management based on PM/VOC/CO2
I'm not that into smart locks or doorbell cams... or cameras in general? Feels a little creepy, but I can see the appeal I suppose.
You can announce if someone is wearing glasses or has a handbag.
When I originally bought my home I was thinking of making everything smart, but I realized all of this was enough for me.
That being said - I'm absolutely STOKED that there are smart thermostatic radiator valves.
I will say for OP though - it may be worth having an expert come in and check on your radiators to help balance your system (or you could do this yourself).
Checking to see if radiators have the correct pitch, if you have the right sized radiator for your home, if you have the right pipes insulated, etc.
My impression was that if you get all the balancing right - you won't really need to fiddle with the valves again (unless of course you want to change the temperature in a room versus keeping it consistent).
I've also heard people say that it's generally a good idea to not have an adjustable radiator valve with the radiators by your thermostat - I think because when set wrong your thermostat will trigger and turn off the boiler.
I've been meaning to rebalance my home, with my first goal being to adjust the valves closest to the radiator so that they fill up the slowest.
We're in different countries so obviously you won't be able to use the contractors I used - but mine were wonderful. Their specialty is steam heat - nothing else. To get a new boiler they had me measure all of my radiators and say what type each one was. This helps figure out the correct boiler size, since most houses don't have the correct ones.
The first time I had someone over, I got into bed and hit all-lights-off, only to hear "Hey! I'm in the bathroom and all the lights just went out!"
your thermostat just happens to support that internally. not everyone's thermostats are 'smart' like that.
[0] https://www.ncelectrical.co.uk/product_images/FT24H-HiRes.jp...
I've definitely no "fashionable allergy" to digital forms of automation. I simply don't want the massive complexity that comes with it.
I'm also not advocating against it, I just don't see the point it in.
Your thermostat? Yes, based on the image above. The cooker? I'd say not. The lights? Definite yes.
What I like about my thermostat timer is that it's simple, local, and requires nothing else. No networking, no app, no maintenance over changing the timer for if I'm away, etc.
The behavior is broadly as follows: Consider a thermostat heating schedule that is programmed for 64F overnight, increasing to 70F at 7:00am. A regular thermostat would begin heating at 7am, and take e.g. 40 minutes before reaching 70F. So between 7:00 and 7:40 the temperature is "less than 70F."
With adaptive recovery, the thermostat figures out (or is hand-tuned to know) that it will take 40 minutes to raise eight degrees, so begins the schedule at 6:20 so that it hits 70F right at 7am.
If that's not what you were saying then, uh, ignore me.
Not once I found anything it allow actually useful. Cool? Yeah maybe the first time, bulb that can switch color is cool.
Beside that, utterly and completely useless.
- Lights on when the first person living here arrive after sunset
- Shutdown every lights when the last person living here leave
- Main switch to shut every lights at night
- 30min light sequence from red to white every morning, everywhere, before playing the "birds" playlist on sonos : waking up like this and not having to deal with switches and darkness while my head is up my ass changed my life.
- Ungrouping every sonos devices each night a 5am and setting volume to each so I don't wake up to full volume and I can have birds in the bedroom, music everywhere else. Screw you Sonos for not making it in your app.
- Gently tone down lights when something is played after 8pm on Apple TV
- Gently lights up when something is paused or stopped on Apple TV
- Setting "night mode" on automatically on sound bar every night at 11pm
- Setting it off automatically every morning at 7am
- Using dirt cheap Ikea remotes for eveything connected, without limitation or Ikea Bridge.
Everything is possible thanks to Home Assistant and some efforts. Because manufacturers either don't care, don't want to be compatible with other brands, or want to keep new exciting features for the future.
Motion activated lights switch is also very useful for corridors and definitely not for lazy people as I often read.
For all of that, thank you HA and its beloved and passionate community !
Nothing on there is really crazy or complex. Just things like running the Roomba when I leave, or turning on lights at sunset.
I’ve found it to be very nice because I can automate common things around temperature, motion, waking up/falling asleep, and leaving/coming home. It also all integrates with HomeKit so I can control everything with Siri.
It’s definitely more in the hobby territory than something truly essential, but I would say that it is definitely useful and better than managing a bunch of random apps to automate lights or whatever.
For those who want something similar with way less work I'd use https://www.home-assistant.io/green
On the side of writing YAML, this was actually all generated by the UI and then exported to YAML when I decided I wanted to version control it. It's really nice because Copilot works pretty well for creating/editing automations.
I have over 100 devices connected to Home AssistantEvery time I dip my toes into "smart" devices, the required operational maintenance of fiddling with them to keep them working always pushes me back to the tried and true workflow of just flipping a light switch.
I’ve been upgrading my adaptive lighting over the past few days so this is neat timing. I’m taking quite a different approach though. While I do have a script that can be called to set a light to the “right” value (based on a global ideal brightness and kelvin values calculated elsewhere plus params for multiplier and offset) I call that for each light or group from individual room handler automations.
The reason is that every room is different. Besides the obvious off or presence states, what is the brightness of the room? Are the curtains open? Is the TV playing? Is it late at night? Is the vacuum in this room? Do we have guests? The answers are all unique to the room.
So each room handler can figure those things out and call the light set script with parameters that offset the brightness, and in some cases like an interval, nudge the current brightness towards the ideal without fully overriding what someone might have set manually.
Fun stuff :)
Instead of relying on a brittle naming convention, I can tag devices as 'rgb_led' or 'humidity' and then target all of those. Entities' naming can now be more natural and intuitive.
I've also used HA for quite a few years, and I have several hundreds of devices. I just (this week) decided to move Mosquitto and z2m out of HA to LXC containers in Proxmox (where HA is already running) and it was very easy. Now I don't have to restart the entire world whenever I have to restart HA (usually updates).
Next is to move Node-Red out to its own container. I already do not use HA's automations because they are very poor compared to Node-Red, and I'm starting to change all flows to use MQTT directly instead of passing through HA.
So in the end HA will be relegated to run non-MQTT integrations and dashboarding and not be a single point of failure.
Home Assistant has been rock solid with zero downtime for over a year now, and that last downtime was due to a hardware failure.
1. A normal desktop experience with multi-monitor for work during the day.
2. A remote dev workstation. I use neovim & tmux so can do development completely headless, so I SSH into this rig for doing dev work. It compiles and runs tests blazingly fast and with up to 32 threads so I rarely have to wait for compilations. It's also great to have something that's "always on" so I can SSH in from anywhere and instantly be dropped right into the last state.
3. Running all my self-hosted stuff like HA, Jellyfin, Audiobookshelf, ArchiveBox, and many more. Some run in containers on the host while others run in VMs. Even the heaviest of stuff runs very well and I never have to worry about OOM or max CPU.
4. A VM server that I can use to quickly spin up any sort of VM I want, permanent or transitive. I have a handful of different distros set up in a "freshly installed" VM snapshot and can near instantly clone and have a full install of that distro.
5. A gaming rig for the occasions I want to play a game. It works great physically (i.e. at-the-desk) and also remotely using Steam Link. I can use the Steam Link app on my Chromecast w/ Google TV to remote in and get high-res/high-fps rendering with practically no latency. My biggest complaint with that is the controllers don't often work great with the Chromecast, but I recently bought a USB-to-ethernet converter so I can plug the 8bitDo dongle in near me and have it get reliable long-range all the way back to the desktop. I've been quite happy with it!
I also routinely find other ways to get utility out of this rig. I like to say that the best ideas are ones that seem obvious in hindsight, and that is definitely how I feel about this setup.
The solution I've come up with but haven't yet put into action is to use an ESP device, with some sort of contact switch which sits _in_ the hole where the lock goes and detects whether the lock (bolt?) is physically present.
This solution isn't likely to be pretty, unless it could be shrunk down to fit within the "hole", but I imagine some sort of ribbon coming from the "device" which should ideally look/be sized similar to a door/window sensor, and goes into the opening in the frame; Main concerns for a DIY solution are battery life and longevity of the switch/contact being smashed into by the lock/bolt each time.
EDIT: A sibling comment mentioned reed switches and magnets, which I had considered, but felt would be either too bulky (reed switch plus magnet) or too fragile (do reed switches come in non-glass form?).
Another option is to disassemble a door/window sensor and replace its reed switch with a contact switch, much like you want to do with the ESP.
I'll have to give this a try now you've suggested it, I've got a few spare Zigbee doors sensors, Ring and IKEA so will be interesting to see which is better suited.
Thanks for the suggestion!
Would love to see a blog post about HA and TRVs
Maybe I'm missing the "killer app" so to speak.
- Turn on my electric blanket from my watch 10 minutes before I go to bed
- Make my echo dot announce when one of the following finishes:
- A washing machine load
- A tumble drier load
- A dishwasher load
- A 3D print
- Force charge my home battery during cheap electric periods
- Turn off the heat pump if the grid goes down, so I can decide myself if I want to use my remaining battery power on heating
- Announce if my printer is low on toner via a message to my watch
- Program a more efficient routine for my water heating than the native solution that came with my heat pump allows.
[edit] I just added another automation I've been meaning to: If the time is after 22:00 and I am home, and the outdoor temp is < 6C and I switch the TV from on to off, then turn on the electric blanket and send a notification to my watch to inform me it has been done. Done this because I sometimes forget to do it manually and turning off the TV at that time is a good indicator that I'm heading to bed shortly.
$13.75 - GIRIER Tuya Smart Thermostatic Radiator Valve ZigBee Thermostat Radiator TRV Programmable Temperature Controller Work with Alexa
All my switches are unicellular and ceiling fans and lights are their fan hubs as well. Over a hundred devices and it generally just works.
My most recent HA journey has been replacing all bulbs in my house with smart bulbs so that I can dim them all to 1-5% by default and then use motion to bring up the lights. It feels magical walking into a room and being able to see but a little dim then the lights fading up. I have it set to use a different brightness at night so it's not blinding. The lights all stay on for ~5min then fade back down.
I've had motion lights for a few years but it's rather "harsh" to have the lights snap on from 0->100% and the "click" from my smart switches was a little annoying. This smart switch+bulb setup is the best of both worlds for me. I do not pair my switches with the lights, I never touch the switches in my house, they are there for other people and as a final fallback if HA stops working (all bulbs will go white/100% when turned on).
Home Assistant is really awesome and I encourage more people to try it out but for the love of god, do not use a Raspberry Pi. It can sort of handle small workloads but HA is going to stress it too far and you will have a bad experience.
lol. Story of many (most?) of my projects :)