Hub Firmware Beta 0.39.X

Hey everyone!

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.
    • integration_test.add_package_capability(capabiltiy_filename)
      • 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.
    • integration_test.load_all_caps_from_profile(profile_def)
      • 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

If you’d like to opt-out, update your preferences via the Account Settings menu item in Centercode

0.39.X releases

0.39.5 Release Notes (September 14-15th release): Hub Firmware Beta 0.39.5
0.39.6 Release Notes (September 17th release): Hub Firmware Beta 0.39.6

8 Likes

Nice! Detailed and to the point firmware release notes. Thank you so much!

4 Likes

+1, finally some detailed release notes. Thanks!

6 Likes

@alissa.dornbos These are the most detailed and professional release notes to be given to the community in many years. Thank you!

2 Likes

For the new guardrails, how do we know if we’ve hit them? Is there a notice in the app or only in some kind of CLI client?

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

2 Likes

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.

1 Like

Well, I be d…Actual release notes! Ok, I see you ST Team! :+1:

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…

Ron, I’m at 309 devices and seem to be fine. I can even see all 309 in the IDE without issues.

(iOS user).

Lutron devices by chance?

1 Like

several times when i hit the 300 device mark weird things started happening. each time i ended up starting over.

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.

We will see…

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.

1 Like

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.

3 Likes

Mine came through a couple hours ago. :+1:

updated 3 hours ago, all good :+1:

Got it as well

Hey

How long for going through the beta signups?
Thanks