Something like garage door that opens with a tap on my phone, music that follows me room to room, door camera that can be viewed from TV ("alt-tab" while watching Netflix), lights controlled by voice, smart mirrors.
Can be a blog, a forum, or a book, but it should be holistic—I don't want it to end up like a Goldberg machine.
Just get a Hubitat and be done with it.
I use it since a bit more than an Year, pip-installed and kept updated on my homeserver, for p.v. (Victron + Fronius + Giavazzi + ... all ModBUS/tcp or MQTT), it's config is obscene YAML, but with org-mode (org-babel + noweb) is manageable, logging is obscene but work OOB enough, automation is obscene but work enough, if logic is not much complex it's doable, the WebUI is nice...
I know I can write something myself, Mosquitto is FLOSS, ModBUS FLOSS libs are there for various languages, but that's not so nice for a simple domestic use case like just seeing how a small p.v. plant works, control the VMC/heat pump and hot water...
Just to play with sensors and crappy wireless switches is even LESS motivating...
IME IoT is crap in general, mostly because too many have no use-case for it so it's sold just to play, not to seriously use and profit from it, also because it's mostly designed by electronic engineers not IT techies, and we all know how ee are bad software side, many other reasons but well... HA so far for me was/is the leas worse pre-made/almost ready to deploy stuff I found. Surely I do not care at all at their suggested deploy with docker, HA cloud etc, just plain pip, but nothing have stopped me so far...
It’s having no discipline nor foresight and instead throwing shit against the wall to see what sticks.
https://www.home-assistant.io/installation/ https://www.home-assistant.io/installation/raspberrypi#insta...
It's not "unsupported" if they tell you how to do it. In other forums, devs have also promised that core will "always" be an option.
It was also the only installation method just a few years ago. Then they experimented with Hassbian/HassOS/Docker, etc. Shit, I remember they had a VDI option less than two years ago. That was FIVE simultaneous installation methods they supported. They shouldn't have let it get that bad to begin with, and pruning just goes to my original point that they keep changing things because they never have any discipline in the project.
Is Hubitat actually better?
I mean for your case, as a dashboard, HA might be better because the Hubitat UI is pretty ugly.
Am I right in concluding this appears to be another closed-source brick which is likely to implode in a few years, as they always do?
You CAN interface with other outside services if that's your jam, but at that point relying on Hubitat continuing to exist is no different than relying on those other services to exist.
At this point I would recommend starting with Home Assistant instead of Homebridge even if you just care about HomeKit support.
That said, I agree with you. If someone is starting from scratch, HomeAssistant is likely a better long-term solution, albeit a bit more daunting to set up initially.
1. I'm trying to add some better automation than what HomeKit directly supports. I've been experimenting with Node-RED, but having Node-RED talk to Homebridge is terrible. I don't know how much of this problem is on Node-RED's side versus on Homebridge's, but Node-RED keeps losing a bunch of my Homebridge devices randomly and getting them back later, meaning my automations are flaky. Also Node-RED itself just bothers me, it makes a bunch of odd choices, especially around how to deal with persisting values across events, the inability to have multiple projects running at the same time, the inability to hide nodes in a subflow without simultaneously turning that subflow into basically a reusable template that shows up in the sidebar, etc.
2. My wife is really interested in trying out Home Assistant for its dashboard capabilities. She wants to stick an iPad on the wall as a permanent home automation interface, but every app for HomeKit that we've looked at has various problems and none of them are sufficiently customizable. She kept seeing people talk about using Home Assistant for this specifically as it has very customizable mobile-friendly dashboards.
After digging in to it, I would agree that Home Assistant is a bit more daunting to set up, although they're pushing more and more into "configure everything through the UI" and so there's less of a need to go editing YAML¹. Home Assistant also has autodiscovery of a lot of local devices which is neat. Not everything is perfect though. I am trying to figure out right now how to expose my Lutron Caseta pico remotes to HomeKit via Home Assistant² and I may end up just skipping that and just exposing separate MQTT device triggers if I need to ask HomeKit to do something.
As it is, at this point I would say that just doing an initial setup for "I want to expose stuff to HomeKit" is actually pretty easy if you don't care about the rest of Home Assistant functionality. Just run Home Assistant, add the HomeKit integration, add integrations for the devices you care about, and then configure the HomeKit integration to make sure it's exposing what you want (it should expose most of the right stuff by default though). Then you can ignore dashboards and automations and everything else. Officially-supported Home Assistant installs also have access to something called HACS which is basically a frontend for installing custom 3rd-party components³, so most custom stuff is indexed there already.
¹I'm actually running this via NixOS right now and trying to put everything into YAML that I can to preserve as much of declarative configuration as I can, but I may give up on that given how many integrations simply don't even support configuring in YAML anymore. If you are setting it up from scratch it's probably best to go through the officially-supported install methods, such as running the Home Assistant OS in a VM or in Docker.
²I've got it done through Homebridge already but I want to retire that. Home Assistant has a built-in Lutron Caseta integration, and a built-in HomeKit integration, but if I ask HomeKit to expose my 4-button pico remote then HomeKit sees an 8-button stateless programmable switch where the first 4 buttons are triggered on "press" and the next 4 are triggered on "release". There appears to be a 3rd-party custom "Lutron Pro" integration with a fork available on the community forums that adds double-press and long-press support to its exposed remotes, but I haven't decided to actually go with that yet as I don't really want multiple Lutron Caseta integrations running (and the built-in one can expose motion sensors as it uses the undocumented LEAP protocol whereas the custom one can't). At this point I'm thinking of piping my pico remote events through MQTT because the HomeKit integration requires a device trigger for stateless programmable switches and I don't see any way to make a custom device trigger without either MQTT or writing an entire custom component from scratch.
³I don't have this myself as it's only available on officially-supported installs, of which NixOS is not one, but people referencing it in the forums makes it sound like it's really convenient.
Given your use case the switch definitely makes sense. I wasn’t even aware node-red could interface with HomeBridge.
It sounds like HomeAssistant has made some significant quality of life improvements since I gave it a test drive. I’ll give it a second look.
And you’re lucky your wife shares your interest in home automation! “I saw this cool wall mounted HomeAssistant dashboard…” isn’t something I can imagine my wife saying, haha.
It's actually kind of horrifying. There's a Node-RED module that uses the hap-node-client library, which is designed to talk to the hap-nodejs library that powers Homebridge. Which means Node-RED ends up talking the HomeKit Accessory Protocol to Homebridge as though it were HomeKit itself.
https://www.troyhunt.com/iot-unravelled-part-1-its-a-mess-bu...
FWIW this isn't true anymore. Most stuff is configured through the UI now (there's even a bunch of integrations that don't even support YAML configuration, just UI configuration). There's still a learning curve to be sure, and there's still functionality that does require editing YAML to handle, but my impression with setting it up now is that it's actually pretty easy to get off and running with just the UI.