57.X Hub V2/V3 Customer Beta Release Notes

[SmartThings]

Hey everyone!

We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.57.7 will begin rolling out in batches starting later today, May 12th, 2025. 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

• 0.57.7

Hub Target

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

Release Date

• Release Date: 12-May-2025

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 (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

• Add support for Matter Intermittently Connected Devices (ICD) utilizing the Long-Idle Time (LIT) feature
• Add Matter Time Synchronization support - the hub now serves as a trusted time source to provide connected devices that support time sync with accurate time.
• Updated mDNS library to improve discovery of Matter and LAN devices
• Fix issue preventing or delaying some Zigbee devices from receiving firmware updates in scenarios where more than 5 Zigbee devices are present
• Improve efficiency of managing stale Zigbee groups that are no longer used to control multiple devices at the same time

Edge Drivers

• Add the ability to register for some events (Switch, Switch Level, and some Zigbee sensors) to be processed and generated outside the edge driver to reduce latency.
• Bugfix to avoid loading subdriver code multiple times in certain cases
• Add support for receiving batches of commands instead of only single commands into edge drivers.
• Support using group commands when possible with Hue LAN edge driver.

NOTE

If you’d like to participate in the beta, 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.

[Andreas_Roedl]

@SmartThings

Add the ability to register for some events (Switch, Switch Level, and some Zigbee sensors) to be processed and generated outside the edge driver to reduce latency.

This seems to be related to this:

Enable native attribute handlers for Zigbee/Z-Wave/Matter drivers

[RBoy (www.rboyapps.com - Making SmartThings Easy!)]

@SmartThings

Add support for receiving batches of commands instead of only single commands into edge drivers.

Any documentation available?

[mocelet]

@SmartThings

Add the ability to register for some events (Switch, Switch Level

Just got the update, it’s been quite the improvement!

Especially for lights that flood the hub with level reports when doing brightness transitions, although the real solution would be to change the subscription interval so they are not sent (with colours or temperature is way worse).

Did a 0.1 second transition in my WiZ light from 100% to 0% which generates 255 reports. The logs span for 6 seconds but felt way faster than before.

Some logs hidden here

2025-05-13T16:52:23.217431454Z INFO Matter Switch  hub handled InteractionResponseInfoBlock { info_block: { endpoint_id: 1, cluster_id: 8, attr_id: 0, nested_path: [], tlv: [4, 251] }, status: 0 }
2025-05-13T16:52:23.218372745Z INFO Matter Switch  hub emitting event 048443b7-5292-4c7c-aea7-a31d3cc7f0b8: {"component_id":"main","capability_id":"switchLevel","attribute_id":"level","state":{"value":99.0}}

....

2025-05-13T16:52:29.731261955Z INFO Matter Switch  hub handled InteractionResponseInfoBlock { info_block: { endpoint_id: 1, cluster_id: 6, attr_id: 0, nested_path: [], tlv: [8] }, status: 0 }
2025-05-13T16:52:29.732105913Z TRACE Matter Switch  Received event with handler device_lifecycle
2025-05-13T16:52:29.734059205Z INFO Matter Switch  hub emitting event 048443b7-5292-4c7c-aea7-a31d3cc7f0b8: {"component_id":"main","capability_id":"switchLevel","attribute_id":"level","state":{"value":0.0}}
2025-05-13T16:52:29.734651913Z INFO Matter Switch  hub emitting event 048443b7-5292-4c7c-aea7-a31d3cc7f0b8: {"component_id":"main","capability_id":"switch","attribute_id":"switch","state":{"value":"off"}}

However, none of those reports appear in the device history, apparently the switchLevel capability is no longer updated from the event! So, the driver or the hub emits the attribute reported by the light but that never gets to the capability.

Maybe it’s a bug or maybe it’s on purpose… If it’s on purpose I understand the reason since the app feels snappier and there was no point on having dozens of events in the history when using transitions. But now, if you change the brightness level from said transitions or from another Matter fabric, the brightness value shown in the SmartThings app or the capability will be wrong.

Mmmh, if I change the brightness from the app, the capability doesn’t update either. That’s certainly weird.

[Andreas_Roedl]

Now test it with a routine: IF level THEN message or whatever.

[mocelet]

As expected it did nothing because the switchLevel level attribute does not change when calling setLevel so the automation never triggers.

But the brightness control from the app works because the hub sends the Matter command to the light. It’s the report from the light the one ignored.

[Andreas_Roedl]

Nice find!

@nayelyz @alissa.dornbos

[mocelet]

Yep, confirming there’s a bug in the native handlers for switchLevel, it won’t update the level.

If you remove the register_native_capability_attr_handler to use the driver generated events as always, it works fine again and level updates and the history appears.

Edit: Maybe it’s the type of the level value? It’s not an integer:

{"component_id":"main","capability_id":"switchLevel","attribute_id":"level","state":{"value":99.0}}

[Andreas_Roedl]

What about switch.switch?

[mocelet]

@Andreas_Roedl

What about switch.switch?

That works great

[Zach_Varberg]

@RBoy

@SmartThings

Add support for receiving batches of commands instead of only single commands into edge drivers.

Any documentation available?

Not yet. This is likely only relevant if there exists a method to send group commands to the end devices, and won’t be achievable for mesh devices, as for security reasons, we only allow outgoing messages directly to the network addresses of devices managed by the driver. However, this can be used for integrations like Hue that support groups for control. You can see Philips-hue batched command handling support by NoahCornell · Pull Request #2075 · SmartThingsCommunity/SmartThingsEdgeDrivers · GitHub for an implementation overriding the default one at a time command handling and using receive_batch to receive and process commands as groups. For the official hue integration the consequence of this is that if you have a rule targeting multiple hue devices, and within the hue app those devices (or a subset of them) are represented by a room or zone, we should send the command to the room or zone instead significantly improving popcorning for hue.

As is always the case with as yet undocumented features we reserve the right to update the API if needed and don’t guarantee stability of the API, although this one is unlikely to change. But until official documentation is out, use at your own risk.

[Zach_Varberg]

@mocelet

Yep, confirming there’s a bug in the native handlers for switchLevel, it won’t update the level.

If you remove the register_native_capability_attr_handler to use the driver generated events as always, it works fine again and level updates and the history appears.

Edit: Maybe it’s the unit of the level value? It’s not an integer:

{"component_id":"main","capability_id":"switchLevel","attribute_id":"level","state":{"value":99.0}}

Thank you for the report, we are investigating

[vctgomes (Vitor Gomes)]

Please, add support to Join into 3rd-party Thread networks!

[Francois_Venter]

The issue with buttons 2, 3 and 4 of the Philips Hue dimmer switch not recording button presses in SmartThings is back with this firmware version.

[mocelet]

@Zach_Varberg

Thank you for the report, we are investigating

Thanks, version 57.10 fixes the issue of the native level handlers, at least for Matter devices.

The logs now display an integer value so I believe my guess was right. I see the tests have been fixed in the drivers too so the issue won’t happen again.

@mocelet

Just got the update, it’s been quite the improvement!

Especially for lights that flood the hub with level reports when doing brightness transitions, although the real solution would be to change the subscription interval so they are not sent

Unfortunately, this improvement was a side effect of the bug that didn’t emit the reports. Now that it is fixed, the hub struggles again with certain transitions.

Started a 5 second transition from 100% to 0% in a WiZ light and, an unrelated automation pressing a button, was delayed 5 seconds after the button press instead of running immediately. We can argue the Aeotec hub is not really powerful enough but, again, the fix is letting drivers change the subscription interval, like Home Assistant did to avoid the same issue.

[Francois_Venter]

The issue with the Hue dimmer switch has been resolved with the .10 release. At first when I tested, it didn’t work but after a hub reboot it became functional.

[mocelet]

There’s a 57.14 released today, apparently.

[orangebucket (Graham)]

@mocelet

There’s a 57.14 released today, apparently.

Yes, I have 57.14 on my beta hub. All I can say is that I didn’t know that until I read this and checked.

I only got 57.13 on my beta hub at the start of the already announced production rollout.