Beta - 62.X Hub Firmware and Edge Driver Release Notes

[SmartThings]

Hi everyone! We’re excited to announce the latest SmartThings Hub Beta. This beta includes both hub firmware version 0.62.X and early access to major upcoming edge driver changes. If you would like to participate check the steps at the bottom of this post to enroll.

The beta period officially starts July 23rd, 2026. The exact firmware versions and their release dates can be seen below and will be updated as new versions are released throughout the beta period. New firmware updates may be released in batches to allow us to monitor performance closely, so you may not get the update immediately. The beta Edge Drivers will be available for install at the start of the testing period.

Note: Your hub will be offline for approximately one minute during the update.

Eligible Hubs

• Samsung SmartThings Hub 2015 (Hub v2)
• Samsung SmartThings Hub 2018 (Hub v3)
• Aeotec Smart Home Hub
• Aeotec Smart Home Hub 2
• ThingsOne Smart Home Hub

Firmware Version Release Dates

• 0.62.3: July 23rd, 2026
• 0.62.4: August 3rd, 2026

Help Us Help You

To help our support team investigate errors, please grant us temporary access to your hub logs by following these instructions:

1. Go to SmartThings Web (my.smartthings.com)
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

Hub Firmware

• Ensure eventual consistency of device state after extended offline periods.
• General stability improvements and reduced network traffic.
• Included firmware updates for SiHAS PMM-300Z2 and PMM-300Z3 power meters, which will be applied automatically if the hub has automatic updates enabled.
• Expanded support for unifying hub Thread networks. Hubs with Thread and Zigbee devices are now eligible to directly join other Thread networks.
• [New in 62.4] Update local time zone calculations to reflect current definitions.

Edge Drivers

• Added a set of device preferences to IKEA BILRESA Scroll Wheel to allow finer, more precise control when adjusting light brightness or color temperature.

Participation and Enrollment

Hub Firmware Beta

If you’d like to participate in this Hub Firmware Customer Beta program, please see these instructions for how to sign up or unenroll.

Anyone who participated in the previous beta is automatically signed up for this one, unless you have unenrolled.

Early Access to Beta Edge Drivers

We also encourage all users to test the latest features and fixes specific to our SmartThings drivers by enrolling in our Beta Driver Channel following the steps below.
NOTE: This is separate from the Hub Firmware Beta mentioned above.

1. Accept Beta Invite: Follow the SmartThings Beta Driver Invitation and log in to your Samsung Account.
2. Enroll: Select Enroll for your specific Hub.
3. Install: Select Available Drivers to browse and Install all relevant beta drivers to your Hub.

[Andreas_Roedl]

Received the update. Didn’t notice a thing, and no devices went offline.

[Andreas_Roedl]

Possible regression: NAT64 is no longer advertised after 0.62.3

It appears that hub firmware 0.62.3 has disabled—or at least stopped advertising—NAT64 on my SmartThings Thread network.

This is based on a direct before-and-after comparison of the Thread Network Data. The diagnostics were collected with the new Thread Network Diagnostic tool, which is still in alpha and does not always discover every device. However, the Network Data returned by the routers is consistent across the latest export.

Before 0.62.3

The SmartThings Thread Border Router at RLOC16 0x8000 advertised a separate NAT64 /96 route:

{
  "prefixLength": 12,
  "prefix": "fd1bc53a66af000200000000",
  "hasRouteList": [
    {
      "macAddr": 32768,
      "routerPreference": 3,
      "isNat64": true
    }
  ]
}

The encoded prefix corresponds to:

fd1b:c53a:66af:2::/96

After updating to 0.62.3

That entire /96 route is gone.

The current Network Data contains only:

• the normal on-mesh prefix fd1b:c53a:66af:1::/64;
• a default route from the SmartThings Border Router at 0x8000;
• another default route from the second Border Router at 0xd400.

Both current route entries explicitly report:

"isNat64": false

Across all diagnostic nodes that returned Network Data, the result is consistent:

NAT64 route entries:       0
Non-NAT64 route entries:  22

So this does not appear to be a single router returning an incomplete response. The Thread partition currently contains no advertised NAT64 prefix.

This matches the behavior documented by OpenThread: an active NAT64 Border Router publishes a dynamically generated /96 prefix as a route in the Thread Network Data. Thread devices obtain that prefix from the Network Data and use it to synthesize IPv6 addresses for IPv4 destinations.

In other words:

Before 0.62.3:
::/0                         default route
fd1b:c53a:66af:2::/96       NAT64 route

After 0.62.3:
::/0                         default route
no NAT64 /96 route

The SmartThings Border Router stack has also changed. It now reports:

vendorSWVersion:
2.2.12-ST-GSDK

threadStackVersion:
OPENTHREAD/610f33e7c-dirty; POSIX; Jul 9 2026 14:53:31

SmartThings originally introduced NAT64 with firmware 0.58.10 and stated in the release notes that it was enabled by default. SmartThings staff also confirmed that each Border Router advertises NAT64 individually and that it can be controlled through the NAT64 Translation setting in the Advanced User Web Interface.

There is no mention of NAT64 in the 0.62.3 beta release notes.

Could the SmartThings team please confirm:

