[HN Gopher] I wrote my own smart home software
___________________________________________________________________
I wrote my own smart home software
Author : thunderbong
Score : 289 points
Date : 2023-06-05 02:48 UTC (20 hours ago)
(HTM) web link (renato.athaydes.com)
(TXT) w3m dump (renato.athaydes.com)
| nvy wrote:
| 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.
| acidburnNSA wrote:
| 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.
| cptskippy wrote:
| > 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.
| georgehotelling wrote:
| > 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.
| prmoustache wrote:
| 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
| ianburrell wrote:
| 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.
| PMunch wrote:
| 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.
| LeafItAlone wrote:
| 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.
| nvy wrote:
| >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
| lostlogin wrote:
| > 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.
| kevstev wrote:
| 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.
| lostlogin wrote:
| 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
| theshrike79 wrote:
| 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.
| zimpenfish wrote:
| > 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.
| alkonaut wrote:
| 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.
| Denvercoder9 wrote:
| > 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.
| [deleted]
| harry8 wrote:
| 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?
| philwelch wrote:
| 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.
| michaelmior wrote:
| > 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.
| ay wrote:
| 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
| asveikau wrote:
| 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.
| jollyllama wrote:
| 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.
| omneity wrote:
| 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)
| aulin wrote:
| 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.
| hnlmorg wrote:
| 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.
| z3t4 wrote:
| 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.
| theshrike79 wrote:
| 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.
| expertentipp wrote:
| There is always that one cronjob to bugfix, web server to
| restart, port being brute forced by some bots...
| icoder wrote:
| 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.
| Izkata wrote:
| 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.
| xmdx wrote:
| 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.
| varjag wrote:
| 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.
| jaywalk wrote:
| 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.
| kkielhofner wrote:
| 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.
| bluGill wrote:
| 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.
| bombcar wrote:
| 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.
| jackson1442 wrote:
| 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.
| bombcar wrote:
| 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.
| robertlagrant wrote:
| > 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.
| bluGill wrote:
| 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)
| formerly_proven wrote:
| 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.
| silversmith wrote:
| 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.
| alex3305 wrote:
| > 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.
| mankyd wrote:
| 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.
| jabroni_salad wrote:
| 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.
| MrDunham wrote:
| 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
| alex3305 wrote:
| 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.
| florbo wrote:
| > 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.
| alex3305 wrote:
| > 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...
| xmdx wrote:
| 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
| neurostimulant wrote:
| 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?
| soco wrote:
| 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.
| bluGill wrote:
| 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.
| bombcar wrote:
| 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.
| Tyr42 wrote:
| Ffff my Zigbee2Mqtt is not working for the last month very
| well at all. I need to dig into this again
| neurostimulant wrote:
| Do you still need Zigbee2Mqtt now that Home Assistant
| already have built-in Zigbee integration [1]?
|
| [1] https://www.home-assistant.io/integrations/zha
| rubenbe wrote:
| 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
| alex3305 wrote:
| 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.
| cptskippy wrote:
| 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.
| goodpoint wrote:
| > That and the other recommended way of setup that wasn't
| mentioned is to install the OS without messing with any
| containers
|
| No way.
| rootusrootus wrote:
| 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.
| tga wrote:
| 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.
| herbst wrote:
| 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.
| ep1cman wrote:
| zigbee2mqtt has its own webUI with a dashboard that seems
| fairly competent at controlling the devices.
|
| https://www.zigbee2mqtt.io/guide/configuration/frontend.html
| andiareso wrote:
| 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.
| noidesto wrote:
| My thoughts exactly.
| cptskippy wrote:
| > 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.
| CommanderData wrote:
| 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.
| blacklion wrote:
| 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.
| blacklion wrote:
| 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.
| 0xdeadbeefbabe wrote:
| Maybe I missed it, but what is so great about a smart home? Seems
| like a burglar alarm would be more interesting.
| gorgoiler wrote:
| 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.
| pmlnr wrote:
| 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.
| iamflimflam1 wrote:
| 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?
| expertentipp wrote:
| 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.
| mrweasel wrote:
| 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".
| scosman wrote:
| Agreed. Switches for everything. Should work like you expect.
| Any automation/control should be optional invisible benefits.
| explorer83 wrote:
| 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.
| _dain_ wrote:
| 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?
| Semaphor wrote:
| > 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/
| tmyllymaki wrote:
| Thanks for showing me this. As another C# dev I know what I'll
| be adding into my HA stack.. :)
| Semaphor wrote:
| It's also a great community on discord, very helpful even for
| beginner questions.
| samldev wrote:
| 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
| sigmonsays wrote:
| 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?
| ianmcgowan wrote:
| 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.
| manv1 wrote:
| 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.
| lelanthran wrote:
| > 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.
| [deleted]
| goodpoint wrote:
| Because surveillance and lock-in are profitable.
| katbyte wrote:
| 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
| adamzegelin wrote:
| > 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)
| brabel wrote:
| 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).
| ThatMedicIsASpy wrote:
| It doesn't help when vendors drop like flies and stop
| supporting your devices or just completely shut off the cloud
| server.
| ur-whale wrote:
| > 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
| rkwasny wrote:
| My take is to use https://www.zigbee2mqtt.io - having a queue
| makes it very simple to add/test automations.
| lelanthran wrote:
| 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.
| lacrosse_tannin wrote:
| 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.
| philjohn wrote:
| 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.
| ErneX wrote:
| I chose to do everything in node-red + mqtt and it's been fun.
| bborud wrote:
| 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.
| ur-whale wrote:
| > 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.
| waterCalendar wrote:
| 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
| jdiez17 wrote:
| You don't need a real-time OS.
| deepspace wrote:
| 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.
| antigravity42 wrote:
| 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).
| PaulHoule wrote:
| I did similar stuff with Python and asyncio.
| shannongreen wrote:
| 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).
| nevi-me wrote:
| 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.
| theshrike79 wrote:
| 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.
| katbyte wrote:
| 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)
| dingledork69 wrote:
| 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.
| Denvercoder9 wrote:
| There's also NetDaemon for those who prefer C#:
| https://netdaemon.xyz/
| Larrikin wrote:
| 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.
| mrmlz wrote:
| 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..
| dingledork69 wrote:
| 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.
| Larrikin wrote:
| 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.
| dingledork69 wrote:
| 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...
| Larrikin wrote:
| 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.
| OJFord wrote:
| 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?
| dingledork69 wrote:
| > 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.
| OJFord wrote:
| Awesome, thanks, this may be the push I needed back into
| HomeAssistant. :)
| piceas wrote:
| 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.
| lloydatkinson wrote:
| That's cool - I've done something very similar and used the
| Worker Service project type along with Quartz .NET for
| scheduling.
| toast0 wrote:
| 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.
| OJFord wrote:
| 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).
| bpa77 wrote:
| 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.
| lynx23 wrote:
| 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
| rcarmo wrote:
| 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.
| sp0ck wrote:
| 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 :)
| jaclaz wrote:
| 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.
| sp0ck wrote:
| Manual fallback is must have. Unfortunatelly not all
| solutions are design that way. It is my No. 1 option I check.
| mrweasel wrote:
| 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.
| lloydatkinson wrote:
| It's UI is very much "programmer art".
| daill wrote:
| 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!
| 01100011 wrote:
| 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.
| dkarl wrote:
| > 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?
| katbyte wrote:
| 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.
| andiareso wrote:
| 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.
| dkarl wrote:
| My experience was more than five years ago, so if I get the
| itch again, I'll take another look.
| inferiorhuman wrote:
| 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.
| matt_s wrote:
| 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.
| plagiarist wrote:
| 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.
| sgt wrote:
| 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
| dividedbyzero wrote:
| 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.
| sgt wrote:
| 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.
| dividedbyzero wrote:
| 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.
| bussyfumes wrote:
| 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.
| bouke wrote:
| 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).
| bussyfumes wrote:
| 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.
| bouke wrote:
| 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.
| grvdrm wrote:
| +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.
| throwaway346434 wrote:
| 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
| mrj wrote:
| 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.
| aulin wrote:
| 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.
| 01100011 wrote:
| 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.
| perrylaj wrote:
| 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.
| mleo wrote:
| 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.
| naasking wrote:
| I'm looking at Mozilla's WebThings.
| theshrike79 wrote:
| 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.
| moduspol wrote:
| 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.
| pmlnr wrote:
| > 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.
| temporal828 wrote:
| > 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.
| leonsmith wrote:
| 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
| nikita2206 wrote:
| 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)
| magic_hamster wrote:
| 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.
| jackdh wrote:
| 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.
| vincnetas wrote:
| 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
| dementik wrote:
| I think HA is using ZHA under the hood for Zigbee
| communications.
| babas wrote:
| 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.
| vincnetas wrote:
| My mistake, zigbee2mqtt is one off third party options to add
| zigbee to HA. But still, quite nice project.
| dementik wrote:
| 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).
| [deleted]
| timzaman wrote:
| > 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.
| acidburnNSA wrote:
| 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.
| oynqr wrote:
| Great, now tell me how to maintain it.
| akx wrote:
| `pip install -U homeassistant` when there's a new version.
| jve wrote:
| > 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.
| lelanthran wrote:
| > 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.
| m00x wrote:
| 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.
| lostlogin wrote:
| This is the way to go. It's absolutely solid and is part of
| my docker-compose.
| ThatMedicIsASpy wrote:
| 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.
| lelanthran wrote:
| 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.
| m00x wrote:
| You can do the same with EMQX or Mosquitto. I have both
| my broker and HA being started at boot by systemd.
| lelanthran wrote:
| > 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.
| saiya-jin wrote:
| 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.
| andylynch wrote:
| 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.
| m00x wrote:
| 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.
| Havoc wrote:
| 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
___________________________________________________________________
(page generated 2023-06-05 23:04 UTC)