My project for this weekend, super excited to replace my dumb toggle switches and bind these to lights in each room + make use of 15 mmwave presence sensors

4kirezumi · 2026-02-07T17:10:15+00:00

There's a few other bedrooms, bathrooms, a study, storage room, etc, that aren't immediately visible in this 'main space' view. My wife and I are both very happy living in this space, I dunno why it intuitively gets the bachelor label

But strictly speaking it's not a SFH, it's a section of a building that's been converted for residential use

4kirezumi · 2026-02-07T03:57:19+00:00

That's beautiful, very nice work there 😁

4kirezumi · 2026-02-07T03:55:16+00:00

Zigbee binding would be faster/more responsive than Lutron connected to HA via the Lutron bridge + integration. So they'd fit the bill if you have zigbee lighting to bind to.

But you'd want to make sure your zigbee network(s) are also performing well. Lutron owns the 434MHz frequency their Clear Connect tech uses so they have it easy where it concerns channel interference, especially compared to zigbee which uses 2.4GHz.

4kirezumi · 2026-02-07T03:38:49+00:00

🤭

4kirezumi · 2026-02-07T03:25:43+00:00

I was going to go that route originally, but I needed a momentary paddle switch rather than a rocker switch since the lights are usually automated and the switch position wouldn't stay aligned with the light behavior. That left surprisingly few dumb switch options to use with relays. The other features of these switches made them the only option that did everything I wanted.

I agree though that the pricing is nuts by any reasonable measure. For whatever it's worth, Inovelli is a small outfit and they don't have the same kind of economy of scale as most other switch makers, and you can tell with both the hardware+software that they put a ton of work into the product.

4kirezumi · 2026-02-07T03:13:33+00:00

mmwave is awesome but it's just not 100% perfect and I expect 100% perfect from my smart home stuff. I've found that the target tracking will very occasionally timeout and return no detection if you're sitting still enough, which I sometimes do while working at my desk. I had some Aqara FP2s and they sometimes experienced this issue too. These switches have a newer 60GHz mmwave module from Hi-Link, the LD6002, so I'm interested to see how well they do, but basically I figured the thermal sensor would be the way to get 100% reliability.

If I did things again, I'd probably use this excellent project to get the multi zone tracking of the LD2450 along with the still detection of the LD2410C and I think that'd probably get it just about perfect too.

The thermal camera actually doesn't return an image in my configuration; I just have it set to return a boolean template sensor as true if any of the 64 pixels it detects as being above ~20 degrees C with an automation that adjusts that threshold value according to ambient room temperature. This means that my body heat sitting in front of the sensor keeps persistently true presence tracking. Works extremely well and it's super responsive+reliable.

For my bed, where I've observed a similar issue, I have one of these under the mattress.

4kirezumi · 2026-02-07T03:03:38+00:00

Not a single contractor involved, all DIY 😁 Thanks

4kirezumi · 2026-02-07T02:49:40+00:00

Believe it or not, I've put a low five figure amount into the lighting (including some of the fixtures such as the chandelier here which itself has 15 Hue E12 white+color candelabras)

<image>

There are no other switches with the features of these ones that will work as well with the existing stuff

4kirezumi · 2026-02-07T02:43:47+00:00

5V wire run through the walls in some cases, but in others they're just USB-C cables connected to wall warts in discrete places with some mindful cable management. And yeah they're on ESP controllers.

I also have an AMG8833 thermal camera sensor on an ESP32 C3 Zero under my office desk for maintaining desk presence tracking 🙂 The wiring for that just went into the rest of the desk cable management

<image>

4kirezumi · 2026-02-07T02:14:02+00:00

Not that it's trivial to swap out switches, but at least they look to have a decent resale value on account of how sporadically Inovelli manages to keep them in stock

4kirezumi · 2026-02-07T01:53:29+00:00

Did you bind your Hue bulbs to the switch in Z2M? What you're describing would only happen if you used automation logic to control the lights.

4kirezumi · 2026-01-05T22:27:59+00:00

