Hub Firmware Beta 0.41.X

Hub Firmware 0.41.X Beta

Hey everyone!

We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.41.x will begin rolling out in batches starting on Jan 13th; 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.

If you haven’t seen our recent announcement announcing 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.


  • 0.41.x

Hub Target

  • Samsung SmartThings Hub 2015 (Hub v2)
  • Samsung SmartThings Hub 2018 (Hub v3)

Release Date

  • Release Date: 13 January 2022 ~ 14 January 2022
    Note that this release will be spread over the listed days, 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


  • Reduce CPU and Memory consumption in various components

Edge Drivers

  • Bugfix for stale tcp socket connects timing out and killing the driver process
  • Bugfix for Edge Driver backed Zigbee devices with the Power Meter capability reporting power levels that were off by a factor of 1000 (incorrect conversions between Watts and Kilowatts)
  • Add AnalogInput Zigbee cluster to the library
  • Allow usage of the "visibility" field for edge driver events.
  • Fix colorTemperature rounding inconsistencies
  • Add Particulate Matter 1 constants for Z-Wave Multilevel Sensor Command Class


Anyone who participated in the previous beta (0.40.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


Will there be information on how to use this option?
I’m looking for it in the documentation and I don’t see anything

1 Like

I see nothing regarding the cosock problems causing random fatal errors and crashed driver updates. I’ve had 000.041.00006 for a week or so and I’m still seeing these issues. Drivers sometimes hang when updating and the hub either has to be rebooted or the driver deleted and reinstalled.

Or is that what you are referring to with this bullet:?

I see nothing regarding the cosock problems causing random fatal errors and crashed driver updates.

Are you referring to the issue you mentioned here?

Bugfix for stale tcp socket connects timing out and killing the driver process

This release note is referring to a bug we found while investigating a different issue that you brought to our attention. This should be fully mitigated now.

Yes. I see this problem quite regularly.

I reported to Nayely that this is not the quite case, although I see this problem rarely.

Will cosock error in “zigbee” Edge driver be fixed too?

@erickv mentioned that this will be fixed in version 0.41, but it’s not listed in release notes.

Is this same problem with the release note about stale tcp socket?

1 Like

I believe @nayelyz or @andresg will be able to confirm if this issue got addressed as we got informed back then.

1 Like

I can confirm that it has not. Two biggest problems with the platform at the moment for me are:

  1. Hung driver re-installs
  2. When driver does proceed with re-install it, driver starts, does some initialization (which includes creating a server socket and doing some http calls), then crashes with the infamous cosock error. Then tries to restart again, then cosock error, etc. ad infinitum

FATAL Shelly Device Driver V1 Lua: runtime error: [string “cosock.lua”]:296: cosock tried to call with no sockets and no timeout. this is a bug, please report it

1 Like

Since I’m in complainer-mode, I’ll add a few more issues not addressed in this firmware update, but that have been reported before:

  1. Erroneous timer warning messages:

WARN Shelly Device Driver V1 failed to cancel dropped timer, timer has leaked Invalid timer ID

This was acknowledged as a bug by Patrick Barrett when he was still here in this topic post

  1. List display types still show values in random order in the mobile app (at least in iOS)

  2. Occasional cases where dashboard states aren’t showing the correct value. The details screen always does. Sometimes it fixes itself, but other times state values seem to get ‘stuck’ on the dashboard.

  3. Random cases where capability attribute emits are dropped or ignored; i.e. the device attribute doesn’t get updated

  4. Handling of closed connections: if the sender of a TCP (HTTP) message immediately closes the connection after sending to the hub (which some devices do to conserve battery or simply because they are poorly written), when the driver does a getpeername in the channel handler immediately after accepting the connection, it can get an error and the driver is unable to know who sent the message (even though the driver can proceed and receive the message itself). This may not be a bug per-se, but there needs to be something done to preserve the IP:port of the sender so that the driver (server) knows who the message is from. There isn’t always going to be self-identifying information in the HTTP headers or endpoint. Again, this is something I had discussed with Patrick but I know he didn’t got around to addressing it.

  5. Unknown if fixed: during custom capability initialization it was sometimes necessary to reboot the hub to fix an ‘unknown capability’ error. The workaround recommended was to use the 'build_cap_from_json" method. Not clear if we should continue to do that or it is safe to switch back to the other (simpler) way?

On the plus side there have been some improvements, and I especially appreciate the fixing of the duplicate lifecycle calls to the driver when preference settings were changed. (That was a killer!)

1 Like
  1. By “List display types”, do you mean in a custom capability, correct?
  2. Does this happen only with custom capabilities? Your description made me think of an issue reported that is related to the alternatives in the dashboard view. When we define certain alternatives in dashboard.states and assign a different value to the attribute, the status is not “updated” in this view.

Note: This kind of issues are not related to the Hub’s firmware update, if you like, we can discuss them in a new thread

About this issue, the build_cap_from_json is no longer necessary, I’ve been working with custom capabilities and you only need to make reference to them like:

local issueWRange = capabilities["commonsmall09402.issueWRange"]

No reboot and no extra files (capability definition or presentation) needed.

Yes. I have a theory that I haven’t yet tested that perhaps not having a defined VID in the metadata may be causing this. I have other custom capabilities that do show correct order but they have a VID.

Great news! This will definitely simplify code a bit :+1:t3: Thank you.

I haven’t found that VID matters. I see the random list order no matter what. I don’t think it’s actually random though - I think the keys are being reduced to a value and then sorted. I’ve managed to get list items in the right order by setting keys to numerical strings (“100”,“101”,…).

1 Like