Is Philips Hue the neglected one and TCP the favored one

@smart, some of this issues has been fixed and we will deploy them to production soon.

  1. The app will check every 5 minutes for state change outside ST

  2. We discovered that for some devices it was necessary to force the next state, in this case on or off, this will prevent the button from getting stuck.

Hello home and mode changes missing bulbs are caused by problem 3.

Hope to this helps :smile:

1 Like

This line refers to bulb value state saturation. This means that the variable was = null. Were you using hue bulbs or did you pair any other bulb?

The last time I added or paired a bulb is several several weeks back.

As far as I know this has been fixed. Please let me know if that’s not the case. Thanks a lot!

Will definitely let you know… And thanks for all the info. Looking forward for the hue update from ST as nothing matters for me at least more than this… :slight_smile: it boosts my WAF and makes me the hero of the neighborhood and does wonders for my social life… :wink:

When is the hue update expected?

Currently it is true, and I’d like to know as well if this will be supported going forward; as well as groups, alert, and effect.

1 Like

@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 == bulb.value.name}           
                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.

Thanks

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.

2 Likes

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:

4 Likes

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.