I wrote my own smart home software | Hacker News Reader

I wrote my own smart home software

renato.athaydes.com

309 pointsthunderbong211 comments

I feel like the initial learning of getting Home Assistant up and running is worth it over creating your own software. Especially in the long run. That and the other recommended way of setup that wasn't mentioned is to install the OS without messing with any containers. Pretty straight forward. Any problem you have there's probably a solution out there because the community is so large and that is worth it's weight in gold imo.

It used to be quite fragile but these days it's gotten a lot better. Still a lot of learning to do, someone with no experience in yaml or understanding under lying tech will struggle at first. They are pushing for UI setup for most things now so it's only a matter of time before it's far more accessible.

How long is the long run though? I've spent a few weeks setting up HA in 2017 only to watch it degrade by a series of busywork redesigns with each consequent update. Rules, app interaction, UI all were broken at some point: often in multiple ways. Devices that worked previously fell offline, and some of the drivers not popular enough to get a keep up rewrite simply disappeared.

My philosophy with HA is not to touch it too much.

I update only when there is some feature I absolutely need to have. And even when there is a new feature, give it a month or two to mature before using. I run a specific docker tag with auto-updates disabled. The instance is not internet accessible, so less care needed for security patches. When there is an exciting new feature, I apply that excitement to the busywork necessary for HA updates, and power through.

Furthermore, I use the built-in UI only for administration purposes. Run a custom react app that talks to HA via websocket/rest APIs. Those are pretty stable in my experience. Same with YAML configured automations.

Sounds like a lot of work, but I feel that it's offset by someone else writing the integrations with 3rd party services. When I want to control my new robot vacuum cleaner from my custom dashboard, all I have to provide is the UI. Someone else has figured out how to talk with the vac APIs, how to authenticate requests, and what to do to avoid getting rate-limited by the 3rd party service. I have to deal with only the HA quirks, not every 3rd party service quirk.

> My philosophy with HA is not to touch it too much.

I get where you are coming from, but for me updating hasn't given me any issues since about a year or so. Especially if you stick with the .2 or higher releases. Those are really stable.

Yeah I have the same approach - I don't update the second a new release comes out, and check the comments to see what the earlybirds have encountered just in case it's a bad release.

Personally I haven't had any issues for a while now, prior to that it was the Python upgrade and all the Z-Wave changes that caught me out. That's all stable now though so updates don't stress me out much.

In fairness, 2017 was threeish years into its development [0]. It's come a long way in the following 6. I've gone months forgetting to update and when I do have had few problems.

That said, in the last year or two there have been sitting updates that broke things — several were vendors updating their integrations.

[0] https://en.m.wikipedia.org/wiki/Home_Assistant

I'm still a bit afraid of doing updates, I always tend to wait for the first minor/patch release before going for it. Things have changed in a big way since 2017 mind you, far more stable, and fewer breaking changes that affect the entire instance, usually it's specific to an integration. I've been running my system for 2 years now without issues. Any problems I do face are related to not understanding the configuration of something I'm setting up, or a cloud based integration introducing rate limes to their api.

There pretty good with announcing any big changes in their blog, here's the latest one: https://www.home-assistant.io/blog/2023/05/03/release-20235

Why HA doesn't have a LTS branch is a mystery to me (other than the obvious maintenance overhead - but the community is huge and I'm sure they could find a maintainer).

When you consider the lifetime of homes, the hardware, etc it makes more sense for HA to have an LTS branch than almost any other piece of open source software.

I, for one, would really appreciate getting bug fixes, security updates, etc over a span of years for some installations. HA development pace is very impressive but the breaking changes can get old really fast, especially when you consider how much you can come to depend on the (ample) functionality.

When it comes to doing updates I typically allocate at least a few hours (just in case) to work through any breaking changes. I usually update ~monthly and like any rolling release strategy it helps minimize the number of breaking changes you experience at any one time but it's still a somewhat precarious situation.

Master needs to be the LTS branch, at least for all things mentioned. Once I have an automation it needs to work for as long as I live in the house. I have better things to do than to maintain the system. I probably won't upgrade the server at all for many years until I buy some new device that isn't supported by the old version, and I expect my house to still work after that upgrade, without having to spend days trying to remember how that old automation was programmed.

This here is exactly why the "smart home" is basically failing, because it needs to be set and forget and continue to work with ZERO maintenance beyond replacing dead components.

The fourth or fifth time you have to explain to your spouse that the lights in the living room can't be turned on because the app is updating or the server is down or whatever, you're going to really be feeling the desire to remove all the smart home stuff and go back to kerosene lanterns.

Which is one of the reason that I've slowly begun to phase Hue bulbs out - they work very well for what they do, but they can fail in annoying ways when the Internet is out, requiring you to get additional switches that can talk their protocol even when Siri isn't working, and at that point, why not just use a "smart switch" and dumb bulbs? At least that fails to just be a normal switch.

> why not just use a "smart switch" and dumb bulbs

I think this is just a better idea all round, although possibly not for bulb manufacturers' share prices.

The two need to work together. The switch on the wall needs to be smart as anyone in my house needs to be able to use it to control the bulbs, without having to open an app. Okay, if you can ensure a thief cannot control my lights while I'm my house I'm good with that, but I have kids, guests, and sometimes I don't have a device on me: it must work for all of them the first time and every time. A bulb cannot do that alone, it must have a smart switch (I've used the flip the switch off/on to control the bulb - it is not an acceptable work around).

The bulb however need the ability to charge color temperature and brightness depending on what I want, and a smart bulb seems best (though dumb dimming bulbs can to work well enough)

What I'd love to see (and nobody makes, but I could make one myself with a bunch of switches I guess) is to have various plain bulbs of different colors, and control them with the switch.

I wish the Hue bulbs worked with a actual smart switch (I have some of the snap on cover ones and they are "ok" but unsatisfying long-term.

https://www.philips-hue.com/en-us/p/hue-tap-dial-switch/0466... is silly, it's battery powered. The old one (Hue Tap) was great, because it used the force of the button press to send the signal needed: https://hueblog.com/2020/07/27/hue-tap-disappears-from-the-m...

So of course it's dead and gone :(

Agreed, though I have to say Phillips Hue lights have been well worth the money in this regard. I have some Lutron switches that snap over my standard flip-switches which prevents accidentally cutting power to the bulbs, and the switches talk directly to the lights (or perhaps through the hub, it's been a while since I've set it up) rather than through a server.

With HomeKit this all also works as long as my local network is up, with no dependency on Apple servers except for off-network access.

My ISP has had several outages, but I haven't run into the issue of "the lights don't work" at all yet. Only thing approaching this is I've automated them to turn on/off when I arrive at and leave home, so when I have people over and step out to run a quick errand all the lights turn off while they're at my place.

Hue works the best of all that I’ve tried for sure. But when we use Siri to control the living room lights, Internet access is needed. The Hue app still works if needed (most of the time) and the little no-battery physical switches keep working with Hue.

But it just doesn’t provide “value” compared to the cost, so I’m not going to rip it out but I won’t maintain it further or expand it.

I had this issue with all internet enabled devices, particularly my Leviton switches.

I moved to Lutron’s Caseta line specifically because they work without internet if something does happen to my network.

There's commercial options that work like this (and indeed those installations can more or less be updated and upgraded with new stuff decades down the line, we've been there, it's been done, and continues to be done) but that's the rub: it's commercial, it costs money, and the hardware involved is much more expensive than cheap IoT gadgets out of shenzen. Wanting the lowestest cost option to also have the longestest life and highestest reliability is of course something we would all want, but generally not how this reality is structured.

Mines been running about 6 years. At first, it was rough at times. It's been a lot smoother since they released hassos, (and I don't even run it, I just use the containers). I don't think I've had any issue of note in about three years. It also has a painless backup and restore system now.

I have been running Home Assistant for over 4 years (end of 2018) and and the beginning was rough. However since about a year and a half, a lot has done to improve stability. I can now safely update every time without breaking anything. The only integrations that break from time to time are custom integrations, which aren't supported anyway. But those have become rarer too. Automations and scripts have been stable for years now. And the release notes are also really, really good.

I would recommend to take another look at HA if you get the chance. Especially within a VM (or bare metal) it's a really good experience.

> Especially within a VM (or bare metal) it's a really good experience.

I've been using the Docker container for a couple years without incident. Like you, the only integrations that occasionally broke have been custom components.

While I agree that automations and scripts have been very stable, I've never really been a fan of the new automations and scripts UI, though, so I just stick to editing the YAML definitions manually. Great to have that option.

> I've been using the Docker container for a couple years without incident.

Before I ran HA Supervised [1], but that was a pretty poor experience. It broke every so often because of some sudden software incompatibility because Supervisor was silently updated in the background. And it really broke everything instead of having a grace period and/or sending me a notification.

> I've never really been a fan of the new automations and scripts UI, though, so I just stick to editing the YAML definitions manually.

Same here. Although things seem to improve in the next version with copy-paste support in the Automation Editor [2]. I would love being able to edit my YAML automations though.

Did you also known about a little known feature that you can setup different automation sources? Just like this:

  automation: !include automations.yaml
  automation foo: !include_dir_merge_list automations/
  automation bar: !include_dir_merge_list automations2/

Although not _best practice_ per se, you can have both UI and YAML automations at the same time. This is especially useful when you want to use Blueprints [3].

1. https://www.home-assistant.io/installation/linux#install-hom...

2. https://rc.home-assistant.io/blog/2023/05/31/release-20236/#...

3. https://www.home-assistant.io/docs/automation/using_blueprin...

I only started using Home Assistant about a year ago, but it has been rock solid to me. I even made my own (simple) custom integration and publish it on HACS and it's been rock solid (no API changes that break my custom integration so far). Could it be that Home Assistant is becoming more stable these days with less breaking changes on every updates?

As many others have said, it's far more stable now. I've been running it 5-6 years now, and experienced more than one broken update in that time. But in the last couple years or so, the only issue I've run into was an SD card that died. I was able to pull a recent backup off it, which was dead simple to restore. And that also taught me to run a nightly backup that goes to a network file share.

Things have improved since then. Ever since zigbee2mqtt and the sonoff zigbee radios became available I have had basically no issues with my network. I think I've changed the coin battery in my tradfri remote twice since I've last had to reset any device.

