Philips Hue Bridge v1 online services will be shut off after April 2020
twitter.com
twitter.com
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.
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.
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.
https://www.home-assistant.io/integrations/tradfri/
https://www.home-assistant.io/blog/2017/04/17/ikea-tradfri-i...
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!
So... the v2 device isn't flawed and we're not about to see a v3 device before v2 is shelved in a few years?
Also, where's it £25? They seem to offer it for £49.
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.
Haven't had the need to do that in the past couple of years, I hope that's still possible.
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.
They've since changed ownership, so I'm curious if the 2020 reply will still be late 2017.
If you have a lan then you can set up radvd (or similar) to distribute addresses. You may need to replace your router though.
Your ipv6 packets head out over a 4to6 tunnel to your broker, and then out to the wider world.
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).
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.
It’ll work fine for web traffic.
There's some other tools to facilitate that.
FWIW, I tried playing with IPv6 on my home LAN. all IPv6 intranet, IPv4 on the ISP WAN, all ran fine on OpenWRT routers with a bit of configuration.
The world is at 26% adoption.
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.
You wouldn't say the same things about a tractor, or about, say, Firefox
Want to make a http://longbets.org/ bet of it?
PS. longbets, please get https.
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.
That actually seems reasonable to me. 8 years is longer support than most other devices.
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.
Philips has the resources to keep this up and running.
> 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.
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).
Even the v1 bridge will still work, it’s just loosing a feature.
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.
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.
https://twitter.com/internetofshit?lang=en
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.
Agree with child comment.
However, I still think they should support the v1 hubs for the lifespan of a typical bulb (15 years), at minimum.
Again, Philips made the wrong call here.
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.
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.
All that's being disabled is the external control.
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.
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.
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.
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.
The bridge provides a well-documented and stable local API which these assistant devices would be able to use as long as they're on the same network.
Why not? Does it not work over a normal connection?
https://play.google.com/store/apps/details?id=com.benchevoor...
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.
Computer monitors are either 1080p, 1440p or 4k in the majority of cases.
If you're looking for a cheap dumb TV, there is no market. The majority of people want YouTube and Netflix built into their TV.
If you want something with a niche use case, then you have to pay niche money.
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.
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.
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.
These are TVs with the smart stuff removed for use in enterprise/hotels that don't want it. Pick your favorite!
Could be because of GDPR :/
I can get to that page from Italy, so no, it must be something else.
Looks like they banned the whole Netherlands at least :D
People warned of exactly this when they started.
Well, "local net" first, it originally had no "cloud" support.
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...
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.
I treat mine as regular bulbs that can be controlled via phone.
This changed with the v2 bridge.
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.
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).
This is very dramatic, but imagine something like this:
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?
Don't know about Google but this is not true for Siri/HomeKit integration, which doesn't use any of the Hue online services.
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
https://fosdem.org/2020/schedule/event/a_mozilla_iot_forcast...
The one I use most is Hue Pro by Prismatic LLC. I like its highly customizable widgets.
https://play.google.com/store/apps/details?id=com.benchevoor...
I suspect HomeKit integrations like "if the door unlocks, and it is night, turn the light on" will break.
you can do a re-pair by typing the bulb's serial number into the app and it will force the bulb to forget it's hub.
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 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).
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
Hopefully this new bridge addresses this issue.