1. Was NAT64 intentionally disabled in 0.62.3?
2. Was the existing NAT64 setting reset during the update?
3. Is this an unintended regression in the new Thread stack?
4. Should the NAT64 Translation option still be available and enabled in the Advanced User Web Interface?

The diagnostics cannot prove whether the translator process itself has been removed, stopped or merely disabled. They do, however, provide strong evidence that the SmartThings Border Router no longer publishes a NAT64 prefix, which means Thread devices cannot discover and use SmartThings’ NAT64 service.

This happened before:

NAT64 not available on V4 Hub

NAT64 worked perfectly fine on my V3… … but on my V4 it’s gone. Nuki app shows that there’s no connection between the lock and the cloud: [Screenshot_20251011_000154_Nuki] The setting is also missing in the AWA: [Screenshot_20251011_000753_Samsung Internet] Mentioned here and I can confirm that I had this setting before: @nayelyz @Michael_ST

Nuki Ultra can’t access the Nuki cloud:

NAT64 is grayed out:

CC: @Itati @nayelyz @Michael_ST

[Declankh]

It would really help if there were proper detailed change logs, not at a code change level obviously (for a variety of reasons ) but at a feature level. That way you’d be able to properly test new functionality that had changed and be able to report undocumented changes (especially those that appear to regress) as bugs with confidence that it’s not an intended change.

[nayelyz]

Hi, @Andreas_Roedl

Thank you for reporting this issue. The engineering team saw your post as well, so they’re already investigating it.

[Oleksandr_Voychenko]

Hi. Can I downgrade FW from v 0.62 to v.0.61? After upgrade of my Aeotec v3 to beta all z-wave devices doesn’t work. I changed parameter of firmware updating to “public”, but it doesn’t help - no stable 0.62 public version yet.

[Oleksandr_Voychenko]

I’ve noticed, that my claim was solved and my Aeotec Hub V3 FW version now is 0.62.00004. Z-Wave devices are working now again. One thing wasn’t solved yet: Z-wave repearing ptocess doesn’t finish.

[Andreas_Roedl]

A short update on the NAT64 issue I reported with 0.62.3:

With 0.62.4, the NAT64 prefix is being advertised again. My Nuki Ultra now receives the expected /96 prefix:

fd1b:c53a:66af:2::/96

and its own Thread diagnostics show:

"isNat64": true

So the original problem from 0.62.3 - where the NAT64 route disappeared completely - has at least been partially fixed.

Unfortunately, the Nuki Ultra still cannot reach the Nuki cloud - even almost a day after the firmware update. It usually re-connects almost immediately.

Before the beta, with the previous stable hub firmware, Remote Access through Thread worked normally. After installing 0.62.3, NAT64 disappeared and the lock lost Internet access. With 0.62.4, the route has returned, but the actual connection still does not work.

The lock itself appears to be connected normally:

• it is attached to the Thread network;
• its parent reports good incoming link quality;
• it receives the default routes;
• it receives the restored NAT64 prefix;
• it still cannot establish Remote Access to the Nuki cloud.

This makes me suspect that 0.62.4 may have restored the advertisement of the NAT64 prefix, but not the complete NAT64 data path.

Possible causes could be:

• the NAT64 Prefix Manager is active, but the Translator is not;
• no NAT64 mapping is created when the Nuki tries to connect;
• the translator was not restarted correctly after NAT64 was disabled in 0.62.3;
• forwarding still uses stale state from the previous on-mesh prefix;
• DNS forwarding or DNS64 is still broken;
• the Advanced Web App setting and the actual runtime state do not match.

The current on-mesh prefix has also changed back from:

fd1b:c53a:66af:1::/64

to:

fd42:58ea:7c8b:1::/64

The Nuki now uses an address from the fd42: prefix, while the SmartThings hub advertises fd1b:c53a:66af:2::/96 for NAT64. It may be worth checking whether the translator is correctly accepting traffic from the restored fd42: prefix and whether any firewall, routing or mapping state was left behind from 0.62.3.

I assume the engineering team will probably not connect directly to my hub, so this will likely need to be reproduced on one of your own beta hubs.

A useful test setup would be:

1. Aeotec Smart Home Hub 2 on 0.62.4
2. NAT64 enabled
3. A Thread device that requires IPv4 Internet access through NAT64
4. Check whether the /96 prefix is advertised
5. Check whether an actual NAT64 mapping is created when the device tries to connect

The relevant OpenThread checks would be something along the lines of:

nat64 state
nat64 mappings
nat64 counters
nat64 error counters

For a working setup, I would expect both the Prefix Manager and Translator to be active, and a connection attempt from the Thread device should create a mapping.

At the moment, the situation looks like this:

Thread attached:          yes
Default route received:   yes
NAT64 prefix received:    yes
Cloud connectivity:       no

So from my side, 0.62.4 looks like a partial recovery: NAT64 is visible again in the Thread Network Data, but the Nuki Ultra still cannot actually use it to reach the Internet.

I’ll give it another day and report back, while you can double check that NAT64 is really fixed.

[Andreas_Roedl]

@Declankh

It would really help if there were proper detailed change logs, not at a code change level obviously (for a variety of reasons ) but at a feature level. That way you’d be able to properly test new functionality that had changed and be able to report undocumented changes (especially those that appear to regress) as bugs with confidence that it’s not an intended change.

… or anything at all.