> That and the other recommended way of setup that wasn't mentioned is to install the OS without messing with any containers

No way.

You also need to allocate some monthly time for maintenance - small or bigger updates, new devices, security issues... it's not a one-time project but an open-ended job.

Ffff my Zigbee2Mqtt is not working for the last month very well at all. I need to dig into this again

for me that happened because of interference. I switched from a Conbee II to a Sonoff Dongle-P and that already helped tremendously. That new dongle is way more stable for me. Also I changed my wifi and Zigbee channels and reduced the transmit power for less interference. Since than my Zigbee netwerk is really stable.

Updating the firmware in my sonoff dongle-p made a massive difference in network stability. It's a bit of a mission to get the update installed but was well worth it.

Do you still need Zigbee2Mqtt now that Home Assistant already have built-in Zigbee integration [1]?

[1] https://www.home-assistant.io/integrations/zha

Until a few days ago zigbee green power was not supported in zha/zigpy. It now seems to be merged. I'm not sure if zigpy supports the same amount of devices as zigbee2mqtt

https://github.com/zigpy/zigpy/issues/341

I found ZHA to be suffering from severe doc rot around OTA updates and a few other edge features, and that devices that just worked with zigbee2mqtt were unpairable or unstable with ZHA. I gave up after 3 months of almost daily effort and went back to zigbee2mqtt, where I had immediate stability and almost zero effort.

Which is why I don't have anything automated in my house. I have kids to raise, I have trouble finding time for any hobbies at all. I don't have time to take on the automate my house hobby.

I do recommend getting at least one Hue bulb for the kids; you can entertain them for a solid half hour by setting the bulb to automatically change colors and turning the rest of the lights off.

I have a Hue sphere bought like 10 years ago(?) and it was fun for a while - a year even - to prepare for sleep in slowly changing lights. Nowadays it just gathers dust in a corner while still looking cool, ain't nobody got time for that anymore.

HASS is updated monthly by contributors so you don’t need to maintain it by yourself. It’s the best effortless way to manipulate IoT devices.

Why? HA can operate entirely offline without access to the internet. You aren't suppose to expose it to the internet, you can't but they advise against it.

In that configuration you only need to update the software when it no longer meets your needs. If it's working then there's no need to update it.

My HA platform project started in 2013. Every few months or so I check back to see if HA has progressed far enough that I can ditch one of the last custom apps in my life.

It's getting there. But it's not quite there yet. Last I checked the logging still saves every change, it's not easy to set up so that it will only save average/min/max over time to save SD wear.