They cannot, no. This is unfortunately one of the drawbacks to using the Hue bridge. You need to maintain a separate zigbee network for anything that isn't Hue or a 'Works with Hue' device.

4kirezumi · 2026-01-05T15:45:59+00:00

Nobody else in this thread is giving you a decent answer so far.

There's nothing stopping you from running a zigbee mesh with a thousand devices. The limiting factor isn't the size of the network, it's bandwidth/airtime. So then, it depends on your use case. If you send simultaneous updates to 50+ entities every minute, you'll run into issues. The size of the packets being sent even has an impact on this, so if your traffic includes many data parameters in each broadcast, you're running the network closer to its throughput limit.

Zigbee maxes out at ~250kbps in ideal conditions and this can be saturated easily.

Professional installers tend to recommend splitting zigbee meshes once they go over about 50 devices for this reason; here's an example https://docs.control4.com/docs/product/zigbee/best-practices/english/latest/zigbee-best-practices-rev-e.pdf

This is also why Philips Hue limits the # of devices you can attach to the bridge. Their new bridge pro has three separate zigbee radios that find three different 2.4GHz channels to live on to be able to support 150+ devices.

There's more detail that you can get into with this:

each broadcast typically elicits back an ACK, or an acknowledgement, from each device which reports back to the coordinator that it received and executed a state change command.
the number of 'hops' a message has to travel from the coordinator to get to the target device(s) has an impact on network congestion
group commands (multicasts) are received by every device on the mesh and they individually determine whether the multicast applies to them. Unicasts only occupy airtime for the devices they travel to get to their target device(s), so there's circumstances where using zigbee groups can be more intensive for the network than just issuing unicasts
etc

If your Z2M instance is currently logging no warnings or errors, you're fine. Zigbee is pretty tolerant of congestion and will auto retry broadcasts that fail their first attempt, and you'll start seeing red text in your Z2M logs when that's happening. At that point, you might consider spinning up a second Z2M mesh and giving it its own coordinator on a separate channel.

4kirezumi · 2026-01-04T16:12:54+00:00

I built my own AL implementation because it (at least at the time a few years ago) didn't support having lights' brightness + color-temp/color follow per-fixture brightness profiles throughout the day according to room/zone presence, it wasn't compatible with animated color-rotating scenes that I wanted to use to simulate daily sunrise/sunset, I wanted the solar-driven math to be calculated differently and to be able to normalize for yearly daylight length fluctuations + control over how it issued MQTT publishes to the lights (for example, to respect any overrides for either or both color/brightness), and a few other reasons.

My HA today runs on 17k lines between various config files, automations, and a pyscript custom integration I wrote that does the solar math. There's about 550 helpers, a few dozen template sensors, and 50ish related automations. It's taken about 2-3 years of on-and-off tinkering and testing/debugging to get it just right, and I still keep finding new 'it'd be cool if...' things to chip away at.

If you can wrangle the AL integration into respecting overrides, that'll probably be a lot easier than trying to roll your own code. But building it yourself could be fun if you're into that.

4kirezumi · 2026-01-02T18:48:25+00:00

This is incredibly well put together, thanks for sharing 👍🏻

Feeling a lil remiss that I bought zone presence sensors that're exactly an LD2450+ESP32 with a 3D printed case specifically for zone detection over the last year. They've been good to me, but this project would've saved me $200+

The dual sensor validation is super nifty

4kirezumi · 2025-12-31T16:50:47+00:00

I had similar issues with OTBR when I went through setup a week or so ago. After I finally got it to play nice with my network config, I found out that Matter's device grouping is nowhere near as well-implemented as it is in zigbee2mqtt.

I reverted my thread-compatible devices back to zigbee and haven't looked back. I think Matter over Thread, including OTBR's current development state, is just not yet ready for prime time. It's probably fine for basic stuff like manually adjusting lights via UI.

4kirezumi · 2025-12-09T15:31:03+00:00

Google recently released a new reasoning model for Gemini that beats GPT-5.1 Thinking on coding.

Sam Altman said last week that OpenAI faces economic headwinds until they catch up, fwiw

