We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.39.x will begin rolling out in batches starting the week of Aug 30; we will send out an email when we start updating Hubs. We will be paying close attention to any issues encountered by users so your hub may not get updated right away. The hub will be offline for about a minute during the update. See below for more specific details about the update.
Please also review our recent announcement of the beta release of SmartThings Edge - a new architecture for Hubs that use Device Drivers and Rules to execute Hub Connected devices with lower latency, higher reliability, and… local execution . Please check out that announcement here.
Hub Target
Samsung SmartThings Hub 2015 (Hub v2)
Samsung SmartThings Hub 2018 (Hub v3)
Release Date
Release Date: 30 August 2021 ~ 03 Sep 2021 Note that this release will be spread over the week, so you may not see your Hub update on the first day of the release period. We will post on this thread once all users should have received the update.
Release Notes
General
Locally enforced rate limits and internal monitoring for rate limits were updated. Each rate limit also has some burst capacity reserved. Other parts of the infrastructure may still rate limit devices if they exceed other limits. Here are the current rate limits which are subject to change:
A hub (across all devices) may not emit more than 30 events/sec sustained
A single driver may not emit more than 15 events/sec sustained
A single device may not emit more than 5 events/sec sustained
Other minor bug fixes and improvements
Edge Drivers
No “default” set of permissions is granted to edge drivers. They must be specified as part of the driver metadata in order to interact with protected APIs (e.g. Zigbee, Z-Wave, LAN, discovery). This aligns with the documented requirements for drivers.
Fixed issue where tcp/udp/tls sockets would “leak” if garbage collected without being explicitly closed first.
Imposed limit of 255 active sockets at any given time per driver.
Add utility for loading custom capability definitions as a part of driver integration tests.
This new function can be used to load a capability from a yaml or json file included in your package directory. This should be done at the top of your test file to make your capability available to use in your tests.
This new function allows you to pass in the profile definition for your mock device and the test framework will attempt to use the smartthings CLI to retrieve all the definitions from the smartthings cloud. This will require a configured smartthings command on the path, and can take quite a while.
You can specify an environment variable ST_CAPABILITY_CACHE to point to a directory where the downloaded capability definitions will be stored and those will be used in future test runs to speed up the process.
Correctly refresh and configure all endoints for Zigbee and Z-Wave devices in the default handling.
NOTE
Anyone who participated in the previous beta (0.38.x) is automatically signed up for this one.
If you’d like to participate in the beta, but haven’t taken the survey yet: Sign Up Here
Currently, it will be fairly silent. We will likely at a minimum be looking to inject logs for developer live logging to indicate the problem and in time we are considering some other options for user facing exception/event notifications longer term. The main symptom one would encounter is that at the rate limit events would be dropped whenever the rate limit is hit. Currently, we use a simple token bucket algorithm for this but we might later add a “penalty box” on top of this which would change the behavior when a rate limit is hit to be a bit different in order to more aggressively prevent buggy drivers from adversely impacting other drivers and the platform.
With the current limits and burst capacity, we don’t expect drivers that are functioning correctly and sanely to bump into the limits. We did have these set too low early on and they were being hit by a developer but in that case things were off by an order of magnitude.
Metrics on this is something we will be looking to monitor during the beta. Fixing that reporting is the actual change included with this firmware release (we were able to adjust the limit parameters based on developer feedback without a firmware release prior to the open beta start).
Thanks for the feedback, the team did a great job. We are happy to hear your feedback. The main reason why we have not had this detail in recent months is because of work we have been doing to prepare for our recent Edge Launch.
Thanks for the details @posborne. I’m not so much concerned about the individual device rate limit as I am the 30events/sec for the entire hub. With a large 200+ device environment, i’m curious how close I will get to this. Is the hub rate limit for all devices, only edge driver devices or groovy and edge combined?
As a user this would be difficult to pinpoint as a rate limit problem unless an explicit warning message is given in an easy to find way (i.e. mobile app, web client, etc). If I noticed a dropped event, the first thing I would troubleshoot is a Zigbee/Z-wave mesh problem, a battery problem, an automation not working right, etc. I wouldn’t suspect a rate limit problem as my #1 suspect.
I’ve been having some serious drop issues lately. Things that have been working fine for months are now misfiring. I am edging ever so close to the 300 device limit. My IDE log shows alot of activities and I have power meters all over the place. Guess its time to dumb down even more…
When I hit the 300 mark previously, the first page in the IDE would have 300 devices and then there would be a second page with the remaining devices. The second page would change the device list almost every time I logged in. I noticed that devices that were on the second page would be the ones that I was having troubles with (misfires, delays, not firing at all…). I am actually having some issues now after installing about 5 of the Meros wifi devices with cloud integration. Before then, everything was working fine. Don’t know if related or just ST making changes in the background.
Interesting. I had heard about that paging issue. For me at least it is all listed on one page and nothing appears to be missing. Nor am I having any general issues with devices themselves that I have noticed. I passed 300 devices a few weeks ago.
Hello, we are beginning the release now. Centercode has also been updated so you should have access to report findings of 0.39 in Centercode as well. Thank you.
