I haven’t used home assistant much in earnest, but I have some gripes after dabbling:
- to get the most out of it, it wants to be installed as an “OS” on a dedicated device (like a raspberry pi). Without doing this, you can’t install add ons from the store. I’m guessing this might be because the add-ons themselves are packaged with docker?
- I went ahead and did what they wanted, and dedicated an entire raspberry pi to home assistant. But from there, it seemed extremely GUI oriented… I had to install an add on just to see my config files! I know plenty of people have had success keeping their configs in version control, but that seems to be fighting the current.
So as a particularly advanced user, I don’t think Home Assistant is for me. Which is perfectly fine!
Does anyone have any recommendations on home automation software for people who write code for a living? The main thing I’m after is a decent library of supported devices that I don’t have to reverse engineer and write SDKs for myself. I’d also like to dump any/all sensor readings and switch states into Prometheus and view data with grafana.
I run HA in docker. Configs are in a volume mount and get backed up with the other zfs datasets (I'm sure you could put them in git too..). Extensions work fine but sometimes you do need to run another docker container, eg zwavejs2mqtt. All that stuff lives in docker compose files in git.
They have moved to be UI based, which does seem to work much better for most users given how complex automations can get.
I agree. First I was pretty heavily against moving a lot of the configuration into UI. But I've embraced it since then. It makes it less "pure", sure, but it's so much quicker now to get things done in my experience.
It works without host access. It's just that to auto-detect devices on the subnet requires low level access across several protocols. Perhaps this could be done without host access but it seems to be a difficult problem.
No, it doesn't work without. Auto-detection is one thing, even that can be NAT'ed, definitely not difficult - bridging broadcasts between subnets is an OLD thing. But I digress, I'm actually speaking of all the integrations that foolishly assume the bind IP and the advertised IP are the same. So it's either an invalid bind address or an inaccessible internal one.
Mine is running with normal isolated networking. Z-wave and zigbee are both working fine. No integrations that don't. I think I originally had to assign the hue bridge to have a static ip though..
Neither Z-wave or ZigBee are the type of thing that would have to be directly visible on your local network to work properly. Try Homekit or something that has actually uses IP networking.
> Without doing this, you can’t install add ons from the store.
Usually you can do it yourself, because yes they are just docker containers. I don't use them myself as I don't find much use for most of them. The more important addon tool is HACS and that works in the stand alone docker container.
> But from there, it seemed extremely GUI oriented… I had to install an add on just to see my config files
Yes it's very GUI focused now, you can usually get to the basic yaml config in any screen though if you click through to manually configue that component. This was generally done because the yaml config method was a pain even for the tech literate... because yaml.
They will never offer as much integration as HA so I tend to find using HA as a dashboard/device integrator and then Node-red/AppDaemon for the actual automations to be more optimal.
> "Does anyone have any recommendations on home automation software for people who write code for a living?"
I develop my own home automation components and use MQTT to interface with HA using its MQTT integration. This gives me the freedom to have fun developing sensors, presence detection, garage door openers, etc, all still with zero reliance on "cloud". And I still benefit from a single UX and integration point on HA, which to me is the biggest value.
I run HA on Docker and it's locked down as much as practical. For example, I use nginx reverse proxy and limit HA itself to 127.0.0.1:8123 -- I don't need/want anything automatically discovered on my network.
I also have no need for addons. That just seems like more headaches when upgrading HA.
I had the same concerns as you. Here is what I did:
- setup HASSOS as a VM in my proxmox (and passing the usb zigbee stick through)
- install HACS for extra addons
- install the VSCode addon (meh, I’d prefer vim)
- install zigbee2mqtt
- write all my automations with appdaemon
That last point lets me write everything as python code instead of point and click (nodered) or some weird and limited (to me) yaml. With appdaemon, anything python can do is possible and you get an api to HA for the automation part.
VSCode also gives you a terminal so you can use git etc.
If you prefer there is also the option of using ssh to edit your files directly, you can break out of the default HA shell over ssh with “exit”.
HA didn’t make much sense for me until I heard of appdaemon. Now it’s amazing for me.
I personally use NixOS for everything, so I totally get the want for versioned config as an advanced user. But I did the opposite and put HA on a raspberry pi. If I die or am incapacitated I want my wife and kids to still be able to manage the lights and other automations. I'd also probably just leave the pi with the house if I sold it, since it is an integral piece needed to fully utilize a lot of installed hardware in the house. I mean I wouldn't take out the sprinkler computer either.
Yes, forcing the OS on people is a bit much. Rpis are not super reliable due to sdcard wear, so i personally prefer to run it on a X86 home server, so the os is not an option then as I use it for other thigs. Currently I'm using a VM to run the os on that server, which seems excessive, comsumes 20gb as a vdi image. I believe a supervised docker install is an option now, but it's officially classed as unspoppported. Shame it's so convoluted to get running.
20gb is excessive? I run it in Proxmox myself, and give it 100gb. Not because it needs it, but because it _deserves_ it. Of all the silly things I host in my house, it's the most deserving of resources.
I'm not worried about the storage, but (almost) forced to run an OS is a bit much. I just want to run it on the same machine as other services and the VM is to me a clunky way to do that. Still overall like HA though.
Personally I wrote my own home automation software. At the time, Home Assistant wasn't compatible with my hardware, now I just prefer rolling my own solution anyways. I do not recommend my software to others. (It's written in Visual Basic and has a ton of personal conveniences basically hardcoded, though I try to maintain the general assumption in design someone else may use it someday.)
Depending how sophisticated your needs are, if you write code, consider writing your own. With libraries handling most of your hardware integration, writing a home automation system is often primarily writing the glue between. (I didn't do this. I made mine much harder for myself, I speak directly to serial ports with hardware codes, it's also much buggier than other solutions.)
It’s understandable why they do this. Given the complexity of a home automation set up with countless error modes across devices, sensors and connectivity alone, reducing any potential problems on the software side at least is logical.
I have used HA on and off for years and have the same issues with it. I want to easily understand the config files it is running with, and be able to configure anything by editing these files, and I don't want it writing to the config (this is one of my biggest gripes — no decent separation of config and state). I want to tie it to other systems myself rather than have it try to automatically discover things. I still didn't find a suitable alternative.
Yeah, if you want to have it 'just work', a dedicated Pi seems fine, though I'm considering moving it onto my NAS if I get a usb Zigbee stick (I have one sitting on the pi's gpio pins).
I know I ran the motioneye service on the nas (docker container) as the Pi was struggling a bit, and to have more room to write the files. If you are already familiar with docker, you can totally run the add ons yourself.
And if you wanted, I think you can configure appdaemon to run without Home Assistant if you have something else running the MQTT service, so you could add the Zigbee2 add on (just a docker image https://www.zigbee2mqtt.io/) and interact with it directly.
Zigbee2Mqtt does a great job supporting lots of devices (IKEA stuff for example), so I think you might just want to get a zigbee stick and go nuts on the MQTT instance yourself. Shouldn't be too hard to log the MQTT events into your custom dashboards.
You might not even want AppDaemon if you want to just code up an event loop yourself...?
But I'm pretty happy with the gui/yaml home assistant experience, as I mostly want fairly simple and predictable automations, and the dashboard is good for the whole family to use as well.
I have Home Assistant OS running in a VM on an HP EliteDesk 600 G3 Mini running Proxmox. I don't really use this for automations directly, although I do have some alerts. Primarily I use this as a dashboard and as a common API for everything in the house (zwave, zigbee, hue, Lutron, Shelly, etc).
I honestly don't do a ton of automations. The one really important one controls a hot water recirculating pump with a Shelly One set up as a temperature sensor. This is a small ruby program that uses MQTT to set the state of the zwave switch controlling the pump switch and directly talks to the Shelly for temperature readings. It talks to the HA API for settings but has reasonable fallbacks if things fall over.
You can always SSH in and edit the config that way (that used to be the only way to do most configuration). If you want your automations to be in a proper programming language instead of rules defined in YAML, check out AppDaemon.
HASS makes it to the top of HN about once a month for good reason!
Probably one of the most well developed open source projects I've seen, both from core contributors finding a way to get paid for what they do every day with nabu casa as well as a large and thriving community.
Over the past two years there's been a ton of work put into making things more plug and play and GUI for folks, but all the technical wiring under the boards is still there for doing just about anything you want.
I have basically everything off the cloud, except for a few things I want on there. If you want everything off the cloud you'd be wise to do a bit of research and get a zigbee and or zwave stick.
Don't blame HASS for IoT providers that are routinely pushing up firmware that breaks anything that interfaces with their products without going through their cloud, but for most things there are things out there that work great without it.
My experience over the past six months of using Home Assistant is mixed.
With every monthly update, something breaks, stuff gets deprecated, then removed. I report those issues, but they get quickly closed without being resolved.
I just don't update home assistant monthly. Maybe once or twice a year? Tbh that seems to work super well. Never have to think about it and it just works.
My solution is similar - I read the release notes every month or so, and upgrade only if I am interested in some of the new features.
I am willing to fix stuff if it breaks, and I have a backup config I can downgrade back if needed.
I take a similar approach to firmware upgrades for my IoT devices - I run them on a couple of separate vlans, so I feel okay only updating them every few months when I see the need (mostly custom builds of tasmota/esphome/etc.)
HA is not ready for grandma, but most technically inclined folks should be able to get a ton out of it after you get past the initial learning curve.
I recommend using the add-on "Check Home Assistant configuration" before every upgrade. I only upgrade when I get the confirmation from this add-on that nothing will break.
The add-on actually download the new version and checks my config file against it. When something breaks, you get the error message so you can fix what's not working (happens once or twice a year for me, usually a config change), and relaunch the add-on to test again.
I have been using home assistance for a few years now, having migrated from the SmartThings eco system.
Over all I am happy with it, but it is increasingly harder to find devices that are not cloud encumbered, even some things that have integrations with HA are basically HA interacting with the OEM cloud API, which not local control.
I prefer zigbee, but I fear the migration from Zigbee to "Matter" is going in the wrong direction, as Amazon and Google are really pushing cloud based control over Local Control...
I use Shelly relays installed behind all my switches to automate every single light in the house: https://shelly.cloud. As a perk you retain the functionality of the existing light switch.
They are reasonably priced, are built with local control as the primary feature and there's not even a hint of Silicon Valley/VC/"growth & engagement" smell.
> I use Shelly relays installed behind all my switches [...]
> As a perk you retain the functionality of the existing light switch
This sounds super interesting, so both the control from shelly/HA and the physical light switch can be used?
Do you have any pictures/blog/something about how to set that up? I briefly looked into this in the past, but it seemed impossible with the existing wiring (only the live wire is behind the physical switch, no neutral).
Basically the switch becomes a simple boolean input to the Shelly - the actual module is always powered. This allows you to turn it on via the network and turn off at the switch if you wanted to, or completely detach the switch from the actual light and only use it as an input to your home automation controller (maybe you want to use it to toggle a different light than the one it's connected to?).
For no-neutral operation they sell bypass resistors that you can put in parallel with your light to pass through enough current to keep the Shelly powered on.
But my understanding is that Matter is conceptually just porting Zigbee to run on IPv6, and no longer being tied to the special Zigbee variation of IEEE 802.15.4.
Matter re-uses the Zigbee Cluster library for actual device control. It can operate over any layer 1 and 2 solutions that support ipv6, but the blessed implementations seem to be Ethernet, Wifi, Thread, and Bluetooth.
It will remain local control, on Apple's insistence. Apple is pretty stubborn, in that the only cloud server allowed to be involved in its home automation systems is iCloud, which is basically only used to let Siri on your phone control your home when away from home.
But that is the thing. The special 802.15.4 is what made zigbee attractive to people like me. How have their own custom zigbee hub and uses a variety of devices from several manufacturers that have all of them report to the zigbee hub that I control
Moving it to just standard wifi, Ethernet, etc will allow device manufacturers to lock out people like me
Others in the community seem excited for it however anytime you have Amazon, Google, and Apple all working together I can never see how that results in good things for users as each are open hostile to user control in various ways.
I've been bitten by HA twice now. One time the Pi it was on simply slowed to a crawl all of a sudden; killing HA fixed that issue, including for large-ish writes to the SD, but that's hardly an option. Second time it broke on me it simply started throwing tons of errors after an upgrade. Both incidents at a time when I had other things to do than spend hours fixing the light switches. Also that terrible YAML DSL was a huge pain since I need this sort of thing infrequently enough to never remember how it works. I definitely can see the appeal but I don't want things like light switches to depend on something that flaky.
Currently running an instance of deconz for all the zigbee essentials which is a lot less powerful but has been rock solid. I have a bunch of Go apps running on the living room Kubernetes, one that streams all events from Deconz and a few other sources to Kafka running on a Raspberry Pi and a few more that add automations that deconz can't do. I'd expected this to be flaky as hell, so the apps running there aren't critical, but it's been rock solid for over a year even though Kafka isn't even supposed to run on ARM.
These issues are why I suggested to a co-worker to run it on a low spec intel nuc and not a Pi. They are cheap second hand and far more reliable than a Pi so are great for a HA server.
He's had great success with the built in backup to google drive solution. He fragged the whole setup once without bothering to do any trouble shooting he just reinstalled the OS and applied the backup and was up and running in no time.
I wanted to jump in and praise this project. After INSTEON suddenly shut down last month, I was able to set up Home Assistant and restore control to the perfectly functional network of devices orphaned by their makers.
Always seamed to me overengineered. Maybe is because I'm skeptical about automations, and I like physical buttons, one button that does something, and automations made in solid and reliable ways (such as mechanical relays for example). But if I need something "smart", and I have a couple of devices in my house, with a couple of automations (basically for laziness, not something I couldn't have done by pulling some extra wires and with mechanical timers and relays), I do them in the most simple and clean solution.
Now all the automations rely on a local MQTT server where my devices connects to an a ~300 lines python program, that communicates with the MQTT server and applies all the automations, and also exposes a simple REST API to do things with a simple `curl` if I need so. Everything (MQTT server and python script) runs on my home router that has OpenWRT on it. I find it simpler to express automations with code than with complex web interfaces or yaml configuration files that are as complex as a program.
So you have your solution ... for you: cool. The rest of us need some assistance for something that is not our expertise. We need the bollards that are put down the sides of the 10 pin lanes to hit a strike.
Not sure why you are complaining about needing a Mossie - I assume that refers to Zwave2MQTT. Zwave actually works these days in HA, thanks to a lot of work in a very short period of time. At work I have 40 odd windows with Zwave detectors and it used to be a bit hit and miss. At home I have been doing very long term trials of Zwave underfloor heating controllers. I have 10 zones of electric underfloor heating and two of them are running Heltuns (v1) at the moment - three years so far. One of them has run away madly twice ie run at high current and hot but not since a firmware update. Strangely enough one of the old controllers ran hot too after a power outage, recently (investigation ongoing).
You describe handwritten Python programs whilst complaining about YAML configs elsewhere. How do you generalise your stuff?
For instance business people are drawn to products aimed at solving the "integration" problem between different enterprise products like a moth to a flame.
What's ironic is that the "integration problem" is much less of a problem than developing user interfaces or database application. From the viewpoint of a coder an "integration problem" is often ten lines of Python which can be completed in less time than it takes to wait for a salesperson to pick up the phone or that you could spend waiting for the documentation of an integration framework to load in your web browser. You generally avoid the devilish data modeling problems that turn up in applications work.
My biggest issue with HomeAssistant at the moment is the refusal of the Devs to support Single sign on methods. Several have been submitted via pull requests and almost gone through and then dropped based on very poor reasoning in my opinion. There is an auth header addon in HACS but without official support the android app is a buggy mess to get working.
HA is the only service I am running now that isn't hooked into my SSO and it's a niggling frustration to say the least.
When it comes to internal services that don't implement auth or have inadequate auth support, there are several projects out there that act as a reverse proxy and handle auth, only passing requests through once authentication is complete.
You can use this with Home Assistant's local IP auth (that just bypasses auth and assigns everything to a single HA user) so you don't have redundant auth mechanisms.
Yeah that's basically what the Auth header add-on is used for. It's just a pain for the Android app. I got it working briefly but hit a snag where my yubikey I use for passwordless login couldn't be used as it's using a webview container and you can't easily just use a yubikey in that scenario. If SSO was supported mainline support for that could be added.
What I have been meaning to do is have my Auth provider fall back to basic password or something else for HomeAssistant logins, just need to figure out HOW to do that.
I'd love it to have some kind of LDAP or other directory service thing. I've got a few other things I run for myself and some friends or family members that already can work with that (notably NextCloud) that would be really cool to connect up with HA too.
Currently I use Authenik on my LAN and VPN, but I used to use Keycloak when it was publicly exposed. I had issues configuring several of the components to work together and decided to use something that "kinda" works out of the box. The app dashboard is also very nice and has the "partner tick of approval" that is so important for hosting your own services.
It's a niggling issue for me, not a show stopper. I did consider it, very briefly, but it's not enough of an issue for me to spend the time and effort maintaining such a fork. Especially with an active project as HomeAssistant keeping a fork working with all the upstream modifications would be difficult.
I’ve been using a Pi 4 with Home Assistant for the last 2 years, but I’ve accumulated so many devices in its dashboard that just turning a light off felt too cumbersome.
Sure, I’ve automated everything I could, but humans are not predictable so I often need to adjust brightness or volume of some device.
I had some keyboard shortcuts in BetterTouchTool using the HA REST API but it felt too fragile. In the end I created my own app to make this easier, called Volum (https://lowtechguys.com/volum)
It gives you macOS keyboard shortcuts and a really simple UI on iOS and iPadOS to control your HA devices and it’s completely free if you want to try it.
Home Assistant really is about home "automation", not home "buttons now on your phone". I have dozens of automations in my Home Assistant install and I only interact with Home Assistant when I'm updating it or screwing with the automations themselves.
In the morning, depending on the weather, both of my floors set to heat, cool or heat/cool. The lights adjust to a cool temperature, fully on. Maybe the lawn gets watered, if it hasn't rained in a while and won't soon (I live in the PNW, so that one doesn't trigger often, haha). At sunset the lights adjust again, and finally most of them turn off at 9pm and the hvac system again adjusts, depending on the weather. The lights and shades in the media room adjust when the TV turns on. And a million other things that I won't bother to type out. But the point is, it all Just Happens, and I go to great lengths to keep it that way. If manual control is needed, just flip the switch or turn the thermostat.
I don't how this is true when lovelace is so well developed and you an have simple dashboards for anything you want to control. My partner hates home automation stuff and even she loves having a button that can pull up everything in the bedroom from the lights to the music to the humidifier as well as having easy switches for "going to bed" or "left the house forgot to lock things up and turn them off" etc
Yes, I can go on about my automations in the same way, it does feel like a magical home sometimes :)
But when I have guests and we need more light for a board game, or when the automation didn’t work as expected and lights are still off at sunset or the blinds got stuck at midpoint, or the heat is still too high and I’m already in bed etc. there’s a real need for fast and effortless manual control.
I’m now investing in Zigbee switches and knobs to have more physical means for controlling the home, but in my engineer mind, an app made more sense at the time.
I spend most of my time on my keyboard laptop anyway, why not use it for dimming the lights, or adjusting the speaker volume.
> there’s a real need for fast and effortless manual control.
On iOS i just pull down the control centre from the clock and it shows my most 6 most used home assistant things (a few lights, temp and door lock). HomeKit Bridge, I think is the integration that provides that.
It provides essentially the same UI as your app, without any app needed, and allows for "hey siri, turn on the hallway light" too.
I use Home Assistant purely as an automation server and as a gateway between different (incompatible) ecosystems. Entities that need manual control are exported over HomeKit and controlled using any Apple device. I use HomeControl for easy access to all devices in the macOS menu bar: https://apps.apple.com/gb/app/homecontrol-menu-for-homekit/i....
I do agree it needs better default widgets. Like when turning a brightness dial it's easy to accidentally scroll the page.
It's also insanely cumbersome to use things like circadian lighting at the moment, which I use extensively since my apartment doesn't that much sunlight. It requires editing a YAML file, which requires installing some editor plugin, which requires supervisor mode, which required a full reinstall as a VM because I'm an idiot and installed the docker version of HA at first. And then figuring out how the hell to get a VM to start at startup in headless mode. And then fumbling for hours with how to install HACS and other things.
IMO if you're using the dashboard to adjust something you haven't really automated anything, you just moved the physical buttons to a dashboard.
The dashboard should be for setting larger scenes.
Example: If you want to watch a movie, you should either be able to say something to your digital assistant of choice or press a single physical/digital button. That automatically sets the lights correctly, closes any blinds and turns on all AV equipment needed.
Don’t you ever need to step out of the automation predefined values sometimes?
I do have most of my house automated, but my pain point is in those rare moments when I need to do something that doesn’t fit anymore in my predicted automation.
I said it in a previous comment as well, but I’ll give some more personal examples here:
1. We have friends coming and we need more light for a board game
2. My wife wants to sew some new clothing creation and needs bright white lights for short periods of time
3. Sun is still very bright at sunset but HA already turned on the lights (I kinda like the sunset natural light, and want to enjoy it without artificial lighting. I have a light sensor for this situation but it’s hard to get it right)
4. I want to change volume of a speaker but I’m not using the device playing the music
5. I want to get the blinds higher/lower without getting out of bed
I’m not saying everyone needs my app, of course. I made it for myself, and just decided to share it with the world, in case there are other people sharing my pain points.
I still don't see why you're not exposing these devices to Homekit in Home Assistant so that they show up natively on your Apple devices in the control centre? Having my smart speaker volume control next to my iPhone's volume control just makes sense for that? Same for quick access to lights? Just pull down from the clock and tap to turn on/off specific lights, or have sliders next to the iPhone brightness slider for lights with brightness granularity. I don't see what an app adds to that?
#3 is boggling for me as I live in Finland. "Sunset" isn't really a thing here.
Automating anything based on "Sunset" or "Sunrise" is 100% useless as the time for both changes multiple minutes per day. Currently the sun will set at 22:28 and will rise again at 04:07. I don't want to control anything based on either =)
1 & 2 sound like something you should have a scene for. For #1: "Alexa, board game mode" and boom you've got enough light. And for #2 just slap on a cheap zigbee switch from Ikea next to the sowing table.
Yeah it’s odd how many of the home automation stuff are thought and created for the temperate zones of the globe.
Well it’s hard to give enough context but none of those would work for me. We sometimes take our board games in the living room, other times on the balcony, sometimes even in the bedroom if the guests have a little child and they need to keep an eye on it. I would have to create a scene for all those things and end up with the same problem: too many button to choose from, doing what I want takes too much effort.
Calling Alexa in English as a Romanian is a sure way to get you some laughs and weird looks from those around you; not everyone is accustomed to voice controlled tech and some even feel uncomfortable around it.
I have a lot of those Zigbee switches, but Conbee has failed on me sometimes and I don’t want to see that type of frustration from my wife again. You know the type: “why can’t you just turn on the lights like a normal person?!”
When you have something in mind to do and the simple stuff stop working, the situation is very frustrating. I imagine it’s like when I want to add some features to my app, and Xcode decides to throw some impossible error that has no concrete solution and I have to do the “clear data voodoo” and restart until it starts working.
Open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a Raspberry Pi or a local server”
65W would represent about a 30% increase on my average electricity usage or about £15/month, probably more later this year. HA is the only thing I run locally, and I mainly use it to save energy - also for watering plants and scaring foxes out of the garden.
I know it isn't going to be pegging at 65W but if it's anywhere in the vicinity, it's cheaper to use AWS instead. I used to have a server that I used for Plex/HA, but in the end the energy cost was higher than a Netflix subscription. I could have upgraded it to more energy efficient hardware but it would have taken years to pay off.
I agree - a used corporate small form factor PC from the likes of HP/Lenovo/Dell has tons of power for HA and can still be had for a next to nothing. They also sip power - under 10W at the wall at idle.
"Run on a raspberry pi" is a little tricky. You seem to need an SSD, or else some careful configuration of what to include and exclude from logs, if you don't want the disk to corrupt in a year or two.
It's a wonderful project but I wish they would be more careful about SD wear.
I’ve just had one SD card with HomeAssistant on it, fail on me last week after a power cut. It’s easy to fall into this fallacy of “it’s been working fine until now, so it will keep working”, I had the same thinking.
Luckily I was doing restic [1] backups daily to my Hetzner box, and my last HA backup was there, so I didn’t have to start from scratch. But it’s still annoying to have to buy another SD, flash it and find a way to restore the backup just to get your home running again.
That's one good reason to use a RasPi, the other is just that they are rock solid, almost bulletproof devices you can really trust, as long as you don't hammer the SD card.
Also, they are affordable, small, and low power, and an actually good SSD kinda messes that up.
I wish there were something that opens the windows automatically at the right time to keep the heat* and humidity out. I'm sure other people will have had that idea, too. But I haven't come across easy-to-use hardware controls. That's not even talking about the full optimal control problem, i.e. weather forecast, the heat capacity and heat permeability of the walls, and any cigarette smoke coming in.
*Air conditioning is hard to get permission for as a renter in Germany.
> I wish there were something that opens the windows automatically at the right time to keep the heat* and humidity out.
The latter part of your problem is a solved one. Weather forecasts and local conditions (from your own indoor/outdoor sensors) for the weather, heat capacity and permeability could be hardcoded or via helpers, cigarette smoke via air quality sensors. All of these can be integrated with Home Assistant.
All that is left is something to physically open/close the window, which should also be a solved problem.
I love HomeAssistant, and use it to power my whole house. I automate most lights, my whole house audio setup, my security system, and more. I highly recommend it.
I think the main use case is avoiding non-open source alternatives.
If you want something that actually offers more capability then something like node-red is probably more useful, it allows scripting all kinds of custom behaviour over many different protocols. (although even then it's rare to find a real use for it, besides having fun hacking things together, though they make it easy to build your own UI for stuff, which is neat)
Primarily, the use case is that it gives you some useful automation possibilities that aren't available in (for example) HomeKit.
Here's an example: I have an AC unit which is either on or off. I don't want my AC running all the time, but I want it to turn on automatically if the temperature raises above a certain value. That functionality is not possible with my AC unit, but I can use HASS to automate it.
Here's another: I have an air purifier which has an intelligent 'automatic' mode, which is supposed to change the fan setting if it detects higher levels of particulate matter - and to be fair, it does, but only between one of three presets. In reality, the machine has a 'turbo' mode which can be manually activated and deactivated.
HASS allows me to automatically switch back to auto mode from turbo mode in case the PM2.5 rating goes back down to a good level (e.g.: 2).
One other thing it's great for is taking IoT products (like for example smart plug sockets) which depend on their own apps, and integrating them with HomeKit.
I have an iRobot vacuum. It has some settings, like it can automatically run when I leave the house. It also has a Siri shortcut so I can control it with my voice. But if I leave home early to go to work, I don't want it to run and disturb my wife. With HASS, I can bridge it to HomeKit, which can trigger it only if NOONE is home.
I could also use HASS and my security camera to only run the robot if there's no motion detected for a period of time and no-one is home, and it's after my wife finishes all her work calls at 5 but before bedtime, but haven't felt a need to go to that level of complexity (plus my cats set off the motion detector all the time!).
It also gives me the option to buy cheap alternatives and bring them to HomeKit, rather than depending on specific apps.
Given that I had a Raspberry Pi lying around anyway, it was an absolute no-brainer.
I’m the same—I have several smart lights, but I can control them all through Google Home—but found a use for it this past winter. In my living room I have a Big Ass Fans Haiku fan, and the signal for volume up on my soundbar is the same as speed down on the fan. I don’t know how companies decide on IR remote signals, but I’ve never had this happen before.
It really annoys me when I turn up the volume and my fan turns off, especially in winter when I want it on to stir up the air. So I set up an automation to check the fan setting and if it is off, turn it on.
So far I haven’t really figured out what else to do with it.
I agree, I feel like it's only for niche uses. But if you have a niche requirement it can be very useful - I have issues with my ISP provided modem and they won't replace it. I use HA to locally power cycle the modem's plug from my phone (my router still works so local networking is fine)
I'm using mine in part as a homekit bridge. Some of my smart home stuff doesn't play nice with homekit, but I can connect it up to HASS, and then I'm able to open my garage door from my phone easily.
Honestly I see exactly NO purpose for such dedicated distro: I use H.A. on my homeserver, deployed via pip, simple, lightweight and effective without the burden of a dedicated distro with the need for security upgrades and enormous integration effort for what? On my homeserver I do many things, there is no point in having many different homeserver or container to run single service if I can consolidate ALL in a single hw, easy to recreate/extend as I with thanks to NixOS/Guix or anything else + some IaC behind.
Such moves have only commercial reasons and normally in practice are commercial fails due to the inevitably low quality of the output. I still have to see ANY dedicated distro with a commercial success behind and without a large number of angry users.
Because it wants to act as an appliance and manage the whole system itself including network configuration, updates, etc. For most users this is the correct approach, though you can opt-out and manually run the actual application in a Python virtualenv on a distro of your choice (in this case HA won't be able to manage the system and updates will need to be done manually from the command-line).
I run home assistant on kubernetetes, but I've been annoyed by things breaking often on updates and reliability issues when running ZHA with a combo USB dongle.
I'm a nobody and even I have had run-ins with certain people on the project. I think they have a similar problem to many hugely popular FOSS authors - you spend 99.99% of the day explaining things to idiots who don't get why things are the way they are, so when the 0.01% of useful, constructive issues float past they get written off by habit.
I personally think some of their leaders also have an over-reliance on gut reaction - have never once seen them admit to being wrong, even on multi year issues where context has changed. I think a useful litmus test for anybody in a position of power is "when did I last change my mind". If the answer is "never", either you're perfect or you need to think about how you've been making decisions.
Used it for five years. You've distilled the all the problems of HA nicely to its source. The product is fine for a while, until the arrogance and disregard the devs have against the user base inevitably breaks something and you have to spend time fixing things. And it happens often.
Edit: Just went through the DNS thread. Good lord. Just their typical M.O. on breaking things in the past.
Human factors aside, the practical result of this is that the methods of getting Home Assistant running are trash. Sure if you stick it on a dedicated RPi with their prebuilt image or use Docker, it "just works". But both of those methods basically guarantee suddenly needing to tinker when your setup randomly breaks. Ultimately if I can't simply apt-get or environment.systemPackages it, I don't really consider it sustainable software to rely on.
I did give in and actually had it running with Docker for some time. Eventually it just got real laggy and stopped responding to input or device state changes promptly. I had no idea why that would have been, and had no desire to wade through Docker manure to figure out how to debug it, so my setup just kind of fell by the wayside. Now when I think "home automation would be nice to have again", I envision just writing my own mqtt-native daemons some day.
The Docker container is the least evil of the choices, but it does have very pointless intentional limitations. Like not bothering to handle the difference between bind and externally visible IP, or by making logs difficult to mount outside the container (to a tmpfs to spare the SD card).
It's not even about "having to support someone's setup" it's about basic best practices, practices other software implements relatively effortlessly.
Very much akin to Canonical's Snap ~/snap folder thousands of users are pleading them to move to a more normal location.
IMO those all seem like predictable results of using Docker. By duplicating a whole system, containerization creates a whole bunch of unwanted complexity. Developers then fail to address every single concern, and when they do address a concern they often end up creating a novel way of managing it rather than integrating it into the standard ways.
I agree Docker is the "least evil" option for HA which is why I gave it a shot. But I still got random breakage, even with their auto update auto everything solution. So I'd say it's more like they haven't done the work to make reliable software, and instead of letting others start to apply pressure so that work gets done, they've dug their heels in with the modern way of saying "works for me". Container images are basically the contemporary .EXE.
If I can be running Internet-facing postfix, powerdns, nginx, asterisk, etc through distro packages and have them stay updated, a home automation daemon that is exposed only to my own network can most certainly do the same. It's tedious work to get software packaged for wider audiences, but if Home Assistant wants to bill itself as one of the leading solutions for libre home automation, then it's work that needs to be done.
I wouldn't say this is a result of using Docker, it's just very visible in that case. It's also not about handling "every single concern", it's users getting punished for poor assumptions made by the developers.
Point being that this incompatibility is active instead of passive, so this effort could be or could have been spent better.
If frenck is a core HassOS developer I never want to touch anything HassOS with a ten-foot-pole. They state in the linked PR they "tried to be friendly" but their tone is anything but the entire thread. They are completely unwilling to engage with the extremely patient Nix people, reiterating hard stop sentences. Zero attempt at developing discourse, just ornery, rude, commandments from on high.
It's not reasonable to ask people to remove your code from their project when they've already done the work on integrating it and it's published under an accommodating license. (edit: It seems the person requesting the removal of his project is an HA dev, some context for those links would have been useful.)
As for the DNS issue that seems to be a technical or design issue, I don't see in that thread any bad behaviour on the part of the devs, unless I missed a post.
> As for the DNS issue that seems to be a technical or design issue, I don't see in that thread any bad behaviour on the part of the devs, unless I missed a post.
The whole thread brings back PTSD when I was running it. It is reminiscent of every major problem they've had.
> seems to be a technical or design issue
This is the exact issue. The head devs don't keep contributors in line or provide any guidance at all. People just submit things, there's no checks on "is this a good idea?" and into master it goes. Does anyone actually want this? Does it make sense on how it's implemented? Will it break anything?
The fallback DNS was put into place because some users have local DNS that returns non-conforming responses in a way that breaks dns resolution in alpine containers (think broken implementations in some of those shitty router-modem bundles that most ISPs give you). Home Assistant OS is based on containers, many of which run Alpine. They had a lot of bug reports about these issues, and they all went away once the fallback DNS was implemented.
They did not originally allow this fallback behavior to be disabled because it should not have been needed, and would only result in those original bug reports returning.
However there was a problem in the original design for fallback, where it had an issue where DNS could get stuck always being routed to the fallback servers. Which means local DNS names won't resolve. While annoying, this is often reasonably easy to work around, as one can typically just assign static IPs to relevant local devices and use the IP addresses. They did eventually fix this, so that it cannot get stuck using the fallback as the primary, and local dns names work again.
Furthermore, they are now able to detect when locally configured DNS is broken in ways that break alpine containers, so they now offer a feature where you can turn off fallback DNS, but if you have broken local DNS your system will be flagged as unsupported, which means that the devs can summarily close your bug reports without investigating, unless you have reproduced the issue on a supported installation too.
Are there any good alternatives? I currently run HA but have avoided upgrading past when they broke YAML configuration "for my own good". I haven't yet found any other good options
I switched to node-red, node-red dashboard and Mosquitto mqtt. Those run just fine runs in an lxd container.
Almost all my devices are flashed with tasmota or have mqtt in them.
Maybe there is a lot less hardware support, and certainly much worse google home support but the 30 devices I have around the house work fine. All family friendly. The light switches just work. The doorbell works and no one knows it goes via an RF bridge to a home made/written mqtt to mp3 player.
I tried setting up HA once on non-docker and it was pretty awful. It has it's own internal dependency management thingy that auto downloads stuff it needs into it's virtual environment.
Much as I love to use standard off the shelf stuff and eliminate original code from my life, my custom automation system has been the one thing I can't find a replacement for, and I don't really expect that to change.
Is it technically open source? Yes. Is it spiritually open source? No. Is it arrogance and poor management? Along with many ways this project is run, absolutely yes.
Too bad. If they intentionally make it hard for people to make a software follow their distro conventions, be it immutability or reproceability, then they shouldn't be too surprised that forcing the software to behave properly could cause side-effects.
