We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.59.4 will begin rolling out in batches starting no sooner than October 31st, 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.
Hub Target
Samsung SmartThings Hub 2015 (Hub v2)
Samsung SmartThings Hub 2018 (Hub v3)
Aeotec Smart Home Hub
Aeotec Smart Home Hub 2
Release Dates
0.59.4: 10-31-2025
0.59.5: 11-11-2025
0.59.6: 11-13-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:
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
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.
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.
I had to read this a couple times, this would fix the issue of get_latest_state returning nil the first time if the driver wasn’t the one that emitted the event, right? Then it’s great news
This is correct, if the device has emitted an event while connected to the hub, the state will be available regardless of if it was generated from the driver or not.
The old problem with buttons 2,3 and 4 on Hue dimmer switch not recording button presses came back with this upgrade. I am using the Philips Hue LAN integration
Edit: Forget that and the logs, it was my fault, Friday and not enough coffee .
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
8
Well that’s problematic. There are many devices (e.g some Tuya valves and sensors etc) which don’t send periodic reports so the drivers use add_monitored_attributes to have the system automatically check on specific attributes and have it poll the device to see it’s still online. This will adversely impact those devices which don’t automatically report configured_attributes due to firmware bugs.
I would not recommend removing this completely, maybe don’t use it by default for regular devices but allow drivers to continue using this amazing API to automatically poll devices which don’t report attributes on a regular basis.
Is there an alternative API which provides similar functionality of polling attributes if they haven’t reported in? If not we’re basically going to have to replicate this API in each driver manually which probably won’t be as efficient as having HubCore do it.
To be clear, hubcore has never done this, this has always been managed only from the lua side in drivers. While we don’t have concrete plans on when this will be removed the overhead is pretty significant, and if you expect a value from a device that does not support reporting, using a single call_on_schedule function to poll the desired attributes is a less intensive way to accomplish that. We’ve noted your interest in either keeping the API or providing a replacement and will discuss before we make any final plans for the deprecation.
4 Likes
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
10
Appreciate it, the current implementation is very nicely done and would be a great to keep the API’s interface the same, even if the backend functionality is stripped down to basically track and send a request on schedule. This will also avoid breaking existing drivers who’s devs aren’t around to update drivers.
On a side note, I found a bug in one of the lua libraries, in st.zwave.defaults.voltageMeasurement → init.lua in the function get_refresh_commands
if device:supports_capability_by_id(capabilities.voltageMeasurement.ID, component) and device:is_cc_supported(cc.SENSOR_MULTILEVEL, endpoint) then
return {SensorMultilevel:Get({sensor_type = SensorMultilevel.sensor_type.VOLTAGE}, {dst_channels = {endpoint}})}
This is incorrect (or more appropriately incomplete) as voltage reports are reported either via cc SensorMultievel or from Meter depending on the device. Most mains powered devices will use the Meter cc to provide this information. A more complete implementation should be:
if device:supports_capability_by_id(capabilities.voltageMeasurement.ID, component) and device:is_cc_supported(cc.SENSOR_MULTILEVEL, endpoint) then
return {SensorMultilevel:Get({sensor_type = SensorMultilevel.sensor_type.VOLTAGE}, {dst_channels = {endpoint}})}
elseif device:supports_capability_by_id(capabilities.voltageMeasurement.ID, component) and device:is_cc_supported(cc.METER, endpoint) then
return {Meter:Get({scale = Meter.scale.electric_meter.VOLTS}, {dst_channels = {endpoint}})}
end
The zwave_handlers may also need to be updated to add support for processing a [cc.METER] report in the same file.
.
good send it to me here what is that.?