Creating new integrations is easy but still not quite a five minute job like it is with my extension API(https://github.com/EternityForest/iot_devices).

I don't think their integration API has quite as much of a "Narrow waist" as I would like. It seems like extensions are somewhat tightly coupled(I looked at trying to make an adapter to use HA extensions in standalone scripts but it seemed very hard).

That doesn't exactly seem ideal for avoiding brittleness.

And updates still seem to break stuff on HA occasionally, plus it's a large platform that I just haven't seen many people talk about aside from enthusiasts, who tend to downplay problems with FOSS apps.

But yet, having custom software in one's life is generally IMHO far more of a liability than an asset.

So what I actually do is just use YoLink and Google assistant for everything I possibly can, and use my custom software for video recording and unusual stuff YoLink doesn't do, and I'm pretty happy with that so far.

I'd love to have a one size fits all "If it need automating, use this" platform, and HA seems like it's got the potential.... but just using the YoLink proprietary platform is the lazy, trouble free, super cheap way.

I ran a HA system for a couple years at my last place. It was great when it worked, but I found it to be fragile, overly complicated, and not well engineered. I'm biased I guess, as I have mostly worked on embedded software and devices that need to be reliable. It's great if you like 'shake and bake' style open source projects that barely work and have a lot of time to tinker with them. I prefer my home automation to work 99.9% of the time and not require large, periodic time investments.

HA, out of the box, also seems to burn up solid state storage due to the absurd amount of logging.

HA looks sexy though, and I think that entices folks. It's nice to have a star-trek style dashboard running on a tablet or whatever. That's not really appealing to me though. I like my automation to have beautiful software, be well tested and reliable, and disappear into the background of my life. Being a SW guy at my day job, I really don't want to play SW engineer on the nights and weekends.

So what's this beautiful, tested and reliable alternative to Home Assistant? did you ever find it? Guess baking your own like OP did is out of the way as per your last sentence.

If Apple Home, Google Home and Alexa aren't enough for you (or you want a fully self-hosted option) you don't really have many options.

Home Assistant is the big one, biggest community, most integrations, you can pay for their cloud stuff to get easy integrations to the big corps above. They also have a dedicated device they sell you can use to run HA.

Domoticz is a bit of an odd bird, I never figured out what was their value propositon

OpenHAB is the one I'd pick if I had to install a system for someone else than myself. It's not exactly easy to configure (the object/entity structure is a bit weird IMO), but it has a pretty decent amount of integrations and it's rock solid German engineering made with boring old Java.

If you want control, my suggestion is to use HA only for the integrations and do all of the brains somewhere else. Either a self-made program that pokes HA using its API or directly via MQTT or Node RED.

> Domoticz is a bit of an odd bird, I never figured out what was their value propositon

Simple, rock solid functionality. If you want more, write scripts.

I really like the approach.

> Simple, rock solid functionality.

Don't ever open that C++ code base unless you have a barf bag.

I started making contributions and gave up because I have better things to do with my time then ruin my soul.

I will also note that they stole the MQTT protocol from Home Assistant - so at least they need ideas from elsewhere. (ie openzwave died so domoticz needs to rely on the same NodeJS subsystem infrastructure of HA)

I love the concept of domoticz - lua, but my god the architecture and implementation is a tire fire.

>I love the concept of domoticz - lua, but my god the architecture and implementation is a tire fire.

Is that better or worse than a dumpster fire?

Tire-fire is spectacular compared to dumpster fire. Highly energetic thick black smoke probably visible from space shuttle with naked eye.

On rock solid functionality:

https://github.com/domoticz/domoticz/issues?q=crash

segfault, leak and hang are also fun ones. Apparently the massive memory leaks in the python integration has never been fixed. Not surprising, one look at hardware/plugins/Python*.cpp is bad for your health.

Does nobody use Hubitat any more?

I'm still using it. Upgraded from the C5 to the C7 a few months ago. I use almost entirely Z-wave devices, and the HomeKit integration built into Hubitat makes it easy to manage them all like native HomeKit devices.

Managing probably any Z-wave mesh isn't something I'd recommend for a non-techie, but it doesn't generally requires consistent maintenance. And with Hubitat, it's a small standalone box that does OTA updates.

For me it fills a pretty big gray area between mass market consumer ecosystems and Home Assistant.

Never found one. It's on my list of things to do someday but that list only grows. I keep telling myself retirement will be a great chance to develop sw like that and give back.

OpenHab,

I'v gone from home assistant to smart things to openhab and its been stable and simple to set & forget.

It's great to setup via the UI, easy to backup and restore as once you actually start to build it into the foundations of your house you start to value the stability of it

I still never used OpenHab (at the moment running HA but not happy about it).

I’ve tried developing custom components for HA and it was so bad, there’s no docs at all and Python being untyped language doesn’t help either. Just out of curiousity I’ve googled OpenHab docs to understand if I could achieve similar there and their docs are awesome, full and well written. (and it’s Java so half of the code IntelliJ will write for you)

Not beautiful, but I use HomeSeer on Ubuntu. It is commercial, but after spending a couple thousand dollars on all the home hardware and server, spending a bit on software makes as much sense. It is reliable with my automations. I have added custom devices and automations through scripts that publish MQTT messages. For simple remote control, I tend to eschew their UI and have HomeBridge publish device access to HomeKit.

I'm looking at Mozilla's WebThings.

I work for a company (Inductive Automation), and we build a platform for industrial automation called Ignition. A few years back we created a special free license tier (and some light weight branding) for personal and educational use. It's called "Maker Edition", and there is a growing group of users using it for home automation. Mostly people already in the operational/industrial automation space, but it seems like it's growing more broadly.

We package Ignition as a docker image, an installer, or just a simple zip archive you can decompress and launch, so it's easy to self-host or deploy to a cheap cloud tier. The biggest downsides are that there will be a bit of a learning curve to using it (as with any new tool), the documentation being focused on commercial use cases, and similarly, we don't offer first party drivers for common home protocols (zigbee, zwave, etc). But we have pretty good docs, a free online learning platform, and pretty active forums. 3rd parties have written various drivers for home use.

I'd love for more in the home automation/maker space to know about and use it. We don't monetize maker edition in any way, and so don't really promote it, but I'd love to see the home userbase grow (and hopefully by extension, the hacker/maker community who might be able to help contribute to drivers and other resources).

It's an open platform built on the JRE, with a public sdk and example modules (plugins) and related tools available on github.com/inductiveautomation. The software is in use to automate virtually every industry, so it's fairly well tested (at least to the extent that a toolkit can be).

Maker Edition info is available at: https://inductiveautomation.com/ignition/maker-edition

Disclosure : work for inductive automation, but otherwise don't have a financial interest in people using Ignition Maker Edition or anything of that (aside from any side effects that come from broader adoption in general). My selfish interest is in a larger home use community so there are more cool projects to check out, resources to share, open source modules published, etc.

All statements here are my personal views.

How about just using e.g. your Apple TV as a hub, to connect to Homekit devices. I'm probably going to do that. You can also build your own devices(*) that connect directly to the Homekit hub without having a bridge or any kind of other software running.

(*) Example; ESP32 with HomeSpan

Homebridge works fine in such a setup as well for devices that aren't Homekit-compatible out of the box. I ran a setup like this for a while, but Homekit just wasn't flexible enough to do the automations I want. Also, everyone on Android is locked out, which can be annoying if you have guests and can't give them access.

I could just let people use the iPad. We have a couple lying around. What I'm interested in is how Homekit wasn't flexible enough to do the automations. What kind of automations were you planning to do?

I guess a good trajectory would be to start with Homekit like you did and then have the option of hosting that bridge yourself via Homebridge when you want to expand or go more advanced.

I'm in the same boat. I'm running two instances of Home Assistant with Zigbee2MQTT for sensors, lights and switches, a few non-Zigbee devices via built-in integrations, and NodeRed for more complex automations. I find the stack to be a bit of a Sisyphean mess, quite unreliable, and a significant time sink.

I'll give some examples:

- HA occasionally freezes for a few seconds during automation runs, though system load, IO etc. look fine. No idea what's going on. It should have more than enough resources. Both instances do this (on different hardware).

- After every restart, ZigBee switches only work after the second press (the first message shows up on MQTT, but is apparently ignored). This is especially annoying if we're having guests when HA acts up; also, some switches use double-press for special behavior.

- Sometimes an automation or two just don't trigger until HA is restarted, but everything else works (happens about once every two weeks).

- Outlets and sensors may be gone from the network for a week (e.g. accidentally left unplugged) but will never be shown as stale in HA.

- Most automations I want devolve into huge YAML messes or huge NodeRed graphs, since I seem to need a lot more flexibility than other HA users. I've found it's a lot easier to just write a script for these, but the developer experience of the various scripting plugins leaves a lot to be desired. Also, yet more flaky abstractions.

- Why is it that checking whether a scene is active is so hard? That's just the sort of heavy lifting I expect HA to do for me.

- Every release of HA seems to add new little quirks; apparently, lots of people in the community don't even bother updating regularly?

- It's very hard to know what's going on inside HA; it seems to log every last thing except for what I'm looking for. I usually just look if MQTT sees the right things, then restart HA until the issue I'm having disappears. That this strategy usually works is problematic in itself.

All in all, it feels more like training a cat, not the hands-off appliance-style setup I'd like to have, and it takes up way too much of my limited spare time.

I really like HA for the user-facing part, great app, great web interface, even supports Apple Watch. I'm comfortable with writing code, perhaps a bunch of scripts against MQTT and the HA API would be the way to go for me, or perhaps something like AppDaemon.

I've also tried using Apple Homekit with Homebridge, and while that was rock solid, hands-off and very reliable, it doesn't have the flexibility I want either.

You arent wrong, there's a different mindset with a lot of homeassistant.

It feels like there isnt an understanding of something like MQTT - I want automations that listen to events, which include data in the payload.

"Subscribe to a topic" and "filter relevant happenings" seems conceptually so easy.

Building a UI to do this, harder. But adding a (bad) widget system of the actions? Hmm.

Its not IFTTT, it should not try to be. Provide visualisation tools to manage what listens and what broadcasts. Have black boxes of logic, just mandate they must respond in a particular way.

Leave the rest to programming. And if non devs are frustrated: help turn them into devs

I've setup HA so that I can turn on/off a couple of WLED smart lights and I found the UX of the dashboard to be a bit confusing.

After setting up a HomeKit Bridge integration, you are given a QR code to connect from the Home app. The code appears in the Notifications tab. I missed the code at first so the Notifications tab was empty and I thought that there should be a button to issue another one? After looking it up online, apparently the way to go is: delete the integration, create it again and be more careful with the Notifications tab.

Then if I want another person in the house to be able to control the lights from their device, I can't show them the code. This makes me wonder whether the HomeKit Bridge supports only one connection or if I just have to screenshot the QR code? It can't be that bad, right?

Other than that, a great piece of software. When I got the smart lights it bummed me out that I couldn't control them with Home and had to use some third-party app to do it so eventually discovering HA significantly improved my experience.

HomeKit can pair only once, to pair it another time it needs to be unpaired first; a design choice unrelated to HA. But you can “share” your home in the Home app. That will add additional “controllers” to those devices (HA being the device here).

Thank you, I thought so. It'd still be nice if they could print it somewhere because that was my first impression so I assume other people not familiar with HA will run into it as well.

Regarding sharing, I tried it, but it says "A home hub is required to add or remove accessories, scenes or people". I looked it up and apparently you were able to use an iPad as the home hub which you'd share access to, but since a certain version of iPadOS/iOS it can only be either an Apple TV or a Home Pod. I think Apple is focusing on being able to access your home setup anywhere so it requires a device that is supposed to stay at home all the time. Still a shame because it hinders offline-first setups like mine.

Mind you, HomeKit really is offline-first. The home hub does operate as the internet bridge, but on your local network you don’t need internet to operate your home.

+1 for same boat.

I've mostly settled into using HA for basic home automation and backing away from lots of or complex automation. There's a certain amount of time I can spend and anything beyond that feels like a job that isn't adding much marginal value at home.

One small tweak that helped with dead/unavailable devices. I set up a simple daily automation that pings all of the Z-Wave switches throughout my house. Was having lots of problems with one or two occasionally looking dead but the once-per-day ping helps.

Maybe it's the zigbee integration? Several people mentioned it being unreliable here. I'm over here with my 5 year old z-wave set up wondering what the fuss is, because it's been super reliable for me.

The only thing I can to do was a little clicking around when the z-wave implementation switched over to js but the upgrade path ended up being straight forward.

  Being a SW guy at my day job, I really don't want to play SW engineer
  on the nights and weekends.

That's exactly why I fell out of love with home automation. The commercial stuff isn't better than HA. I don't want to care what brand my zigbee lights are. I don't want to come home and debug Siri or that god awful Hue app. I just want to turn my fucking lights on.

Home automation promises Star Trek and delivers the bastard offspring of 2001 and Galaxy Quest.

It might be neat to voice activate a mood with lights, music, etc. but the amount of effort to set that up and maintain all of that is literally 100x the effort I'd spend flipping a couple switches and turning on a playlist on a speaker. Literally 60 seconds to do it manually (assuming you know/have setup a playlist).

The only "smart" devices I have are for a room where you want a switch for a lamp but there isn't a switched outlet. Add a smart plug and a physical switch, done. No hub, no scripts, no automation. Its cheaper than buying smart bulbs which usually require some manufacturer's hub/app/nonsense.

My lights work pretty reliably, but I've done hours of research on goddamn lightbulbs. And then automating schedules and programming switches is harder than it should be.

> It's great if you like 'shake and bake' style open source projects that barely work and have a lot of time to tinker with them.

I think this is a cool way to relate to technology. Is there a word for technology that people enjoy because it's broken all the time?

I have a good friend who has been in management for twenty years, and he maintains a complicated home network like he was head of IT for a circa-2000 small business. Mail server, printer server, FTP, etc., mostly bare metal with a couple of VMs for things like a Windows domain controller. The most modern thing he has is a media server so he can buy music and movies on physical media.

It takes a moderate amount of tending, and once a year or so, something major breaks and he has to spend a weekend or two tinkering and fixing things, solving a complicated puzzle of software and hardware compatibility. I think it's a therapeutic outlet for him. If you talk to him, he'll give you complicated reasons why the whole thing is extremely practical, but nothing that would justify the dozens of hours per year he puts into it. I've probed for how he feels about it ("I bet it's nice to get hands-on every once in a while, eh?") and from his answers I'm pretty sure he has no awareness of it serving any emotional purpose for him. I bet it drives his wife crazy when she wants to watch a movie and he has to run into his office to tweak some configuration, but from my distance, I think it's pretty cool.

What I can't stand is the subset of people who keep trying to trick the rest of us into using their tinkerware, the "install Linux for your parents in 1999" crowd. When I bought a house seven years ago, I was really excited to set up some home automation, but after a couple of weekends of research I realized it was going to be a full-time hobby. I remember in particular being on Reddit and looking at the comment history of someone who had a pattern of saying "once you get it set up it's relatively pain-free." It was obvious from his history that it had been basically a second job for him for over a year. I decided to live in an unautomated home and invest my energy into other things, and I'm very glad I did. What drives people to lie about things like that to people who won't enjoy it?

I have a pretty decent home automation setup going for the last 5 years at this place with no issues using the hue ecosystem till my hue bridge died last month. Motion battery free buttons and timers for lights and outlets.

Have now made the jump to HA so we will see how long it can go post setup without falling over (and adding some things) but 5 years before the first issue (and so far I have some hue bulbs going on 10 years) is solid enough imho

So it can be done and is not always a lie.

I strongly disagree with anyone saying home assistant is support he’ll.

I enjoy automating and doing sysadmin things for fun, but I have a life and young children. I don’t have time to tinker as much.

Home Assistant has come a long way and has been extremely reliable the last few years. I mostly use it for automating camera detections and motion/contact sensors for security.

You can be as hands on or hands off as you want to be.

In general I’ve found if you want to do any sort of automation whether store bought or tinker-level, you’re going to be wasting some time.

as i said in my experience with the hue ecosystem it ran for years, 5 years, with no issues. it literally was set and forget and just worked. until it died and i moved to HA i hadn't added or changed anything for at least 2 years to the point i had to install the app to my phone when the bridge died lol

My experience was more than five years ago, so if I get the itch again, I'll take another look.

it sounds like HA is far more polished now so i'm hoping it goes well. but hue over the last half decade has been 100% solid and reliable for me till the bridge died

After a reasonable period of things working I just had an issue where some lights wouldn’t respond. At first I thought it was the saturated 2.4G wifi, then it got distracting enough to take up an early morning and it turned out that “for security reasons” HA made a choice to block my MQTT server until it was updated.

Not my favourite discovery and required a whole migration plan. Now I’m seriously reading the above article and thinking after (4?) years it’s time to leave HA.

Not to sound negative, it reads like the author quickly dismissed HA without a great reason so they could build their solution.

There's a lot of home devices beyond ZigBee, with a large community supporting them. Beyond ZigBee, we will see Matter devices also cropping up over time.

I do like the idea of being in control of one's automation software. The risk that I've seen though is when one ends up spending more time on building the software than the automation, which can happen when one writes their own integrations from scratch (i.e. not using Z2MQTY, ESPHome, HA, etc).

With that all said, I like HA as the central programmable hub, but have come to dislike the proliferation of ecosystems that require add-ons I'm mostly looking at Sonoff devices that tie you to ewelink and phone home in opaque ways.

I'm personally probably going to go with Matter for store-purchased and DIY devices. I'm already nearly done with our first DIY devices at home. A light strip for the kitchen, that has some sensors for useful automation.

Not rolling my own solution makes it easier for me to build a few devices for friends later.

HA is _very_ good for integrating stuff, mostly due to it being the de facto standard for DIY home automation. Basically if something has any kind of API that can be accessed in any way, someone has already made a HA integration for it.

On the other hand, it's absolutely crap at doing complex automations. The Web UI gives me heartburn any time I need to make it do anything else than simple "if temperature is over 40 on this, do this" things.

The UI does make complex automations _possible_ for non-programmers. But for me, every time I click on the UI or attempt to "program" using the convoluted YAML syntax I keep thinking "this would've been like 5 lines in an actual language...".

Thus: I use Node RED for the more complex stuff paired with an external program I made that connects to the HA Mosquitto server and pokes stuff directly when needed.

Yea I kinda wish you could just write code for it. I’d even accept writing it in python as that’s what ya is written in (as I too don’t like python)

Pyscript adds rich Python scripting to HASS : https://github.com/custom-components/pyscript

An example script:

    @state_trigger("security.rear_motion == '1' or security.side_motion == '1'")
    @time_active("range(sunset - 20min, sunrise + 20min)")
    def motion_light_rear():
        """Turn on rear light for 5 minutes when there is motion and it's dark"""
        task.unique("motion_light_rear")
        log.info(f"triggered; turning on the light")
        if light.outside_rear != "on":
            light.turn_on(entity_id="light.outside_rear", brightness=255)
        task.sleep(300)
        light.turn_off(entity_id="light.outside_rear")

It's what made me ditch node red after going down the same path.

There's also NetDaemon for those who prefer C#: https://netdaemon.xyz/

Can anyone comment on whether Pyscript vs AppDaemon is the better path? It felt like to me as someone that codes as a living PyScript was the better choice, but I also only ever used Python in college and grad school, and just haven't had the time to investigate a difference between the two and wanted to just get started. Using PyScript seems easy but it also feels like its just the main authors preferred way of working and is pretty buggy outside of how he likes to work in Jupyter notebooks

The Home Assistant community seems to have the entire gambit of people who can't code at all, the people who never coded professionally and make riduclously complex things like the fabled Excel accountants, to the professional developers doing stuff for fun, but nobody actually shares anything worthwhile outside of awful YAML and youtubes about awful YAML.

I'm currently using AppDaemon for a couple of webparsing-scripts. That has worked just fine without touching it for... well over a year by now.

But i have a nagging feeling that i should probably use PyScript instead.. If anyone has a more thorough analysis i'm open to hear it..

For what it's worth, I don't use the Jupyter notebooks. Just have a folder somewhere with python scripts that get reloaded as I edit them.

I've found that it just feels like I'm fighting a river to go up stream if I don't incorporate the web browser + Jupyter work flow that the author likes.

Auto complete for discovery just refuses to work in PyCharm and VSCode for me. The way PyScript is setup seems to be a strange bespoke system that kind of breaks the import system between files, type safety only sort of works sometimes, and just other quirks where I seem to just have to get used to all of the red underlines if I want to use an IDE as part of my development process.

But it still seems to be best option for allowing me to use any libraries in the ecosystem, gets rid of boilerplate, and the author is actively maintaining it. I didn't really find any other viable options outside of Python that would let me actually code my automations without yaml or a GUI.

I was very excited when I found a Kotlin implementation, KHome, but by the time I found it, it was already a seemingly dead project.

If you are expecting auto discovery of state variables or service calls then that would be nice, but that seems like a bit too much to ask. And it's not something that I personally feel is necessary as you're likely already are familiar enough with the home assistant states/services that you want to interact with by checking them out in the home assistant developer UI.

My PyCharm just shows those types as unknown, not as errors. I get auto completion & type checking for all the code I write myself.

It's also important to note that PyScript isn't regular python. Instead it's an interpreted script[1] that is compatible with the Python syntax. This is unfortunate, but enables most of the magic of PyScript which otherwise would not be practical.

[1] https://github.com/custom-components/pyscript/blob/master/cu...

The thing is, the Jupyter notebook does support auto discovery/complete of all of the state variables and services, but only in the browser. Not even in the notebook running inside the IDE.

It's just maddening that I can't seem to figure out how to get that one part working. I end up using a mix of the notebook and going through the developer UI, but wish I could figure out that one quirk.

Where is that stored? My beef with NodeRed was that it's not very git/manual-change/file friendly - random IDs and minor change in UI causing a large on-disk shuffle.

Even if I use a UI for making a modification sometimes, I want to be able to commit a clean diff like:

      sensorLightBackdoor:
    -   timeActive: range(sunset - 20min, sunrise + 20min)
    +   timeActive: range(sunset, sunrise)

Or whatever. Which obviously I can do with python, as long as it's stored neatly in config in a .py file, or even if embedded in HA yaml or something?

> Where is that stored

In a `pyscript/*.py` file, so you can open it with a full blown IDE and use all your usual comforts, and commit the results to git.

Awesome, thanks, this may be the push I needed back into HomeAssistant. :)