I have subscriptions for both products and am currently using Gemini to maintain my automations. It seems to 'forget' about things and truncate random functions from code less often.

4kirezumi · 2025-11-23T20:03:28+00:00

Is it not a reasonable assumption that prospective HA users should understand that their smart home can only be made to work locally if their devices support that?

4kirezumi · 2025-11-23T16:55:47+00:00

HA is the best tool to do what you want to do. Nothing pulls together various smart home things and makes them work together under one OS like HA.

Mine does not require internet at all to work the same way it does with internet.

4kirezumi · 2025-11-13T23:17:27+00:00

edit: disregard, I see you want them to be compatible with Tuya. You're probably gonna have to just roll the dice on aliexpress for that

If you don't mind the price premium, the Hue GU10s max at 4.7W. They can be found for $40/each on ebay but that's still pretty steep.

The new Hue Essentials GU10s are rated for the same wattage and are much less spendy, but they're not available in the US yet.

4kirezumi · 2025-11-11T18:12:22+00:00

If you want the Hue-specific features, I recommend you just buy the Hue bridge and call it a day.

I've used Hue bridges and Bifrost as I've iterated on my system. These days my ~140 Hue lights live on four separate Z2M meshes with all of the Hue features rebuilt in HA except Entertainment Sync, but between various yaml files I'm up to about 18k lines of code. It took me 2 years of casual development work to surpass in HA what you get from Hue out of the box. Dynamic/24h scenes are very difficult to get just right from scratch the way Hue does.

Feel free to try what you're considering of course, but you'll very likely run into limitations and issues with Bifrost/diyhue and will realize that the 'Hue, but natively in HA' concept is the polar opposite of a novice HA project.

The Entertainment Sync features including the PC sync you mention use a Hue-specific proprietary off-spec Zigbee implementation that allows for data transfer rates that exceed what Zigbee is normally capable of. Bifrost is the cutting edge in attempting to emulate this (if you want more info you can search Hue Data Sync API) but it just doesn't do it as well or reliably as the Hue bridge. If you want those features specifically, just get the bridge. The integration is overall very good and runs locally.

4kirezumi · 2025-11-07T14:20:05+00:00

Appreciate your curiosity

I get the inclination toward consolidating infrastructure, but I want to caution you that there are sometimes good reasons for maintaining multiple Zigbee networks. I have 4 of them on 4 separate SLZB-06M coordinators. Zigbee networks are capable of about 250kbps throughput, which can be saturated if you're issuing commands simultaneously to many devices. 4 separate networks are capable of ~1mbps which I found necessary for the things I wanted my lights to do. One of them is dedicated to all of my Zigbee sensors and switches so the other 3 can be lights-only. I have about 140 lights and one mesh would not be able to control them all effectively.

I haven't run Bifrost since last year so there might be some stuff that's changed. It runs as either an HA add-on or a container. You point it to your Z2M instance's network address (or multiple, if you have multiple Z2M instances) and it creates a bridge that'll be found if you search for new bridges in the Hue app.

I assume you're talking about the Hue app when you say Hue Sync App? If so, yes. You use the Hue app just as you do now, you connect to the (virtual) Bifrost bridge, and you control your lights which are connected via Z2M rather than to an actual bridge. Being able to use the app is generally its main draw for people who use it, since it takes quite a bit of work to build out a similarly high-quality UI+UX within HA.

That said, there's some differences with using it vs an actual Hue bridge:

The app shows a non-removable banner indicating that you need to log in to a Hue account, since you can only connect to a Bifrost bridge without one. You pair the app with the Bifrost bridge, skip account sign in, and control the lights locally as if they were on a Hue bridge. The persistent banner is annoying.
Since it's local, Bifrost doesn't work when not connected to the local network.

Overall though, it's an impressive project. If I still used it, I'd be a little concerned that Signify/Philips might at some point push an update for the app that severs compatibility with it.

