Hub Firmware Beta 0.41.X

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?

1 Like

I believe @nayelyz or @andresg will be able to confirm if this issue got addressed as we got informed back then.

1 Like

I can confirm that it has not. Two biggest problems with the platform at the moment for me are:

  1. Hung driver re-installs
  2. 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

1 Like

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:

  1. 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

  1. List display types still show values in random order in the mobile app (at least in iOS)

  2. 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.

  3. Random cases where capability attribute emits are dropped or ignored; i.e. the device attribute doesn’t get updated

  4. 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.

  5. 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!)

1 Like
  1. By “List display types”, do you mean in a custom capability, correct?
  2. 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 :+1:t3: 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”,…).

1 Like

Hello we are planning another Beta release for 41, see below… thanks!

Release Notes: Hub Firmware 0.41.7

Hub Target

  • Samsung SmartThings Hub 2015 (Hub v2)
  • Samsung SmartThings Hub 2018 (Hub v3)

Release Date

  • Release Date: 25 January 2021

Release Notes

Edge Drivers

  • Fixed a bug where updating a crashing driver could sometimes lead to a driver becoming stuck in an unrecoverable loop
  • Fix an issue with Zigbee-backed edge drivers sometimes failing to configure in a rejoin situation (e.g. after factory reset)
2 Likes

When will the edge libraries of firmware 041.x be available?

APIv0 Hub Release 40.X

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.

2 Likes

Hello again community.

We are releasing another minor version of 41.8, before the upcoming full production release. Thank you for your continued support.

Hub Target 0.41.8

  • Samsung SmartThings Hub 2015 (Hub v2)
  • Samsung SmartThings Hub 2018 (Hub v3)

Release Date

  • Release Date: 28 January 2021

Release Notes

  • Various fixes and improvements
3 Likes

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?

@Zach_Varberg,

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 :wink:

--- 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 :smile: 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.

4 Likes