That like a useful security feature for the Hue system, allowing third-party control without compromising operation. It’s fantastic that people can enable or disable light discovery according to their preferences.Magic 8 ball online
The problem isn’t that call. You can see in your log that that worked fine and it found your hub. The problem occurred after that when it was attempting to download the rest of the data from the hub. There is a TON of data that comes across, and your packets are malformed. My best theory is that the response is too large for the ST socket layer to contend with and it is mangling the packets before they get to the driver.
You are on the V2 hub, so it is possible that there is a bug in their firmware on that hardware version. Maybe it has less memory for these processes? 
Do you have access to a V3 hub you can plug into your network?
Unfortunately, the V2 hub is the only one I have. Is there anything else I can try?
v3 hub has less memory than a v2 and runs the exact same version of firmware.
1 Like
Does this still work with ST? I had previously installed this months ago using the above youtube video. I want to add some hue light bulbs, however when I go to my hue bridge in ST I don’t have the same settings anymore to add lights. It looks like this.
I removed it and tried to re install. At first just the regular hue bridge would be scanned. If I press the hue button then it brings over another hue bridge with all the lights but I still don’t get settings I had before. I reset ST hub as well and still have the same thing. Has the driver changed? Is the screenshot I took suppose to be like that? If thigs have changed how did I add a new light bulb?
Yes but you need to use a workaround for the time being as ST broke the UI in a recent app update. Scan back in this thread a bit for more.
2 Likes
I have been using this driver since before Christmas and it has allowed me to use the bulbs and rooms on my hue hub so much more effectively.
Recently, I am getting a big delay on some occasions with sensors turning on bulbs. It started around the time of the big European outage about a month ago, but has continued since then, so might have been a coincidence.
I’ve checked the logs and the sensors appear to trigger instantly and the relevant bulbs are turned on in the Smartthings logs at the same time, so it looks as though the communication between the hubs is the delay.
If I use the hue app it is instant, but I have the same issue with Alexa as it uses the Smartthings integration. Any voice commands can take up to 30 seconds, but sometimes it is instant.
Difficult to diagnose!
Thanks that worked!
2 Likes
I’ve also seen that colour control often don’t seem to match the colours in the Hue app. Sometimes after selecting a colour on the colour wheel, the spot would randomly jump to a location slightly off from where I dropped it, and even then the actual bulb colour isn’t what smartthings is displaying. Reds would ofter be more orange, and orange more yellow. Blue would be more purple or vice versa.
More ofter than not I’d go to the Hue app to set the right colour. Anyone else experience this?
For what my opinion is worth, this driver is still worth its weight in gold even with the extra production value of the workarounds. The only thing I really miss is the blinkenlighten 
Taking it down means that if we ever need to reinstall, we’d be up the creek, no?
Yes. 
I get a mailbox full of requests regularly saying the UI doesn’t match anymore. Not the users’ fault. ST is to blame, but it is frustrating.
1 Like
Issue with Smart Lighting app… I tried setting up my Kasa light strip to “Sync to switch” using my Hue Bedroom light (room group imported via this driver). When I turn on the Hue light, the Kasa light turns on as expected. When I turn off the Hue light, the Kasa light turns off as expected… then a second later the Hue light turns back and triggers the Kasa light turning back on. I could not get the lights to turn off last night and had to delete the Smart Lighting rule.
I’ve tested the same “Sync to switch” using a ST virtual dimmer and that works fine, without turning back on. So it appears to be an issue when using Hue as the source “switch”.
Do you have them sync’ing in both directions or just uni-directionally?
Sounds like a race condition which can normally be avoided by using a Routine with precondition to check the state of the device to be sync. Something like this:
If Switch 2 is off (precondition)
Switch 1 turns on
then
Turn on Switch 2
If Switch 2 is on (precondition)
Switch 1 turns off
then
Turn off Switch 2
2 Likes
I only want one-way sync and that is what the Smart Lighting app does… at least with other devices (non-hue bulbs, virtual devices, and switches). It only seems to be when syncing to a Hue device (room) which doesn’t work.
I am currently using routines to turn the light off/on currently, however, I would like it to match the brightness level which is something the Smart Lighting app will do. Trying to do this routine can get complicated, but I do have my routines setup to toggle between 2 brightness level based on if the Hue light is above/below 50%.
After doing some more testing I found that Smart Lighting DOES work correctly if I control the Hue light via the Hue app. It does NOT work correctly if I turn the Hue light off via ST and so its appears to be something wonky with what the driver is doing.
Is anyone else using the Smart Lighting app and seeing this behavior?
for my use, once the procedure described has been done, nothing changes.
Now I can see and use the temperature and brightness data from the sensors and it’s convenient for me.
However, I am unable to use the on/off state of a HUE lamp which is actually a sonoff (HUE manage it as an on/off lamp), info of change on/off comes after a very long time
Please don’t take down the driver. The factory integration of hue in ST using the cloud is not reliable. Therefore this driver is the only way of a stable hue integration in ST.
3 Likes
Smartthings currently offers two official integrations for Philips Hue.
The first is a “linked service“ which is cloud to cloud at the account level. This does not require having a Smartthings/Aeotec hub.
The second is a local LAN integration using a local edge driver. This does require having a smartthings/Aeotec hub, because all edge drivers run on a hub.
And then, of course, there is the third method, the community-created edge driver under discussion in this thread.
I can’t say whether either of the two official integrations are more stable than the other: I have seen reports both ways. 
I also hope that this custom integration continues to be available as it offers features not available in either of the two official methods.
But if you are trying to use an official method and you do have a smartthings /Aeotec hub, you do have a local choice there if you want to try it.
I have an aeotec hub, and last time I have tried the official way, the ST app only had offered linking, no edge driver. That’s the reason why I have found this driver. And linking is not very reliable.
Do have a URL how to use the stock driver, if this driver is dropped and a new installation is necessary?
Stock drivers are automatically distributed to all customers who have hubs so you should already have it.
You go to add a device, but instead of choosing the link to services link (#1 on the following screenshot), you just tap “next“ (#2 on the following screenshot) and you will then use the official LAN edge driver.