We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.41.x will begin rolling out in batches starting on Jan 13th; we will send out an email when we start updating Hubs. We will be paying close attention to any issues encountered by users so your hub may not get updated right away. The hub will be offline for about a minute during the update. See below for more specific details about the update.
If you haven’t seen our recent announcement announcing the beta release of SmartThings Edge - a new architecture for Hubs that use Device Drivers and Rules to execute Hub Connected devices with lower latency, higher reliability, and… local execution . Please check out that announcement here.
Version
0.41.x
Hub Target
Samsung SmartThings Hub 2015 (Hub v2)
Samsung SmartThings Hub 2018 (Hub v3)
Release Date
Release Date: 13 January 2022 ~ 14 January 2022
Note that this release will be spread over the listed days, so you may not see your Hub update on the first day of the release period. We will post on this thread once all users should have received the update.
Release Notes
General
Reduce CPU and Memory consumption in various components
Edge Drivers
Bugfix for stale tcp socket connects timing out and killing the driver process
Bugfix for Edge Driver backed Zigbee devices with the Power Meter capability reporting power levels that were off by a factor of 1000 (incorrect conversions between Watts and Kilowatts)
Add AnalogInput Zigbee cluster to the library
Allow usage of the "visibility" field for edge driver events.
Fix colorTemperature rounding inconsistencies
Add Particulate Matter 1 constants for Z-Wave Multilevel Sensor Command Class
NOTE
Anyone who participated in the previous beta (0.40.x) 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
I see nothing regarding the cosock problems causing random fatal errors and crashed driver updates. I’ve had 000.041.00006 for a week or so and I’m still seeing these issues. Drivers sometimes hang when updating and the hub either has to be rebooted or the driver deleted and reinstalled.
Or is that what you are referring to with this bullet:?
I see nothing regarding the cosock problems causing random fatal errors and crashed driver updates.
Are you referring to the issue you mentioned here?
Bugfix for stale tcp socket connects timing out and killing the driver process
This release note is referring to a bug we found while investigating a different issue that you brought to our attention. This should be fully mitigated now.
I can confirm that it has not. Two biggest problems with the platform at the moment for me are:
Hung driver re-installs
When driver does proceed with re-install it, driver starts, does some initialization (which includes creating a server socket and doing some http calls), then crashes with the infamous cosock error. Then tries to restart again, then cosock error, etc. ad infinitum
FATAL Shelly Device Driver V1 Lua: runtime error: [string “cosock.lua”]:296: cosock tried to call socket.select with no sockets and no timeout. this is a bug, please report it
Since I’m in complainer-mode, I’ll add a few more issues not addressed in this firmware update, but that have been reported before:
Erroneous timer warning messages:
WARN Shelly Device Driver V1 failed to cancel dropped timer, timer has leaked Invalid timer ID
This was acknowledged as a bug by Patrick Barrett when he was still here in this topic post
List display types still show values in random order in the mobile app (at least in iOS)
Occasional cases where dashboard states aren’t showing the correct value. The details screen always does. Sometimes it fixes itself, but other times state values seem to get ‘stuck’ on the dashboard.
Random cases where capability attribute emits are dropped or ignored; i.e. the device attribute doesn’t get updated
Handling of closed connections: if the sender of a TCP (HTTP) message immediately closes the connection after sending to the hub (which some devices do to conserve battery or simply because they are poorly written), when the driver does a getpeername in the channel handler immediately after accepting the connection, it can get an error and the driver is unable to know who sent the message (even though the driver can proceed and receive the message itself). This may not be a bug per-se, but there needs to be something done to preserve the IP:port of the sender so that the driver (server) knows who the message is from. There isn’t always going to be self-identifying information in the HTTP headers or endpoint. Again, this is something I had discussed with Patrick but I know he didn’t got around to addressing it.
Unknown if fixed: during custom capability initialization it was sometimes necessary to reboot the hub to fix an ‘unknown capability’ error. The workaround recommended was to use the 'build_cap_from_json" method. Not clear if we should continue to do that or it is safe to switch back to the other (simpler) way?
On the plus side there have been some improvements, and I especially appreciate the fixing of the duplicate lifecycle calls to the driver when preference settings were changed. (That was a killer!)
By “List display types”, do you mean in a custom capability, correct?
Does this happen only with custom capabilities? Your description made me think of an issue reported that is related to the alternatives in the dashboard view. When we define certain alternatives in dashboard.states and assign a different value to the attribute, the status is not “updated” in this view.
Note: This kind of issues are not related to the Hub’s firmware update, if you like, we can discuss them in a new thread
About this issue, the build_cap_from_json is no longer necessary, I’ve been working with custom capabilities and you only need to make reference to them like:
local issueWRange = capabilities["commonsmall09402.issueWRange"]
No reboot and no extra files (capability definition or presentation) needed.
Yes. I have a theory that I haven’t yet tested that perhaps not having a defined VID in the metadata may be causing this. I have other custom capabilities that do show correct order but they have a VID.
Great news! This will definitely simplify code a bit Thank you.
I haven’t found that VID matters. I see the random list order no matter what. I don’t think it’s actually random though - I think the keys are being reduced to a value and then sorted. I’ve managed to get list items in the right order by setting keys to numerical strings (“100”,“101”,…).
I have seen that in the illuminance defaults of v 041.x there is still no default reporting interval configuration.
I don’t know if they are really in the Hub, but I have the drivers since v040.x with the reports configuration manually in the installation, because if I don’t do it, the illuminance capability doesn’t work.
I do not want to remove it, if it is still necessary because it is not in the defult libraries that you have published from firmware 041.x
Thanks
-- Copyright 2021 SmartThings
--
-- Licensed under the Apache License, Version 2.0 (the "License");
-- you may not use this file except in compliance with the License.
-- You may obtain a copy of the License at
--
-- http://www.apache.org/licenses/LICENSE-2.0
--
-- Unless required by applicable law or agreed to in writing, software
-- distributed under the License is distributed on an "AS IS" BASIS,
-- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-- See the License for the specific language governing permissions and
-- limitations under the License.
local zcl_clusters = require "st.zigbee.zcl.clusters"
local capabilities = require "st.capabilities"
--- @class st.zigbee.defaults.illuminanceMeasurement
--- @field public zigbee_handlers table
--- @field public attribute_configurations table
--- @field public capability_handlers table
local illuminance_measurement_defaults = {}
--- Default handler for illuminance attribute on the illuminance measurement cluster
---
--- This converts the Uint16 value to IlluminanceMeasurement.illuminance in lux
--- Based on formula described in ZCL reference - MeasuredValue = 10,000 x log10 Illuminance + 1
---
--- @param driver Driver The current driver running containing necessary context for execution
--- @param device st.zigbee.Device The device this message was received from containing identifying information
--- @param value st.zigbee.data_types.Uint16 the value of the illuminance attribute on the illuminance measurement cluster
--- @param zb_rx st.zigbee.ZigbeeMessageRx the full message this report came in
function illuminance_measurement_defaults.illuminance_attr_handler(driver, device, value, zb_rx)
local lux_value = math.floor(math.pow(10, (value.value - 1) / 10000))
device:emit_event_for_endpoint(zb_rx.address_header.src_endpoint.value, capabilities.illuminanceMeasurement.illuminance(lux_value))
end
illuminance_measurement_defaults.zigbee_handlers = {
global = {},
cluster = {},
attr = {
[zcl_clusters.IlluminanceMeasurement] = {
[zcl_clusters.IlluminanceMeasurement.attributes.MeasuredValue] = illuminance_measurement_defaults.illuminance_attr_handler,
}
}
}
illuminance_measurement_defaults.capability_handlers = {}
return illuminance_measurement_defaults
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
18
You may need to add this to illuminanceMeasurement_defaults.lua after line 47:
I have gone to use the defaults of the capability occupancy and there is a syntax error in the function of emit the event, the & operator seems to have some nostalgia for groovy
--- Default handler for occupancy attribute on the occupancy sensing cluster
---
--- This converts the Bitmap8 value of the occupancy attribute to OccupancySensor.occupancy occupied if bit 1 is set
--- unoccupied otherwise
---
--- @param driver ZigbeeDriver The current driver running containing necessary context for execution
--- @param device st.zigbee.Device The device this message was received from containing identifying information
--- @param value st.zigbee.data_types.Bitmap8 the value of the occupancy attribute on the OccupancySensing cluster
--- @param zb_rx st.zigbee.ZigbeeMessageRx the full message this report came in
function occupancy_sensor_defaults.occupancy_attr_handler(driver, device, value, zb_rx)
local attr = capabilities.occupancySensor.occupancy
device:emit_event_for_endpoint(zb_rx.address_header.src_endpoint.value, ((value.value & 0x01) ~= 0) and attr.occupied() or attr.unoccupied())
end
Thank you.