Hacker News Reader

Comment by delusional | Hacker News Reader

> Certain manufacturer devices being flaky, yes, but as a platform

This makes me a little weary of your comment. I don't think I'd really care if my lights not working was due to a "manufacturer being flaky" if they worked yesterday, but don't today.

Are you talking about devices being flaky on first setup (which sucks, but is understandable), or are you talking about them being flaky after an update?

View on HN

I think one solid way of handling the instability is to use high quality light automation (Lutron Caseta, for example) for the things you'll really notice, but for stuff you care less about (for me that's cameras, temperature sensors) you can use cheaper ZWave stuff w/ home assistant. The lights turn on and off when I expect, but temperature might update a little less frequently if HA is flaky.

Long tail can be flaky, but in practice as long as you buy devices that are local first IE don't need to access the cloud you'll be fine.

(For temp and humidity sensors the Bluetooth Xiaomi sensors are great and they're about $5 each)

Honestly, for any sensor that's basically just read only, the best thing I've seen is to just avoid all of the bluetooth/wifi/zigbee/zwave entirely, and just use basic tried and true accurite (or similar) sensors that never need updates and just pull the data with rtl_433. Way, way less fuss, they always just work, batteries last longer, by and large zero bullshit.

It's the devices that is flaky. Some of the shitty bulbs I got don't always turn on in one command but that was true via their own app too. Basically shitty devices aren't magically better via home assistant.

> Basically shitty devices aren't magically better via home assistant.

I feel like half the griping about HA is people realizing all the hardware errata and physical reality bullshit embedded developers have to paper over on a daily basis.

E.g. no, you can't just read contact sensors without debouncing

If I had to guess, they're probably referring to the way that certain devices broadcast their APIs to external services. A lot of them have no intention of allowing open access to APIs (e.g., my mini-split controller requires a slight hack to get it connected to HA).

That is, the flakiness isn't due to HA updates breaking connections or an unstable server, but rather manufacturers designing closed and/or brittle systems. Try as they might, the HA authors and surrounding community can only do so much for such devices.

Also, I believe the word you're looking for is 'wary' (as in, to be skeptical or suspicious), not 'weary' (as in, to be tired). :)

I have several Aqara temp/humidity sensors that intermittently lose connection. They don't affect the operation/stability of the rest of the HA platform and is not a problem with HA, as my other zigbee devices that report the same data work fine.

I should probably just remove them, but I don't have any automations that depend on them.

Reply on news.ycombinator.com