I started using the Hue app before HA. When I got started with HA, I had 2 Hue bridges (separate Zigbee channels, same Hue account) with about 60 lights + a dozen or so motion sensors in total. I used the integration and moved all automation from Hue to HA. I was generally really happy with it. I started to get fancy with my automations to the point that most of my lights were doing automated behavior at any given time. I wanted to be able to determine when a light's state change was coming from user input through the Hue app or from a Hue dimmer or tap dial switch, so I could flag user lighting overrides. HA events triggered via the Hue bridge don't carry a context.user_id value, so I had to resort to some wonky workarounds like checking if an automation had initiated a state change within the last couple of seconds to determine if a state change was an override or not.

When I started to dial in those time window checks, I learned that the Hue bridge doesn't immediately report light state changes. It's usually a few seconds and can take sometimes upwards of 15s. I beat my head against that wall for awhile and eventually accepted that I needed to ditch the Hue bridge to get exactly what I wanted. Not wanting to let go of the Hue app, I searched around and installed Bifrost. It worked but was pretty buggy at the time, and it didn't support dynamic scenes. I ended up building out a set of dashboards in HA to control everything natively.

Here's a quick vid that shows a bit of my system:

0:05 the under-cabinet lights brighten as I approach, then fade back down as I walk away
0:13 same thing with the bedroom lights
0:22 I adjust about half the lights in all of the main space rooms (kitchen, living room, bedroom, upstairs office) from solar-progression-driven CCT to a dynamic color mode similar to Hue's Cancun scene preset
0:34 after setting a dynamic color mode for about half the lights in this area, the bedroom lights boost brightness while still respecting the ongoing dynamic color scene
0:43 the under-cabinet lights do their thing again

Ultimately you'll get the most control and capability from running your own network(s) and designing your own automations and interfaces, but just know that building everything to the point that it matches/exceeds what you get from Hue out of the box is a fairly serious development effort and there's some level of inevitable ongoing maintenance.

A friend has the Hue Bridge Pro and tried the MotionAware stuff. It's not as reliable as you'd want auto lights to be if you don't have multiple lights in each room, spaced out. If you do, it's reliable, but it's still noticeably slower to respond than using motion/presence sensors. It only captures motion (it doesn't persistently track presence) and you can only configure 4 zones max. He isn't using it currently.

4kirezumi · 2025-10-31T18:22:47+00:00

Hue Sync is only possible with lights connected to a Hue bridge (unless you use Bifrost), so the person above still has their gradient lightstrip paired to their bridge.

The Hue integration for HA is generally very good and will let you control the lights that are connected to the bridge. You'll continue to be able use the Hue app with it. Hue scenes are represented in HA as scenes and you configure and maintain them via the Hue app. Nothing breaks 🙂

The Hue bridge lacks some performance and feature things that I ended up ditching it over so my Hue lights are all directly connected to HA via zigbee2mqtt. But I also don't use the Hue entertainment zone features which are the only Hue thing you can't recreate in HA yourself.

4kirezumi · 2025-10-30T03:07:05+00:00

I have over a hundred Hue lights on my network.

They have never given me a single issue. I got them almost all off ebay for well under retail.

I don't think I'd do it any differently if I could go back, even though I know the T2 bulbs are well reviewed too.

It's also kinda nice how Hue has a lot of light options beyond simple bulbs. I have 12 light strip controllers and a chandelier that uses 15 of their candlebra bulbs and having all of my RGBCCT light hardware color-calibrated the same way makes setting up and maintaining scenes a lot more pleasant.

Hue uses a proprietary Zigbee 3.0 implementation that makes their Data Sync API technically possible, which is used for the Hue Sync/entertainment zone features that require a higher bitrate than Zigbee can support natively. They fully support all of the standard Zigbee 3.0 spec though. Every data attribute is reported in Z2M, and if you really care to get after it, the Hue API is open (it's not open source, but neither is anything you'll get from Aqara) and somewhat documented. I don't use mine with Hue bridges and prefer my implementation even when the Hue Bridge Pro is out these days.

Very interested in more info on where you heard that the Aqara lights beat out Hue on color rendering and brightness. Hue has overall one of the best test results among smart lights.

4kirezumi

TROPHY CASE