We will begin rolling out Samsung SmartThings Hub firmware version 0.59.8 starting on December 8, 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. Once downloaded, your Hub will briefly go offline as it reboots and applies the update; most customers will experience less than one minute of downtime. We will update the status page when the release is complete.
Hub Target
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
Release Periods
December 8th, 2025 - December 12th, 2025
Platforms to be updated:
Samsung SmartThings Hub 2018 (Hub v3)
Aeotec Smart Home Hub
Aeotec Smart Home Hub 2
ThingsOne Smart Home Hub
January 12, 2026 - January 16, 2026
Platforms to be updated:
Samsung SmartThings Hub 2015 (Hub v2)
Note that this release will be spread out over the course of one week per release period, so you may not see your Hub update on the first day of the release period. This release period is an estimate, so the rate of hubs updated and final completion date may vary slightly within the timeframe. Please check the status page for more up to date information on this release.
Release Notes
General
Upgraded to Matter 1.5 SDK
Added support for Matter Cameras with the following features:
Live Streaming, Snapshot and Video Clip Recording, Zone Management, Live Talkback, Pan-Tilt-Zoom
Requires SmartThings App Version 1.8.41.x (Android) or 1.7.41.x (iOS), which will be available soon
When merging a Hub’s Thread network into a 3rd party network, handle unexpected data in the Thread network settings that might have previously prevented the merge from succeeding.
Edge Drivers
Significant Memory optimizations
In sum these changes represent cutting the memory used by running drivers on the system in half. In practice this means all hubs upon receiving the firmware should be able to support double the number of drivers and devices. The exact gains will somewhat depend on the devices and drivers being used.
These changes should be fully backwards compatible and automatically apply to all existing drivers. Some, like the new method for subdriver loading, will require driver changes to fully utilize the new savings, but the existing methods will continue to work, they just wont see the same benefits.
Add lazy_load_subdriver_v2 option that allows for a different subdriver structure to further limit memory usage of subdrivers
Split some commonly required files up (e.g. st.utils) so that only the functions being used are in memory so some previous functionality may be in new files
Remove device event state cache from lua. Instead if get_latest_state is called the value will be loaded from the hub, and after that point will continue to cache events generated from the driver, but only for values that have been requested via get_latest_state
Additional structural changes to optimize memory footprint.
Other Driver Changes
On startup enforce parent devices being sent the init lifecycle event before children allowing children that depend on parent information to not have to handle cases where the parent is not yet present.
Extend the latency improvements for default handlers to Zigbee Light Link (ZLL) devices
Deprecation Notice
For Zigbee devices, the monitored_attribute feature is being deprecated. There are other systems in place for tracking when we last heard from a device and updating the attributes, so duplicating that effort in the driver was both memory and cpu expensive but unnecessary. For now a warning will be added to documentation and on calling functions related to monitored_attributes and the release where these will be fully removed hasn’t been decided yet, but developers should remove usage when they next update their drivers.
I’m currently getting a soft memory limit warning on my new Home Hub 2. Even though it’s got more memory that the v3 hub I migrated from. It this a memory limit or a hard coded number of drivers. And will this number be doubled going forward after this update ?
Me too, hopefully just a logical split across a christmas release freeze though.
Very common for service providers to have non-essential update moratoriums over major commercial holidays. It would also be sensible to prioritise newer and still available hubs as they are going to be the new customers over the same period…
Speaking as a (2015) V2 hub user, I think ‘serialising’ the update of different model hubs makes it easier to predict when your hub will be updated. Suspending updates over a major holiday period, when homes may be unoccupied is also a good idea (I think there was some criticism in the past).
I take comfort from the fact that the same update is being applied to 2015, 2018, and 2025 hubs.
I definitely would not be giving Samsung ideas with speculative posts on this thread.
Reminding you my message from previous hub updates:
Two problems are still missing:
increase the transition of oflline time, so we won’t receive false offline states from zigbee devices that works on battery, that didn’t report status within 2 hours. I prefer 10 hours.
Just to clarify, as a few of you have already caught onto the reason for two separate release periods this time around is us wanting to be sure we have proper monitoring coverage during the busy holiday times here in the US and splitting by model made the most sense. The V2 releasing later is purely a result of a busy time of year .
Yes, but the app doesn’t need to make a distinction and just let us exceed the 300 limit . The current limit is based on the location and not which hubs, or even the number of hubs in the location. However, maybe this will sway them to change it.
If the Aeotec v4 (aka home hub 2) has both more cpu and ram it ought to be able to support more devices, unless there’s some other non hardware constraint it might be best to vary device limit by hub variant. However I can see that might confuse matters for the customer, I still think it would be best to get the max out of your kit though, rather than force everyone to the lowest common denominator.
The Aqara motion sensor, that is using Community driver, also went offline. After the first motion detection the device status changed to online.
My email account registered in the forum is the same one I use for SmartThings.
Of course, the problem could also be in Shelly’s Matter implementation.
MQTT communication to the Shelly 1 Gen3 device has been working and is operating normally. MQTT communication takes place via another ST hub.
EDIT:
SmartThings engineering team reviewed the issue and confirmed that the Shelly1 Gen3 device cannot be found on the network and is failing to respond and the hub is working correctly.
The normal power off - power on fixed the problem. However, there is not always a babysitter to do this.
My summary:
The reliability of Matter communication is not yet at the same level as Zigbee and Z-wave communication.
.
. The current limit is based on the location and not which hubs, or even the number of hubs in the location. However, maybe this will sway them to change it.