Their reasons for dismissing HA seem sound to me. Python is a negative for some people. Suggesting to run in docker is a negative for some people.

Personally, I gave in and installed HA in a VM, because it seemed like the least effort way to use HomeKit capable devices without purchasing Apple products, and I was able to connect the HomeKit things, but I can't figure out how to do what I want with them, so I not sure what I got. Ideally, I want to make my 'smart' thermostats a bit smarter ... better coordination between zones, different minimum fan runtime rules than I can get from the thermostat, loosen the setpoints when the tv is on or someone is on the phone, so the hvac noise is less bothersome, etc. But I can't figure out how to get HA to track the fan runtime, so all that complexity is like ugh, I'd be better off doing it myself, except the homekit stuff isn't sensible either.

Yeah I thought not liking the way of self-hosting it especially was fair enough. And I suppose language is too even if I don't mind in this case - Java certainly puts me off OpenHAB (and anything else it's used for).

I've been running openHAB for 3 years with over 100 Z-Wave devices (every light and window in the house, auto-sensing everything), 25 touch screens (one in every room) and wifi/ethernet integration with everything else you can think of (eg UPS, TV, Sonos, Sonnen batteries, Envoy solar interters, air conditioners, sprinkler systems etc). It's never failed and the community is helpful. Irrespective of whatever it's written in, the versatility and 365 x 24 reliability is absolutely rock-solid.

The risk is real and reasonable if one is willing to rationalise it as a hobby / learning / playing with hardware and a trivial amount of soldering.

In my case I wanted to play with sensors and the pico w. A pi with a sprinkling of c#, Nats, and influxdb connects, controls Ikea stuff, and reports all the things.

Micropython on the pico is not my favourite part of the process but it might have been faster for me than just writing in c.

That’s cool - I’ve done something very similar and used the Worker Service project type along with Quartz .NET for scheduling.

I too balked at the absurd complexity in the HomeAssistant stack, and it's kinda kept me off the "smart home" train because I refuse to buy into somebody's walled garden.

As a result the sum total of smartness in my home is... A little STM32 Blue Pill that reports whether or not the basement door is locked or not. Yay?

Edit: oh and the raspberry pi that measures the moisture in the soil of my beloved Norfolk Island Spruce and tells me over IRC when it needs water.

I got into HomeAssistant in the early days, maybe around 2015. As such, I've stayed with the simpler installation method just make a hass venv and pip install homeassistant into it. This has mostly worked ok for years, and I've raised eyebrows as they've pushed more people to their linux distro, hoping they wouldn't stop supporting the basic installation method. I did finally have to install one docker thing to keep zwave working after support for the (legitimately bad) python-openzwave lib was deprecated.

> I too balked at the absurd complexity in the HomeAssistant stack

You can ditch their whole OS, management and orchestration/containerization stack, and just run it as a Python application in a virtualenv (they call it "Home Assistant Core"). I recommend it, it's much better than trying to keep up with their (mediocre, imo) distribution. Even if you don't want to manually setup a virtualenv, you can run it as a single container.

What kept me for the smart home train is the lack of need.

I am still trying to grasp what it would improve to my life

I was like that too, for a long time. But for me, it comes down convenience, rather than need.

Some examples: 1. I have a smart lock on the front door. Now when friends/family want to visit and I’m not around, I don’t need to hide a key that they then can lose. They just get a code that I can have expire when they leave. 2. I am constantly either too hot or too cold. Being able to change the thermostat from where I am means I don’t have to interrupt whatever I’m doing and walk across the house. 3. Same with lights. I can climb into bed, tell my phone “goodnight”, and it shuts off all lights and locks the door.

Again, nothing that is “necessary”, and sometimes I feel lazy because of it, but it results in fewer interruptions.

The one use case I use that I can’t really replicate without smart home, is being able to remotely toggle power. Smart outlets mean I can hard reset an unresponsive server, camera, or other device.

>I am still trying to grasp what it would improve to my life

I mean yeah, once the novelty wears off of having Siri turn off your lights to impress your boomer neighbours, or whatever, there seems to be no real "killer app" for home automation.

However there are a lot of small things I wouldn't mind having:

- The aforementioned "hey your tree is too dry" push notifications on my phone

- No need to get out of bed to check the downstairs deadbolt(s)

- Automatic and/or manually-controlled activation of garden bed hoses with some kind of zigbee solenoid valve or something

> Automatic and/or manually-controlled activation of garden bed hoses with some kind of zigbee solenoid valve or something

A basic smart plug does this for me. I hooked one up to a cheap solenoid that opens a valve when powered up.

It was very inexpensive and had been very reliable. It’s just on a TP-Link Kasa smart plug.

It’s also in HA so that if I forget to turn it off, it turns itself off after 10 mins.

Do you know which solenoid you used? I am not sure if our definitions of cheap are different, but I looked at this about a month ago and the options I found were fairly pricey, but would hopefully be more robust than the rainbird system I had go bust on me after three years.

I think it was the below - note this is in New Zealand dollars (half the value of US dollars).

https://www.bunnings.co.nz/k-rain-solenoid-valve_p3120237

Appreciate this! I did see some plastic ones around this price range, I guess it was just a bit more than I expected to pay. I noticed that this one just has leads- did you wire it into a plug yourself? Any concerns around doing that in a waterproof way?

I often find that "prototyping" these types of projects is fairly easy, but making them into a "product" that looks good and will be reliable is much much more difficult.

