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.
Yes. I see this problem quite regularly.
I reported to Nayely that this is not the quite case, although I see this problem rarely.
Will cosock error in “zigbee” Edge driver be fixed too?
@erickv mentioned that this will be fixed in version 0.41, but it’s not listed in release notes.
Is this same problem with the release note about stale tcp socket?
I believe @nayelyz or @andresg will be able to confirm if this issue got addressed as we got informed back then.
I can confirm that it has not. Two biggest problems with the platform at the moment for me are:
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:
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!)
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”,…).
Hello we are planning another Beta release for 41, see below… thanks!
Sorry about the slow release, I was waiting to make sure everything was finalized. I’ve made the release of the lua libraries for 0.41.X.
Hello again community.
We are releasing another minor version of 41.8, before the upcoming full production release. Thank you for your continued support.
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
You may need to add this to illuminanceMeasurement_defaults.lua after line 47:
local illuminance_measurement_configuration = {
cluster = zcl_clusters.IlluminanceMeasurement.ID,
attribute = zcl_clusters.IlluminanceMeasurement.attributes.MeasuredValue.ID,
minimum_interval = 30,
maximum_interval = 300,
data_type = zcl_clusters.IlluminanceMeasurement.attributes.MeasuredValue.base_type
}
illuminance_measurement_defaults.default_illuminance_measurement_configuration = illuminance_measurement_configuration
illuminance_measurement_defaults.attribute_configurations = {
illuminance_measurement_configuration
}
If I’m right, this should automatically be trigger the configure_reporting when the default capabilities/handlers are set.
@Zach_Varberg any thoughts?
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
What am I missing? & is the ‘bitwise and’ operator in Lua 5.3+.
Yes, in the specification it comes like this, but in my editor it seems that the syntax correction plugin is outdated or wrong. It gives me an error in that function.
In addition to the fact that the sensor, which I do not have available, was giving that capability as offline in the app, I thought that it could have some relationship.
I have asked the user who has the sensor to do some tests and it does not work, but the logs do not give me any clues
I don’t know if a zigbee sensor with the occupancy capability will work for someone
You see ST added analogue input capability to the new firmware.
Does that help us, effect us in any way? Just curious.
It would have helped to make the Environment Sensor driver easier, which uses that cluster and 
had to write by hand,
But the information and the open source code available on the ZCL clusters and their attributes in the default libraries is very good and essential to do any integration.
