Some comments:
- Yes they are expensive. BTW have you looked at the cost of non-Ikea lamp fixtures... High end house furnishings are crazy expensive. The issue is not "they cost so much", it is "can I figure out a way to make them look nice in my home".
- If you want something cheaper, look at Yealink on Amazon. BUT the Yealink hexagons are quite a bit smaller (about the size of a fist) and quite a bit thicker.
- The BIGGEST problem with these devices, no matter who is providing them, is that not one of the companies involved has a single brain their entire corporate organizations. Not one of these devices comes with any sort of usable programmability. So you may start with grand ideas of using them as status lights, to indicate the expected temperature tomorrow, or the humidity, or the AQI or whatever. But as soon as you try to do anything you'll find it ranges from impossible to just so damn difficult and fragile it's not worth the effort.
You want to program them in HomeKit? HA HA HA. Ever tried to use variables within HomeKit routines?
You think you can do it with a HomeKit-based shortcut? HA HA HA. Same problem that variables don't work, AND with the extra joy that Apple appears to have broken these with tvOS 13.3 and they're not fixed yet.
You think you can use the native app? HA HA HA. Look at EXACTLY what the native offers, not what you hope it offers, or what you think it should offer.
You think you can use IFTTT? Now you're starting with something that MIGHT work BUT
- how do you plan to bridge the gap between the scripts running at home on your hub and IFTTT communication? You can't make the webhook calls in a HomeKit routine, and for a Shortcut, see above -- it won't run right now on tvOS.
- HomeBridge? No way. Right now HomeBridge is basically read-only --- it can provide fake sensors and devices for HomeKit BUT it cannot read HomeKit values (so you can't get at your humidity sensor or whatever) AND it's not a scripting hub, so right now at least, you can't put node-red or JS scripts on it.
- addressability of the individual lights is a major PITA
- the IFTTT service always looks good when you finally get to skim it (and you CAN'T skim it until you have registered with Nanoleaf...) but these services are always poor cousins that the company just doesn't care about.
So the Hue IFTTT service, for example, offers extremely limited ways to set colors, and ZERO support for either color temperature or their White Ambiance bulbs...
What about going really low-level? Yes, you can talk to these types of devices via a REST-like API. And that kinda sorta gives you full control. But at that point you're not just a hobby scripter, you're a full-on developer. You have to do discovery yourself, figure out the devices of interest, manage a persistent store mapping the user-level names to the device addresses, write the app in full-on C/Swift/JS, and find an appropriate place to host it. Of course all this is doable; but it's now a project taking a month or two, not one day of play and fiddling to try to get them to do what you want.
And, like I said, NO-ONE in this space has a clue. Phillips Hue is just awful for a developer. All the Chinese stuff (Tuya/Smart Life/Yealink/Govee/...) is both a random crapshoot as to HW quality, the API stuff is REALLY rough, and they have paid even less attention to RAS than the Western companies. (So maybe you don't care that every interaction with your lightbulbs goes out over the internet, it's not handled locally -- but you probably will care when they stop working because your internet is down.)
And Apple? Apple should fire every single person involved in HomeKit and start again from scratch. That team has had five years to work on it, and after five years the app is perhaps the lousiest 1st party app on iOS (a field with some pretty serious competition!), it's riddled with both UI and lower level bugs, it provides less support for programming than shipped with an Apple 1 (not even comments, FFS!), and it's riddled with incomprehensibly moronic design decisions: eg is the target action of an automation rule a scene or a collection of actions -- how about we make it one thing in the API, something different in the UI, and then leave it up to the user to slowly go insane as we randomly toggle between the two?
So bottom line, IMHO:
- if ALL you want is pretty lights synced to your TV, get govee light strips with a camera. Whole shebang for around $70, no fuss, basically works.
- if you want nice panels on the wall that change colors, but don't need them to be very large or provide much light, look at the Yealink. A LOT smaller, a LOT cheaper, maybe do what you want.
- if you want something that looks like the nanoleaf photos (and don't mind the white edges), man up and pay the nanoleaf cost. Ain't no-one selling anything in that size and thin-ness for a lower prices. But, do us all a favor, and do a web search for "how to hide cords" and hide the damn power cord! Your pretty lights shouldn't lose appeal from such an obviously visible power cord. Paint it the wall color, stick in the wall, run it through a copper or stainless steel vertical pipe (think curtain rail) or decorate it in a very obvious way; don't just leave there as a visible white cord!
- if your dream is to control the panels on your terms, not just accept whatever canned color scenes nanoleaf (or hue, or yealink or ...) provide, give up now. Yes, you CAN make something happen today, if you are smart, determined, and willing to try fifteen things before one finally works. But it will take you weeks to get there, and along the way you will frequently alternate between profuse crying and clinical rage at the stupidity of every single person involved in these %$#@ing lights and their APIs.
[automerge]1588442189[/automerge]
They look rubbish, the white borders around the edges ruin the look. Helios Touch hexagons look nicer.
Those are quite a bit smaller and, I believe, thicker. That may or may not matter to you...