Aeotec Smart Home Hub/2018/2015 Model Hub Firmware Release Notes - 0.48.03

Most of my linked services just t vanished. When I try to re-add, it gives network error.
Delay in automations and responses.

2 Likes

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.

5 Likes

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.

4 Likes

Yes same, when I try reconnect Google to SmartThings it’s says “something went wrong”

4 Likes

Same here.

In addition most of linked services/devices like Yeelight, eWelink, Meross etc are not showing. Trying to re-add gives server error.

1 Like

AWS outage

https://downdetector.com/status/aws-amazon-web-services/

https://health.aws.amazon.com/health/status

3 Likes

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

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:

  1. 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.

  2. 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 :face_with_raised_eyebrow:

(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.