[HN Gopher] A kernel developer plays with Home Assistant
___________________________________________________________________
A kernel developer plays with Home Assistant
Author : pabs3
Score : 161 points
Date : 2025-05-17 01:36 UTC (21 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| readthenotes1 wrote:
| The data ownership reminds me a bit of an early business ummm
| transaction if Dr Phil:
|
| 1. Sell the gullible public long-term memberships to a gym, with
| long-term subscriptions.
|
| 2. Sell the subscriptions to a 3rd party.
|
| 3. Close gym. Subscription contract still valid.
|
| https://www.celebitchy.com/8971/dr_phil_ran_a_health_club_sc...
| riddley wrote:
| It's very easy to be cynical. Home Assistant belongs to a non
| profit. While that in and of itself isn't bullet proof, it does
| go a long way.
| balloob wrote:
| Founder Home Assistant here. Want to chime in that I always love
| to see write ups like these to see the great things what people
| achieve with Home Assistant.
|
| Not everyone might know, but last year we started the Open Home
| Foundation[1] as a non-profit in Switzerland and I donated Home
| Assistant to it[2]. It's fully funded by users. There are no
| investors involved.
|
| We are fully committed to building out a smart home that focuses
| on local control and privacy. Yes there are rough edges, but
| we're actively working on it in the open, with progress being
| released every month.
|
| ~Paulus Founder Home Assistant & President Open Home Foundation
| https://github.com/balloob
|
| [1]: https://www.openhomefoundation.org [2]:
| https://www.openhomefoundation.org/blog/announcing-the-open-...
| cyberax wrote:
| Is it possible to donate to your foundation via some kind of a
| subscription?
|
| I have a Nabu Casa subscription, but I don't really need it.
| baby_souffle wrote:
| > I have a Nabu Casa subscription, but I don't really need
| it.
|
| Shame there's no way to donate it.
| lolinder wrote:
| I mean, if you're paying for the subscription but never use
| it that's effectively a donation, right?
|
| OP explains their motivation for not accepting small
| donations in another comment:
|
| https://news.ycombinator.com/item?id=44014822
| hardwaresofton wrote:
| At some point a company is going to start making hackable, local
| connection devices (cloud optional) with published APIs and sell
| them at a higher price tag, and they're going to be fabulously
| wealthy, commanding higher margins than the others.
|
| At least, that's what I like to tell myself.
| balloob wrote:
| There is Zigbee, Z-Wave and Matter. These are all smart home
| standards that are fully local and devices will be able to be
| set up and used even when the company goes out of business. You
| are however limited to the things that are standardized.
|
| If you want to go a step further, look for devices made for
| ESPHome or devices made by Shelly. Both have local APIs and are
| very hackable.
|
| (disclosure: I am the president of the Open Home Foundation and
| ESPHome is one of our projects and I am also a board member of
| the Z-Wave alliance)
| hardwaresofton wrote:
| > There is Zigbee, Z-Wave and Matter.
|
| I am not a practitioner, but instead someone that looks at
| the ecosystem from time to time and has been waiting for a
| while, because I dont see the stack + DX/UX that I want yet.
|
| Zigbee never reached critical mass and requires a hub. Z-wave
| seems to be the same. Thread _over wifi_ (IIRC different
| protocols /transports are just fine) is what I think will be
| the future.
|
| IMO Thread wins out, support gets put into routers, and I can
| just have a thread enabled router which MAY have other
|
| I don't want to buy an IoT hub. Many IoT devices I want to
| control are powerful enough to run Wifi, and I want to
| control them with a standard networking stack with high
| adoption and familiar tooling. Thread seems to fit this use
| case the best.
|
| Please feel free to rip apart the above opinions, they're
| loosely held. I'd love to learn how wrong I am today!
|
| > If you want to go a step further, look for devices made for
| ESPHome or devices made by Shelly. Both have local APIs and
| are very hackable.
|
| Thanks for the recommendation! Appreciate the disclosure and
| apologize for the blast of relatively uninformed opinions.
|
| One more side question -- why is it so hard to get a simple
| IoT button that runs local Wifi (really hoping for no base
| station) only and is battery chargable?
|
| Buildable with an ESP32 clearly but I just want to buy this.
| balloob wrote:
| Maybe not exactly what you are looking for, but check out
| the Shelly BLU Button1. It's a BLE button with a long
| battery life.
|
| It sends out BLE packets when pressed, which can be picked
| up by Home Assistant via a Bluetooth adapter or using a
| Bluetooth Proxy. You can make the latter with any ESP32 and
| https://esphome.io/projects/?type=bluetooth
| hardwaresofton wrote:
| Thanks for the recommendation! This definitely makes it
| easier. IIRC BLE power mode + wake on BLE + wifi would
| probably work for easy use!
|
| Sounds like a far off weekend project
| hardwaresofton wrote:
| BTW, just bought a bunch of Shelly stuff. Looks like that
| project might happen sooner than I thought! The Shelly 1
| also looked like a good option :)
|
| Thanks again for the rec.
| yjftsjthsd-h wrote:
| With Thread+WiFi, can devices talk to the internet? Because
| denying them that ability is a lot of why I like
| Zigbee/Z-Wave.
| balloob wrote:
| Wifi yes. Thread depends on the settings on the Thread
| Border Router. Ours defaults to no internet access.
| hardwaresofton wrote:
| I'm sure I'm speaking to the choir here but access to
| Wifi != access to the internet!
|
| Why I'm excited about thread over wifi is that I don't
| need any extra specialized gear and possibility one
| device could run by itself
| mook wrote:
| While true, it's really hard to shop for devices that
| have access to WiFi without internet. It's too easy for
| the manufacturer to slip in the internet requirement and
| not put it on the box. Using other protocols makes the
| expectation disappear.
| cyberax wrote:
| ZWave is the most stable radio-based standard right now.
| It's not great, and it's not very extensible, but it's OK-
| ish. There's one hackable device:
| https://z-uno.z-wave.me/technical/ but its SDK is not that
| great.
|
| Pure ZigBee is... spotty because there are no certification
| requirements. Matter is stuck in development hell, but is
| slowly getting better.
|
| And the problem with WiFi is energy efficiency (or a lack
| thereof) compared to ZWave/ZigBee/Thread.
|
| So far, I've tried probably most of the home radio
| standards. Lutron was the most reliable, but it's also
| super-proprietary. My next house will just have conduits
| with low-voltage cables running to all the light switches,
| so I can use something like KNX instead of the radio-based
| stuff.
| hardwaresofton wrote:
| > And the problem with WiFi is energy efficiency (or a
| lack thereof) compared to ZWave/ZigBee/Thread.
|
| This is a problem I'd really like to solve the old
| fashioned way/I think it prevents too much building.
| Energy density, rechargability, etc are like CPU speed to
| me -- it will eventually be solved, and I can deal with
| replacing a device every month or swapping a rechargable
| battery (especially if the device can tell me it's low).
|
| I really do think it will be Thread+Wifi routers that
| eventually get a built-in Thread antenna that win (at
| least wining me over).
|
| If either ZWave or ZigBee had managed to get into the
| home router space, they would have won already IMO. There
| are probably annoying reasons they couldn't until now.
|
| > So far, I've tried probably most of the home radio
| standards. Lutron was the most reliable, but it's also
| super-proprietary. My next house will just have conduits
| with low-voltage cables running to all the light
| switches, so I can use something like KNX instead of the
| radio-based stuff.
|
| Thanks for sharing this and your other experience!
|
| Also TIL KNX.
| cyberax wrote:
| > I really do think it will be Thread+Wifi routers that
| eventually get a built-in Thread antenna that win (at
| least wining me over).
|
| That actually had been the case for a while. A lot of
| WiFi routers had a built-in Thread (ZigBee) radio, but
| then nobody actually used them and the manufacturers
| stopped bothering with them. So now pretty much only Eero
| access points still have it.
|
| > Also TIL KNX.
|
| My dream is to have _actuated_ switches, that have full
| tactile feedback. So that the paddle will physically flip
| when switched remotely.
|
| I commissioned an engineering company to look into that,
| but apparently this is not feasible at all with the NEC
| and UL requirements in the US. The only way is to use low
| voltage wiring to the switches and then use them to
| control line-voltage relays. This kind of system is
| popular in Europe, so you might as well just go with
| something like KNX.
| hardwaresofton wrote:
| > That actually had been the case for a while. A lot of
| WiFi routers had a built-in Thread (ZigBee) radio, but
| then nobody actually used them and the manufacturers
| stopped bothering with them. So now pretty much only Eero
| access points still have it.
|
| Thanks for this context -- when I searched I only found
| "thread border routers" -- I couldn't find a router made
| by a well known brand that _included_ thread
| functionality -- it always seemed to be "buy a router
| AND buy a thread border router".
|
| Really surprised that I missed the wave on this and
| wonder if it was a "we want people to buy two things"
| rather than no one actually using it. Maybe I just have
| to wait for it to come back around?
|
| Maybe the answer here is a USB powered device with an
| extra 2.4Ghz radio (running like.. OpenThread or whatever
| I need to do thread over an available antenna?) attached
| to the router?
|
| What I don't understand is why I just use the _existing_
| router 's 2.4Ghz antenna for this? The amount of
| confusion in the space and inability of devices to do
| multiple things is really annoying, to be frank. I can
| only surmise the reason this stuff is not easy/obvious is
| profit-incentive (outside of the difficulty of designing
| good standards of course!).
|
| [EDIT] OK, so the antennas aren't the same, despite being
| the same frequency -- clearly this is to ensure speedy
| operation at the hardware level.
|
| So the add-on antenna would probably work if I bought
| some parts from mouser:
|
| https://eu.mouser.com/c/passive-
| components/antennas/?protoco...
|
| [EDIT2] Nope, more confused. Multi-protocol antennas
| exist. Why is this not a set-and-forget option for all
| the routers??? Someone clue me in to the politics/power
| struggle or whatever the real reason is here. And then
| connected + taped something to my router.
| cyberax wrote:
| > Really surprised that I missed the wave on this and
| wonder if it was a "we want people to buy two things"
| rather than no one actually using it. Maybe I just have
| to wait for it to come back around?
|
| It's worse. There are _no_ new stand-alone Thread Border
| Routers on the market. You might find old stock of
| GL.iNet routers, and I believe there were a couple of
| other experimental devices.
|
| If you want a robust Matter network, your best bet is to
| use Apple or Google devices as border routers. Or you can
| use a USB ZigBee stick with HomeAssistant.
|
| > [EDIT2] Nope, more confused. Multi-protocol antennas
| exist. Why is this not a set-and-forget option for all
| the routers???
|
| No market demand, so router manufacturers just don't
| bother. The initial versions of Matter were a burning
| trash fire.
| hardwaresofton wrote:
| Thanks for the color here -- sad but I get it.
|
| Sounds like we're almost there and Zigbee/Thread are at
| least supportable with the same hardware. I can work with
| that I guess!
|
| > No market demand, so router manufacturers just don't
| bother. The initial versions of Matter were a burning
| trash fire.
|
| I remember hearing about this -- they fixed/improved it
| eventually but I guess the damage was done.
| spott wrote:
| That is an expensive dev board for something like this...
|
| Here is a esp32-h2 with thread and zigbee support for
| $5-$12
|
| https://a.aliexpress.com/_mMfZEsX
|
| I figure support for something like this is likely to
| increase faster than a $70+ board.
| baq wrote:
| > why is it so hard to get a simple IoT button that runs
| local Wifi (really hoping for no base station) only and is
| battery chargable?
|
| Battery life is atrocious and latency from deep sleep will
| be very bad. I've got Zigbee buttons from ikea that run on
| nimh batteries for a couple years now and only used like
| half of the charge. The hub is an usb dongle attached to
| the home assistant server, no issues.
| hardwaresofton wrote:
| > Battery life is atrocious and latency from deep sleep
| will be very bad. I've got Zigbee buttons from ikea that
| run on nimh batteries for a couple years now and only
| used like half of the charge. The hub is an usb dongle
| attached to the home assistant server, no issues.
|
| So what do you consider to be "bad" battery life? I've
| got quite the tolerance, but the problem is that they
| don't even exist. Everyone seems to stop out on this at
| "it would never be worth it".
|
| > Zigbee buttons from ikea that run on nimh batteries for
| a couple years now and only used like half of the charge.
|
| This is intense for me, I'm happy with replacing
| batteries every 6 months if I could simplify deployment
| by 10x.
|
| > The hub is an usb dongle attached to the home assistant
| server, no issues.
|
| Maybe deployment isn't as hard as I'm making it out to
| be! That said, nothing easier than sending some packets
| to an IP address. I assume Zigbee APKs are easy... But
| for example if I search on crates.io
| (https://crates.io/search?q=zigbee) I don't see any
| obvious choices.
|
| To restate what I want (and hopefully is sounds a bit
| more reasonable) I want to be able to buy _one_ smart
| light bulb, configure it over BLE to connect to Wifi and
| for the rest of it 's live configure it/change it via
| Wifi. I want that for basically every device, and I'm
| fine with swapping batteries every 1 to 6months if I
| could have that!
| baq wrote:
| BLE should also work but you also want a dongle, so
| hardware wise it's the same; ideally you also want a
| couple gateways (Shelly devices can do that out of the
| box btw, and new Shellies will be supporting Zigbee.)
|
| You should look into zigbee2mqtt IMHO.
| fader wrote:
| > Maybe deployment isn't as hard as I'm making it out to
| be! That said, nothing easier than sending some packets
| to an IP address.
|
| I think this might be the case. Get a USB zigbee dongle
| and spend ~1 hour setting up Home Assistant and you're
| more or less done. Adding a new device consists of
| clicking a button in HA to enable permission for devices
| to join and then powering on the device. It will discover
| the network and report the features it exposes.
|
| You can control devices via HA over wifi. Plus HA gives
| you an API that you don't have to maintain and update as
| you add new classes of devices to the network.
|
| You'll spend far more time repeatedly replacing batteries
| with wifi devices than you will with configuring HA once.
|
| Edited to add: one nice thing I forgot to mention is that
| using HA for your own homebrew devices lets you keep a
| single consistent API for those and commercial devices.
| You can build a little ESP32 device with custom sensors,
| displays, etc. and control those exactly as you would
| with off-the-shelf products.
| Asmod4n wrote:
| thread and matter will, in my opinion, never matter for
| consumers. Why? It's basically a walled garden.
|
| Think HomeKit but a tiny bit more open, the open bit is,
| that a vendor can allow it to communicate with devices of
| other vendors. But they don't have to.
|
| Thread also needs more expensive SOCs, with Zigbee you only
| need a tiny micro controller with a few MHz of clock speed
| and a few KB of RAM. Thread and matter on the other hand
| can require megabytes of RAM.
|
| Vendors which nowadays sell HomeKit devices can reuse their
| SOCs for thread matter, keeping their 3-4 times higher
| prices compared to devices with the same functionality from
| Zigbee vendors.
| hardwaresofton wrote:
| > thread and matter will, in my opinion, never matter for
| consumers. Why? It's basically a walled garden.
|
| I'd counter with the fact that walled gardens are
| incredibly popular, and in particular to consumers.
| Consumers don't care if the gate is locked or not, they
| care if the flowers are pretty and the tea at the garden
| party is nice.
|
| > Thread also needs more expensive SOCs, with Zigbee you
| only need a tiny micro controller with a few MHz of clock
| speed and a few KB of RAM. Thread and matter on the other
| hand can require megabytes of RAM.
|
| IMO prices of SOCs are going to zero. ESP32s are a great
| example of this. Once RISCV is more widely used and
| capable things will accelerate even faster.
|
| > Vendors which nowadays sell HomeKit devices can reuse
| their SOCs for thread matter, keeping their 3-4 times
| higher prices compared to devices with the same
| functionality from Zigbee vendors.
|
| I think we agree here...? I think that HomeKit device
| that is _just a bit more open_ is going to win. But I
| think that HomeKit device gets adopted faster if it 's
| just a router -- I can understand updating a router to
| get a smart home. What I don't want is confusion around
| whether I need a hub or not, or whether devices work
| together or not.
|
| Buying a single router that acts as a hub + Wifi
| "repeaters" (IIRC that's what they're called) that can
| "extend" the signal (and along the way give other devices
| a point to connect to) makes _perfect_ sense to me as a
| consumer. I already know what WiFi is, and I want better
| coverage, not worse. The smart home stuff just falls out
| of tech I am already familiar with, efficiency by damned.
| Asmod4n wrote:
| Thread is a WiFi replacement, the devices talk IP over
| thread.
|
| And it has an encrypted pairing process to your vendor
| controlled hub. Said vendor can allow or disallow it
| which other vendors may speak with said hub.
|
| Here is the landscape we have: HomeKit: fully closed,
| requires certification from Apple. Very expensive and
| limited functionality.
|
| Zigbee: fully open, anyone can make Zigbee devices and
| sell them without any restriction. Operates on the same
| frequency all over the world. Devices are super cheap.
| You can expand the protocol however you like as a vendor.
|
| Z-wave: fully closed, several incompatible frequencies,
| requires certification to sell devices.
|
| Thread and matter: semi closed, same ieee standard as
| Zigbee for data transfer. Vendors can allow it to talk to
| devices of other vendors. Requires certification. Same
| price tag as HomeKit, aka 3-4 more expensive than Zigbee.
|
| All of them require hubs. And only with Zigbee you are
| guaranteed to have interop between all vendors and all
| devices sold across the globe. Thanks to Home Assistant.
| With thread the vendor can simply disallow you to use
| your devices with HomeAssistant, which is unacceptable by
| me.
| Asmod4n wrote:
| Oh and, Zigbee has automatic range extension as part of
| its standard. Every device with a plug expands your
| network.
| hardwaresofton wrote:
| Thanks for all this context/explanation -- also the
| follow up. Automatic range extension (i.e. actually being
| a mesh and forwarding along messages) is an excellent
| feature.
|
| > All of them require hubs. And only with Zigbee you are
| guaranteed to have interop between all vendors and all
| devices sold across the globe. Thanks to Home Assistant.
| With thread the vendor can simply disallow you to use
| your devices with HomeAssistant, which is unacceptable by
| me.
|
| This is the one I want to push back on -- Thread over
| Wifi doesn't require a special Hub right? Taken with
| other info from this thread clearly in the real world
| it's not so simple to find the right hardware... but it's
| _possible_ to just buy a thread device and use it over
| regular old wifi.
|
| Sounds like Zigbee is closer to ideal than Thread or
| Thread/Wifi.
|
| Maybe this is the startup someone needs to do -- some
| reasonably powered device to attack to a router/connect
| close to a router which supports Thread and Zigbee, has
| completely local management and call it a day. Is this
| just over-complicating a smart hub? Don't know.
| Asmod4n wrote:
| Thread is using the same protocol as Zigbee, which
| requires specialized hardware to talk to it. You can't
| get around a centralized hub when wanting to use them on
| your WiFi network.
|
| Thread just adds an IP layer above Zigbee. Zigbee is on
| the same protocol layer as Ethernet or WiFi.
| hardwaresofton wrote:
| > Thread is using the same protocol as Zigbee, which
| requires specialized hardware to talk to it. You can't
| get around a centralized hub when wanting to use them on
| your WiFi network. > > Thread just adds an IP layer above
| Zigbee. Zigbee is on the same protocol layer as Ethernet
| or WiFi.
|
| AH, I've just realized that I've been using the wrong
| terminology.
|
| I've been meaning to say Matter over Thread vs Matter
| over Wifi!
|
| Matter seems like a decent way forward, and it can work
| only over wifi which is what drew me in to focusing on
| Matter. IIRC Matter/Zigbee isn't a thing (though it
| technically should be possible, Zigbee is just a
| transport as far as Matter is concerned right?).
|
| [EDIT] works -> can work, Thread/Zigbee -> Matter/Zigbee
| Asmod4n wrote:
| Thread and Zigbee implement the same IEEE standard.
|
| Matter would be correctly the application layer protocol
| of thread and could be spoken over any transport. Like
| HTTP
| Asmod4n wrote:
| But here comes the tricky bit, when you buy either Zigbee
| or matter devices each vendor will add its own
| extensions.
|
| In the Zigbee ecosystem vendors out right refuse to
| communicate with devices from other vendors even though
| Zigbee is an interoperable standard.
|
| That lead to the birth of zigbee2mqtt, literally hundreds
| of years of development time went into it to have full
| feature support for every Zigbee device that exists.
|
| For thread and matter devices each vendor would have to
| do the same. And that won't happen, leading to a
| fragmented ecosystem.
| hardwaresofton wrote:
| Welp that's depressing.
|
| Thanks again for laying this out -- I've been seeing
| zigbee2mqtt everywhere and this explains why someone
| would add mqtt to the mix. Sounds like this is another
| thing that needs to be run/managed on the software side
| to be robust.
|
| This is an insane goal (and who knows when I'll actually
| get to work on this project), but what I _want_ to build
| is an all in one something that "just works". So
| roughly:
|
| 1. Pick a good enough physical comms stack to hit _most_
| things
|
| 2. Write software to fill in the rest
|
| It's going to be difficult but it feels like the setup
| for all these tools is just hard, when it doesn't have to
| be _if_ you could pin down the hardware /install
| instructions, then write a really decent software layer
| to pull it all together without making people go homelab.
|
| That said, that's probably what home assistant devs
| thought before they reached the current level of
| complexity, I'm probably preparing to attack a windmill
| here.
|
| I think my secret sauce here will be WebAssembly -- if I
| can nail down the hardware below, build/convert a ton of
| adapters via WebAssembly, and then build a
| compelling/easy to add/install/manage/configure UI on top
| of that, I might have myself something worth posting to
| HN someday.
| Asmod4n wrote:
| IMHO, thread and matter will probably be as mature as
| homeassistant and zigbe2mqtt in the 2030ies. At the
| moment, Zigbee devices can work without any hub as long
| as you stick to one vendor.
|
| Aka buy lightbulbs and switches from ikea and you can
| right out start using them, I believe you only need a hub
| to create groups of devices which then can get controled
| with one switch. You then could unplug the hub and still
| use them, only needing a hub for ethernet bridging and
| automations.
| hardwaresofton wrote:
| > Aka buy lightbulbs and switches from ikea and you can
| right out start using them, I believe you only need a hub
| to create groups of devices which then can get controled
| with one switch. You then could unplug the hub and still
| use them, only needing a hub for ethernet bridging and
| automations.
|
| Yeah thanks for pointing this out -- just need a single
| Zigbee coordinator (if my light research has been correct
| so far) and I'm ready to go.
|
| I think IKEA bulbs will also be in my future.
| wlesieutre wrote:
| > Thread just adds an IP layer above Zigbee
|
| To clarify this: Thread is not building on top of Zigbee,
| they are both independently built on 802.15.4
| raffraffraff wrote:
| Does the hub requirement matter that much though? I mean if
| you want truly peer to peer, then yeah, but if you're
| already using Home Assistant you can plug a cheap ZigBee
| usb dongle into that.
|
| So the bit I'm missing: _how_ do you control them purely
| over WiFi? Do you run software on your phone that can
| control the target? Eg: app talks directly to the device
| over your network, instead of via a browser + Home
| Assistant running on a Pi. I can 't think of any examples
| of a product that works this way without being cloud
| enabled (IE: there is a hub but you don't own it)
| hardwaresofton wrote:
| > Does the hub requirement matter that much though? I
| mean if you want truly peer to peer, then yeah, but if
| you're already using Home Assistant you can plug a cheap
| ZigBee usb dongle into that.
|
| Maybe not, but I don't really want to actually run Home
| Assistant, I want the basics to hack on, really. Trying
| to pick the most open thing that will be easy to program
| _without_ relying on using something like Home Assistant
| (not that its bad or anything).
|
| > So the bit I'm missing: how do you control them purely
| over WiFi? Do you run software on your phone that can
| control the target? Eg: app talks directly to the device
| over your network, instead of via a browser + Home
| Assistant running on a Pi. I can't think of any examples
| of a product that works this way without being cloud
| enabled (IE: there is a hub but you don't own it)
|
| Yeah that's my goal -- basically I want to be able to
| control the devices from _anything_ web connected (and
| ideally, the same program running in multiple places).
|
| My thinking is that I can build this _without_ being
| cloud enabled if I "just" (famous last words) had
| Thread/Wifi.
|
| With all the excellent feedback in this thread (thanks
| HN!), it's looking like a small SBC + a Thread/Zigbee/BLE
| dongle[0] is the way forward, and hooking that up to my
| router via USB so it's always powered and follows the
| router around (maybe velcro it on).
|
| SBC (or something smaller maybe, but probably the SBC) so
| I can program it myself.
|
| [0]: https://sonoff.tech/product/gateway-and-
| sensors/sonoff-zigbe...
| lawn wrote:
| The basics of Zigbee isn't Home Assistant, it's something
| like zigbee2mqtt with a USB dongle and then you interface
| directly to an mqtt broker.
|
| For my automations I do just that and I bypass home
| assistant and control my devices directly over mqtt. It
| works very well.
| viraptor wrote:
| > I don't want to buy an IoT hub.
|
| Different expectations. I don't want my things to know that
| wifi exists. It stops vendor lock-in, it ensures local
| communication, it means things work even if network goes
| down. It also makes sure they will never autoupdate or join
| Mirai botnet.
|
| I've got a mix of zwave (fibaro), ZigBee (Ikea) and ble at
| home and I'm ok with that.
| hardwaresofton wrote:
| Yeah I think so -- I like to think I can control my
| router at least, so I don't have to worry about it. That
| said, probably not protected from the botnet case.
|
| Also, unfortunately up until now I've been saying the
| wrong thing -- I mean Matter over Thread versus Matter
| over Wifi. Matter over Wifi seemed like a winner to me
| because I could just use it.
|
| It looks like going forward I'll be plugging a small SBC
| into my Router's USB (+ ethernet) and connecting a Zigbee
| + Thread dongle. That should cover me for most
| communication options, then from there it's "just" a
| software problem :)
| wlesieutre wrote:
| Same boat here, I like knowing that none of of my devices
| can get network access, all they can do is communicate
| with HomeAssistant.
|
| And with Zigbee bindings most of my inputs are set up in
| a way that they still work even if HomeAssistant goes
| down.
|
| Not that HomeAssistant has ever down, but I can imagine
| its SSD or something failing and not bothering moving it
| to a different computer for a few days while I get a
| replacement in.
| Aurornis wrote:
| > I don't want to buy an IoT hub. Many IoT devices I want
| to control are powerful enough to run Wifi,
|
| Having a lot of career experience in this area, I greatly
| prefer to keep my IoT devices off of my WiFi.
|
| You don't need a separate hub device for Zigbee or Z-Wave,
| just a simple USB adapter that you plug directly into your
| device controlling everything.
|
| Keeping the low bandwidth IoT devices off of the main WiFi
| had a lot of advantages. It's also much easier to rotate
| your WiFi password when you can do it all without
| reconnecting every light switch in your house, for example.
| cbull wrote:
| The "Hub" device can be as simple as a USB stick that's
| attached to the machine running Home Assistant. That's what
| I have been running for years, a Z-Wave USB stick that
| passes through to a ZwaveJS docker container (which also
| communicates with HA).
|
| So it's not like you need a big stand alone device that has
| to have it's own Wifi or ethernet or anything like that,
| it's just a USB stick.
| baby_souffle wrote:
| The number of companies that does this _is_ growing.
|
| Shelly was early, the cheep chineese stuff was easy to hack but
| they eventually moved to cheaper and more esoteric chips where
| custom firmware is non existent or not as mature. This is
| changing back, though! The number of ESP-32 powered LED light
| controllers that I've seen on Ali that feature a USB port for
| reprogramming / have all the GPIO labeled ... even have a
| HA/ESP-Home/WLED logo on them is infinitely more than I saw in
| years past (a few is infinitely more than zero, right?)
| dns_snek wrote:
| Buyer beware - There's a mountain of products on the market
| that are advertised as "open source" which lures many of us
| in, but many of those products have poor quality hardware.
|
| My heuristic for anything operating at mains voltages is "If
| I can find a product that looks just like this on
| Temu/Aliexpress, I'm not buying it". They're probably white
| label products sourced from the same factories and suffer
| from the same quality issues.
|
| Relays found in smart plugs are often sketchy in my
| experience. About half of the ones I bought or set up for
| others make unsettling noises that made me worried about poor
| electrical connections and risk of fire. I only have two
| Shelly plugs but those don't suffer from these issues.
| viraptor wrote:
| Tuya and their rebranded versions fall into that area too.
| Their power switches die early and they actually went from
| easily reprogrammable to hostile firmware. They have own
| cloud service you can't leave, only get an access code to -
| and the firmware prevents downgrades. Terrible company.
| dns_snek wrote:
| Tuya is just an IoT platform used by many cheap devices
| but I agree, it's low cost and cloud based which is a
| terrible combination. I wouldn't touch it.
| darkwater wrote:
| Just buy the ZigBee versions, they work beautifully with
| HA
| baby_souffle wrote:
| > Just buy the ZigBee versions, they work beautifully
| with HA
|
| 802.15 does have it's place but some of us prefer 802.11
| unless battery requirements dictate lower power PHYs.
| Zigbee is also depreciated; if possible, seek devices
| using Matter for their interop.
| baby_souffle wrote:
| > but many of those products have poor quality hardware.
|
| Absolutely. Cheap hardware means corners cut... regardless
| of how open the software is.
|
| Shelly devices are quite open and well made but easily 2x
| the cost of other wifi relay devices. Belkin WeMo devices
| are similar price to shelly and about as well made but
| their software leaves literally everything to be desired.
|
| Knowing what risk is acceptable and how to identify if a
| particular component is built to a spec that obviates that
| risk or not is probably going to _always_ be part of the
| DIY scene.
| MostlyStable wrote:
| I've been trying to find high quality, open/local
| controllable LED lights that have beefy enough electronics
| and heat control to not die in in a couple of years.
| Unfortunately, quality of construction is even more poorly
| tested/documented than open source/local control.
|
| And even more unfortunately, price itself is not a very
| reliable indicator. Low price is usually a sign of poor
| quality, but high price is not a sign of high quality, but
| rather more often just an attempt to take advantage of
| people who don't know better.
| rstuart4133 wrote:
| The article does mention https://refoss.net/, quote:
| There is a crucial difference here, though: the Home-Assistant
| integration for Refoss devices, which interfaces directly with
| the monitor and needs no cloud connectivity, is written and
| provided by Refoss itself. Home-Assistant compatibility is the
| first bullet item on the above-linked product page.
| 05 wrote:
| Lots of "smart" products come with BK7231x chips that are
| flashable to esphome, nobody needs another custom protocol
| (even if open) since esphome currently supports local encrypted
| transport that's going to be better than 99% of what the
| Chinese (or even western) companies are going to design for
| local communication.
|
| Oh, and hobbyists mostly aren't going to pay premium for those
| either, unless those come preflashed with esphome and sponsor
| hass project, and even then 90% people are still going to buy
| the cheapest option on the market:)
| Aurornis wrote:
| > hackable, local connection devices (cloud optional) with
| published APIs and sell them at a higher price
|
| This business model doesn't work.
|
| Many have had this idea. They all run into the same problem:
| The target audience for hackable home automation devices
| doesn't like paying a premium for anything they think they
| could DIY.
|
| If you have a $70 nicely designed, documented IoT sensor but
| the DIY home automation people think they can put ESPHome on a
| $10 Amazon device and accomplish nearly the same thing, which
| one do are they going to buy?
|
| If you go through the forums you can already find some semi-
| premium devices that are a little better constructed and might
| have better feature sets. They're always followed by comments
| from people recommending a cheaper option.
| umbra07 wrote:
| Isn't that kind of what GL.inet does? They seem pretty
| successful.
| russdill wrote:
| How is that not exactly zigbee and matter?
| pabs3 wrote:
| A link for the first article in this series:
|
| https://lwn.net/SubscriberLink/1017720/7155ecb9602e9ef2/
| tomhow wrote:
| We changed the URL to this from
| https://lwn.net/SubscriberLink/1017720/7155ecb9602e9ef2/ and
| posted this https://news.ycombinator.com/item?id=44014505, to
| avoid splitting the discussion between the two parts.
| NewJazz wrote:
| Is there a way to contribute to LWN without creating an account
| or having an ongoing thing? Does nobody use crypto?
| pabs3 wrote:
| Looks like they don't accept donations, sounds like it is much
| harder to accept them.
|
| https://lwn.net/Articles/828428/
| https://lwn.net/Articles/1019619/
| shellwizard wrote:
| You can wait for around two weeks for the article to be free to
| read, if you don't want to subscribe
| NewJazz wrote:
| I just want to support. I guess they have prepaid
| subscriptions and I can just pay for x months a year that I
| think is fair. I don't read it a ton but wanted to
| contribute.
| jsmo wrote:
| Thanks! Check out Lars' channel for some interesting insights
| into Home Assistant with remote sensors:
| https://www.youtube.com/@LarsKlintTech/search?query=home%20a...
| KillenBoek wrote:
| Just wondering why anyone would go through the hassle of
| installing home assistant on Linux when the fantastic hassOS
| exists which will run perfectly virtualized.
| edejong wrote:
| Because we want to run more than just Home Assistant on the
| same OS? Because traditionally OS and application layers were
| separated? Because we trust mature Linux distros more when it
| comes to LTS and security patches? Because we already know our
| way around Debian/Ubuntu/Nix/etc.?
| theK wrote:
| Absolutely this. Once you get into the game of running apps
| at home with certain quality assumptions you end up having to
| bolt on various things (VPN, DNS, log aggregation etc) that
| are better wrapped around the application instead of having
| them run within it. And having an AppOS typically just gets
| in the way of all that plus what edejong said that you
| already know how to do it on the typical production OSes and
| learning to do it for every AppOS is just cumbersome.
| ramy_d wrote:
| Seconded. My home server does many things, one of which is
| homeassistant.
| SparkyMcUnicorn wrote:
| Proxmox adds very little overhead. I'm running dozens of
| things alongside HAOS.
|
| The OS is the path of least resistance and gives you the best
| experience for low maintenance.
|
| https://community-
| scripts.github.io/ProxmoxVE/scripts?id=hao...
| chneu wrote:
| I'm also running dozens of things alongside HA and I don't
| have to use proxmox.
|
| It's not hard to run HA in unsupported mode. The only real
| difference is an annoying reminder that you're unsupported.
| Everything else works, including plugins/add-ons.
|
| I've run HA a bunch of ways. It doesn't really matter all
| that much. Use HACS to fill any gaps.
| SparkyMcUnicorn wrote:
| One-click updates work from the dashboard? I don't think
| they would.
|
| Of course you don't have to go the proxmox route, but it
| is an easy route.
|
| I have a proxmox cluster, so moving things between
| machines, high availability, and backups are a breeze.
| Had an SSD go bad a few months ago, and I just moved
| everything on that machine to another node until the new
| drive showed up. It was a pleasant experience.
|
| There's plenty of other ways to achieve this, but this is
| what I chose and I'm happy with it. It's simple, and I
| can manage everything from my phone if needed.
| Denvercoder9 wrote:
| > Proxmox adds very little overhead.
|
| It's still running a second kernel and entire userspace
| stack. In my world that's not "very little overhead".
| aryonoco wrote:
| Using Proxmox with lxc containers, there is no second
| kernel. It uses the host kernel's native cgroups and
| namespaces for process isolation. You can actually
| achieve the same with just systems and namespaces.
|
| Having said that, I think if you prefer traditional
| distro packaging, you should absolutely stick to that.
| Aurornis wrote:
| ProxMox supports both VMs and LXC containers. You would
| use LXC containers for low overhead. No second kernel.
| Denvercoder9 wrote:
| ProxMox supports it, but it's not what the linked script
| does, nor is it officially supported by HAOS.
| SparkyMcUnicorn wrote:
| Yep!
|
| I'm aware of the tradeoffs here. For home assistant
| specifically, there's two options if you want to stay on
| the path of first-class support. Run it bare metal or in
| a VM.
|
| Going a different path isn't a bad choice, or even a big
| downgrade.
|
| I had fun with all the different ways of running home
| assistant 6+ years ago, and then decided to embrace a
| solution that required the least fuss and would hold up
| long term. I'm happy with my choice, and it gave me
| exactly what I was expecting.
| goodpoint wrote:
| > we trust mature Linux distros more when it comes to LTS and
| security patches
|
| This. If I have to trust some huge container or custom OS
| where is the benefit of open source?
| lhamil64 wrote:
| I used to use Home Assistant via Docker, but I've since
| switched to Proxmox with HAOS in a VM and a second Debian VM
| for everything else. My main reason for this is that it seems
| like the more supported scenario. For example, when the Voice
| Assistant stuff first came out the setup was only really
| documented via HAOS add-ons. I managed to get it working with
| standalone Docker containers but it was a pain to figure out.
| It really is simpler to just use HAOS IMO.
| pbasista wrote:
| > fantastic hassOS
|
| That is a very subjective opinion.
|
| As was already mentioned, people rarely want to run a dedicated
| physical server for just a single purpose. The concept of Home
| Assistant Operating System requires exactly that.
|
| Also, it is Debian-based. It uses the `apt` package manager
| which is slow. Some people may prefer something faster and more
| modern, like `pacman` or `dnf`.
|
| > run perfectly virtualized
|
| Fair enough.
|
| But that obviously requires virtualization being set up on the
| server. If people do not use virtualization for anything else
| on their server, they may as well set up Home Assistant
| directly.
|
| Finally, I think there is one more issue.
|
| Many of the integrations which are possible with Home Assistant
| Operating System require physical hardware being connected to
| that server. A reader, a receiver, something like that.
|
| But these home servers are often placed in some inaccessible
| locations, like an attic, where the data from sensors is
| unavailable. It may be impractical to run cables there. And the
| wireless devices may be too far away for a receiver located
| there to be able to read them.
|
| So people need to come up with work-arounds to get their data
| to their server. They set up various signal proxies and thin
| clients which receive the data from the sensors on the spot
| where they are available and then send them over network to the
| Home Assistant server.
|
| Unfortunately, from my experience, many integrations completely
| ignore this usecase. They are likely focusing on a happy path
| where everything is connected locally to "the one" server. And
| only then they behave nicely and work out of the box. But as
| soon as you need any special step or behavior, it is necessary
| to dig deeper and create custom layers to transport the data
| from your devices to the server.
|
| Home Assistant Operating System does not make any of that
| simpler. Perhaps on the contrary, it forces you to use a
| specific Debian-based distribution with possibly outdated
| packages that you cannot easily upgrade without breaking Home
| Assistant.
|
| Which is why it makes little sense to bother with it, in my
| opinion, for these kind of installations.
| cyberpunk wrote:
| > Also, it is Debian-based. It uses the `apt` package manager
| which is slow. Some people may prefer something faster and
| more modern, like `pacman` or `dnf`.
|
| Do people really care if it takes 5 seconds to parse a
| package index vs 1? I don't get this argument at all.
| cassianoleal wrote:
| I wholeheartedly agree with you. This is one of the most
| bizarre arguments against it that I've ever come across.
|
| And that's even before you realise it's based on fiction:
|
| > Home Assistant Operating System is not based on a regular
| Linux distribution like Ubuntu.
|
| https://github.com/home-assistant/operating-system
|
| There is _no_ apt or any other package manager on HAOS.
| pbasista wrote:
| Yes, you are right. There is one more abstraction layer.
|
| Home Assistant Operating System uses Buildroot which uses
| Docker to run container with Home Assistant Supervisor.
| And only that container is Debian-based [0].
|
| [0] https://github.com/home-assistant/operating-
| system/blob/0c75...
| cassianoleal wrote:
| And that's entirely inconsequential, since it's in an
| immutable container where `apt` will never be used.
| WhyNotHugo wrote:
| I just installed python3 on Debian and Alpine. It takes 16s
| vs 4s (I ran the test three times, and kept the fastest
| measurement for Debian and the slowest measurement for
| Alpine).
|
| Sure a one-time wait of 12s doesn't change my life. But I
| won't use apt/apk _once_; I'll use it every single time
| that I install something. It low-key bothers me when my
| flow is interrupted by having to wait for machines to do
| their job, increasing that by 300% doesn't help.
|
| This wouldn't be a deciding factor for me. But it doesn't
| add points for the Debian-based approach.
| j1elo wrote:
| A couple weeks ago I powered a laptop that had been sitting
| unused for several months. It had Ubuntu 22.04 installed.
| The initial `apt-get update` took some time to download new
| indexes, and _almost 3 minutes_ to process them all
| afterwards, while I was right there staring at the screen
| wondering why I was there staring at the screen for so
| long, because this experience always happens as soon as any
| of my machines stay off for more than a couple weeks. apt
| is indeed very slow.
| pbasista wrote:
| > Do people really care
|
| I suppose it depends. I do care because I typically need to
| do it regularly. And it is nice to have it done quickly.
| darkwater wrote:
| What about the ones running it in Kubernetes? ^^;;
| rurban wrote:
| I tried to install it on a raspi 4 with touchscreen for my wife.
| The raspi worked fine with Debian, esp. it's installer asks for
| the wifi and ssh keys, and therefore you can trivially connect to
| it.
|
| Not so with the homeassistant installer. No wifi setup, no ssh
| access at all. You really need to cable it, nmap the new IP, and
| then I got stuck because the web server doesn't show up.
| Attaching the keyboard brought me into a restricted ha> prompt,
| where I cannot fix anything.
|
| So far it's horrible
| madaxe_again wrote:
| I'd suggest that you use a docker instance. The setup is
| trivial.
|
| Not having HAAS has made little difference to me being able to
| do all sorts of stuff - and HACS gives you access to a whole
| bunch of additional stuff, and works in docker.
| shermantanktop wrote:
| +1. I know the parent reads like "do it my way" but ha in
| docker really is simpler.
| SparkyMcUnicorn wrote:
| I did this a few months ago for a test home assistant setup and
| had the opposite experience. I forget exactly what I did, but
| it involved editing a file with the wifi settings and dropping
| my public ssh key on the SD card before installation.
|
| If you use ethernet, no editing required. Web interface goes
| into setup mode automatically.
|
| Worth noting that ha cli[0] (ha>) does have a `network` command
| to configure this as well.
|
| [0] https://github.com/home-assistant/cli
| archi42 wrote:
| Mind that you should not use a Pi with SD card for HA. I'm not
| sure what the official stance is, but: In my peer group failing
| SD cards were responsible for a vast majority of issues. Causes
| are probably a mixture of heavy logging and power outages;
| either from the grid, or user error not shutting down the Pi
| before disconnecting power.
|
| At our house I run HAOS in a VM (on a beefy server). My wife
| uses the app on her phone (as do I), and we have a cheap tablet
| with the app for guests. On the laptops/desktops we also have
| access to the web UI.
|
| As the article points out, remote access for the phones can be
| done via the commercial offering or a VPN (as in our case:
| wireguard on the OpnSense).
| xnzakg wrote:
| Completely anecdotal experience but I've been running HA on a
| Pi from SD for quite a few years now with no issues.
| baq wrote:
| Wholly depends on how much stuff you've got. I've started
| having issues with the Linux io scheduler when the auto
| backups got large (1G+), the thing just hung and needed a
| power cycle.
| diggan wrote:
| > Wholly depends on how much stuff you've got
|
| Also what SD card you have, the durability between
| different models differ _a lot_. The SD card I use for my
| dashcam been working for years (A "SanDisk MAX
| ENDURANCE" card), some other cheaper SD cards can stop
| working properly after just months if you're using them
| for write-heavy stuff.
| raffraffraff wrote:
| Anecdotal agree, but I only use it for my lights (about 20
| smart bulbs + 5 sensors + 4 remotes) and I never tinker
| with it. At least 4 years later, that little Raspberry Pi 3
| + ZigBee dongle + sdcard are kinda forgotten about.
| mook wrote:
| Interesting; my Raspberry Pi 3B+ + Zwave dongle + SDcard
| eventually got too slow (to the point that HAOS updates
| would fail). Switched it to an old ChromeBox and it's
| been no problems since.
| stereo wrote:
| You don't need to nmap; instead head to
| http://homeassistant.local:8123
| cyphax wrote:
| If you type "login" at the ha> prompt, you'll get a root shell.
|
| This is something I also had to accept about HA. It runs in a
| VM in my case so it worked out-of-the-box, but you don't just
| ssh to it after installing it, and the ha> prompt is just a bit
| different. So far, it hasn't been in the way, although it
| occasionally takes time to find out how to do things.
|
| It's very flexible though, and apart from devices in your house
| there are many outside sources of data to use, like weather
| data, sun elevation or trash pickup dates. The HA app on your
| phone gives you many sensors usable in a flow. The time spent
| on it usually results in something worthy of that time, in my
| experience.
| Aurornis wrote:
| Much respect to Home Assistant for making everything as
| accessible as it is, but it's inherently a complex project. It
| also has to deal with trying to be everything to everyone,
| which makes it hard to identify the easy path through setting
| it up among all of the options.
|
| There are two ways to get through Home Assistant:
|
| 1. Identify the easy path instructions, get equipment that
| matches perfectly, and follow the instructions to the letter.
| Use only equipment known to have great integration. Upgrade
| only when necessary. Change nothing as soon as it's all
| working.
|
| 2. Be willing to spend a lot of time tinkering and debugging.
| There's a big Home Assistant channel in one of the big Slacks
| I'm in where everyone eventually hits something that takes days
| or weeks to figure out.
|
| Many companies have tried to package or use Home Assistant as
| the foundation for plug and play IoT hubs, but they all seem to
| end up with the same realization that it really needs a capable
| and willing human in the loop as soon as you deviate even
| slightly from the list of devices with excellent support. This
| isn't even entirely Home Assistant's fault: Most of these
| devices were never designed for third party control.
| pmlnr wrote:
| Home Assistant is a toy when it comes to automation reliability.
| It's a good toy though.
|
| I'll stick to my domoticz for the "if it ain't broken..."
| approach.
| SparkyMcUnicorn wrote:
| If you choose your hardware wisely, it's incredibly reliable.
| Most of my house is automated and I all I've done with it in
| the past year is add a few devices.
|
| I will admit that low (or zero) maintenance is easier to
| accomplish if you know your way around a little bit.
| O5vYtytb wrote:
| I've never had HA itself fail. I've had it installed for 10
| years and the only true failures were hardware (server, iot
| devices) or my own config mistakes.
| Gud wrote:
| I used HA for about a decade without so much as a hiccup.
|
| What makes you think it's a toy?
| apexalpha wrote:
| I have HA running for years (in Docker) and it's very reliable.
|
| It has integrations with allmost all devices or apps I use and
| the support for DSMR (Smart Electrical Meters) is first class
|
| I plugged a cable into my meter, the usb end into the server and
| it just works.
|
| It does have a steep learning curve, though. It really seems "by
| IT people for IT people"
| tails4e wrote:
| I have it in docker a d use supervised mode (which seems
| discouraged, but I want my machine for other uses also). The
| one thing I struggle with is updating, I'm concerned if I
| update it'll break. Is there a way to fully snapshot a
| container state and it's disk state, so I can 100% restore to
| it if something goes wrong ? I'm still running HA from 2020
| because of this.
|
| The other think I'm not a huge fan of is it's template
| language, it's clunky to say the least, but overall it's a
| great amd flexible system
| apexalpha wrote:
| I just backup the folder (volume) and that's it.
|
| If I should ever need to rollback I can change the Docker
| image tag from 'latest' to a specific one I guess.
|
| I've never had to do it but I do know people sometimes
| complain about updates breaking things.
| baq wrote:
| I'm running it with docker compose for the same reason and it
| never failed an update, but there was an occasional config
| tweak required. For the most part it's compose pull, compose
| up, check back in a couple weeks for the point release.
|
| Updating from that far is probably risky but you don't need
| to backup everything, just the config directory. Automated
| backups to Google drive are worth the upgrade alone.
| acidburnNSA wrote:
| In the last few releases they've polished the built in backup
| and restore features, which are available in the setting menu
| now.
|
| https://www.home-assistant.io/integrations/backup/
| ImPostingOnHN wrote:
| _> Is there a way to fully snapshot a container state and it
| 's disk state_
|
| `docker commit` should help you there, in making a copy of
| the container
| mmmpetrichor wrote:
| All the persistent storage is in the host directory path you
| map into the container. Just backup the directory you're
| mapping into the container. Don't try to save the container
| state.
| Calwestjobs wrote:
| some filesystems support snapshots for directories. your
| software does not have to have "compatibility" for it, it
| just works.
|
| with BTRFS you can even mount/work with multiple snapshots of
| same directory at once. it is great for debugging.
|
| deduplication will save you space.
| Hikikomori wrote:
| Could run it in a VM instead.
| 0ld wrote:
| It used to have a steep learning curve, I'd say. Once I've had
| a long complicated manually written configuration of all my
| devices, integrations, automations etc, which gradually got
| replaced by simple clicking in the gui. On the other hand, this
| also meant a lot of breaking changes over the years, when I had
| to re-configure my staff the new way
| Abishek_Muthian wrote:
| For a long time I was running home automation using individual
| scripts and was happy with it. Then I found myself in a remote
| place where the ISP gave a shitty modem which hangs when there's
| no heavy usage -\\_(tsu)_/-
|
| I had to automate restarting the modem when the Internet is down
| by power cycling a smart plug[1], Home Assistant turned out to be
| extremely useful for that. Official HW integrations and Node-RED
| was very straightforward to solve my problem. Since then I'm
| managing and monitoring various hardware devices in my home
| through HA.
|
| What's interesting is that there are manufacturers who are not
| only fine with HA but work with developers of HA integrations
| which enable offline usage of their IoT products even though
| their official apps are completely enshittified.
|
| Nowadays I checkout HA compatibility before I buy a IoT device.
|
| [1] https://abishekmuthian.com/restart-modem-automatically-
| when-...
| brbcompiling wrote:
| Feels like building my own smart Jarvis at home -- kinda tricky,
| but super fun!
| russdill wrote:
| There's an excellent thread with someone doing just that, but
| Friday.
|
| https://community.home-assistant.io/t/fridays-party-creating...
| Havoc wrote:
| The real magic is in my opinion in ESPHome. The fact that you can
| amateur solder some aliexpress $2 sensors together and have that
| actually work in HA with no coding except some yaml that you
| found on the internet is wild.
|
| >It would be interesting to see what would happen to a pull
| request adding support for, say, OpenThings Cloud as an
| alternative. The fate of that request would say a lot about how
| open the project really is.
|
| I kinda hope nobody tries. Their attempts at monetization have
| been pretty friendly and tame thus far & if something spooks them
| that could change.
| oakesm9 wrote:
| > I kinda hope nobody tries. Their attempts at monetization
| have been pretty friendly and tame thus far & if something
| spooks them that could change.
|
| To be fair to them they've been making a big push on adding
| backup support recently. Their Nabu Casa subscription has built
| in support for this and was a major selling point for me
| getting the subscription (I have Wireguard for remote access
| already).
|
| At the same time they implemented first class support for their
| own subscription, they added the hooks for other integrations
| to provide the same level of backup support. Now you can easily
| choose to use Google Drive, S3, BackBlaze and others just as
| easily as Nabu Casa. In some ways it's "better" as Nabu Casa
| only supports a single latest backup.
|
| From this they seem pretty friendly and not too interested in
| lock-in.
| mook wrote:
| Unfortunately their new backup support forces encryption;
| that makes sense for cloud-based backups but not for local
| (NAS etc.) ones. Requests for that just get replies to do it
| with manual backups the old way.
| tw04 wrote:
| Why is that unfortunate? Encrypting backups is just a good
| best practice in general.
| mook wrote:
| Because that means I need to manage the encryption key
| (which is a file, not a password). It makes it harder to
| do restores because I need to dig out the key.
|
| I don't have anything I care about in the Home Assistant
| install to need encryption; if you have access to that
| you are already in the network, same as the actual
| running device.
| badlibrarian wrote:
| Unencrypted backups is an option.
| bjackman wrote:
| Yeah ESPHome is magic. I set up a full home humidity monitoring
| setup for the cost of a soldering setup + approximately $0 on
| components. No subscription bullshit, no proprietary interface
| bullshit, just exactly the setup I want and it was fun and easy
| to build!
| Jgrubb wrote:
| Same. I had a couple extra ESP boards from an order where I
| only needed one, an extra breadboard and humidity/temp sensor
| and decided to finally measure the temp out in the
| greenhouse. It's amazing to have all that in a grafana dash
| running on a r pi.
| anon22981 wrote:
| Do you (or anyone!) know a good tutorial / series / blog
| how to get started with home automation?
| stavros wrote:
| I'd say install home assistant, and get a device that
| runs ESPhome, so you can tweak it. Unfortunately I don't
| really have anything more specific than that, but I agree
| that ESPhome is great. You solder some stuff, define the
| pins in the config, and everything works.
| zimpenfish wrote:
| The ESPHome Bluetooth Proxy is amazing - no faffing with
| Bluetooth on Linux (which remains a shambles) needed!
| Tigress8780 wrote:
| Even though ESPHome has warnings about using WiFi and
| Bluetooth proxy together being unstable, I've found it to be
| much better in terms of stability and performance than the
| Intel Bluetooth adapter connected to my Home Assistant
| system. BlueZ is probably more complex and less mature.
| XorNot wrote:
| ESPhome runs my whole house now basically.
|
| It's the HA system I've always wanted and the only way I would
| ever do it: everything just speaks regular IP, has a web
| interface, and lives on an isolated Wi-Fi network.
| dengolius wrote:
| My friend uses self-hosted open-source software to monitor all
| his home IoT devices[1] and copies important information to the
| cloud. I'm using StarFive VisionFive 2 to host my database for
| monitoring, but also have a copy of the data of a chip hetzner
| arm vps, as well as hosting backups on the two different clouds.
| I know users who are running[2] for years to monitor Solar
| panels, lawn watering and vegetable garden watering.
|
| My question is: is it really convenient to use only SaaS now if
| there is always the possibility of losing your data? I am
| referring to the case described in the article.
|
| [1]: https://vrutkovs.eu/posts/home-infra/ [2]:
| https://github.com/VictoriaMetrics-Community/homeassistant-a...
|
| PS: I'm working at VictoriaMetrics company
| CoolCold wrote:
| in recent podcast episode with the found of your company (
| https://www.youtube.com/watch?v=8xkCykuJwKs , Ot startapa do
| mezhdunarodnogo biznesa: istoriia VictoriaMetrics i eio uroki |
| Aleksandr Valialkin | #36) he explicitly described the path
| VictoriaMetrics has come and one of the early steps was trying
| to sell SaaS, while quite a lot of users/customers want to have
| on premise/own setup for such tooling.
|
| So, answering your question: > My question is: is it really
| convenient to use only SaaS now
|
| no, it's not
| farawayea wrote:
| Home Assistant is a very popular home automation platform used by
| many. Most articles and posts fail to mention concerns regarding
| the user experience, security and long term stability. The most
| common complaints are related to the ease of use and to the
| backwards incompatible changes. The ease of use complaints are
| usually about setting it up, putting together automations and
| setting up dashboards.
|
| Home Assistant is described as a home automation solution which
| runs locally on your hardware inside your home. Its current
| development process has many issues.
|
| https://github.com/home-assistant/frontend/issues/18549 is a
| serious privacy concern. Nabu Casa and the owners of the CDN can
| collect the following information about the users of a Home
| Assistant installation: the integrations they use, the IP address
| of all devices which use the particular Home Assistant
| installation, the user agent of the device opening the dashboard,
| the precise location based on IP address, the user's ISP and
| possibly very specifically the people through a combination of IP
| address associated with a specific set of integrations configured
| for an installation. Nabu Casa employees can claim that the data
| isn't sold or used. The people who run the CDN can do as they
| please without Nabu Casa's knowledge. It's not possible to load
| these icons without an Internet connection.
|
| The recent changes made to the backups in Home Assistant OS
| aren't user friendly. It's no longer possible to make an
| unencrypted backup without resorting to manual work by invoking
| an action. This arbitrary change wasn't necessary. It shows that
| the development process is chaotic and without a clear focus on
| making Home Assistant a more polished solution with the user in
| mind. It's just what they want to do.
|
| Security is yet another weak point for this project. Home
| Assistant is a Python monolith with 1000 direct Python
| dependencies and countless other indirect dependencies
| https://github.com/home-assistant/core/blob/dev/requirements....
| All these Python packages and their dependencies are bundled in
| everyone's Home Assistant installation. This is likely the
| biggest Python monolith in existence. You can compromise this
| project by compromising any dependency. Some of these packages
| are provided by Chinese companies for cloud based integrations.
|
| Some addons can only be run with net: host on Home Assistant OS.
| This is one more potential vulnerability if one of these addons
| is compromised.
|
| Bugs and regressions frequently get ignored on their tracker.
| There's a bot which closes tickets for which the developers have
| no interest. They choose to implement new features and to
| refactor without concern for people who can no longer do what was
| once possible. Features can change from month to month without
| any regard for the user's experience or for the overall
| stability. The graphs are one such example. New or changed
| functionality appears to lack thorough design before
| implementation. Unstable changes make it into stable releases
| every month.
|
| Paulus has recently stated that Home Assistant is the best home
| automation solution out there. It's not really the best because
| it's very good. It just happens to be the most popular among
| people with some technical skills. It's the best because the
| others are very bad, support less hardware, require a cloud
| connection, have poor security, are privacy invasive, require a
| subscription, are extremely expensive, are updated once per year
| or for several of the mentioned reasons.
|
| Home Assistant's advantage over commercial solutions is its large
| number of integrations, that it's open source and that there's a
| large community behind it. I wouldn't call it better at all. It's
| very similar to commercial solutions when privacy, security and
| usability concerns are ignored. The advantage of some cloud free
| commercial solutions is that they're likely to be more stable
| without breaking something once per month or every other month.
|
| Those who still want to run Home Assistant may want to run it as
| a Docker container without Home Assistant OS, to use a separate
| network for the smart home devices, to avoid cloud connected
| cameras, to avoid cloud based integrations and to isolate Home
| Assistant from the other non-IoT devices found on the network. It
| can be a high value target for hackers and for companies who want
| to sell your data. I wouldn't recommend running it if one's not
| tech savvy. It's not something one sets up for someone else who's
| not tech savvy either. Things will break. It's just a matter of
| time.
| sfeldma wrote:
| I'm concerned about privacy also, especially with Home
| Assistant integrations that "dial home" to vendor's clouds.
| Your data is not private. Check out my project that puts
| privacy as a main feature: https://merliot.io.
| protocolture wrote:
| Home Assistant is great, I have been able to push it to do things
| I wasnt expecting it to permit. Just running Python within a
| container arbitrarily interacting with the network and sensors. I
| used it to backend my own home web application.
|
| I believe a lot of people who are upset with the product have
| radically incorrect expectations.
| balloob wrote:
| Founder Home Assistant here. Want to chime in that I always love
| to see write ups like these to see the great things what people
| achieve with Home Assistant.
|
| Not everyone might know, but last year we started the Open Home
| Foundation as a non-profit in Switzerland and I donated Home
| Assistant to it[1]. It's fully funded by users. There are no
| investors involved.
|
| We are fully committed to building out a smart home that focuses
| on local control and privacy. Yes there are rough edges, but
| we're actively working on it in the open, with progress being
| released every month.
|
| ~Paulus, Founder Home Assistant & President Open Home Foundation
| https://github.com/balloob
|
| [1]: https://www.openhomefoundation.org/blog/announcing-the-
| open-...
| diggan wrote:
| > I donated Home Assistant to it[1]. It's fully funded by
| users. There are no investors involved.
|
| I cannot thank you enough for this. It was a bit risky adopting
| Home Assistant for everything ~two years ago, but that you guys
| did this move really makes me feel less scared about eventually
| having to replace it with something else.
|
| I'm subscribed to Home Assistant Cloud (via Nabu Casa) even
| though I don't use it just because it seems to be one of the
| few ways to financially support you, is there any way of doing
| one time donations to the foundation itself?
| hiatus wrote:
| It seems that's the only way according to their "support us"
| page.
|
| https://www.openhomefoundation.org/organization/#support-
| our...
| balloob wrote:
| We don't want to come to rely on donations and have to show
| Wikipedia-style beg banners in our app (I would personally
| hate to see that myself).
|
| So with the limited resources that we have, we currently only
| consider bigger donations valued $10k or more. We've had
| monetary donations from DuckDuckGo and Espressif so far.
| magicalhippo wrote:
| I didn't get the begging feeling from using Blender, though
| it has been some years ago. IIRC they focused on donations
| for specific features and showpieces like their movies.
|
| As a very happy Home Assistant user, hopefully you can
| manage something similar so you have enough money to stay
| afloat and keep up the good work.
| bonzini wrote:
| Maybe you could allow people to pay more for Nabu Casa?
| Blankono wrote:
| beg banners or awareness campaign.
|
| I never had issues with that.
| devwastaken wrote:
| smart homes dont work because wifi doesnt work. almost every
| user is running low quality hardware or does not deploy a
| meshing AP to reach the devices. the devices are not resilient
| to lost packets and high latency
|
| just change a wifi ssid with smart devices in a home and watch
| it all crumble. users want nothing more than to get rid of
| "smart" once they realize its not smart enough to figure out
| how to change wifi networks.
|
| endless "updates", rent seeking, breaking changes, account
| setup - its not worth it.
| Calwestjobs wrote:
| when you last complained about Torvalds rent seeking lol.
| Hikikomori wrote:
| There are WiFi alternatives.
| stavros wrote:
| You don't have to use WiFi, this whole argument is just
| invalid. Use Zigbee instead.
| alwa wrote:
| You should check out Home Assistant and the vast range of
| ecosystems it integrates with! There a dazzling range of
| radio standards and manufacturers that have considered the
| problems you're describing.
|
| You could (and I understand many people do) run an entire
| smart home without any WiFi at all, if you'd like.
|
| Home Assistant is free and open-source, and I understand from
| his comment above that their founder generously donated the
| project to a non-profit foundation to sustain it that way for
| the future.
|
| Which is awfully reassuring with respect to the rent-seeking
| incentives you're worried about.
| bluGill wrote:
| I got frusterated with HA's attempts to make is hard to run
| outside of their distro and installed openHAB. I find that works
| good enough for me.
| liotier wrote:
| Funnily, I had the opposite journey: I got plainly frustrated
| with everything OpenHab and was delighted with the versatile
| integrations and ease of setup with Home Assistant...
| bluGill wrote:
| If you use openhab as they want it is easier. However if you
| don't want it it on a dedicated computer it becomes much
| harder.
| linker3000 wrote:
| I tried HA back in the day and got YAML-bound trying to get
| various sensors and controllers to integrate and work reliably. I
| revisited HA a couple of times over the years, but by then had
| become cosy with Node-RED and saw no strong reason to change. I
| understand HA's now more configurable through the front-end GUI,
| which is nice.
|
| I've just integrated an office UPS with the Node-RED stock
| dashboard to log status, mains voltage and battery charge state -
| it took all of 5 mins, including the time to install the UPS NUT
| plugin for Node-RED via the GUI.
|
| I love the ease of the visual, block-based configuration, and the
| ability to add codable function blocks to process and modify
| data.
|
| The only things that are not so great in Node-RED are the
| dashboard look and feel, and the dashboard setup tools.
| mkoubaa wrote:
| Looking forward to the day we might have home appliances
| _without_ on board cpus, they will just be LAN wifi firmware
| devices. Something like HA could be used to make them as smart or
| as dumb as the user wants without giving the manufacturer any
| control over the UX
| baq wrote:
| That's literally Zigbee.
| tomhow wrote:
| Please note this is a two-part series. The second part can be
| read here:
|
| https://lwn.net/SubscriberLink/1017945/93d12d28178b372e/
|
| Someone posted that URL as a separate submission shortly after
| this was submitted, but rather than splitting the discussion,
| we've merged the comments here so it can all be discussed as one
| topic.
| homedespot wrote:
| I started using home assistant when it first came out, found it
| too clumsy, returned years later, and found it too bloated.
|
| A lot of volunteer work has gone into it but it lacks overall
| coordination of efforts and a usage model that is simple and
| consistent. That's one of the downsides of open source: too many
| cooks and you get mediocrity, but accidentally when everyone is
| good hearted about it.
|
| I had to do so much research on appliances I was adding that it
| was easier to just roll my own gateway and cloud. Now it is a
| vastly smaller code base that I control and can easily debug
| issues.
|
| Maybe HA could refactor into a smaller set of modules that
| doesn't require a huge set of assets from the get go?
| MostlyStable wrote:
| Is there anywhere that compiles a database of local control
| capable smart home devices? I tried briefly to search and I found
| databases of smart devices but none seemed to have that as a
| filter.
| gempir wrote:
| The Home Assistant docs at least document how the integration
| works by "IoT Class"
|
| https://www.home-assistant.io/blog/2016/02/12/classifying-th...
|
| For example Tado: cloud polling
|
| https://www.home-assistant.io/integrations/tado/
| ldng wrote:
| Well clearly he did not look under the hood ... I did. A few
| technical decisions are ... questionable. But it's prohibited to
| ask why in the forum. HA could do well in cleaning up its
| community that can be particularly toxic, especially toward
| advanced user and start accepting critics. The hostility one face
| when they don't want to follow the "dumb down version, do as we
| say" installation process is really off-putting.
| dfc wrote:
| Its not prohibited here. What technical decisions are
| questionable?
| billfor wrote:
| Yes it's prohibited I posted a few corrections (one positive
| , one negative) to his technical review, and it got
| downvoted, as will this probably....
| jolmg wrote:
| I wouldn't consider downvotes to mean something is
| prohibited. I did in the past because that's what I limited
| myself to downvoting, but people just downvote what they
| don't like for whatever reason. All you can do is to not
| let it get to you.
| Bjartr wrote:
| "prohihited" implies an official rule enforced by the
| community organizers. Downvotes are an expression of
| opinion by community members.
| traverseda wrote:
| Home assistant supervisor is not very friendly. It's designed
| so that it _must_ be kept up to date, and handles it 's own
| auto-update features. It also won't run nicely in a docker
| container with some significant hacks. This means that the
| only deployment option if you want a _complete_ home
| assistant install is to use their "Home Assistant OS" or
| specific debian versions.
|
| Generally it feels like they're making deploying it as hard
| as possible, doing stuff like checking if supervisor is
| running in a docker container and just not working if it is.
|
| This is presumably born out of frustrations with users
| deploying it incorrectly, but there really is no reason a
| supervisor based HA install can't run in a docker container.
| I've got a some private hacks doing just that, that I'm
| hesitant to post publicly in case they find some way to break
| it.
|
| No idea what the obsession is with keeping a full home
| assistant install from running in a container, but it's very
| strange. Trying to add more friction so they can sell more of
| their dedicated hardware? Their hardware is nice and stands
| on it's own, the only reason I don't use it is because I want
| to run on an old touch screen chromebook for very low power
| usage.
| jillyboel3 wrote:
| I've been running home assistant in docker for years. Just
| the `homeassistant/home-assistant` image. Don't need
| anything more. Best I can tell is that the supervisor is
| for people who just wanted a managed home assistant in a
| box setup at which point it's fair for the software to take
| over the system.
| watusername wrote:
| As one example, they (core contributors and founder) were,
| and still are, very heavy-handed regarding how you are
| allowed to install their software:
| https://news.ycombinator.com/item?id=27505277
| billfor wrote:
| > Home Assistant has support for that remote option, and no
| others.
|
| The openHAB Cloud Connector allows connecting the local openHAB
| runtime to a remote openHAB Cloud instance, such as
| myopenHAB.org, which is an instance of the openHAB Cloud service
| hosted by the openHAB Foundation
| (https://www.openhab.org/addons/integrations/openhabcloud/)
|
| > There is also a container-based method that can run on another
| distribution, but this installation does not support the add-ons
| feature.
|
| You can use the add-ons with the containerized version. This has
| been discussed elsewhere.
| MacNCheese23 wrote:
| I don't really get HA. It seems oversized for what most people
| need for their own home automation. Maybe I'm just jaded because
| my house is fully KNX wired, but the only "addon" I need is
| NodeRed for some Dashboard and Integrations of ESPs that are just
| for additional monitoring. It runs in a lonely docker container
| just fine and does not need a million dependencies.
|
| Then again, I also don't understand why people buy every
| "smart"/cloud based device and try to glue everything together -
| when the hardware fails most likely the vendor does not exist or
| no longer supports it anymore and then you start all over again.
| pkulak wrote:
| So, this comment boils down to: "this free software project has
| too much capability, and there exists hardware that is reliant
| on cloud servers."
| cbull wrote:
| Your house is wired with an alternative and you can't imagine
| people who DON'T have that infrastructure are looking for a way
| of doing smart automations?
|
| I have been using HA for years and I love it, it does what I
| need it to do while operating quietly in the background. I
| don't have any devices that are "cloud based" so I don't care
| if the vendor goes out of business or not.
|
| My stuff is a mix of wifi, z-wave, and my cameras are ethernet
| cabled but can be integrated with onvif.
|
| My house was also built in 1958, there's no chance I'm running
| KNX cabling anywhere, much less all the places I have devices.
| jillyboel3 wrote:
| > Home Assistant has support for that remote option, and no
| others.
|
| It's literally just a reverse proxy. Set up any you like.
| Wireguard, cloudflare tunnel, caddy with a security plugin, the
| options are limitless.
| greatgib wrote:
| Something that annoys me a lot with recent versions of HA is that
| it does not play well anymore with yaml file configs. Your are
| mostly forced to configure things through the interface, that is
| ok but might be annoying and painful to do when you have a few
| devices with a little bit more complicated setup.
|
| For example, I wanted to replace a light bulb by another one that
| has a different Mac address to replace another one exactly.
| Before it was as simple as changing the Mac in the config file.
| No it is more complicated.
|
| Also it was very easy to review and backup the config files. Now
| it is less obvious.
___________________________________________________________________
(page generated 2025-05-17 23:00 UTC)