The problem for me, and as far as I can see a few more people, especially in Europe, has been that several days ago Hue devices started behaving erratically, so started looking and found (I was one of the first to to post on another thread that I’d found a new driver automatically installed) the new driver. Although we’ve avoided reinstalling or deleting to start with, recommending the same to others, we tried changing the ‘new’ driver. (We should take into account that for me at least I had no idea that Hue needed migrating - everything I have is Edge and bought my hub when the change from Groovy was announced.)
Fatal mistake! Now to repair automations. Positive side -
Routines are now not lost and show where devices need updating 
Rules have @TAustin 's API Browser function to list all rules with those devices. Thank you 
For now, the suggestion about reinstalling the device was for @Tino_Race and @Rogue66 only since in their case the team saw the driver switch event. For others, the investigation is still ongoing, please, @arcspin don’t delete your devices until we get the instruction from the team.
Will comply with your instructions.
@nayelyz exactly the same for me as @rogue66 said
I’m not going to reinstall anything until we see what the solution for the other users is as this would be days of work recreating routines
Also I deliberately only changed the drivers away from and back to the default drivers on one out of two hue hubs that I have connected to the same ST hub. Yet both are displaying the same behaviour so I’m finding it hard to see how that is the sole cause of the issue
Both of my hue bridges are v2
If this helps investigation, in my room called “living room”, three of my lights currently work via ST
Living Room 4
Living Room Lamp Front
Living Room Backlight
None of the other lights in that room work via ST
All in that room are connected to the came hue bridge
Nothing special has been done in ST in relation to individual lights.
Of the 3 lights that do work in living room and dining room, I’m more than 50% confident that they were bought in the last year or two, compared to most of the others which are from ~ 2016-2018. Wondering if bulb version or install date is affecting this?
OK so after following the advise to reinstall the device (delete Hue bridge form Smartthings then re-discover) I can confirm that, for the moment at least, I am now able to control Hue lights via Smartthings again.
Things to Note:
- It did take 3 or 4 attempts to re-discover and connect Hue Hub to Smartthings
- I did “loose” all my lights from Smartthings and basically have to re-add/rediscover them all following re-adding the Hue Hub.
- Once rediscovered I had to manually put all the lights back into their correct rooms
- I had to manually update all of the Automations I had that involved controlling lights to re-add the correct lights. (Note Automations were still there but marked with red symbol to indicate they needed updating with the “missing” light)
- Additionally for anyone using Amazon Alexa be aware I did also have to manually re-do several rooms and automations within the Alexa app as, in my case, they were using the “old” Smartthings devices rather than directly controlling the Hue devices
Fingers crossed that this is now sorted and these notes might help others and thanks to @nayelyz for the help
Exactly the same for me except I had a power outage for a few minutes (regular occurrence which normally causes no issues) and then lost them all again.
Hi, everyone
Moving on with those that still have an issue, could you help us get logs from the driver when you send a command to see the events received and sent by it, please?
For that, you need to set up the SmartThings CLI (here are the instructions) and run the command below:
smartthings edge:drivers:logcat
The IP address of the Hub can be found in the IDE or in the CLI by getting the details of the Hub.
To get the Hub device ID, you can make this request first:
smartthings devices --type=HUB
This command will provide some details of the Hub and you’ll find a property called “localIP”:
smartthings devices HubDeviceId -y
Copy those logs in a file and share it with us, you can send it to build@smartthings.com.
Sounds like you were all converted to their Edge driver which was recently rolled out. The migration clearly has issues. I’m probably biased, but I think most of you would be better served by using my driver for Hue over here:
It has more features and allows group control in addition to just single lights. Hopefully I’ll see you over there.
Good morning,
I run the SmartThings CLI and got some logs that I have sent you.
However, if I did that right I cannot tell because the instructions assumed prior knowledge in running scripts.
If the logs are wrong you guys have to give more precise instructions.
I’m now off for business and are not back at my computer until Friday night.
I can still read and answer questions in this thread but are not able to get more logs. I hope others also can get logs for you.
I have also answered @alissa.dornbos in a PM.
Yep. Not nice, but understandable. You removed devices, and for ST you added new ones.
I group all my bulbs from now on, so i have less work repairing automations.
Select: Devices/+/new ligtning group
I have some locations connected via the “link account” option. When you are not physically there, you cannot push the Hue hub button.
But i use some bulbs as an alarm via automations.
Lets say you want to know if somebody switched on a light somewhere.
Even with the non local, linked account, option the ST reaction was fast enough.
Automation: if away and a bulb is on, give me a message
After reinstalling the hub all Hue lights are now running correctly for me. I notice that the driver is updated 6/6.
Thanks for your help.
I hereby confirm the account is ready for support
Then you also have the 048 ipdate for the Hub?
My hue driver is older.
No, not yet, still have 47.11
No, I have the V2.1 Hue Hub
My ST Hub is running 47.11
Hi @nayelyz, I sent those logs through.
For benefit of yourself and community members this is a tl;dr version of that email and found the following conclusions:
I have two bridges, one with 100% working lights, the other with ~5% working lights
For the working bridge, all Hue devices logs start fresh of 16:54 BST on June 1st, the first log entry is “Mode Normal”
For the poorly-working bridge, devices that work start a fresh log at 17:07 with the same log entry.
For devices that don’t work, there is no log history at all.
CLI logs repeat this message for non-working lights:
2023-06-08T10:19:35.507026045+00:00 TRACE Philips Hue Found Bridge for stray light <<>>, re-adding
2023-06-08T10:19:35.514388128+00:00 WARN Philips Hue Found “stray” bulb without associated Hue Bridge. Waiting to see if a bridge becomes available.
The version of my drivers is dated 23rd May.
The logical conclusion is that ST pushed out a driver update on the afternoon of 1st June, it applied successfully for all bulbs on one bridge, and broke the connection for the majority, but not all bulbs, on the second bridge. Any subsequent change and reversion of a driver on on of my two bridges is not the root cause, else all of the bulbs on that bridge would be broken right now. The loss of connection to the hub happened on the 1st at a time that I was on holiday. No configuration was touched on my end until at least 4th.
When trying to troubleshoot this issue I stumbled across a Reddit thread which promoted your Driver. Switched over as a means of a ‘workaround’ to ST breaking my Hue connection, but quickly realised your driver offered much better integration that the native ST connection to Hue and will be staying put.
Thanks for developing and sharing a great driver.
Hi,
I have now made a log and sent it to build@smartthings.com