Replace Philips Hue Automation with Home Assistant's
blog.frankel.ch
blog.frankel.ch
I've also gone the Zigbee2MQTT (ZQM) route instead of the ZHM built into HomeAssistant as it just supports a lot more, and a lot better in my experience.
Once you're in the open world of Zigbee, you can also go the Ikea Tradfri route as well for bulbs that are a WHOLE lot cheaper.
I've found HomeAssistant with Zigbee to be extremely reliable, but the idea that a botched software upgrade or failed VM could make it so I can't turn my lights on and off feels like a bit too much. Caseta doesn't use an open protocol, but it does allow all your switches, remotes, lights, etc, to work totally independently of HomeAssistant or Internet/WiFi, and the hub allows integration with home automation or remote control. I've played around with Philips Hue and other smart bulbs, but it feels too much like a toy rather than something I'd replace all of my lights with, and ultimately I ended up with an all Caseta light setup for my home.
Why is "work[s] totally independently of Home Assistant" a desirable property?
https://www.zwaveoutlet.com/pages/z-wave-associations
https://www.silabs.com/documents/public/application-notes/AP...
https://inovelli.com/collections/z-wave-light-switches-red-s...
https://www.getzooz.com/products/
https://leviton.com/products/dz15s-1bz
https://byjasco.com/products/smart-home-automation/z-wave
How are any of these functionally different?
Why is this an issue? Z-Wave is a mesh network, all hardwired switches/outlets/etc. are repeaters by default.
> low volt LEDs in your kitchen like I do
What is "low volt?" 12-24V? I have this in my kitchen using a 110V -> 24V dimmable LED PSU and a Z-Wave triac dimmer.
Zigbee is not Z-Wave - Z-Wave has far more definition and structure to available devices and can do everything Lutron can do at this point.
That’s not entirely correct. Zwave is more expensive because if you want to sell your zwave solution there’s a monopoly on zwave. Nothing to do with complexity or age.
As for “better performing”, I don’t even know how to respond. Latency? Reliability? Power? Bandwidth?
Zwave in general is better then zigbee due to lower frequencies and staying out of WiFi/bt. However it is more expensive and less options.
Any that you'd recommend in particular?
For zwave, the best actual physical control was with Leviton - they have a rocker switch for dimming and are therefore easier to use than most. They don’t support multi-press scenes or anything like that but I found that to be a bit of a gimmick anyway, and dedicated buttons are a better option.
Inovelli had the most features, but aren’t precisely colour matched to other brands - they are kind of whiter than the standard white colour so stand out if you put them in a bank with others or against certain face plates.
In my new house I have a few zooz switches for special cases alongside Lutron for everything else and Zooz work fine.
Inovelli and Zooz dimming controls are both done by holding down the on/off paddles which isn’t intuitive for visitors, and it’s hard to fine adjust without resorting to app control.
Of everything my favourite is Lutron Diva for hands down the best looking and easiest to use actual physical control but these use a proprietary (albeit easy to integrate) hub.
Zooz is probably a close second, and probably the go-to for switches, relays, smart plugs, sensors, etc. today.
I do have a couple of zwave dimmers for special cases (dimmer and fan in one switch), and they support zwave association. Without the hub being available, one switch can turn on another - you could have the light turn on a fan, for example, or associate a remote control to a light. Zigbee has a similar feature.
A: > the idea that a botched software upgrade or failed VM could make it so I can't turn my lights on and off feels like a bit too much. Caseta doesn't use an open protocol, but it does allow all your switches, remotes, lights, etc, to work totally independently of HomeAssistant or Internet/WiFi
...I got the OG yellow/amber when it was kickstarted, and have added a 1tb NVME and a z-wave dongle (it came with zigbee).
The newer ones (green) have "ditched" internal networking other than wifi for compliance / regulatory reasons (eg: 1 hardware radio == complex, 2-3 hardware radios == exponentially more complex and requires differing international certifications).
https://www.home-assistant.io/green/
https://www.home-assistant.io/connectzbt1/
https://www.home-assistant.io/docs/z-wave/controllers/
https://www.home-assistant.io/common-tasks/os/#home-assistan...
...as that reddit thread alludes to: you're fairly better off chasing an old NUC-type-thing and just plugging in the extra dongles to that anyway (potentially zip-tying a hub, or maybe getting some 90º USB connectors so you're less worried about snapping things off if it gets bumped, dropped, or stepped on).
The software is pretty darned solid, I've dug into it a fair amount and haven't had much issues with it in the ~3-4 years I've had it.
As the CLI link describes, there's 2-3 layers of "reliability" going on: core => supervisor => host. Basically the supervisor will restart / rotate / backup the HA-core (aka: docker image), and you can occasionally update the "Host" (aka: OS). https://www.home-assistant.io/installation/linux/#install-ho... ...their HomeAssistantOS basically wraps all that up, and if you install it "that way", you effectively turn whatever hardware you're using into an "appliance"... really, just depends on what layer you want to handle your O.S. updates (ie: throw HA on as "just another service" on your homelab? ...or "let the little box manage itself").
The reason I added Z-Wave (eventually) was to get access to an exterior-rated, dimmable plug/extension cord (dimmable string lights) ... HomeKit ones were finicky, and I couldn't find any good ZigBee ones. The reason I added an NVMe inside (eventually) was I wanted to chase using it as kindof a plex-ish / backup / media server, but there's "gross" issues with HA's backup strategy by default (ie: it backs up the "whole HD", including `/Media/...`, which makes backup times exponential compared to "just the *.config.yaml", and effectively halves your usable disk space).
Since you'll have to buy some of those dongles anyway, start with that and do the "home assistant OS running on a rpi" route. Get a feel for it, and then jump in to a NUC which you can air-drop next to your family's cable modem.
I've got 80-90% of everything bridged over to Siri/HomeKit (all devices are treated "as good as apple home app", and only a few HA-specific "super-nerd stuff" that I've set up in the HA gui itself (ie: timed scripts for turning things on/off when we have a party in the back yard). You still have to pop in to HA when adding a new device, new device-type, or to update any of the three layers (integrations => home assistant => kernel/os/core), so like once every few months like any potentially vulnerable IoT device.
Overall, a solid 7-out-of-10 (because it's OSS) ... as OSS it's 9-out-of-10... just desperately needs some cohesion, GUI-love, simplification, etc, but the compatibility and power is all there!
Also: how hard is it to back up 6 YAML files and a small config directory?
Not sure what this means, but personally I dramatically prefer traditional "dumb" wired light switches that flip up or down to interrupt a physical circuit vs. Caseta wireless doodads with their little blinking LEDs, microswitches, and inability for "three way" switches to properly respect the primary dimmer slider's physical position.
Our contractor put in Caseta and it made me very happy to replace them with ordinary light switches. It makes me sad how much marketing and sales effort is going into pushing people into a brittle and overcomplicated computerized system trying to "fix" something that isn't broken.
It's on my bucket list to try and find a way to cram a full shim of an Australian Clipsal style light switch with a no neutral wifi and relay module so you can do this by just replacing the switch plates (as it is it's my way or going with capacitive touch).
My last apartment had fancy light fixtures with esoteric bulbs and old wiring. Caseta was the right choice there.
My new apartment has a kitchenette with proprietary LED lights, so I've migrated my Caseta system there. However, the living room and the bedroom don't have any built-in lighting at all - just some lightswitches hardwired to control certain outlets. I've circumvented the switches and replaced them with a Hue Wall Switch Module: a little transmitter that takes the analog circuit switch and converts it to a digital Zigbee event. This allows me to put lamps with Zigbee bulbs wherever I like and still control them with the built-in wall switch.
I know Zigbee bulbs can end up turning themselves on after a power outage, and I'm sure that can be annoying. However, there are some scenarios (like mine) where permitting the digital rough edges ultimately gives you a better solution than relying on whatever arbitrary decisions the electrician made.
Some switches don't allow direct binding, though. All of the Hue switches I tried support it, but some Tuya switches don't. On the other hand, all lights from different manufacturers which I tried were able to bind directly.
The first year I had to fiddle a lot with the tooling. The uptime of HA/zigbee2mqtt wasn't great. It was good to have this as a fall back.
The configurations you set up in Zigbee2MQTT are synced with HA and can be used there as well. I use the options provided by HA for higher-level tasks, such as automations, custom sensors, statistics, and more. Everything I configure there will not work when the server/coordinator goes down.
One kind works without ever needing internet access (on the IOT device itself or on the app if it uses an app) except possibly when you want to install a firmware update and perhaps when first setting up the device.
The other kind requires you to log in to an account from the IOT vendor, but doesn't actually need internet access to then use the device. The thing to watch out for with these is that sometimes the login has a time limit so you occasionally have to re-login. Or sometimes you have to re-login if the vendor's app updates.
An example of the latter is some TP-Link smart plugs I have. I only use them from Apple Shortcuts, but it is still TP-Link's app controlling them underneath and occasionally the shortcut stops working until I open the TP-Link. When I do that I invariably find that I'm no longer logged in, and logging back in makes them work again.
For lights in particular another thing to consider when choosing them is what they do on power up. Some let you set the behavior and remember that on the IOT device, typically offering some subset of these options: light off; light full on; light however it was when power was last lost; light on to a specific brightness and color.
Some have one of those behaviors and you can't change it. Typically "light full on", because that means you can use it both as an ordinary bulb that you turn on and off from a regular light switch and as a fancy IOT light.
For lights that you only occasionally need to dim or change color on that can be great. But for lights that you often want to turn on and off remotely so you need to leave the switch on all the time it gets really annoying because every time you get a power outage or often even a significant power flicker they turn off and come back full on.
That is really an implementation problem of your smarthome. Where we used to have unobtrusive javascript, enriching the web page as it got applied - you also can have unobtrusive smart switches: There are units which get built into the wall, yet allow for Zigbee connection: you both get to run the light in a smart and in a manual way. Many smart sockets also have buttons on them to allow a manual override.
I'm using zigbee relays placed behind my regular light switches. They work perfectly fine should the home assistant setup ever go down, with the added benefit that i can control them remotely too and react to them being turned on or off in other automations.
I just flashed a batch of 16 'energy metering smart plugs' this way using a TTL/USB adapter, two clothes pegs, three sewing needles, a patch wire and a breadboard [1]. No soldering necessary, just point the needles at the right chip legs, push the patch wire in the right spot and flash the firmware.
As far as I'm concerned this is the only way to use IoT devices, using free software under your own control. Software which only communicates with hosts you designate. Software which is not dependent on 'cloud' services. Software, above all, which can not be used to turn your equipment against you - not by spying on you, not by selling your data to others, not to bring down the electricity network by simultaneously switching off and on massive amounts of equipment every 10 seconds. Even so I run these devices on a separate network which can not reach outside of its own /24 (no IPv6 on this network, it is not necessary).
I also don't use Home Assistant since I prefer openHAB, at least for now. I've tried HA (core) but thus far I'm not convinced it offers something I can not get from openHAB which I've been using for years now.
[1] https://www.elektroda.com/rtvforum/topic4042412-60.html#2133...
They can! You can bind clusters from several devices together, I have a couple of such devices. For example, you can bind a two wall light switches together.
The problem is that the UI for it is typically hidden and/or absent.
However, you can also pair Zigbee switches to other Zigbee devices directly (although I've never tried it).
Less options for automation, but it's 100% local only by default. You need to specifically enable remote operation.
I don’t use any vendor hubs at all. Everything is directly connected to the USB dongles at the main network controllers.
I don't have any other Hue products anymore, but the hub still runs for those 4 switches.
It's separately a reasonable upgrade path for people becoming increasingly familiar with smart home tech, smart bulbs are a particularly easy entry point with clear added value with new features (white temperature is a personal favourite) and battery operated motion sensors, with a clear path to further home automation adoption with Home Assistant.
Generally I am happy with Zigbee, it's super annoying to pair, but for battery powered devices it's unbeatable.
I went from a some AliExpress USB Stick to a ConBee2 to the Home Assistant Yellow. I use Ikea, Sonoff, Xiaomi (Aqara) Zigbee devices all of them "just work".
The one big thing Zigbee is good at is not requiring you to need some proprietary App, all devices are just paired locally, you don't need to question if that app you just installed phones home.
For general hardware advice:
Overall the Home Assistant Yellow was the best choice overall, I would anyone who doesn't want to spend a ton of time on HA hosting to just buy it. Everything works pretty flawlessly with it.
Conbee 2 ist still my current stick because I am experimenting with the Matter/Thread Support on the Home Assistant Yellow, sadly without success though.
My best recommendation if you want to tinker with smart devices is get anything that you can flash Tasmota on. (List of Devices https://templates.blakadder.com/ )
Tasmota is an amazing piece of software that runs on your smart device for example a power plug.
https://tasmota.github.io/docs/
Get MQTT running on your Home Assistant device, or any in your network and start connecting stuff to it.
I have Shelly powerplugs flashed with Tasmota and that opens up so many possibilities.
For example, it operates on an "update" data model. There is no difference between a sensor being offline and not reporting info vs a sensor being online but reporting a repeating (previously seen) value. Add to that the way data is stored (two week retention; this weird relationship with Grafana and Influx where not all data actually goes to Influx from HA)... Even the date picker is frustrating.
I'm trying to center around MQTT, myself, but looking for a way to use many of the wonderful integrations created by the Home Assistant community. I'm also trying to find a good solution to "react to state changes".
Not for everyone obviously but it's simple and works well.
They let you use HA's massive library of supported devices, but you don't need to bother with their YAML "programming" horrorshow.
All the community is behind HA though, so it has the most integrations.
Weird, I have a device with a flaky wireless connection and when it is offline HA definitely reports it as unavailable. Graphs covering these time periods have gaps when the device was offline. Perhaps what you are seeing is device specific?
There was, I believe, no need to leave the light on when there is no motion.
(I hesitated on adding a motion-activated light to the bathroom because, for example, taking a shower might cause it to time-out and you would be showering in the dark.)
In any event I did not use any kind of networked device — just your standard $15 Lutron motion sensor light switch you can get from Lowe's or Home Despot.
I mention what is probably obvious because a use case in the article was to activate a light when it senses motion. No need to over engineer that.
_back_ that with an additional "Shelly" dongle (wifi control that is installed _behind_ the switch-plate), and you get both direct switch control, as well as direct WiFi control.
AFAIK the switch will override on/off when you hit it from the wall, and the WiFi will override whatever the current switch setting is. You never lose control from the wall-plate, and only gain control via WiFi.
I've had an Aqara FP2 for a while but haven't really found a killer use for it. Maybe the bathroom is that case.
Toilets, hallways, entrances etc. work just fine with IR motion sensors. See motion -> turn light on for X minutes. Optionally reset timer to X every time you see motion.
But for places like offices where you might be sitting relatively still for 30+ minutes, mmWave is better. It knows you're there and won't turn off the lights even if you don't wave your arms around :)
The price difference isn't that big though. You can get a HA compatible mmWave device in a nice case for ~50€. The official Philips Hue motion sensors (IR) are around 40-ish €, the really cheap ones like Shelly you can get for around 20€.
1. Get a Zigbee USB adapter (e.g. SONOFF's is great)
2. Get a Raspberry Pi Zero W
3. Install mosquitto and zigbee2mqtt.
4. Enroll your devices and schedule them using bash scripts and cron.
There was no way I was going to be paying Phillips for one of their shitty bridges or hubs after they intentionally gimped their Bluetooth control in order to force you to need one and then rugpulled everyone about not needing to register and log into the app. Dirty business. I'll never buy anything from them again.
The above took just an afternoon. Zigbee2mqtt documentation is great.
Especially since Philips is going the same route as all the other enshittified / cloud home automation services (requiring an account, pushing mandatory terms of service updates after the product is launched, cloud lock-in). It's probably just a matter of time until they stop producing Zigbee bulbs altogether but the current generation works fine with private / free home automation solutions.
I like Hue's rooms where all bulbs in the room are updated at the same time (seems like a basic thing), while others apps don't quite do this right. Applying a color change to the room vs each bulb in the room. I have one room with 3 separate light strips where the app "spans" a light patterns across each device. Again, not something other apps do without setting each individual bulb.
The Hue app works really well for me, and being unable to find an equally featured replacement keeps me on it
But if you start adding a second brand like IKEA (their bulbs are a LOT cheaper than Philips) or Wifi stuff from Shelly, you either suffer the trap of 3+ separate apps or bite the Home Assistant bullet eventually.
IMO Home Assistant doesn't really do a good job with controlling the lights. It doesn't have the creative abilities to create or choose predefined "cool" scenes. Besides I don't want to know how much work I need to do in Home Assistant to re-configure the smart switches from Hue and their features.
In the end I can still control the Hue bulbs with Home Assistant if I want to. The Hue app doesn't prevent you from controlling the Hue bulbs from Home Assistant
In the mornings and evenings all my lights are more yellow and bright white during the day.
The colour changing thing was cool for like 2 months, haven't touched it since (Except for my Hue Sync setup behind my TV)
For one thing, the Hue bridge requiring an ethernet cable is mind-blowing to me. My router doesn't have an ethernet port, and yes it does say on their website, but I wouldn't have expected it to be a requirement, especially when it actually has wifi capabilities on-device, they're just disabled.
Setting up HA was a real pain, it's definitely not "Plug and play". I used a Pi 4 and got a bunch of weird errors, and debugging it is not for the faint-hearted. Eventually I did get it working by downgrading to a year-old version, but now it doesn't recognise my Tapo (TP-Link's brand) lights, the integration just doesn't work.
Overall, it's quite a hassle to get set up so I see why people don't bother unless they've got a lot of free time or are really into it, or just pay the premium for an all-Hue system that does actually work out of the box.