Most of my linked services just t vanished. When I try to re-add, it gives network error.
Delay in automations and responses.
Just looked at the history - the Sengled bulbs come on every 6 minutes.
In the last hour I have lost connection between Google Home and Smartthings.
When I give Goggle Home a command that is connected to Smartthings I get this audio response:
âI couldnât reach Smartthings.â
Can this be connected to this mail I got an hour ago?
" Aeotec Smart Home Hub, SmartThings Hub 2015 (v2), and SmartThings Hub 2018 (v3) Firmware Update
The scheduled maintenance has been completed.
Jun 13, 18:00 UTC"
What is happening with Smartthings.
Same happened here. Cant control my lights. When i ask google to turn on or off lights it says âI couldnât reach Smartthings.â How will i solve this issue. All my smart devices are someway connected to smartthings and now nothing works. Lights, lightstrips, switchbot devices, motion sensors, tvâs, speakers, cameras etcâŚpeep its 11 pm here and this stresses me out. Hopefully in the morning someone has replied something or it has automatically started to work again? Wtf smartthings did that it single handedly handicapped and killed my smart home deviceâs? I have aotec smart home hub.
Yes same, when I try reconnect Google to SmartThings itâs says âsomething went wrongâ
Same here.
In addition most of linked services/devices like Yeelight, eWelink, Meross etc are not showing. Trying to re-add gives server error.
None of my devices are responding after the update, is there a fix?
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
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.
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.
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
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.