Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> * Rationally, I might have been better off going with Home Assistant, which has ready-made integrations with Shelly, Zigbee dimmers, and probably thousands of other device types, but I wanted complete control and hackability, and I preferred to spend time building my own system rather than learning and customizing Home Assistant and maybe never getting it to work like I want it to.*

This thought was correct. Home Assistant is absolutely incredible, easy to use, polished, and flexible. You can get it to do all of this easily.

I got it installed and configured within ~3 hours.



I've got some Shelly Plugs. I decided to operate them with a self made web app running on my home server. That app makes HTTP calls to the API of the plug. It's very simple, just a curl from bash would work. One call to turn on the plug, one to turn it off and one to read the power meter. I put buttons on the web page and it does what I need.

There are no dependecies from other services and especially no dependency from Amazon or Google (the plugs work with them too.) Given the size of the web app maybe it also spared me some time because I suspect that installing, configuring Home Assistant and learning how to use it and what works and what doesn't are not zero time activities.


I don't myself but I know that many use Node-RED[0] for home assistant applications. It comes with thousands of plugins, easy to construct web frontends and it's completely open source.

I believe one can also combine it with Home Assistant, I think there are interfaces.

Learning curve is initial exponential (think of visual Unix pipes) but once understood, there are limitless things that you can do with Node-RED. It's basically a visual programming frontend to NodeJS.

[0] https://nodered.org


This is what use for my home automations, including some Shelly 1s. It's pretty neat.


That's just some silly scripting GUI, isn't it?

No real reason to write code in blocks when you know how to not do that.

I have an express server that runs my automations using the REST API.


Yeah, one of these days I expect to set up homeassistant, and even recommend it to others, but I'm happy driving my shelly plugs with bash+curl from a streamdeckui entry for now :-)


I have different opinion on Home Assistant. It's surprisingly heavy compared to alternatives, the YAML configs are insanely overcomplicated, they move too fast with Python versions (phasing out 3.9 when it was still the default on the then stable Debian, etc).

My 2 cents go for Zigbee2MQTT, Mosquitton, and Domoticz. Domoticz has it's problems, but it's been a faithful workhorse for me for the past 6 or more years.


Almost all my issues with Python versions went away when starting to use HA in docker container. Everything is very smooth.

One way is also to use HAOS but it is kinda limited.

Current stack for me is HA+traefik+Z2M+Frigate+Mosquitto. All running in containers, on top of Debian. Works perfectly.


How is it limited?

I have been thinking of migrating my setup from a docks container to HAOS on metal.

I have like 1 dozen Intel j5105 boxes, might as well use them.


Limited; as in you might have to find a way to configure some things in a different way than you are used to.

HAOS in a principle is a lightweight immutable distro for running containers; the HA itself is the same container that you would be running if you went the Docker path.

In my case, I have my IoT toys in a separate VLAN; HAOS needed to have access to both, main LAN (for the frontend) and IoT LAN (to talk to the devices). Configuring that meant installing container with SSH, making sure I can connect to the host via that (the featured "Terminal & SSH" addon won't allow that, you need the other, "Advanced SSH & Web Terminal"), and then using nmcli to configure the network.


Thanks for the reply.

I like the concept of paring down and organizing my myraid docker containers into native HAOS "add-ons".

That plus having a better update cycle and less hardware pass through headaches is appealing to me.

I've also been encountering a bug in my docker build pipeline that freezes my ability to remove a container until I restart it. Pretty frustrating.


If you want yaml based configs and running on a non HomeAssistant provided OS you are already making it hard for yourself.

This is not the most popular route and therefore also less supported my advice:

- use a raspberry-pi with Home Assistant OS or buy one of their self made raspberry-pi alternatives Home Assistant Yellow etc.

You can run docker but it's still not straightforward because then you need to passthrough like USB Devices etc, I would recommend against it.

And from there use the yamls to define a very basic config like language, location etc (I'm not sure that you even need to do that). But only use the GUI from there on.

Everything can be done with the GUI, I haven't touched my yaml files in years.

And I regularly upgrade versions too, haven't had any upgrade issues either.


> Everything can be done with the GUI, I haven't touched my yaml files in years.

Command line sensors, REST sensors, some types of virtual sensors, groups (I think), there's a lot of stuff you still can't do in the GUI, and even if you don't mind writing their stupid YAML-based config, the documentation isn't very friendly and in places outdated and contradicting itself.


IME documentation is pretty up to date and correct. Care to share some concrete example?


+1 for Zigbee2MQTT. I've been using it at the core of my home automation for a few years, and it's incredibly reliable.


HA is phasing out yaml integration config. They'll only accept core integrations with UI based setup now.

AFAIK you still need to do everything else in yaml tho.


Another vote for home assistant, also from another thread further down use a dockerized version, no issues. I have all kinds of things connected, lights, switches, shellys, custom sensors/collectors and it all works flawlessly. Just amazed how good HA performs after using various other things over the years.

You're also not tied to HA, but can develop using anything then once it all works put the result on HA.


I love HA for it's stability. However, I've written several HA integrations and I've got to say that their component API is insane. Inheritance based, vaguely documented, shifting terminology, etc. I'm working on my own use-case based API just to rationalize it a bit.


In order to get some sensors working I used Arduino examples from the web, understood the example and how it interfaces with my platform. Once it all worked I was able to transfer everything to HA, successfully. Going with "I'll just use HA from beginning", got me stuck thoroughly.

I feel like one of the people waving at the cloud saying: "Use Home Assistant", same as back in the days of use linux for all your troubles.


Once you use OpenHAB you will never go back to HA


Why? I already have zero issues with HA and it does everything I want it to do.


Windows has zero issues and so does MacOS yet there’s a market for both and lifelong users who switch from Win to Mac report a better experience.

OpenHAB allows for way more customization and integration.


I don't understand your comment about Win/Mac, but I run HA as a VM, so the OS doesn't matter at all. The same is true with Docker containers.

As for "way more" customization or integration, can you give an example or two? HA is scriptable.


OpenHAB comes in a container as well.

OpenHAB abstracts all of your devices. So your light switch can directly interact with Spotify , or your tv input can influence the color of your Philips hue bulbs. I know that is not a good example but it exemplifies the integration between different objects you may want to automate. This is native, you can also do scripting to support custom actions as well, which is based on JavaScript. Then you can build many different uis. You can have the home assistant-esque UI or you can build your own ui complete with custom css and js to give a completely unique interface to your automation environment.

Also notifications aren’t locked behind a paywall with openHAB. OpenHAB cloud is free, or you can launch your own OpenHAB cloud container and self host notifications (assuming you get the relevant Apple/android api keys)


> OpenHAB abstracts all of your devices. So your light switch can directly interact with Spotify , or your tv input can influence the color of your Philips hue bulbs.

Yes, this is exactly what HA does. I have devices of wildly different, closed-off brands working with each other.

> This is native, you can also do scripting to support custom actions as well, which is based on JavaScript.

HA also has this.

> Also notifications aren’t locked behind a paywall with openHAB.

They're not in HA either.

> OpenHAB cloud is free

I would rather pay my home automation system to make sure they can survive and keep maintaining the software. I think I pay like $5/month. I was recently trying to figure out how to pay them more, honestly.


Then openHAB is not for you, cheers!


I think the other commenter was hoping for some compelling reasons why you prefer OpenHAB over HA. On the surface both system seem very similar, I can't really figure out where they differ from looking at both homepages.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: