Hue Bridge now only works with Hue-certified brands (no GE, Osram, or Cree) (market trends discussion)



So this is interesting… Phillips pushed out a firmware update for both the V1 bridge and the V2 bridge which now locks out any bulbs other than those that are “friends of hue.” That means that GE, Osram, and Cree bulbs can no longer be attached to a Hue bridge. Nothing to do with SmartThings, this is a Phillips decision that they don’t want to answer customer support questions about devices that they have not certified compatibility with.

Some of this has to do with the GE link problem of their frequently showing as not available to the Hue bridge. Some of it apparently has to do with some other issues with Cree firmware. And the fact that some of the osram bulbs are color tunable which the Hues are not. Phillips wants their customers to have a “consistent customer experience.” Which is entirely their right when it comes to the bridge.

People complaining that they aren’t meeting the ZLL standard don’t understand the ZLL standard applies to the Hue bulbs. The bridge is a different type of device. Zigbee and zwave have always accepted that coordinator/controllers might have unique features as part of market differentiation.

Anyway, lots of complaints and concerns over on the Hue developer forums. And ST discussion in the following topic:

But I wanted to start this topic as a look at this as part of a trend, validated by HomeKit, towards separate ecosystems for IOT. I think we’re going to see more and more of this. The current “try everything and see what works” approach to compatibility is frustrating for consumers. The protocol certifications become a minimum, but don’t really tell you which features of which devices will be available with any particular controller.

In the last two weeks two different SmartThings employees have advised prospective customers to use only zigbee devices. Obviously, that’s not a company position, but I will not be at all surprised if a future V3 SmartThings is weighted heavily towards thread and zigbee devices.

I do expect IOT consumer sales in the low-end to fragment just like the mobile phone industry. People will choose an ecosystem and then stay within it. Like android versus Apple versus windows phone.

As I mentioned before, my expectation is that there will be HomeKit/Insteon versus works with Nest versus Weave Thread at a minimum. And probably several others as well. I do think it likely that Phillips Hue will work with all of these, but they’re going to limit the devices they bring with them to a very predictable, very stable, set with common features.

Indeed, I think it likely that all of the candidates with the exception of the weave thread group will have a limited set of devices and features. And if that will be OK with most consumers as long as the typical use cases are met.

We’ll have to see. But in terms of a future of the IOT industry, I think the Philips move is huge. The third-party certification organizations simply haven’t done a good enough job of defining a minimum set of required features for compatibility.

Personally, I think they needed to have defined More detail in the device classes, the way it’s done in other engineering areas. But that’s my background and my bias. I don’t think “multilevel switch” as a single category is sufficient.

I think if they really wanted interbrand compatibility, they needed to define probably seven or eight different types of wall switches, each supporting a different group of command sets/clusters. So consumers could know that their controller would support all of the features of an A, B or C switch, but not a D, E, or F switch. But the alliances didn’t do that. And consumers end up buying an even installing devices that don’t work the way they expect them to.

So now we’re seeing market pull in the opposite direction. Again with HomeKit as the big validator. And consumers accepting a very limited choice of devices, but knowing that those devices will work when they bring them home.

Philips’ willingness to step back from supporting other brands probably won’t hurt their sales much, particularly now that the hue white is priced so competitively. But I think it does say much about the importance of reliability in this market segment. We’ll see. :sunglasses:

@johnr @Sticks18 @juano2310 @twack @mitchp @tyler @infofiend @bravenel @pstuart @workmonk

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #2

Well you can add me to the list of people who are upset with Phillips decision.

I definitely will avoid their products going forward.


Thanks, that’s the link I meant to include originally. :sunglasses: I’ve fixed my post.

@jody.albritton @johnconstantelo @slagle


You can certainly avoid their products if they don’t meet your needs. But from a philosophical position I don’t think this is really any different than SmartThings not supporting the GE handheld remotes (which are Z wave certified secondary controllers). Or the various multibutton light switches.

And from a market position, it may strengthen the Philips brand.

I don’t know if you saw but the Quirky bankruptcy has been held up by a GE filing that quirky’s poor customer support on the cobranded devices hurt GE’s reputation. The judge is studying the issue. But GE wants anything that is cobranded GE pulled out of the asset sale to prevent further damage when some other company picks it up.

(One of the specific examples is the Arros air conditioner. )

The concept of limiting compatibility to devices that actually do work with your product is gaining steam.

(Brian Diehl) #6

