[OBSOLETE][UPDATED as of March 24, 2016] Hue Lights & Groups & Scenes (OH MY!)

Adding groups from the ST app would be pretty cool. Hope you get it working!

My hub was working fine this morning but now the hub has disappeared from the service manager and I can’t seem to reconnect it (0 hubs visible). Adding insult to injury I can’t remove the HLGS smartapp as I get one of those lovely unexpected errors. In my experience virtually every error can be expected if you use ST long enough. This is really frustrating. The Hue apps work…BUT I noticed some of my groups were scrambled (lights from different groups getting moved). Weird!

So I managed to somehow remove the hub and reinstall. Lots of groups showed up this time…as groups and not scenes. However when I made a new group (after discovering the hub with HLGS smartapp) it showed up as a scene. I had to resort to using the hue zigbee device handler for a bit. One thing I noticed is that with that code setlevel() doesn’t turn on the light. It took a few minutes to figure out this behaviour but I like it. It allows me to separate light level from on/off so I can use separate rules to adjust brightness at night/early morning/day etc. Very handy!

The Philips Dimmer Plug has the following properties in HUE API:

“type”: “Dimmable plug-in unit”,
“name”: “Bathroom”,
“modelid”: “LWL001”,
“manufacturername”: “Philips”

Just as I thought. I will update the service manager so it will appear in the lights section. Thanks!!!

Seeing an odd behavior. I have my hue bulbs set to turn on via the wake up routine. But one bulb turns on at 20% and I can find no logical reason why.

Any thoughts?

Nope.

Have you checked to see if you have some forgotten smartapp doing that (go into device and click the smartapps tab to see).

If no other app, then post the portion of the IDE log that shows what app is causing it. Thanks.

I’m having some real problems over the past day.

Everything was working fine until Sunday night. I think my router rebooted, but essentially I woke up and some of my lights were on. Looking through ST logs and my Router logs, it seems to have rebooted whilst there was motion in my house, and my ST - Hue link just stopped. Didn’t turn the lights off that were on when the RuleMachine rule said it should after 10 minutes, didn’t turn the lights on as it should have in the morning.
So all yesterday, ST wouldn’t control my lights although everything else is working fine. My Hue app and my Hue Tap control my Hue lights fine. If I went into HLGS Smartapp, it would find my Hue Bridge on the correct IP address, it would ask me to press the link button, it then just didn’t see that I’d pressed it. Never gave me the Success, couldn’t go ahead, pressing Next just took me back to discovering bridges.

I tried updating in place to the latest version of HLGS, nothing. Updated all five device handlers, and the SmartApp. Still the same, not detecting the link button being pressed.
I then removed all instances of lights, and my Bridge (which was a headache in itself, but eventually I got rid of it) and uninstalled all traces of HLGS. Reinstalled it, now it doesn’t find a bridge.
Factory reset my Hue Bridge, set it up all via the Hue app again, set my Tap up - all working perfectly, apart from HLGS doesn’t find the bridge.
My Hue app works fine so I know the IP address of the bridge, and I can control the lights through that, but I’ve left HLGS alone for 15 minutes looking for the bridge and 0 found.

I’m running the original bridge (round) with four Lux, one colour Hue and three GU10 - all Hue original, not copies or odd brands.

Any ideas what to try next?

Edit: I opened up live logging and get a few interesting bits. I have saved a huge chunk in case it’s useful, but I can see stuff along the lines of

7faf0539-361f-4b7a-8ca0-1e849f4d9b7e 21:47:47: debug Device was already found in state…
7faf0539-361f-4b7a-8ca0-1e849f4d9b7e 21:47:18: debug UNVERIFIED BRIDGES!: [uuid:2f402f80-da50-11e1-9b23-00178819f990:[port:0050, ssdpUSN:uuid:2f402f80-da50-11e1-9b23-00178819f990, name:Philips hue (192.168.0.16), devicetype:04, mac:00178819F990, hub:4b2d884a-6443-4b6b-892a-e6fc18c07d3b, ssdpPath:/description.xml, ssdpTerm:urn:schemas-upnp-org:device:basic:1, ip:C0A80010]]

(192.168.0.16 is the correct address for my bridge)

This is a complete hunch, but I have a feeling that uninstalling HLGS wasn’t enough to clear the state variable containing the Hue Bridge information. Did you also delete the SmartApp and Device Handlers in the IDE when you uninstalled all traces of HLGS? If you use the standard Hue (connect) does it find your bridge?

I deleted everything - all my lights, bridge, SmartApp, Device Handlers all from the IDE.
It was a bit of a struggle to be fair, it seemed that HLGS Smartapp wouldn’t uninstall as it had reference to the AP Hue Bridge, and the Bridge wouldn’t uninstall as the Smartapp was using it. Eventually I managed to get rid of the Smartapp via Locations -> List SmartApps -> Edit and using the red Uninstall button.

The Philips Hue Lighting (Connect) also fails to find the Bridge.

What firmware version is your Hue hub running?

01031131 (assuming it’s the number alongside “Bridge” in the About section of Settings…)

