Hub Firmware Beta 48.1

Hub Firmware 0.48.1 Beta

Hey everyone!

We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.48.1 will begin rolling out in batches starting on May 8, 2023. This will be a phased rollout so that we can keep a close eye on any issues that arise so your hub may not be updated immediately. The hub will be offline for about a minute during the update. See below for more specific details about the update.

Version (Release Date)

  • 0.48.1 (May 8th - 9th, 2023)
  • 0.48.2 (May 17th - 18th, 2023)
  • 0.48.3 (May 31st - June 1st, 2023)

Hub Target

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

Help Us Help You

As part of our Beta program, it is important for our support team to investigate logs from Hubs running that are reporting errors. To provide our team access, please follow these instructions:

  1. Go to SmartThings Web (
  2. Log in to your Samsung Account
  3. Select the Menu (⋮) and choose Settings
  4. Toggle on Account Data Access
  5. Select the time period and choose Confirm

Release Notes


  • Addition of Meter Identification Cluster to the Zigbee Libraries
  • Add ability to manually initiate firmware updates for individual Matter devices even if the Hub’s automatic device firmware update setting is disabled
  • Improvements to Edge Driver memory usage
  • Additional improvements and bug fixes


  • Various improvements and bug fixes


  • Improved onboarding time for Matter devices
  • Various improvements and bug fixes


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


I’ve come across a fairly major bug in this firmware. Sometimes, when a Z-Wave device is paired and the Z-Wave driver doConfigure lifecycle is called by hubcore, the hub’s node id in the environment variable driver.environment_info.hub_zwave_id is missing. This causes a loss of directional communication with the device because association configuration requires this node id and the times this id goes missing while pairing the device can no longer initiate communications with the hub. I’ve also raised a ticket for it.

1 Like

Hey @RBoy Thank you for reporting this issue. Do you have a rough timeframe of when you experienced this?

All day today, sent in the logs along with the time stamps and other debug information. Also submitted the hub logs from the ide.

Good morning,
Also this time I didn’t get the beta update, my hub is stuck at 47.11. Thanks for your help

Thank you for your communication.

Can you please share with us if you never saw the zwave ID populated? Or is it just that periodically throughout the day it is unavailable?

@alissa.dornbos , same here. I still haven’t received the update. I did get an email from ST saying there was some sort of issue validating my hubID, but it’s correct and I validated everything on my end that was asked of me. Not sure why this hub beta had issues while all the other ones in the past were just fine.

Hello @johnconstantelo and @GiacomoF, I’m looking into both of your cases as to why your hubs were not updated and will hopefully have a resolution shortly. Thanks.

1 Like

I’m still seeing the behavior today, it’s easy to replicate, every time I pair the device and update the driver I can see the issues (once in a rare while the information will be populated during pairing but most of the time it’s missing). Let me explain what I’m observing in more details:

When a device is paired there are three lifecycle handlers called, init, added and doConfigure. During the first 2 there’s absolutely no information in driver.environment_info (it reports an empty table {}), where as during doConfigure it’s only partially populated with only the hub_zigbee_eui but the hub_zwave_id is missing (this is the critical one for z-wave devices)

When a driver is updated, init is called and this time driver.environment_info only contains hub_zigbee_eui (v/s nothing during a pairing) but the hub_zwave_id is still missing.

doConfigure and added are never called again for z-wave devices other than during the initial pairing so there’s no way to tell if that information gets populated later on.

When the other lifecycle handlers like infoChanged and removed are called after the pairing is completed or when capability commands like refresh are called, it does contain the hub_zwave_id in the driver.environment_info structure so I don’t see any issue there.

I hope this helps pin point the source of the problem.

A couple of other bugs/things I’ve noticed with this firmware.

  1. When the lifecycle handler init is called during pairing or after a driver update, the driver.environment_info structures are empty during pairing and only contains the zigbee_eui after a driver update, which means there is no zwave_hub_id. Is this by design or a bug?
  2. When the lifecycle handler added is called, the driver.environment_info structures are empty, which means there is no zwave_hub_id and there’s also no zigbee_eui. I’m going to assume that this is a bug because there are ST drivers in production today which are communicating with the device during the added lifecycle but without the hub id, the association groupings will fail and it will lead to a loss of communication with the devices that require association groupings.
  3. According to the documentation the infoChanged lifecycle handler is called when there are changes made to the device information, quoting: An example could be a change to the name of the device. I can confirm that this is NOT happening with firmware 48.1. When the device name is changed the infoChanged handler is not being called.

Hey John. Your hub should be updated now to 48 - thank you for your continued engagement. It is always appreciated.

1 Like

one hub (Smartthings Hub I) has updated while the other (Smartthings Hub II) has not updated yet. Thank you for your support.

Hello - We have released 48.2 with a fix for this, can you confirm if you are still running into this ?

Thank you for your communication.


It’s been fixed with 48.2, thanks for the quick turnaround.

1 Like

So I found another bug in the 48.2 firmware. I have a sleepy z-wave device. When I try to exclude it, the mobile app exclusion screen (and device) confirm that it’s been excluded.
However the device is still showing up in the list of devices in the account and I also noticed the driver removed lifecycle method isn’t called.
I’ve submitted the hub logs from the IDE (hub ID D052A83575270001), time is about 6:20pm EST, device id fe42833a-b6c3-47be-a529-85f663d123bb

@alissa.dornbos I’m seeing this issue repeatedly (as in about 30%-40% of the time with z-wave sleepy devices), the device excludes successfully but it isn’t removed from the mobile app and the driver removed lifecycle isn’t called essentially creating a ghost device in the system and only way to remove it to forcefully delete it.

I’m seeing a secondary issue, where I’ve seen one device get duplicated in the mobile app while pairing. Also when I force deleted some ghost devices (which excluded successfully but didn’t disappear from the app), it also seemed to disconnected an unrelated working z-wave device, as in it could no longer communicate with the hub. There seems to be some wires getting cross internally.

1 Like

Hey @RBoy .

I am sorry that you are expirencing these additional issues. Can you please confirm with me some more details?

What version of the App are you using? iOS or Andriod? If you have screen shots or videos, that is always very helpful too.

Can you reproduce this with any of your other non 48 hubs?

All my dev hubs are on the beta firmware. Will take a video of the issue the next time.

iOS 16.6, iPhone 12 Pro latest SmartThings app

Happened again, I’ve captured some screenshots and logs, will PM them to you

1 Like

@alissa.dornbos , what’s provided in the 48.3 release that we just got for our hubs? I’ve noticed a few Zigbee switches go offline for an hour or so and then come back on their own or after being manually used (this could have been under 48.2, but not sure).

EDIT : add a leak sensor to the mix of devices going offline. The batter died and I replaced it, which made it report data for just about an hour but now it’s offline for no reason at all.

This other single-post thread perhaps needs to be acknowledged too.