I was a little disappointed when I saw this. If I didn’t already have Hue, I wouldn’t go get it knowing this (even though I have an iPhone for work that may end up getting some tinker-time for homekit stuff because…why not?)

I’d stick with bulbs that can be connected directly to the controller of the platform I choose. (Apartment renter, so re-wiring switches and outlets, while possible, is not exactly the best practice due to the time and effort being lost when having to remove and re-setup after a move…bulbs make more sense in the environment).

I understand the point of view that the bridge was designed to be a hub for the Hue bulbs, not for any and all zigbee bulbs out there. I also feel that they could have anticipated this before the launch and done something differently (different zigbee options out there) to limit the items connecting so only the Hue bulbs could.

I’m interested to see how it plays out for them in the long run. They are Homekit certified and next summer when we start seeing a slew of Homekit items, they will be on display and everyone will remember they’ve been around for a few years already and have the kinks worked out (because the initial kinks are the worst part of the IoT world).

I have the Hub and some bulbs as well as a tap, but going forward, I will be buying another brand.

During the life of a product, I would expect more options to open up for usage, rather than seeing them limit and remove features. This just feels backwards.

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #7


I can move my GE Link bulbs to SmartThings, but what if Samsung / SmartThings decides to pull the same stunt? What if Amazon Echo did?

If a platform is inadvertently or inconsistently open, it’s worse than one that was closed at the time of purchase.


The GE Links failed the compatibility test with SmartThings specifically because of the drop off problem, so they’re not on the official list, and ST could block them at any time.

Philips has said other brands can apply to be certified through the 'Friends of Hue" program, so we’ll see what happens there. If they start adding back some outside brands, that would say a lot.

Again, I put some blame on the certifying organizations. Everyone knows the
Links have a problem. But apparently it’s not enough to ding their Zigbee certification. So should Philips really have to carry the customer support costs for another company’s broken product? I’m not seeing the logic there.

(Matthew Kelch) #9

At least with SmartThings we have the ability to create our own device types which imo makes this a non-issue. As much as people like to complain about SmartThings it really is a fairly open system.

I do wish the SmartThings hub supported ZLL – if it did I would dump my Hue bridge immediately.

For what it’s worth, despite my GE Link bulbs showing up as ‘unreachable’ with my Hue Bridge, I’ve never had an issue controlling them.

(Matthew Kelch) #10

Like I said in the other thread, if they want to remove support from the 2.0 bridge that’s fine. It’s not okay for them to fundamentally change how a productI bought more than a year ago functions. Myself and other users have been using and relaying on this functionality for months or years. The worst part is that my GE Link and Cree Connected bulbs all work great. I haven’t had a single issue with them.

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #11

We don’t have the ability to make locally executing Device Type Handlers.

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #12

No. Absolutely not. But all they need to say is, just like SmartThings says, “not officially supported and may need to be removed from your system to receive technical or warranty support on your Philips products”. Or as SmartThings calls it “SmartThings Labs Device”.


That’s exactly the market trend issue, I think.

Should Philips allow some customers to have a bad experience (like the GE links marked as unavailable) and then tell them there’s a brand incompatibility and ask them to remove them.

Or should they prevent the bad experience from ever happening? But at the cost of annoying customers for whom the devices were working OK.

I guess there are really two separate questions here. If they go with the second option for all new customers, I think most people are OK with that.

The question is how they handle the transition for existing customers with existing devices which now don’t meet the requirement.

I agree that personally I would probably prefer a grandfather option for people with existing equipment. With a notification in the app about what was going on.

We’ll just have to see if the market punishes them for this.

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #14

I doubt that it will hurt Philips, unfortunately.

In general, people don’t expect “complex” products from Brand A to work with Brand B (e.g., the Samsung Galaxy Gear Watch only works with Samsung phones). And I bet many consumers assume that the Moto 360 Watch only works with Moto X phones; it’s a marketing challenge for Lenovo to convince consumers that their watch is compatible with any phone that is “Android Wear” compliant.

So Philips doesn’t get hurt … but rather much worse: The #SmartHome industry gets hurt.

It’s called fragmentation; and it is a major challenge for all the Android Phone manufacturers and developers that Google has to work hard to overcome in order to compete with Apple iOS.

This is exactly the sort of messy stuff that this industry doesn’t need right now.

(Scott G) #15

Sadly I expect it to get worse before it gets better. The big guys aren’t content with any of the current protocols, and they all have their own ideas.

