Is Philips Hue the neglected one and TCP the favored one

@juano2310 @tyler This is a new one that I see along with the exception that I reported last time (the highlighted line…) for the Hue Bridge.

97515c33-3bd1-4443-9c3b-3b7dfbe7c739 ‎2‎:‎53‎:‎18‎ ‎PM: error java.lang.NullPointerException: Cannot invoke method multiply() on null object @ line 516

97515c33-3bd1-4443-9c3b-3b7dfbe7c739 ‎2‎:‎53‎:‎14‎ ‎PM: error java.util.concurrent.TimeoutException: Execution time exceeded 20 app execution seconds: 91983958456644 @ line 510

97515c33-3bd1-4443-9c3b-3b7dfbe7c739 ‎2‎:‎53‎:‎13‎ ‎PM: error java.lang.NullPointerException: Cannot invoke method multiply() on null object @ line 516

Probably this loop is timing out…

   for (bulb in body) {
                def d = bulbs.find{it.label ==}           
                if (d) {
                	if (bulb.value.state.reachable) {
                        sendEvent(d.deviceNetworkId, [name: "switch", value: bulb.value?.state?.on ? "on" : "off"])
                        sendEvent(d.deviceNetworkId, [name: "level", value: Math.round(bulb.value.state.bri * 100 / 255)])
												def hue = Math.min(Math.round(bulb.value.state.hue * 100 / 65535), 65535) as int
												def sat = Math.round(bulb.value.state.sat * 100 / 255) as int
												def hex = colorUtil.hslToHex(hue, sat)
												sendEvent(d.deviceNetworkId, [name: "color", value: hex])
                    } else {
												sendEvent(d.deviceNetworkId, [name: "color", value: hex])
												sendEvent(d.deviceNetworkId, [name: "switch", value: "off"])
                        sendEvent(d.deviceNetworkId, [name: "level", value: 100])
												def hue = 23
												def sat = 56
												def hex = colorUtil.hslToHex(23, 56)
												sendEvent(d.deviceNetworkId, [name: "color", value: hex])

The first exception regarding null pointer may be because I have two Philips lux’s connected to the hue hub. Of course the Lux bulbs will will only have the state info for switch and level only in contrast to hues which will have state info for hue, saturation, color, switch and level. So, of course all these calls will fail in the code snippet shown below as we are not checking for existence of the state info and doing a math operation on it in the hue service manager (connect app).

@juano2310 OK I have an issue with what you were asking about. I had 5 bulbs in hue and ST for at least a few weeks then recently added a hue bulb and a LightStrip. I started the hue connect to detect the new bulbs but nothing, they were never detected by ST. I tried at different times/days and never got ST to detect them so I opened up a support ticket. I was told Aaron uploaded a new firmware to my hub and asked that I unplug the network cable and power cable for two minutes which I did but still no detection. After that I was instructed to either wait weeks for QA to investigate or to remove the bulbs/bridge etc. from ST then re-add. I removed everything from all my SmartApps/Hello Home actions, removed the bridge then added everything back. All bulbs were detects (7 total) in ST.

Today I bought a new hue LUX, added it to hue and tried ST but once again, nothing. I am not going to remove everything then add everything back into ST each time I purchase a new hue bulb, this is ridiculous.

Anyone have any thoughts? This is just one of many issues I’m experiencing with ST but it certainly is very frustrating.


1 Like

@smart and @hscox030,
I will be looking into this issues next week. I think I have and idea on how to fix both but I need to get a Lux to test both adding a new bulb and the saturation = null.
I will keep everyone on the loop :smile:

1 Like

Are you hiring by any chance? :wink:

1 Like

@smart, we are. I can get more information if you are interested.


Scenes are something that I’ve requested a year or two ago; but I have no idea if they are on the roadmap.

There is a good “Scene Machine” SmartApp (by @wackware), and I’m likely to expand upon it, I think … I was hesitating in the hopes that a more integrated approach would come from SmartThings as you suggest.

Here’s a long discussion you can refer to – I’d love your input!

…CP / Terry.

Wouldn’t you get the same result with GE Link bulbs connected to the Hue bridge? I’m sure you have a couple of those somewhere lying around the office.

Juano, I have also been working on some hue code to bring in hue groups and lights so you can control them either way and to bring in the fade time so that we dont have to use timmers… however i have not gotten stuck in the loop of not being able to pair smartthings to the hue bridge… I was wondering if this is something that you have solved? (it gets stuck on the verifybridge part) If so I would be very interested to see where you are [if you have code on github etc…] and to help where I can.

@geko, in theory is the same, but better safe than sorry, and I rather have them all to test the whole integration. I have a Best Buy 4 blocks from home so this isn’t an issue. Also, I will be meeting Philips HUE engineers also, on the 10th, to work on improvements :smile:


Based on the thread title. I think TCP is getting the love based on price point. If you put the Hue bulbs at the same price point, then TCP wouldn’t last or be a bleep on anyone’s radar.

I’d love to replace my 40 or so TCP bulbs with Hue, but if you did the math it doesn’t make sense.
Hue = $59.99
TCP = $14.99

That’s for color, no? Can’t compare an RGB(W) bulb to a fixed white.

But … I am also having total success with GE Link bulbs on my Hue Hub ($15+). The GE Link’s do look a little odd because they have clear glass with just a bit of internal deffusing.

Just have 3 Hue’s for a lounge room, and I watch eBay for the occasional others.

Philips Lux (white) are overpriced … but they may stick with that “high-end” market.

But we need ST compatible scene controllers!!!
I presume this controller is NOT usable as a general SmartThings trigger?

Not its not!

Yes I’m talking about the color. I have 2 GE’s but the TCP’s kill it. IMO

Glad to hear that you are working on the Hue integration. I have been having problems with groups of Hue lights. They often won’t all turn on, or off, as commanded.

If you’re polling every device every 5 minutes aren’t you significantly increasingly network load and so in danger of creating mesh collisions and drop outs that way? Not to mention possibly increasing energy usage? And in physical fixture arrangements (multiple smart bulbs physically close together) isn’t there a danger that multiple zigbee end devices have chosen the same parent, potentially overwhelming it?

My understanding is that the whole reason for push sensors is that mesh networks are inherently bad at supporting frequent polling use cases. Fixed traffic architecture is a much better match to those requirements. Lots of factory floor installations take devices that need to be polled frequently out of the mesh network altogether and hardwire a hotline to devices that require frequent state checks from the control station (as opposed to push updates from the end device).

What am I missing?


I just bought my first Hue Lux to replace a GE Link in one of our lamps as its a nicer white. But can’t get ST to see it nor will it see my Hue Hub to start discovery!

Really looking forward to seeing the new version of the App with better Hue control as they are a core part of my ST setup!

Also…in the Zigbee Pro standard which will form the basis of Zigbee 3.0, a failed delivery will result in the parent resending the message 3 more times. So polling a device which is off generates 4 times the traffic you expect at the parent. Keeping the parent busy with multiple (and perhaps overlapping) poll requests could degrade the network in that area. Add high density node areas as is typical in lighting installations and it could get really bad.

The alternative to coordinator based interval polling is a smart switch that creates a “turning off” event or even a “maybe turning off” event that THEN triggers a hub poll (limited to one time) of the devices controlled by that switch.

There are lots of ways to do this, depending on the type of switch being used. Obviously something like the ACTion dashboard or the ST app itself can do it easily when the off request is received.

Secondary controllers like the Aeon Minimote can do this by placing each off request in a scene that initiates the one time poll after a 5 minute delay.

Dumb switches like a retrofit lamp switch can still be captured as a “maybe turning off” event through a nearby proximity sensor that triggers the one time poll. This does mean you’ll poll anytime someone moves close enough to the switch, but it’s still a lot better than interval polling.

Granted, these smart switch approaches all require user education if only for device deployment. But most consumers can understand that they would need to install a smart switch OR physically lock the dumb switch if they want to always know accurate status. And network load will be much lighter.

BTW, Philips recognised exactly this issue and addressed it with a smart switch: the Hue Tap. Not with interval polling.

Hi @JDRoberts, In this case the polling is to the HUE bridge that is a LAN device to get the status of the bulbs. You can request every second but this will increase the load on the cloud side and not your setup .

@juano2310 My hues are not updating their status correctly when turned off via an external app. A refresh is only bringing over the current color, not the current state of the bulb. Is this being addressed in the upcoming release?

Hi @jodyalbritton, I discovered that if the name of the bulb was changed by the user they lose reference and they stop updating correctly. I’m working in a solution as well as adding new light bulbs.

@juano2310 Is it related to that? I have never ever changed the name of my bulbs and to the extent that the names are same as in hue site. But I don’t think it ever refreshes the state as of now if triggered by third part app. Do you mean that in the next update? If what @jody.albritton is talking about can be achieved it will be a great step. We are so anxiously looking forward to the update that you all are talking about.