It’s not related to the Updates. Seems AWS is down in areas impacting on connectivity to various sites
From Italy the connection with google home sometimes works, sometimes it doesn’t work… random. (yesterday problems, today works fine).
But the problem, for the second consecutive day, is Philips Hue. All Hue don’t work in smartthings. I fix this by restarting my smatthings hub. Done yesterday, but today same problem again, restarted the hub again.
I posted on another thread, exactly a week ago, that after the issue with the new Hue driver, and after reinstalling the Hue hub and repairing automations, all was running well.
But now for 3 days I have exactly the same problem every day, today again hub and all lights offline. Firmware 48.3 and driver 6/6.
Tag @nayelyz Thank you
1 Like
So glad it is not just me that this has happened to. I have been ripping my hair out on this because I could control the lights in the Hue app, but in Smartthings it was saying the lights were offline, yet at the same time automations that used the lights such as were working.
To work around it I have removed the Hue Hub via the SmartThings site and all the associated lights, and then in the application I have added it back as a device, but this now only seems to work if you add a device within a room section in the Device’s tab, the Hub does not go into pairing mode, ie “green flashing LED” elsewhere. If you do it else where you get the 34-302 error.
The downside is that if the connection had been local before it reverts back to cloud but at least you get control of the lights again.
1 Like
how are you determing its cloud? You can’t use the ole Groovy IDE any more to determine this. It should still be local with the new Edge integration.
1 Like
Hi,
Graphic API is still there looking at the hub and monitoring it.
I can see the items removed as local and when they got added back as cloud.
It’s there, but the Groovy IDE can’t read the status of Lua Edge drivers correctly because they don’t use Groovy. If you go the menu for the device in the app and there is a Driver menu option then that means it’s running local.
Could you have added it using the hue cloud to cloud integration?
Consider a community developed Edge driver: https://community.smartthings.com/t/st-edge-philips-hue-lan-beta/249030
1 Like
The IDE is only good for doing hub logging these days. All device info is not accurately reflected. If you want to see the state of your setup today, use the API Browser+.
In general, devices that are controlled from a manufacturer’s app and connected to ST via Link Services are cloud->cloud integrations and don’t run locally on a hub. Only Edge drivers for Z-Wave/Zigbee/Matter/LAN/Websocket devices run locally on the hub and then only if certain things are not included in a Routine like sending Notifications.
A couple things to report for community awareness:
-
The update seems to have come with some new Edge drivers that were installed even though I have no such devices: bose and SamsungAudio. Since there is a limit to the number of drivers, it’s important to be aware of this. I used the CLI to uninstall them both.
-
A driver of mine that uses a WebSockets library was broken by this firmware update. Seems to be something with the coroutine management for channel handlers receiving data. I’ve reported it and am awaiting resolution. It looks like this in the driver log:
WARN Shelly Gen2 Device Driver V1.3 unnamed handler on driver thread encountered error: callback error
stack traceback:
[C]: in local 'poll'
[string "?"]:5: in field '?'
[string "cosock/socket/internals.lua"]:54: in function <[string "cosock/socket/internals.lua"]:34>
(...tail calls...)
[string "websocket/sync.lua"]:28: in method 'receive'
[string "init.lua"]:319: in upvalue 'callback'
[string "st/driver.lua"]:480: in function <[string "st/driver.lua"]:479>
[C]: in function 'copcall'
[string "st/thread.lua"]:92: in function <[string "st/thread.lua"]:54>
… don’t know if it is necessarily a firmware bug - it could be a problem that is newly uncovered in the driver. (This particular driver has been working just fine for many months with prior firmware.)
@TAustin , I have noticed the Bose/Samsung drivers have been around and mandatorily included for a while (x2 releases ago…ish?)
Deleting them in the past seemed to have no effect as, for me anyway, they ‘magically’ seemed to re-appear!
Deleted them again this evening and will see if they stay gone 
(Wemo and Hue - I am using @blueyetisoftware 's driver for the latter, seem to be two others installed without being in use too…)
They have been around for a while now and it has more to do with their official release into production. They currently need to be installed for there to be discovery routines to run.
I am rather hoping that the search parameters file that is being pushed out for the stock LAN drivers might be intended to be a sort of fingerprint to avoid this.
There’s a seperate topic on this. I asked if these drivers count toward the total number of installed drivers but haven’t gotten an answer.
Why SmartThings has installed unnecessary Wemo etc drivers to my hubs
3 Likes
Must be just the first I’ve noticed them.
And I’ll amend my earlier post - I thought I deleted them, since got no error with CLI, but they are still showing up 
Saw the wemo driver too, but it had found a Linksys range extender, so at least had one device. But the driver was reporting comms errors trying to reach it, so I deleted the device. Wouldn’t doubt if it pops back up again the next time I do an Add device…
1 Like
With the force install of the ST unwanted drivers i find devices start to drop off my hub, they put me near 40 drivers, deleting them and 2 or 3 drivers now unused, stability returns and devices remain connected
For whatever reason the devices that drop off my hub are Ikea smart outlets, Ikea movement sensors and or a single Xiaomi temp sensor
I’m nowhere near the 40 driver limits, but also experiencing drop off issues with the Ikea Outlets
I removed the Linked Account information. I even deauthorised in Hue account. I selected the Hub to Hub connection, not the Linked Account connection.
Follow up to my post regarding a problem caused by this firmware update to one of my drivers:
The SmartThings team has found the issue and will address it in their next update. In the meantime they’ve recommended a workaround which I’ve tried and it works.
Details For LAN driver developers:
When using the tcp socket receive() method, you can pass as a parameter the number of bytes you want to receive. YOU MUST NOW FORCE THIS VALUE TO BE AN INTEGER by using math.floor(), as in:
local number_of_bytes = 10
socket:receive(math.floor(number_of_bytes))
Otherwise, with the latest firmware update, Edge (C code) sees this parameter as a floating point number and this causes the error I reported earlier.
2 Likes
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.