I said it in the other thread that I understand the Philips decision, even if I don’t like it. But the certification standards either have too much flexibility or too little testing because the variation in functionality among devices of the same profile is so wide that ST has a devicetype for each zigbee smart bulb instead of one dimmable light type. Cree don’t report their attributes correctly or support dimming for on/off commands. Osram needed several firmware updates to recall their last dim level when sent an on command (basic part of spec). GE Links don’t stay connected. Hue bulbs don’t support attribute reporting or binding. It’s the wild west even though there’s an easily obtainable document stating they should be the same.

(Convinced ST will never be unbroken…) #16

Interesting move… understandable, not happy about it, but tough for me to blame Philips. They’re product works; probably better than any other product in this space. We all rolled the dice with GE because they were cheap. In hindsight, I should have known better. The whole GE/Quirky thing was a mess from the start.

I’ll not cut off my nose to spite my face as Hue is one of but a few systems that provides everything on my HA checklist (local and remote operation, good API, and reliability; SmartThings integration not withstanding). Instead I will avoid the update until I can swap out my Links with Hues. I will not use lamps that depend on SmartThings.

Which begs the question… what does one do with Links these days? With Wink dead, they have no official controller, right?

(John Rucker) #17

Sorry I don’t pay much attention to light link products. That whole profile was a huge miss-step by the ZigBee Org in my opinion. It caused and appears to still be causing a tremendous amount of bewilderment and frustration with users. Phillips joined the ZigBee org as a promoter so it could force the creation of the Light Link profile. From my understanding they wanted a new security model that forced vendors to go through certification before their devices were given a unique trust center link key. Unlike the Home Automation profile (that uses a well known trust center link key) a ZigBee Light Link device must go through certification before it’s parent organization is awarded a unique trust center link key. This was supposed to insure compatibility of light link products. The second big thing the Light Link profile provided was the ability to create a Light Link network without a hub. That was a hug thing for Phillips and the other members so they came up with that hokey touch link process that allows you to bind a Light Link bulb to a Light Link switch without a hub.

I never thought of the Phillips hub as an open home automation hub. I have one but it hasn’t been powered on for two years. All my Light Link devices are directly connected to my SmartThings hub over the ZigBee HA profile. Light Link devices can also connect to the Home Automation profile (its part of the Light Link spec, at least they got that part right).

My question for you Light Link lovers (smile) is this. Do the Osram and Cree Light Link devices still work with the Hue bulbs in a no hub configuration? If they do then everything is to spec that is what the Light Link profile is all about. I bet they still work fine if you take the Phillips hub out of the picture. I don’t think there is much we can do about it. I agree it sucks and Phillips is going to loose some business but not much. I’m guessing they want to sell light bulbs not hubs.

I wish SmartThings would re-visit its lack of support for directly connected Hue bulbs. My Hue bulbs work great these days!! They improved with the software update that was released just before Hub V2 shipped. So they were working great on hub V1 and now on hub V2 as well. The published Hue ZigBee custom device type needs improvements but other than that I would recommend you guys take a look at moving your Light Link devices over to the HA profile and directly connect them to the SmartThings hub. You will loose the ability to group the bulbs into a ZigBee group but that could be simulated with a better custom device type and smart app.

(Blake Westerdahl) #18

Interestingly though, this update doesn’t seem to retroactively remove non-certified bulbs. I updated my Hue Bridge firmware this morning prior to reading this thread. My one GE Link bulb is working just fine through the bridge.

(Geko) #19

Sure it’s their right, but removing features from the released product is always bad customer experience. Any way you look it, it sucks. Boo Philips. :frowning:

I also think it’s a slap in a face for all Zigbee and ZLL promoters who were lambasting Z-Wave for being a “single-vendor” solution. There you have it, a product that was supposed to be interoperable is now locked down to a single vendor.

(Bobby) #20

Talking about boo Philips. I just finished yesterday migrating last GE link to Hue hub because I got tired of the inconsistency I was getting in ST…and I have 20 of them…So yeah, not doing the 25 times on/off to each of them to put them back on ST. They’ll be the smartest dumb bulbs!

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #21

I wonder how long we can go without updating the Hue Bridge firmware and mobile App(s)?

Perhaps just until we try to add some new model of Philips bulb or control switch?

Unlike SmartThings, at least so far, Philips doesn’t push firmware updates to the Bridge until the Customer choses to using the App.