my problem with being too critical of this is that hue is very open, very well documented and nothing else is.
declaring that you'll never buy another philips product ever again because they shut off hosted services support for a relatively flawed v1 device -- when a v2 device is available for £25 -- is pretty petulant imo. it will still work on your lan.
i've got 15 hue bulbs and a hue bridge but i don't use any of their cloud services. i control them via zigbee light switches on a raspi running homeassistant paired to the hue hub without any "hue cloud account" or any reliance on internet access or anything of the sort.
i don't know of another mainstream brand who will even begin to allow that without significant vendor lock-in.
They market their bulbs as having a 15 year lifespan. It's not unreasonable for consumers to expect the hub to have at least the same lifespan. There's arguments both for longer and shorter lifespan expectations on the hub depending on perspective (it's not a regular-replacement component / it has outside dependencies that can't be maintained without cost), but a reasonable middle ground of the life of the bulb is hard to argue against. Especially as the 'starter kit' is three bulbs and a bridge.
I remain extremely glad that my IoS components at home are all based around my own central service offering. This is a massive amount of work despite me knowing what I'm doing, requires regular upkeep, and is absolutely not what is being sold to consumers when they pay a premium for products like Hue.
Lifx has an entirely open and very well documented local UDP API, and a pretty open and well documented REST API.
On top of that, no need for a bridge or base station. They can operate entirely locally with no need for a mother ship if you don't need to control them away from home.
I make pretty heavy use of the UDP API from my local server and help maintain a Go library.
Those are WiFi though, no? Not exactly the same thing. Personally, I prefer a hub/bridge and then a mesh network for Home Automation. I’ve got Hue, Z-Wave, and WeMo. I much prefer the experience with the first two now.
Wifi, Bluetooth, cellular, bespoke solutions, etc. are all "just radio waves" yet entail a vast spectrum of engineering and business requirements including cost, power usage, implementation complexity, reliability, interoperability, and range.
The lifx bulbs require a bridge/base station.. it just happens to be a much more ubiquitous standard: WiFi.
The Philips Hue bulbs are pretty open. I use them with a Zigbee module on a raspi with no Philips Hue hub. Ie they work fine with standard Zigbee kit. You can theoretically pair them direct to other Zigbee devices without even a controller, at the expense of flexibility.
I was curious about those. How do they compare to Philips Hue in terms of colour spectrum and bulb quality? They are much cheaper and it would be great to be able to mix and match.
I non-scientifically feel like they are actually a shade more accurate and pleasing than the Hue bulbs. No idea what the actual numbers are, but at equivalent settings, the Ikea ones make the room feel a bit more like I want it to. I have a suspicion they have the better spectrum as well, but I may be wrong on that. The Trådfri bridge is a complete disaster though; color temperature can only be set to 3-ish presets that cannot be changed, even though the bulbs can do the whole spectrum, switches are very limited in what they can be programmed to do, etc., wayy behind Hue. I use their bulbs with a Dresden Electronic Conbee Stick on a Raspberry Pi and their software, works very well. The Ikea bulbs very occasionally flicker off and on again for a millisecond when paired to a Hue bridge; it's not frequent (every few days?) or very noticeable, but it's there.
I don't have any Philips Hue to compare and I also haven't tried their color bulbs. If you're still curious, I'd recommend getting a bulb that comes with a dimmer switch and try it out. It can then always be paired with the gateway if you want to go further.
I like that I can use the IKEA mobile app AND Home Assistant AND their control devices (dimmer switch, motion sensor, etc). The IKEA app allows for quick changes on the fly while Home Assistant handles automated tasks throughout the day while the control devices provide control over the bulbs when the software is too far from reach or potentially out of service. I also like the shape of the IKEA bulbs as they're more traditional and fit some old lamp shades. Cheers!
I love Xiaomi Yeelight smart bulbs. They allow LAN usage even in the official app. There is API documentation. It has been a great experience developing solutions using it.
Not for Xiaomi specifically, but I remember allowing some apps all the permissions they needed... then blocking some of them from settings somewhere, and they worked fine (for my needs).
Haven't had the need to do that in the past couple of years, I hope that's still possible.
Imagine you are designing the web server for some hardware like this.
You might write it in Go, dockerized and hosted it in Kubernetes in Google Cloud. You might use a hosted mongo db and 3rd party auth service.
Now in 30 years time, Google Cloud will probably no longer exist, your database API will have changed beyond recognition, and your auth service has closed down. IPv4 no longer exists and your hardware depends on it so you have to build all kinds of compat layers. You won't be able to get hold of all the packages for your server side code. The Go compiler probably won't even run on an OS 30 years from now. Your staff have retired, and nobody new wants to learn a programming language from 30 years ago.
Maintaining a server side API, even a really simple one, pretty much costs 1 fulltime person forever.
This hasn't always been the case. If you had written your code as a self-contained DOS executable back in 1990, you could still run it bare metal on some of today's hardware, or on any hardware without too much hassle in a VM. Hardware from 30 years ago running in a cupboard probably has a 50/50 chance of still being alive today, and if you had set up 2 backup machines at the time, you'd probably have something working now even with nobody touching it for 30 years, sans the occasional office move.
I hope you're right, but i'm not entirely convinced. IPv4 has proven to very resilient.
A survey in Denmark of pretty much all ISPs reveals that most, if not all, of the large ISPs have absolutely no plans for migrating to IPv6. Not as "not right now", but as "no plans at all". Some of them have plans for migrating business customers, but no plans for residential.
We'll end up with companies running IPv6 and the rest of us stuck on an IPv4 network with a 4to6 gateway.
I asked my ISP, and got a template reply telling me they were shooting for late 2017. I asked again in 2018, and received a template reply telling me they were shooting for late 2017. I asked in 2019, and got the same reply ...
They've since changed ownership, so I'm curious if the 2020 reply will still be late 2017.
I can imagine a weird contraption of a custom DNS server that tracks client requests, returns unique private IPv4 addresses and simultaneously tells to some NAT-PT engine that this source IPv4 address talking to that destination IPv4 address needs to be translated to that IPv6 address.
I can imagine this to be extremely fragile and break whenever an IP address is looked up using any different manner than plain DNS (e.g. by having IP in API responses, or just using DoH). Yet, I can imagine someone's probably already working on this abomination.
Nah, that's not the problem/solution, not in the ISP context. It's trivial for most ISPs (unless they have ton of ancient hardware and neglected to upgrade, or if they have very poor and limited peering options) to obtain an IPv6 block and set it up on their backbone network.
All the complexity is about providing this to the end users. Depending on your tech stack, you may have no issues, or you may need to replace just about everything (NASes, accounting/billing system, etc - whatever pieces were built with IPv4-only in mind)
Source: I worked for an ISP a while ago. We got our servers IPv6 connectivity, in, like, a day. We haven't solved IPv6 end-user connectivity (but it really wasn't a priority then), although was we had a few experimental connections - with lots of duct tape and random end-user issues whenever something was misconfigured (e.g. at the time not every site's AAAA record was actually responding, despite the existence).
Working on software from the late 80s to 90s also come with its challenges. You’ll have a discontinued third party database engine that is no longer maintained and writing files on smb shares wich more or less regularly breaks. It’s probably written by real plumbers and not software plumbers because they back at the time were more available. If you haven’t constantly adapted the code it for sure doesn’t compile with a modern compiler.
I have (c++) code from the early 1990's that compiles and works fine. People like to crap on c++ and Windows, but for just getting things done and maximum compatibility, I have yet to see better systems.
Same thing with old 90's linux and most code from that time. I guess the key thing is not the OS or languages but the reliance on external things, a dockerized microservice on a modern cloud is basically on the other end of that spectrum.
This might be one of those "it's a feature, not a bug" dealies. Software is now subject to similar rules of decay and planned obsolescence as hardware and material objects. Guess you just have to go buy a new one under whatever pay structure is the current paradigm.
Except the vast majority of material objects don't decay, or at least don't decay quickly.
The hoe I use for de-weeding my garden was my great grandfathers, and is probably 100 years old. It functions pretty much the same as it did when it was new. My father had to put one new screw in it I remember, so it has served its purpose continuously for 100 years with ~20 minutes of maintenance.
A similar small bit of software would need recompiling monthly, and rewriting every 10 years, at huge labor costs, just to keep the same functionality.
While I get your point, are you honestly saying a hoe has lasted 100 years and still completely usable to its original standards with absolutely no sharpening, oiling, cleaning or care of any kind other than changing a screw?
Stainless steel wasn't exactly common back then, so I'm assuming this hoe was probably iron with a wooden handle?
The iron would definitely need to be at least cleaned and dried after use to prevent corrosion and the handle, while probably at least treated at one point, would likely need some kind of maintenance, even if just cleaning, to prevent rot and decay?
After 100 years not even a single nick in the blade that needed to be honed out? Never hit a single rock with it? Tree roots never dulled it?
Sorry, I know I'm being kind of facetious, but manual tools definitely need care and maintenance if they're used regularly. Even simple ones.
To give a better and perhaps more relevant example: The wiring and many electrical devices in my house are over half a century old, yet all the switches and outlets still function perfectly fine.
Just to make a counterpoint. The wiring and many electrical devices in my house are over half a century old, the entire circuit breaker panel needed to be replaced a few years ago, the light in the bathroom actually just stopped working a couple weeks ago, i've replaced both the switch and the light fixture itself, but still no light so it's looking like it may be damage to the wiring, outlets are extremely easy to overload and a couple just don't work at all, there's actually an extension cord running from the basement through the floor connected to a working outlet there to replace one of the non-functional outlets.
A hoe is a very simple tool. You could say something equivalent of `cat`: the software is pretty much done, no need for particular maintenance, and it will work in 30 years time. If we still use UNIXes in 100 years time, I don't see `cat` failing either.
You wouldn't say the same things about a tractor, or about, say, Firefox
While there are reasons for concern, I don't really blame Philips (Signify) for this. They released the v1 hub quite early in the smart home space. It wasn't compatible with Apple Homekit features when they were released due to hardware limitations for reasons they presumably couldn't have predicted (unless they made it a more capable and expensive device in the hopes it would support unknown requirements). They made all v1 owners an offer to get a new hub "free" with a colour changing bulb, though it's not good value if you don't want the colour changing bulb or find it on sale and don't care about the hub. The old hub will continue to work, just not remotely. After eight years, I think it's a responsible and fair response within the parameters of consumer gear. The only way it could be better would be if the hub weren't required at all, or it was more easily interoperable with other controllers, but from the start that would have meant a more complicated experience.
I was an early adopter of Hue, even though it's kind of expensive I enjoy the capability to change the colour and mood of room lighting. $400 worth of lighting hardware for a house over 15 years is less than the comparable effect of painting a single room. From the start it has good support for local-only implementations with good open source libraries.
Better than I would have expected... and it still works locally. This means you can probably still connect it up to another automation system of some sort. Maybe I'm the only one who doesn't care, because I don't use the cloud features anyways... I mean most cloud-connected devices don't even have an option for local management, and just become a brick when the cloud service goes down.
I'm kinda okay with this, as long as I can interconnect my stuff with open platforms. Sure, most users want something that Just Works™ and that's what sells, but the market has no real de facto standards so things are bound to change and get discontinued. I just want something that I can fully control, but it implies some work and planning.
> So, Philips Hue users need a new $60 bridge after 8 years?
Looking at the wiki [1], v2 wasn't released until October 2015, and presumably v1 remained on some shelves for a couple months after that. So more like they need a new $60 bridge after 4 years.
This bothers me about phone updates - my manufacturer provides "two major version updates" - but in the case of my particular phone, it launched one version behind mainline, received the first update couple weeks after launch, I bought it when it was almost a year old because of the release cycle, and got the "second" update two weeks after purchase. They followed their update policy, but still leaves the public hanging.
All that said, I wouldn't buy smart lights anyway, and this situation doesn't bother me and seems like a somewhat reasonable timeline, since it doesn't totally break their functionality.
Yup, and the old bridge will keep working locally, still has an open API, and there was an upgrade program when v2 was introduced, with a 33% discount. Four or so years ago.
They gave me a pretty good upgrade deal just a month ago: a new v2 router with a lightbulb for under $60 Canadian ($45 US, now). This was offered to me somewhere in the iOS app when I was checking for updates. It took a while to ship (came from Europe for some reason), but I consider it a good deal, and have no regrets about buying the v1 router when I got it. The old bulbs work with the new router, though not as smoothly as the new bulb.
If you bought a hammer 8 years ago and the hammer company had a way to "deactivate" certain uses of the hammer so it only worked in a few situations, would you say "8 years is long enough for a hammer, it's perfectly reasonable they force you to buy a new hammer in order for it to work properly." ?
Philips has the resources to keep this up and running.
A Hue Bridge is not like a hammer. Your analogy is cute and appealing, but not actually analogous (the biggest problem with analogies...)
> Philips has the resources to keep this up and running.
See how your analogy doesn't work? A manufacturer of a hammer doesn't have to continually expend resources to keep your hammer operating, secure, and compatible with other devices. Because it's just a hammer.
That's not right. You've just based your assertion with a faulty assumption that a bulb has to be smart - sure the analogy breaks down. But, the parent is making an analogy about a "dumb" bulb - both hammer and bulb are tools. Hammer is used to hit nails and a bulb is used to illuminate dark spaces.
A manufacturer of "dumb" bulbs doesn't have to continually expend resources to keep your bulb operating, secure, and compatible with other devices - simply by the virtue that the bulb isn't a smart bulb.
To fail your analogy criteria, the bulb just have to be a "dumb" one or the hammer can be a smart-hammer (you can concieve that for the sake of a thought exercise).
What? I never said anything about bulbs. A Hue Bridge is not a bulb at all. And “dumb” bulbs still exist, you can buy them, most people aren’t really complaining when they don’t last forever, and frankly they’ve got nothing at all to do with my comment or the one I was replying to.
In this case, I'd put it on the buyers. It's a lightbulb, and like many home appliances it doesn't need any cloud stuff. Or rather, it can work just fine with self-hosted software.
Buy it and never use their cloud services or knowing that it can always disappear - if it doesn't work without Internet connectivity, don't buy it. Doesn't take a genius.
The world could seriously use some legislation for hardware devices tied to online (dis)services.
Maybe if you can't guarantee that your service stays alive for the lifespan of your hardware product, your product shouldn't have existed in the first place.
But it's worth scrolling through the previous posts by that account to see a myriad of similar "your expensive internet-dependent thing is now useless" scenarios.
AFAIK the bulbs are compatible with v1 and v2 hubs, so the bulbs do not need to be replaced. The v1 hubs will continue to work across a local area network. Philips offered a heavily discounted upgrade for v1 hub users to get a new v2 hub.
However, I still think they should support the v1 hubs for the lifespan of a typical bulb (15 years), at minimum.
Yea, as long as it works locally and they don't pull the old app .. still it's shitty they're trying to push people to buy new shit they don't need. It's just creating waste to increase sales. The attempt to grow without responsibility really needs to die. Consumerism with the goal of more consumerism is a cancer.
While it's tempting to blame this on Philips doing this to increase sales, I think it's just as plausible that they just don't want to spend resources on maintaining the infrastructure required for the v1 bridges anymore. The v1 was very early in the market, and doesn't even have the horsepower to support HomeKit etc.
This is also a more likely explanation if you consider that Philips offered heavily discounted v2 bridges to v1 bridge owners. It's probable that it's cheaper to Philips to sell v2 upgrades to customers at or below cost than it is to maintain support for the v1 bridge.
Having said that, it sucks for v1 owners that they have a product that's going to lose features unless they upgrade. I do have a few Hue bulbs (with a v2 bridge), but I have everything set up through openHAB, with remote access going through a server I control. This way I don't have to rely on anyone but my VPS provider to keep all of it functional. Unfortunately this route is out of most people's technical know-how. And I certainly sympathize with people who could do this, but would rather use an off-the-shelf product that just works.
The v1 / v2 split was arguably Apple's fault. v1 launched before Homekit; then Homekit required special hardware authentication; then v2 launched to support this; then Apple walked back on the special hardware and allowed things to be done in software, but Philips had already made breaking changes for v2.
This forced obsolescence is beginning to get out of hand.
I completely understand that running the online portion of this costs money, but that needs factoring in to the business model from the start. I imagine that they didn't think about this when the product first launched in 2012.
I do wonder if a u-turn (similar to the one Sonos has just done) will follow after bad media coverage.
Bulbs (the expensive part) will still function, just gotta upgrade the $25 bridge.
And even without upgrading the bridge, bulbs will still work just fine with the older one, as long as you are trying to access them on your LAN instead of while you are outside of home. What Philips did here sounds very reasonable to me imo.
All that's being disabled is external control through Phillips' servers.
If you're willing to set up port forwarding (and DDNS if needed) there are apps that allow you to enter both internal and external addresses, so you can still have external control.
...which all the digital assistants like Google Home or Alexa use, so this breaks voice commands for those. For most people, that's the main reason to have smart lights.
The V1 bridge does not require any outside access from an Echo device -- it communicates directly with the bridge over the local network. With V2 it requires a skill, a Hue account, and access from the internet to the bridge.
Are you sure it requires access from the internet to the bridge for V2? I think it may only require that the bridge can access the internet.
I have a V2 with "Out of home control" set to disabled and it works fine with my Echo Dot and with the Amazon Alexa apps on my phone and iPad.
My guess is that the bridge sends status information, including the bridge's IP address, to the Hue site, and the Echo can retrieve that information in order to find the IP address to send commands to.
That's specifically if you're using HomeKit remotely - if you're using HomeKit locally it works without internet connectivity, unlike Alexa/Google Home.
The online service will be shut down but the bulbs will continue to be locally controllable and Philips is releasing a dedicated app to interact with the v1 bridge.
Is it really such a huge deal that you can't access your bulbs over the internet? What's the use-case for this? Are you controlling your lights while you're not home? Do you not have access to the network the bulbs are connected to when you're at home?
I have Hue installed and this just seems like a non-issue to me.
I can access my Hue bulbs over the internet without using Phillips' servers. I doubt Phillips' app will do this, but there are other apps that will, such as Hue Pro.
Sure, but computer monitors are typically much more expensive than TVs of the same size.
Computer monitors are designed to be looked up close, which mean they are often at a higher resolution and higher quality. Furthermore, especially with gaming monitors, high refresh rates and low response times are important. A TV only needs 60Hz and response time is mostly irrelevant unless you are console gaming.
I recall a comment on HN a few months ago from someone who said they deliberately didn't connect their smart TV to their wifi, but then found that the internet-enabled features were in fact working. Turns out the TV had indeed found an open wifi network on its own and had automatically connected. They had to create a locked-down VLAN on their own network (with no outside connectivity), and connect to that in order to get the TV to remain offline.
Did they name this TV brand and model? Because this sounds a bit ridiculous.
The majority of open WiFi networks are WiFi pages with captive portal logins.
Of those, there's a good subset of which you need to pay for.
Sounds more like a case that someone else connected the TV to the WiFi network to browse YouTube and when they discovered it they decided to choose the most farfetched reason.
The real cost there is data usage, and just keeping the SIM live. Even with large volume discounts, that's not gonna be cheap. (Wireless carriers don't price machine uses cases the same way they do retail phone SIM cards.)
And then there's obsolescence: you said 3G... how long before carriers have shut down their 3G networks, or at least have reduced coverage to the point where it's hard to get a 3G connection in most places?
Granted, if the manufacturers only use that as a backup, since most customers probably will connect the TV to their wifi, maybe it won't cost that much.
The real cost there is data usage, and just keeping the SIM live. Even with large volume discounts, that's not gonna be cheap. (Wireless carriers don't price machine uses cases the same way they do retail phone SIM cards.)
I don't buy this. Here in the Netherlands, every house is fitted with a smart electricity/gas meter, that connects over cellular. The Kindle 3G has worldwide connectivity.
If Samsung or Sony goes to a major carrier to get a low-data rate 3G or 4G connection to send viewing habits, etc., times a gazillion units, they will get it. Such analytics are worth a lot, so I guess the cost is easy to offset.
They're locally running servers, doing all things on premises. My only issue with Philips is that I'd love to have an SDK to run my own code on the bridge (which is possible, though, but in unofficial way).
I guess if all this third-party stuff in the cloud (which are going to break because of the API shutdown = external connectivity/tunnel shutdown) would be apps, downloadable to the bridge instead, things would be better...
This. Fuck all this basic technology redesigned with Internet functionality. This bulb has been going for longer than people live http://centennialbulb.org/ but if it were connected to Philips' bullshit, it'd have been dead dozens of times over.
It's not the light bulb's API versioning that's the problem - it's that the fucking bulb has an internet connected API in the first place.
That's not entirely true for the v1 bridge. The echo needs internet access, of course, to understand the command but the actual control of a v1 bridge is done on the local network.
I have about 60 hue devices. Its useful enough to me that i would just buy the bridge if I had to. In fact I WANT them to release a new bridge that supports even more devices.
If you ask why - first is I am very sensitive to bad lighting as it seems to be a cause of migraines, Hue has amazing quality. Second I like the automations, not just turning on and off at the right time but also changing colour temperature. Having motion sensors so walking around triggers lights turning on is something that I got really used to.
I got hue bulbs and a 3rd party zwave/zigbee USB stick, hue works really well with it via Node-RED and Home Assistant :) I understand that for most users hue bridge seemed like the easiest way to connect but hopefully they will find that it's not that difficult to connect them via other means.
Comparing TP Link (wifi connected) bulb with Hue - the former reacts a lot quicker than tp link after boot (if you are using the normal switch).
For the most part, at least we don't have to worry about forgotten, rogue IoT devices. The overriding mission has been to connect it to shitty online services. Watch these companies go out of business or deprecate APIs.
This is very dramatic, but imagine something like this:
I'll have to check whether or not this'll affect my grandparents' lights. Probably not the absolute end of the world (90% of their usage is "Alexa, (back/front) porch (on/off)"), but I know they do like to control the porch light with the app (it's on a schedule, too).
The Hue internet stuff was never useful to me, so even my v2 hub is only used on my local network or by HomeKit. I don’t blame them for EOLing it, but it’s super nice of them to only take down the v1 APIs and not kill the entire product.
Well - they've done a pretty good job of ensuring that if I get smart lights again, I'm definitely not buying Philips.
This change breaks all the digital assistant integrations ("Hey Google, turn on the lights"), which is pretty much the only reason to have smart lights in the first place. If you can't use voice commands, you might as well just use the wall switches. Who wants to pull out their phone and switch the lights on and off with an app?
I know this isn't the point you're making, but I find smart lights useful for automatically turning on or off at various times. I don't use Hue, but I think that part should still work if you lost internet connectivity.
I suspect HomeKit integrations like "if the door unlocks, and it is night, turn the light on" will break.
You can also get the dimmer switches / remotes, I thought about getting some next to my bed because Google Home doesn't seem to work with my (Philips Hue) lights anymore.
I don't think this is related - it just stopped working a few days ago. Not sure why
I'll keep them though as I do have some automation setup - lights turn themselves on and off automatically
This is abominable, there's literally no reason other than "It costs money to maintain this, and we'd rather make money selling new stuff than support what we already made". I have a v2 bridge, but back when I bought it about 3 1/2 years back, I payed a lot of money for it. It's not an expensive product to manufacture, so I expected that money to go towards supporting it long term. So much for that.
You paid a lot of money for the bridge? It comes with the starter packs? I know a few people with these systems that have v2 bridges piled up at home as it was cheaper to get the starter kits and a bonus bridge than it was to buy the bulbs individually.
I personally piled some v2 bridges in the trash for this same reason. It feels vaguely like shucking external hard drives. The garbage piles up higher.
When I moved my Philips Hue bridge got damaged. Turns out there is no way (and I tried) to get your lightbulbs to reset and attach to a new bridge. Not very happy with Philips Hue, wish there was a better option out there.
My original bridge recently bricked (hours of wireshark logs led me to believe it boot loops every 17 seconds) and I was able to associate my bulbs with a new bridge easily.
Steps are as follows:
Turn the bulb on for three seconds and then off for three seconds, repeat a few times, then turn it on and it should blink. Turn it off, start the pairing/search process and then turn the bulb back on.
It helps to use a lamp/light switch if you have them somewhere that requires plugging/unplugging to turn off.
You can search for them using the serial number. I did this recently when I bought some second-hand Hue gear that was still connected to an old bridge.
You can also reset them using the dimmer.
Failing that, https://huetips.com/lamp-finder/ has worked for me in the past for finding awkward devices that I didn't have the serial number for (older LivingColours devices).
So here is my frustration with the hue service... The uptime is terrible.
Outages have happened weekly and there isn't even a place I can see statuses...
There are many night where I want to cut my lights off with the app and I just can't. No explanation just no connection from their application to their service..
There have been so many times I've had to use the api manually to do this
declaring that you'll never buy another philips product ever again because they shut off hosted services support for a relatively flawed v1 device -- when a v2 device is available for £25 -- is pretty petulant imo. it will still work on your lan.
i've got 15 hue bulbs and a hue bridge but i don't use any of their cloud services. i control them via zigbee light switches on a raspi running homeassistant paired to the hue hub without any "hue cloud account" or any reliance on internet access or anything of the sort.
i don't know of another mainstream brand who will even begin to allow that without significant vendor lock-in.