I found a transformer with bare wires that was the right voltage and wired it up.

It was from a local electronics store (Jaycar).

It’s in a dry area so getting wet isn’t an issue for me.

I think I could make it quite tidy and waterproof if I needed too - the lower voltage makes me comfortable with that.

It’s been in use for several years now and has been rock solid.

It's the small things.

1. My hallway lights come up at the correct intensity and light temp for the day every time there is motion. They also turn off at different speeds depending on the time of day. (at night, min brightness, yellow light, turn off after 30 seconds - someone is just waddling to the bathroom. in the day, full brightness, 6500K light, turn off after 5 mins)

2. I can control my AC remotely with my phone and it automatically manages itself depending on the price of the electricity (I'm on a hourly market-rate plan). If the price is low, it'll over-cool my house at night and cost for the morning.

3. Voice-controlled profiles for complex setups. Gaming = pull down the curtain on the window that shines on the TV, turn off a few lights that glare on it. Movies = all curtains down, all lights off. Even the one from the bedroom, because it shines to the couch in full darkness.

4. Smart switches that turn off lights that don't have a direct electrical connection.

5. A switch beside the door that turns off all lights and a few appliances in the kitchen that have no business being powered when I'm not at home.

> I am still trying to grasp what it would improve to my life

HomeAssistant does the following for me:

+ captures all the weather stuff into one page (internal + external sensors combined with "official" weather reports) + automates the little fan heater to warm up the bedroom pre-bedtime if required (also provides all the controls on a page) + captures the oven temp probes onto a page (means you don't have to walk into the kitchen to check)

I can do all these individually but that'd still be a "smart home", just more faff for me.

That's definitely the sound approach. But there tends to eventually be a few gadgets here and there that have clear benefits. Not the whole voice-controlled whole house lighting effect things that might be the typical showcases, but for example controlling two aircon units with different manufacturers in one place instead of having to use either to remotes or two apps. Because the smart tech tends to creep into peoples home whether they want it or not these days. Maybe the aircon comes without a remote (the app is the remote).

Most obviously then use the manufcturer's default setup which is each manufacturer having their own "smart" apps for their gadgets. What's worse is that each of them tend to think that their apps and products should be at the center of the stack, so each manufacturer of window blinds, air cons or routers have their own (terrible) closed version of Home Assistant. But nothing properly integrates everything and you are left with one app to control your AC and another for some lighting and a third for your garage door.

So when I use Home Assistant it's really because I want to use less smart tech. I want very few smart features but I want to use just one app for the smart features I do need, and I want to avoid using an app at all if I can help it. So I don't want to dig up and use 10 apps for gadgets around my house. I have zero interest in voice controlling anything. For example I want the lights to switch off when I leave (arm the alarm). I want anything that would be an alarm (Fridge too warm, smoke detector beeping) to also go off in my pocket. That peace of mind stuff. That's easy with HA.

I've been into home automation stuff for a while, and it certainly feels like this with a lot of products/services. Part of it is definitely just the feeling of living in the future.

That said some stuff is really nice, but typically require more than your average "smart home". In my mind I've made a distinction between "smart home" and "convoluted home" devices. A "convoluted home" device would be something like an app controlled light. The simple one-step process of flicking a switch is now a multi-step process of unlocking your phone, finding the app, and turning it off. Sure it has more features like changing the temperature or colour of the light, but it's not "smart".

The "smart" part of a system comes with interactions and logic between systems. An example that I have in my house is that my phone sends the time of the next alarm and an event whenever it is connected or disconnected from a charger. So half an hour before my alarm goes of the lights in the bedroom slowly dim up, waking me up gently. When the alarm rings it will turn on the rest of the lights in my house to full brightness and white light. Then in the evening, at a set time, the lights will start getting warmer, and then dim down helping me get sleepy before bedtime. And then when I connect my phone to my charger at night the lights in the whole house turns of. This is "smart". It means I barely if ever touch light switches any longer, don't have to remember to turn of lights at night, and that my natural day/night cycle works better.

With presence detection based on whether the phone is connected to the WiFi you could also turn lights off completely while I'm gone. With controllable ovens you could extend the system to turn down the heat to save power. The list goes on and on, but the thing which makes it all possible is not so much the "smart"-ness of the individual device, but the combined "smart" of all the interconnected systems.

Home automation provides lots of little advantages but it is hard to tell if it is worth the effort or cost.

My first home automation was smart switch for upstairs AC so could turn it on without going into the heat. The main motivator for Home Assistant was turning on porch light from outside. Now, I mostly turn on room lights from remote switch across the room; time saved is small but it adds up. It is also handy to control things with voice.

Home Assistant has enabled some automation and remote control. I have lights scheduled to turn on in evening when away. I have turned off lights from Uber on way to airport. Or turned on AC when house got super hot.

> I refuse to buy into somebody's walled garden

That's actually why I landed on Home Assistant. It's Open Source so I know that if things ever go bad someone will fork it and I won't have invested deeply in a dead-end ecosystem.

Getting started for me felt like the first time I learn a new board game. The rules seem incomprehensible and everything is unfamiliar, but that's the price of trying something new. Eventually the concepts started to click and I saw how things fit together.

I will say that telling my spouse to install an app with a web GUI was much easier than it would have been to get her on IRC to control the house.

> I too balked at the absurd complexity in the HomeAssistant stack

I did for the longest time, trying every alternative but I eventually embraced it. The modern docker container OS image runs perfectly fine on an old Raspberry Pi 2B and the modularized container architecture makes it easy to up/down grade parts of the system as needed. Add-Ons (e.g., Z-Wave, Zigbee, TP-Link, etc) are Docker Containers by default so they're easily maintained and upgraded by the core supervisor.

It is a lot of complexity that they have been progressively hiding behind a pleasant UI but it still has some rough edges. The complexity is due to the modular ability to support nearly every smart home feature out there.

> The biggest problem with HomeAssistant, however, is its really overengineered setup for running on mini computers like the Raspberry Pi, which was my goal.

False, i ran mine on rpi for 2 years now with many sensors. Zero issues and not even close to maxing out the pi.

> I have a strong aversion to Python due to its horrendous package management history (we use dozens of languages at work, guess which language is the only one that causes build issues all the time?). It’s a nice language, but for things like home automation, having build/dependencies problems is the absolute last thing I need.

Not sound reasoning imo, this is mangable if you know what you're doing. Clearly, HA doesnt have any problems related to this version management.

Agreed, package management is fine. Just make a home assistant virtual environment and you're done.

  python -m venv /opt/venvs/hass
  source /opt/venvs/hass/bin/activate
  pip install homeassistant

boom done.

Great, now tell me how to maintain it.

`pip install -U homeassistant` when there's a new version.

If pip was a good package manager, this would be the correct answer. Sadly, pip is crap.

Care to expand on that, or is that just the usual FUD about old versions of pip?

> Not sound reasoning imo, this is mangable if you know what you're doing.

I dunno; if the author is correct about this bit:

> The recommended way to run it is with a fleet of Docker containers (and they even tell you to install their own Linux distro to make sure all the large amounts of software you’ll need is managed more easily).

then, yeah, it's horribly over-engineered.

I tried finding docs to understand how to create a plugin to support a new protocol and didn't really find anything.

I also got turned off by the outright obstinacy of the support forum (example: https://community.home-assistant.io/t/mosquitto-broker-annou...)

Home assistant is not what I have in mind when I think "perfect for the job". It really is over-engineered, with (apparently) great plugin support, but very little in the way of docs.

It's really not that hard to run. I run mine on an Intel NUC by just running a docker container managed by systemd. It took me 2 min to set up, and 10 to configure.

This is the way to go. It’s absolutely solid and is part of my docker-compose.

And then you try to add an MQTT broker and learn you cannot install addons because you are on docker. Now you have to tinker on your own and add more docker containers.

Docker adds a high level of complexity for non-technical people.

If you're trying to mass market something (like Home Assistant) to non-technical people, containers are a dealbreaker.

OTOH, if you are selling something to technical people, containers are a feature.

You can do the same with EMQX or Mosquitto. I have both my broker and HA being started at boot by systemd.

> It's really not that hard to run. I run mine on an Intel NUC by just running a docker container managed by systemd. It took me 2 min to set up, and 10 to configure.

Are you perhaps being sarcastic? Maybe sarcastically pointing out how much of a pain in the rear it is to run Home Assistant?

The type of homeowner who wants home automation isn't going to learn what "NUC" means, what "Docker" means, what "Container" means, what "Systemd" means.

What you said is the equivalent of telling the average car driver "It's not really that hard to replace the timing belt on a Golf 1. I just removed alternator, timing cover, lined up the marks on the camshaft's sprocket and the crank pulley, and slid the new belt on with the square-keyed-adjustment tensioner that it came with. Took me 30m".

I find, as I get older, that I get more critical of complexity. I'm even more critical when it's in a field I am proficient in, because then I can see how much of that is simply complexity for complexities sake.

Brilliant juniors are most common source of this in my 20 years of software dev experience. The usual 'they were busy with how it could be done and didn't check if it actually should be done'. One of the worst things for creating long-term technical debt is to let such bright folks run free.

KISS principle above all, when you look at products from really long term perspective and treat people as replaceable (which they always are and all will eventually leave), absolutely nothing trumps that. Unless of course somebody plays politics and create some cathedral for them to maintain, and only them. Which is behavior that should be recognized early and 'punished' accordingly.

The thing is, you /don't/ need to know any of that that; it's all under the hood. Sure you can open it up, but the recommended setup of flashing HassOS to a drive & booting off it is really simple, you don't even need to know Docker etc are in the backgrounds unless you are heavily customizing or writing add-ons.

If they want something easy, they should stick to Google Nest/Apple Home.

HA is for DIYers, they should know a tiny bit of how systems work. Docker is really simple.

> first, it’s based on Python. I have a strong aversion to Python

Yeah, that's how we engineers feel - if it ain't my eavorite/elegant language, BYO... Program :)

> overengineered

Yeah, I also ran off of RPI4 for a few years, along with MQTT, Nextcloud (+SQL), photoprism, bitwarden and whatever needed for proxying via nginx. I only migrated to better hardware because I wanted to browse my pictures faster, photoprism solved that even on RPI, but I wanted faster indexing and offline face recognition where RPI turned out to have too little RAM.

On normal load, my RPI would still have room for other containers.

Having HA within a container was a feature - not too much to configure and everything is isolated, so I can still run other services from RPI. And easy upgrades.

> I have a strong aversion to Python

Me too, I like nothing about the language. Luckily, almost everything you do in HA besides contributing is not done in Python (by default).

But I love C#, so just in case there are others, I wanted to mention that you can write all kinds of automations in C# as well with NetDaemon [0]. Including full intellisense.

[0]: https://netdaemon.xyz/

Thanks for showing me this. As another C# dev I know what I'll be adding into my HA stack.. :)

It’s also a great community on discord, very helpful even for beginner questions.

Shameless plug, I wrote a Golang library for writing Home Assistant automations called gome-assistant [0]. The API looks sorta similar to this C# one, I only briefly glanced at netdaemon though.

[0]: https://github.com/saml-dev/gome-assistant

Not a GO-user, but something you might think about stealing from NetDaemon: It has typed entities, so instead of ".EntityIds("binary_sensor.front_door")" you can do something like ".Entities.Sensors.front_door".

It obviously requires a script to run after you add/remove any in HA, but IMO it really improves the DX.

The "framework effect" seems to be a thing these days, not only with SPAs using the newest JS framework.

When I stumbled across an HN article describing a CLI app for the OpenAI API, I thought that is just what I was waiting for. Unfortunately, when I tried it, it didn't work for me. After a debugging session, I found a bug in the openai python package which led to my key not being used if I have ~/.netrc exists. Pretty much a demonstration of the "framework effect". The simplest things, read CLI tools, become buggy in subtle ways because you inherit every bug deep down in the dependency chain. I ended up implementing my own OpenAI API CLI client in just a few lines of shell. Much easier to review, and almost impossible to have subtle hidden bugs.

https://github.com/mlang/openai-kiss

It's too bad that the author is getting dragged in these replies. They decided to avoid a dependency on docker among other things, and more power to them. The author could create a system that's stable for 20 years, with no updates. Docker will almost certainly force you to update, it probably even has to reach external servers and will brick past a certain point if you don't update it. I don't know for sure, but I wouldn't be suprised.

The author will almost certainly have less of their own maintenance to do since they are not beholdent to updates from dependencies than if they had gone with the more "well-supported" solution.

As long as they document it properly, it could work well for decades. Probably for longer than home assistant will be supported.

> I have a strong aversion to Python

I have had a great experience with HA (unlike with OpenHAB which is a Java-based monstrosity with a data schema that is near impossible to figure out).

It's unfortunate that he went and rewrote an entire home management stack just because he dislikes Python.

Even worse, the justification for disliking Python, namely:

> It’s a nice language, but for things like home automation, having build/dependencies problems is the absolute last thing I need.

is absolutely not a problem if you run HA on a tiny dedicated box, because all of that stuff is completely handled (and hidden) by the HA update system.

> The biggest problem with HomeAssistant, however, is its really over-engineered setup for running on mini computers like the Raspberry Pi, which was my goal.

It may feel over-engineered if you look under HA's skirts (the fleet of docker containers thing), but turns out you almost never need to go deep into HA to get it to do things, and when you actually do, HA is actually pretty open and easy to work with. (just ssh to port 22222 if you really need access to the bare metal system).

I would agree that the HA setup is a bit unusual for someone used to just ssh into a linux server: I had the same initial reaction. But turns out it's actually never much of a problem. It's just different.

Also, it may look heavy, but it runs absolutely fine on a small raspi-like computer.

> Is the best solution we can come up with a bunch of Docker containers running on a custom Linux distro?

Why not? It may "feel" big and complicated, but in practice:

    - it's very well packaged
    - it's very well maintained
    - it has support for a *ton* of home automation devices
    - it runs out of the box on a tiny and cheap SBC (a raspi) without overloading it

All you have to do is dedicate a raspi to the problem and be done with it, not really a big problem.

And if you really want to run it on a Linux server that is used for other things, and the HA architecture irks you the wrong way: just wrap HA in a native qemu VM and run it on your server along your other stuff.

The author's attitude reminds me of one of the best software articles ever, "Cash Cow in the Tar Pit" (https://www.computer.org/csdl/magazine/so/1996/03/s3041/13rR...).

The reason a "legacy" system seems so clunky and over-engineered and hard to modify and has so much corner case handling is: real-world experience and bug-fixes. When you throw that old cow in the tar pit and start developing your shiny new application, you throw all those years of hard-earned experience away with it. By the time your application works as well as the old one, it will be just as ugly.

FWIW, I have been running HA in a qemu VM on a NUC for years, and it is one of the most stable pieces of software I use. It supports every device I can throw at it, and the automations, while clunky, are easy to manage, as long as you keep KISS in mind.

I love what author did and I'd probably do the same, I guess I'll replicate author path. It all depends on requirements, but I also dislike python, I want to do something in python (and I've started something but a bit against main trends), but packages and recent step to get rid of signatures is a big no from my side. Too many news here and there about "enriched" versions of packages regarding python - and I know other tech stacks have it too, but looks like they have it less. I would not see it as problem if HA had dependencies statically linked, which in python terms would mean just copied fixed versions into HA repo.

Anyway what is wrong with HA/OpenHAB? It's too "enterprise" or rather too rich and therefore seems heavy to run - VM with at least 2GB of RAM? No, thanks.

What requirements I have for smart home:

- made for tinkering people - preferable approach as in open-hardware initiatives where one electric motor can be used either for water pump engine or spinning table saw, so you can use it with things you already have and you have some indications about how to connect it all together in various cases

- something designed for the cheapest hardware (nowadays rpi comes quite cheap though but it is not truly open and there are availability issues)

- something doing only what is necessary and not cloud-first

- option for build time removal of unused features

- no need for hot loaded plugins

- build based on tools with long term compatibility in mind (again, sorry custom extensions for each new language in the world)

- real time system or at least good separation of control vs deployment/etc

- designed as optional extension to existing world with switch-off mechanism

- no need for vast ecosystem as long as it is based on freely available standards

- nice to have feature is to provide scripting scenarios, can be deployed independently from main control board

- should be cross-platform on native level, so in the end going to C, no heavy vms or interpreters, nice to have runnable on bare metal

- things like reports presentation should be done not in the hardware which has actuators, data should be kept in another piece of hardware e.g. PC

You don’t need a real-time OS.

At some point you want your home automation system to do things for you. If you're maintaining your own fragile custom infrastructure you're spending more time on it than it saves you by automating stuff.

Sure it's fun and it's a great learning experience, but don't try to make it look like a better solution than a popular, proven, tested and maintained one like Home Assistant.

I built my own smart home set up before Alexa et al came along and later switched to Alexa because my wife and, later kids, took priority. My experiences with commercial smart home solutions is that they require just as much babysitting as anything you build yourself. The only real benefit of commercial solutions is that my wife isn’t afraid to add plugs et al to the smart home infrastructure whereas before it would be entirely down to me. But the cost I pay for that convenience is reduced privacy and potentially insecure hardware connected via WiFi.

Honestly, if I was building something out again, I would totally optimise the set up for privacy and security rather than convenience of having a spouse connect new devices.

Building something specialized for only yourself might be faster then bending existing solutions to fit your requirements. And if you do something more advanced it will likely also be cheaper to build it yourself then buying the solution. And the knowledge you gain will be invaluable.

Obligatory XKCD: https://xkcd.com/1319/

Also: in some cases it really is faster just to make your own rather than learn the Home Assistant Way Of Doing Things.

There is always that one cronjob to bugfix, web server to restart, port being brute forced by some bots...

Anyone embarking on a home automation journey. Think very carefully how the non-technical people in your life will cope if you aren’t around - what do they do when things don’t work?

In addition to when they don't work. What about when the company stops supporting them or just goes under? The industry never seemed to build long term trust whenever I looked into it.

My acquaintances bought a house from debt closure with a monitoring system. Now they have a one room with idle servers. I'm afraid to visit because they'll ask to "install windows" on every one.

People probably forget that IoT devices can be pretty expensive to yank out again. I would want to move into a home full of IoT devices configured by someone else, how do you even ensure that everything is reset and disconnected correctly.

There was an episode of the Coder Radion podcast a few years back, one of the hosts had moved into an apartment with a few smart home features, it took him forever to reset and reconfigured. He described it as "living in a haunted house".

Agreed. Switches for everything. Should work like you expect. Any automation/control should be optional invisible benefits.

Problem is not with smart home software, but hardware.

Ok, we now have "smart" lightbulbs. And even thermostats. Great stuff! I think, it is possible to have "smart" curtains.

But I have simple example: now I'm living in country, when price for electricity changes every hour. I can extract this price programmatically without problems.

Suppose, I want to wash my clothes when electricity is the cheapest, but no longer than 24 hours. No problem, algorithm is simple: calculate average price over, say, week (possible), look at state of washing machine, and if machine is prepared and ready (power-on, standby, program selected, door closed) and price is small enough (or there is a 23 hours passed from washing machine readiness), give machine command to start.

I can imagine (and implement) Very smart algorithm when to start washing.

But it needs washing machine, which can be polled for status and started remotely (but prepared locally, as software doesn't know did you want to wash color, white or black clothes, for example).

Is here any such machine on the market? Nope...

Same with microwaves, dishwashers, stoves, anything.

TBH, here are washing machines with WiFi. With proprietary, mobile-only, cloud-only applications. Maybe, it is possible to hack these protocols. Maybe. Maybe, cloud will be up and running in 10 years (typical age of washing machine in my life, after which it requires replacement due to failure of one of the main aggregates). Maybe. And, maybe, you country will not block this cloud and cloud will not block you country. Maybe.

So much for smart home.

My "HA" setup is really driven by Zigbee2MQTT -- most of my lights, devices (light switches, washer, dryer) and sensors (temperature, motion, doors/windows, water leaks) are all random Zigbee devices that Zigbee2MQTT does a wonderful job talking to, without any need for vendor software or services.

https://www.zigbee2mqtt.io/

I happen to use Node-RED for automation -- this is the easiest part to replace, it could just as well be Mako, pyscript, AppDaemon, NetDaemon, or plain Python scripts talking to the MQTT server.

What I can't easily replace from HA is the nice UI, both over the web and as an app (same thing really). I guess Mako makes it possible to hack together a web interface, but it's a lot of work for a poor result when compared to what you get with HA (or OpenHab) out of the box.

I would love to find a simpler, MQTT driven "HMI" app for both web and mobile, completely disconnected from the logic behind.

I have a small ruby app running on my home server that keeps the zigbee2mqtt stream open, its fairly simple but provides the main functionality of the smarts in my home. If I get a new device I just hack my own bridge and link it in.

My point is a smart home doesn't have to be complex and can be fun to do yourself.

zigbee2mqtt has its own webUI with a dashboard that seems fairly competent at controlling the devices.

https://www.zigbee2mqtt.io/guide/configuration/frontend.html

The Zigbee2MQTT web UI might be useful for debugging, but a mixed list is hardly a good way of interacting with home devices.

Home assistant is too involved to set up… Proceeds to code a basic display that will need endless support.

Home assistant can run on a pi and is actually decently lightweight. Just because behind the scenes it uses containers doesn’t make it complex and difficult to maintain.

My home assistant hasn’t needed and babysitting and is my least involved support project. Upgrades are stable and one-click and you can use as little or as much of its functionality as you want without the sacrifice for performance.

My thoughts exactly.

Can echo this too, I was afraid my smart home would become a fulltime job. Home assistant has been one of the least problematic thing to support when doing upgrades.

It's a great project.

> Home assistant can run on a pi and is actually decently lightweight.

I've been running Home Assistant on a Raspberry Pi 2B for years with no complaints.

It takes about 7 minutes to compile the firmware for a single ESPHome device which is a long time but it's hands off so it has no impact on me.

All smart home is great to you and you family until author maintain it. What happend when you have to leave for a month or for some reason unable to maintaint it ?

My experience is that beyond some stack complexity level simple power outage render open source solutions to the point my intervention was required. Additionally this software is full of bugs due to how it is developed.

I had situation when I was on a business trip and one of my hall light went strobe mode :) Turns out there was a bug and race condition was triggered because someone activate PIR sensor the same micosecond previous action was turning light off (NodeRed)

Wife went crazy, called me to turn this madness off :)

Home is smart when users can handle it without you in any daily scenarios. Otherwise it is just our fun/hobby not real solid solution :)

Thank you for sharing your experience, without any personal experience I always thought that the issue with these is essentially that of "maintenance", in a ideal/perfect setup, there should be something like a by-pass switch to allow manual operation of the lights/devices, but I don't think this is possible at all without modifying heavily the electric circuitry of the house.

Manual fallback is must have. Unfortunatelly not all solutions are design that way. It is my No. 1 option I check.

That's really what keeps me off smart homes in general, I don't want to fiddle with it. I do see some of the value, but mostly I don't see it as proving enough benefits to justify that added complexity. My dad likes to dabble with smart home devices, and some of it is really good, and some is just junk. For three months he could adjust heating, because a server in Norway was down, and apparently not monitored.

I recently bought a new house, and while a lot of modernization is required, I'll still be excluding all IoT and smart home devices/features, and I've given up on wireless for most things as well, there will be a plethora of ethernet jacks.

Heh, skimming over the comments it looks like no one has the same setup I settled on: Home Assistant as just a simple API.

Home Assistant was pretty simple to install and connect to devices (I'm currently all Z-Wave), but I didn't really care for its built-in rules. But it provides a REST API to interact with everything connected to it, instead of having to fiddle with configuration files.

So I have one system that makes sure the remote Home Assistant process is running, that provides a simplified API for everything else (mapping simple labels to the Home Assistant Z-Wave identifiers and handling the REST request for me), and a second one for actually controlling it with whatever rules I came up with.

I've found it to be pretty stable overall.

I’m kind of surprised that all of the top comments on this are some variation of, “it would be easier to just use Home Assistant”. I would understand that reaction on a site called “Sensible Smart Home Consumer News”, but hackers build software and you’d expect Hacker News to have some respect for that. I’m not saying writing your own software is always the most cost and time effective solution, and I would push back against it in a work setting if it was inappropriate, but from a hacker ethos perspective, writing your own smart home software for your own house is cool and deserving of respect rather than denigration.

Very nice reply, totally true.

the current state of all smart home drives me mad. Why does my thermostat have to reach out to a cloud service to change the temperature?

Why does any of it operate on remote cloud API calls when it could operate locally?

> Why does any of it operate on remote cloud API calls when it could operate locally?

Vendor lock-in, and gives them the ability in the future to hold your devices hostage by requiring you to pay a subscription fee.

Various IoT platforms, eg Tyua (which gets rebranded a lot), sell a complete package that is totally cloud oriented. Configure the product behavior online, click order, purchase 10000 controller chips preflashed with firmware implementing said behavior, integrate with devices, slap logo on it, sell.

Also, maybe the developers of these products only know how to write cloud enabled software? (slightly joking)

Apart from the not-at-all-paranoid answer of "money", it's probably just easier for them to program - if you're going to have (honestly, required for 99% of users) integrations with cloud services like alexa, google, homekit, HA etc. where you need to provide an end-point, it's just easier to make your own app talk to the same end-point. Which is money too, I suppose.

Because adding brains and storage to hardware is expensive. And putting simple things on customer prem means less things can go horribly wrong.

And people actually like controlling their hardware from out-of-the-home, which makes doing everything locally even more complicated.

When you start trying to present end-users with a graph of whatever metric you want, you run into issues with storage, response time, CPU usage, storage, the web front-end, storage, etc. Then you have issues updating all that.

And if you want to do something like, say, comparing and benchmarking against other users you can't.

Really, only technical people care about this kind of stuff, and they can go ahead and write their own or use HA.

> Because adding brains and storage to hardware is expensive.

I disagree with this; it's expensive if you need the device to support Python or C# or similar. A $5 esp32 chip has enough storage and RAM to both act as a controller for hundreds of devices, AND run a minimal webserver to provide an interface for the user to automate those devices.

> And people actually like controlling their hardware from out-of-the-home, which makes doing everything locally even more complicated.

I second this: people who want home automation also want the ability to control it from their cellphone anywhere in the world. Unless they are technically proficient enough to setup their own public-facing server that is on 24x7, the customer is almost always going to prefer the device that is connected to a proprietary vendor's cloud.

I just moved over to HA and so far nothing including presence detection is cloud dependent (35 zigbee devices dozen or so wifi flashed to esphome)

It’s been pretty amazing tbh

Cloud based smart home offerings must be avoided at all cost. A home shouldn't be dependent on the Internet working, or a subscription fee being paid to whoever provides the service. There's zero reason for introducing that dependency, except as a business strategy to extract as much money as possible.

Integration with GoogleHome/Alexa/etc doesn't require cloud, they're running inside your home and can easily hit the device directly (wifi devices) or via the controller (which can "forward" the commands to the devices on the local network or the zigbee/zwave net).

It doesn't help when vendors drop like flies and stop supporting your devices or just completely shut off the cloud server.

> Why does any of it operate on remote cloud API calls when it could operate locally?

How else your thermostat manufacturer going to implement vendor lock-in? /s

Because surveillance and lock-in are profitable.

If looking for lightweight solution with zigbee (usb dongle) one can also take a look at Zigbee2MQTT [0]. This library is used by HomeAssistant under the hood, but it can be used independently as a standalone app and let one interact with zigbee devices using MQTT json messages. And it supports a lot of devices : "Currently 2971 devices are supported from 379 different vendors"

[0] https://www.zigbee2mqtt.io

I think HA is using ZHA under the hood for Zigbee communications.

It can use both. ZHA is included in base HA. Z2M is an optional addon. Z2M has better support for obscure devices in my experience. I Also strongly prefer the management interface in z2m.

My mistake, zigbee2mqtt is one off third party options to add zigbee to HA. But still, quite nice project.

Yep, Z2M seems to be very reliable way to handle zigbee devices. Also it feels little more vendor-lock free (considering HA as vendor here).

Interesting piece. My home automation solution is based on Homebridge, zigbee2mqtt and just enough Node-RED for charting and doing a bit of glue (virtual devices, custom integrations, etc.) and I’m very happy with it, but I was looking at Mako server the other day.

I found it refreshing, but the licensing is just weird — parts of it mention that the web content hosted by the server is also covered by it, and I’m not sure if that is a tenable approach.

I tried Home Assistant multiple times, always went back to Domoticz. It allows simple, but quite powerful scripting though actual lua instead of overcomplicated, weird YAML files, eats significantly less resources, and is rock solid.

Some tasks HA knows is rather complicated to execute in Domoticz, but definitely doable.

There is mosquitto for MQTT and Zigbee2MQTT on the same node, the whole consumption is < 300MB.

This is the first "smart home" thing that actually seems interesting to me.

It's still kinda nuts how much arcane bureaucracy is needed simply to make two computers in the same room talk to each other, and nobody else. Why can't I just control the brightness of my living room lights as easily as my laptop backlight, without the packets taking a detour through Langley?

The amount of skeptical people in this thread is astonishing, it is natural to questions pile of complexity even if it is well established. In an unlikely event it goes south, author will have much easier time debugging his simple setup then waiting for reply from a home assistant forum (even though they are lovely people and nothing against HA).

I started with a similar path a few years ago - IKEA smart home gear. The controller went away fairly quickly. I stayed for a long time on raspberry pi + Zigbee stick from DeConz + Apple home integration using homebridge.io.

Deconz felt a bit bloated/buggy, so I switched to using a cheap USB stick from aliexpress, and using zigbee2mqtt, which turned out to be a pretty good combination.

Unfortunately Apple decided (while I was on a business trip) that Apple TV 3 was no longer good enough as a home hub, so all of my soft switches stopped working...

As a result in a couple of days I wrote a quick MVP replacement in Rust, which has been working very nice for me, and the "user" (significant other) feedback was that it is now much more reliable and responsive.

Putting it here in case anyone finds it useful.

https://github.com/ayourtch/homegui

I can understand why people do this.

After having tried out various offerings written in Python, PHP, Node and whatnot I'm tired of things that almost work. That is, they work well enough to convince me to try them, but not well enough for making me want to continue running them.

Regarding home assistant:

> Is the best solution we can come up with a bunch of Docker containers running on a custom Linux distro?

It's really not that bad when you consider that HassOS has an updater. You don't need to reason about any sort of docker config if you don't want to. A lot of users have no idea what docker is and still get by. It's pretty appliance-like. Additionally, I run hassos in a VM, and that takes away even more of the 'managing a linux distro' aspect.

A few years in I did want the control to manage a docker container myself for frigate. I keep that alongside the hassos VM and no issues. So you can even mix and match if you like.

I've thought about it. My automation needs are straightforward, and occasionally Home Assistant ships an update that makes me work to get things back up and running. A few weeks ago it caused my zigbee configuration to completely lose all devices any time HA restarted. That was aggravating, having to go around to each one and relearn them, only to see them forgotten again. Ended up rolling back, and then pinned the version at the previous release. No more problems, and I probably won't enable updates again. I need it to just work.

My take is to use https://www.zigbee2mqtt.io - having a queue makes it very simple to add/test automations.

My base stack is comparable. I have all sorts of Zigbee devices on an RPI + RaspBee, and Shelly devices behind my wall switches. However, I use Node-RED on top of that. Many things are available as plugin (MQTT, Deconz, daylight, database, web UI, etc) It contains some custom script-nodes, to achieve a 'state' in between inputs and outputs. Now I can just add and change stuff by clicking around in Node-RED.

To me it's a nice combo of 'off the shelf' and maintaining full flexibility.

Just like I try to avoid self-hosting monitoring and devops stuff, I wouldn’t feel comfortable relying on something I have to maintain for home automation.

Unless you don’t care if one day your self written home automation system stops working, and if you don’t happen to be in the mood then it will remain broken for months/forever.

Mako looks like a nifty piece of tech on the other hand. I wish there was some sort of similar application server for JS (deno comes close but Mako looks much more complete)

> The biggest problem with HomeAssistant, however, is its really overengineered setup for running on mini computers like the Raspberry Pi, which was my goal.

Some might call it overengineered, but it works great. Flash an SD card with Home Assistant, pop it in and you'll be ready to go with minimal configuration. I've had HA running on an RPi4 for years with very few issues.

Considered building my own too but then sanity prevailed and realized that the development effort and device support that has been put into HA/ESPHome is not something worth duplicating.

Still very tempted to write my own presence detection code though since that’s a little fuzzy and case specific. That would still use HA for the heavy lifting on sensor inputs etc

esp8266 and esp32 boards from ali plus various parts. Flashed with tasmota or (for the glow electricity meter reader esphome). Temp & humidity sensors, somfy blind controllers, ws2812 strips, relay to infra-red to control hifi receivers.

Athom plugs pre-flashed with tasmota to measure power point usage and switch on and off. Athom bulbs pre-flashed with tasmota.

Homeassistant works great. Toss in wireguard for remote access with smartphones.

It's good fun. It's cheap. It's cloudless. It's better than anything you can buy. Go the DIY! You do tinker a bit, if you hate that aspect of DIY then maybe pass on smarthome stuff. Parts probably paid for themselves in reduced electricity consumption. Once you measure something, behaviour changes etc.

I run Homeassitant on a 12 y.o. laptop that also runs mosquitto, has some usb disks plugged into it, runs samba, pi-hole, owntone, wireguard, timecapsule etc.

Home assistatant works pretty well and easily, imho.

How are you doing it?

If I put smart stuff into my home — color bulbs, switches, sensors — then I’d probably be changing about 40 bulbs and 40 switches. Throw in the HVAC and some other things and we can round it up to 64 different inputs and outputs.

That’s equivalent to half a keyboard and an 8x8 pixel screen. I couldn’t agree more with this article.

Every time I think of home automation I almost go for it, but upon second thought I realize this means adding an entire tech stack that I will have to maintain to what's basically a couple of switches. Having my windows, lights or thermostat break on updates is something I don't need.

To provide another point of view, I've had a simple light & fan connected to Google Home for the last couple of years. Since connecting it to Google from their own app's I've not needed to go back / update them since.

I‘m wondering that no one mentions fhem. I’m completely satisfied with running it joining self-built, Homematic IP, HUE, Max!, Shellie’s and SaaS stuff with Echo integration. But besides that good job writing something in this size on your own! Hopefully you‘re able to maintain it!

Maybe I missed it, but what is so great about a smart home? Seems like a burglar alarm would be more interesting.

Nice that you should say that :) I also wrote a home automation system.

Well... actually, it's a kinda burglar alarm except it's focus is alerting way ahead of actually getting inside. I added home automation bits (minimal) just so one can elicit a real world response, but I do use it for minimal home automation (Lights, heating control and letting the chickens in and out).

I have yet to announce on on hacker news and so because I still have to write a bunch of documentation. It uses the latest state of the art computer vision triggering, currently yolov7 and I'm about to release support for yolov6. It's multimodel, so you can double check it's result with more than one model, even for specific parts of an image.

The architecture diagam and installation instructions are here:

https://github.com/hcfman/sbts-install

I actually, started writing this in 2008 and most of the current state in terms of the user interface were finished in 2012 but I only released it into open source last year really. In 2019 I add support for yolov3 and have been adding models even since.

It's written in Java and installs in just two commands on nvidia jetsons at the moment (Not in containers). The inference framework is a simple websocket based wrapper around other models so it's easy to add new models and that's written in python.

Well I finish the new release to introduce yolov6 and support for the seeed studios platforms I'll make an announcement on hacker news, note I still have a lot of work to do on documentation.

Oh, one or two more details pertainent to some of the comments above.

It has a builtin GUI around a certificate manager, so you can generate, import and use TLS inside your intranet between devices.

It doesn't use a domain specific language, rather just a simple web gui around a state machine. IMHO you can't pretty much do what you need with a state machine and anything that can't be done like this can be handled easily via the generic rest interface and if you need notifications it supports web socket based notifying of events. This make's it easy to add new rules on the fly from your phone if you want.

It make's it easy to add new pages of buttons to control the state from your phone and generates nice video alerts with multi-camera views of the trigger event.

And it's totally undiscovered. You can be the first early adopters! :)

Nice! That fog machine is great. Guess it's time to get a jetson.

I've always been fascinated by the dissonance between what some people insist they need from an off the shelf system (bulletproof with a dedicated security team because Security is Hard, rock solid reliability because I depend on it 24/7) and what they will accept in a DIY solution (completely unsecured un-audited software with no tests and something broken every other day).

I chose to do everything in node-red + mqtt and it’s been fun.

It's UI is very much "programmer art".

I did similar stuff with Python and asyncio.

Coincidentally, I spent this past weekend looking into this.

This space is ripe for a well-funded new entrant to step in, create a decent protocol for home automation and make a killing.

The options in this space are awful, with no clear indication of security, competing "standards" that don't cover even the basics of an appliance-like device, and cloud-lockin for almost everything!

Nothing is aimed at the average homeowner (No - writing in Python or Lua is not how people want to automate their home).

Lets talk about the media-level protocols: WiFi in homes is ubiquitious and cheap, things like Zigbee or LoRa raises the cost and the effort for HA, local RF isn't widely supported by devices (with good reason). How does a homeowner know what to go with?

Let's talk about bootstrapping a new device on the HA network: device discovery!

Some devices require an internet connection and the homeowner has to have an account on the cloud (Adafruit IO, various proprietary vendors). Some use a fixed mDNS name (Shelly), some require to download the vendors app (used to set network config, credentials, etc), most simply don't do it at all. I even found one or two that require the owner to browse to a particular local IP, because the device starts off in AP mode.

Okay, lets say you jumped through the hoops (registered an account on a cloud service, gave the device internet access, used its AP to set it up, or it set itself up doing mDNS query for _mqtt._tcp.local, or whatever).

Next problem: authentication of the device on the network. Some devices just don't support it, some support it using AES with pre-shared keys, some support it with basic HTTP auth over TLS, some use mqtt with TLS, some offer mqtt, but in plaintext only, with encryption being over HTTPS (reverses the pub/sub model horrifically), many support x509 certs loaded onto the device (the worst option for an appliance!), some (using CoIoT) have support for DTLS (But need a valid x509 cert) ...

Problems aren't over yet. So, you go with something ... and then find out that your controller is not compatible with one device. Maybe you need a Zigbee bridge because everything else is WiFi. Maybe that device requires x509 cert over WiFi, while everything else is using auth credentials. Maybe it's hardwired to use vendor's cloud and the rest of your network is using Home Assistant. Maybe it's using ESPHome and everything else is using CoIoT.

That's fine, you think, I'll just use Home Assistant, which has integrations for everything on the planet, to "bridge" the different protocols. But now you're stuck with Home Assistant as a controller, which has limited automation facilities.

Honestly, what homeowners want is to buy a device and plug it in, and have a nice interface for devices which allow the homeowner to specify what happens on any event.

That's it. No messing about with Python, Containers, Lua, mDNS sniffers, accounts on public internet clouds, renewing x509 certificates, etc.

Plug it in, use username+password to access the Home Automation network, that's it.

From a technical PoV, I can see a mechanism to get it done this way.

That's what Matter is supposed to do, and why all of the various smart home vendors seem to be jumping aboard.

To your point of "stuck with HA as a controller" that's not entirely true, if you're an Apple household, install the HomeKit bridge and expose things to homekit where you can automate to your hearts content.

I did rich-people home automation as job for a couple years, like 7 years ago though. It's all broken. It sucks.

There's no good graphical programming thing in existence. The A/V or HA people are not the people that are going to invent it.

You're making it way too complicated on yourself somehow. You just go to Home Depot or Lowes or whatever, buy a device, plug it in, create an account in the whatever and connect it to your Siri/Alexa/Google. There's no Lua or Python in sight. No Raspberry pi home servers either. If you want to make it hard on yourself you can, but why would you?

Home Assistant is fine, and means a less technical customer doesn't deal with and of that nonsense you're talking about. I'm sure there's things you can't do with it and for that you would need to be a programmer but if you just want to say"hey Google I'm taking a shower", and have it set the lights in your bathroom, and turn on the heater, or have it switch the lights to warm at sunset, or an hour before, that's totally possible.

Reply on news.ycombinator.com