I had the same issue. I just got home but am deleting the hub, lights and hue and will try to re-pair.

Wondering if something changed in the hue hub or smart things.

Randomly, I just added HLGS into the app (didn’t even reinstall the code in the IDE, just added it in Marketplace -> My Apps using the code I was failing with last night), it found my bridge after 5 seconds, works perfectly. Just reinstalled all my lights and creating rules again.

Weird.

I’m having the same issue. Any solution for this?

There seems to have been an update to the way that SmartThings handles hue lights: Hue Lights not reporting status accuratley

Could well be related, but that issue is the exact opposite of what I had - for me, the Hue app never stopped working perfectly whilst any attempt to use ST to control Hue, whether via HLGS or the official Hue Connect, just failed to even see the bridge.

It’s even more weird mine just started working, so I don’t really know how to fix it if it goes again (without a two day epic marathon of uninstalling 90% of my rules, apps and devices and starting again)

I had something similar happen to me. I think it’s the ongoing platform issues. When they started, I had a day or two where all the Hue apps could see one of my Hue bridges but not the other. I verified with my browser that the bridge was still functioning properly. The ST apps would get the SSDP discovery response from the bridge, but then any HTTP requests sent to it would just vanish, as far as ST was concerned. I think the only option is really to wait it out, unfortunately.

@penner42 Did rebooting your ST hub fix the Hue hub issue for you?

Everyone else who’s having issue with a non-responsive / undescoverable hub: try rebooting your ST hub and try to add your Hue hub again. Report back if that did/didn’t work.

I have tried removing code, rebooting, then reinstalling code. I’m still getting the error bellow.

c6e0c6fd-2ad8-4630-903d-465f826829c3 8:43:53 PM: info LOCATION HANDLER: devicetype:04, mac:00178824E9FA, networkAddress:C0A80186, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:2f402f80-da50-11e1-9b23-00178824e9fa::upnp:rootdevice, ssdpTerm:upnp:rootdevice, ssdpNTS:
c6e0c6fd-2ad8-4630-903d-465f826829c3 8:43:52 PM: debug Device was already found in state…
c6e0c6fd-2ad8-4630-903d-465f826829c3 8:43:52 PM: trace SSDP DISCOVERY EVENTS
c6e0c6fd-2ad8-4630-903d-465f826829c3 8:43:52 PM: info LOCATION HANDLER: devicetype:04, mac:00178824E9FA, networkAddress:C0A80186, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:2f402f80-da50-11e1-9b23-00178824e9fa, ssdpTerm:urn:schemas-upnp-org:device:basic:1, ssdpNTS:
c6e0c6fd-2ad8-4630-903d-465f826829c3 8:43:52 PM: trace NON-HUE EVENT devicetype:04, mac:00178824E9FA, networkAddress:C0A80186, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:2f402f80-da50-11e1-9b23-00178824e9fa, ssdpTerm:uuid:2f402f80-da50-11e1-9b23-00178824e9fa, ssdpNTS:
c6e0c6fd-2ad8-4630-903d-465f826829c3 8:43:52 PM: info LOCATION HANDLER: devicetype:04, mac:00178824E9FA, networkAddress:C0A80186, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:2f402f80-da50-11e1-9b23-00178824e9fa, ssdpTerm:uuid:2f402f80-da50-11e1-9b23-00178824e9fa, ssdpNTS:
c6e0c6fd-2ad8-4630-903d-465f826829c3 8:43:52 PM: trace NON-HUE EVENT devicetype:04, mac:00178824E9FA, networkAddress:C0A80186, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:2f402f80-da50-11e1-9b23-00178824e9fa::upnp:rootdevice, ssdpTerm:upnp:rootdevice, ssdpNTS:
c6e0c6fd-2ad8-4630-903d-465f826829c3 8:43:52 PM: info LOCATION HANDLER: devicetype:04, mac:00178824E9FA, networkAddress:C0A80186, deviceAddress:0050, stringCount:04, ssdpPath:/description.xml, ssdpUSN:uuid:2f402f80-da50-11e1-9b23-00178824e9fa::upnp:rootdevice, ssdpTerm:upnp:rootdevice, ssdpNTS:
c6e0c6fd-2ad8-4630-903d-465f826829c3 8:43:41 PM: trace verifyHueBridge(C0A80186:0050)
c6e0c6fd-2ad8-4630-903d-465f826829c3 8:43:41 PM: debug UNVERIFIED BRIDGES!: [uuid:2f402f80-da50-11e1-9b23-00178824e9fa:[port:0050, ssdpUSN:uuid:2f402f80-da50-11e1-9b23-00178824e9fa, name:Philips hue (192.168.1.134), mac:00178824E9FA, devicetype:04, hub:c8824ca1-f1a0-47cd-86bc-82069f5c6483, ssdpPath:/description.xml, ssdpTerm:urn:schemas-upnp-org:device:basic:1, ip:C0A80186]]
c6e0c6fd-2ad8-4630-903d-465f826829c3 8:43:37 PM: debug Device was already found in state…