Hub Firmware Beta 0.42.6

Developer Programs Hub Firmware Beta
1

Hub Firmware 0.42.6 Beta

Hey everyone!

We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.42.6 will begin rolling out in batches starting on Wed March 23. 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.

Version

  • 0.42.6

Hub Target

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

Release Date

  • Release Date: 22 March 2022 ~ 24 March 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

  • Zigbee device queried endpoints increased from 4 to 16.

Edge Drivers

  • Allow drivers to specify additional_zcl_profiles to allow Zigbee messages of unexpected profiles to be parsed as ZCL
  • Move driver call_with_delay and call_on_schedule to be handled on the non main st.Thread to reduce likelihood of blocking issues locking the driver.
  • Update low level API to pass ipv4 hub address as string
  • Add websocket Lua libraries, this can be accessed by calling require(“lustre”) See Lustre’s docs for more information on usage
  • Add st.json library to be preferred for dkjson for optimization purposes
  • IO errors on socket communications will now bubble up instead of restarting the driver
  • Added driver lifecycle event hook to the shutdown event

NOTE

Anyone who participated in the previous beta 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

If you’d like to opt-out, update your preferences via the Account Settings menu item in Centercode

3 Likes
2

Any documentation for this?

1 Like
3

What is the updated version? 42.5 or 42.6? Both are stated in the post.

4

42.6

I have made the correction, thank you.

5

that’s strange then… my hub displays 42.5

6

Thanks for letting me know, will take a look.

7

42.5 and 42.6 are the same functionally, the only change in 42.6 was a fix for a bug in the build process that only affected our “external beta” builds. @jkp I believe you were part of the testing for edge drivers right? So you’re actually getting a build from one step before the external beta build, what we call “internal beta”/“external alpha”. We could move the external alpha folks back to external beta but there hasn’t been any strong need. And there may be future functionality testing where having the smaller alpha group could be useful.

Hope this helps clear things up a bit - sorry for the confusion!

3 Likes
8 
Lua: deserialize error: invalid value: byte array, expected a string
Traceback:
stack traceback:
	[C]: in function 'coroutine.yield'
	[string "coroutine"]:9: in function 'wrapped_coroutine_resume'
	[string "cosock.lua"]:210: in field 'run'
	[string "st/driver.lua"]:731: in method 'run'
	[string "init.lua"]:84: in main chunk

this is something new

9

Hi, @veonua.
Can you share the code snippet that causes this error, please?

11

I’m not on the beta, but great to see official websockets support coming.

I have websocket library baked into one of my drivers, so i will have to update when official support comes along

1 Like
12

I guess it will be an upgrade from the Hub Beta version of firmware 42.5

When a driver is installed, it prints in the logcat the fingerprints of all the devices paired with it.

  • Device ID
  • Manufacturer
  • Model
  • Clusters supported, but with your name not the ID number (for zigbee devices)
  • Command Class supported (for Z-Wave devices)

Nice improvement!

For Zigbee driver:

2022-03-30T16:12:49.034921737+00:00 TRACE Zigbee Motion Sensor Mc  Zigbee Device: 9b6380e3-7155-4d74-85f6-0878a92e0a85
Manufacturer: Samjin Model: motion
        [1]: Basic, PowerConfiguration, Identify, PollControl, TemperatureMeasurement, IASZone, Diagnostics
2022-03-30T16:12:49.059016404+00:00 TRACE Zigbee Motion Sensor Mc  Zigbee Device: 9ea4a325-0393-4760-9059-d2cd06f47250
Manufacturer: Samjin Model: motion
        [1]: Basic, PowerConfiguration, Identify, PollControl, TemperatureMeasurement, IASZone, Diagnostics
2022-03-30T16:12:49.083475070+00:00 TRACE Zigbee Motion Sensor Mc  Zigbee Device: 075f38a5-5928-444b-ac8a-4563446777f4
Manufacturer: Samjin Model: motion
        [1]: Basic, PowerConfiguration, Identify, PollControl, TemperatureMeasurement, IASZone, Diagnostics
2022-03-30T16:12:49.106162070+00:00 TRACE Zigbee Motion Sensor Mc  Zigbee Device: dba21d2f-0a43-4260-97f1-4abffcc0d4cc
Manufacturer: _TZ1800_fcdjzz3s Model: TY0202
        [1]: Basic, PowerConfiguration, Identify, IASZone, Diagnostics

For Z-Wave Driver:

2022-03-30T16:29:26.176370338+00:00 TRACE Z-Wave Switch Mc  Z-Wave Device: bd5c15c7-76f5-4430-b95d-c8ea349e9f61
Manufacturer: 0x010F Product Type: 0x0203 Product ID: 0x1000
        [0]: SWITCH_MULTILEVEL, SWITCH_BINARY, DEVICE_RESET_LOCALLY, ASSOCIATION, CONFIGURATION, MULTI_CHANNEL_ASSOCIATION, MULTI_CHANNEL, PROTECTION, CENTRAL_SCENE, ZWAVEPLUS_INFO, VERSION, MANUFACTURER_SPECIFIC, ASSOCIATION_GRP_INFO, POWERLEVEL, APPLICATION_STATUS, CRC_16_ENCAP, METER, NOTIFICATION, SECURITY, FIRMWARE_UPDATE_MD        [1]: SWITCH_MULTILEVEL, SWITCH_BINARY, DEVICE_RESET_LOCALLY, ASSOCIATION, CONFIGURATION, MULTI_CHANNEL_ASSOCIATION, MULTI_CHANNEL, PROTECTION, CENTRAL_SCENE, ZWAVEPLUS_INFO, VERSION, MANUFACTURER_SPECIFIC, ASSOCIATION_GRP_INFO, POWERLEVEL, APPLICATION_STATUS, CRC_16_ENCAP, METER, NOTIFICATION, SECURITY, FIRMWARE_UPDATE_MD
2022-03-30T16:29:26.199377005+00:00 TRACE Z-Wave Switch Mc  Z-Wave Device: e062ff99-4cfc-47c2-be7f-91881fdc3a8c
Manufacturer: 0x010F Product Type: 0x0402 Product ID: 0x1002
        [0]: MULTI_CHANNEL, SWITCH_BINARY, MANUFACTURER_SPECIFIC, VERSION, CONFIGURATION, ASSOCIATION, MULTI_CHANNEL_ASSOCIATION, MULTI_CHANNEL, SWITCH_BINARY, SWITCH_ALL, FIRMWARE_UPDATE_MD, POWERLEVEL [1]: MULTI_CHANNEL, SWITCH_BINARY, MANUFACTURER_SPECIFIC, VERSION, CONFIGURATION, ASSOCIATION, MULTI_CHANNEL_ASSOCIATION, MULTI_CHANNEL, SWITCH_BINARY, SWITCH_ALL, FIRMWARE_UPDATE_MD, POWERLEVEL
4 Likes
13

Adding a new custom capability to an existing driver is no longer locking it up and requiring a hub reboot. That’s fantastic. Thank you.

14

Hello!

Late last week, we published a new version of the firmware 42.7 is now released for customer Beta.

1 Like
15

@nayelyz @alissa.dornbos

I’m on 42.7.

It appears CapabilityCommandDispatcher handler is being triggered twice.
For example, when I tap on “ON” button, the driver will receive the same event twice.

local driver = Driver(
    'Lan Driver',
    {
        discovery = discovery.handle_discovery,
        lifecycle_handlers = lifecycles,
        lan_info_changed_handler = lan_info_changed_handler,
        capability_handlers = {
            [capabilities.switch.ID] = {
                [capabilities.switch.commands.on.NAME] = commands.handle_switch,
                [capabilities.switch.commands.off.NAME] = commands.handle_switch
            },
16

Thank you for bringing this up, @hongtat. I will report this so we know the impact, what I found curious is that even though it is being printed twice, only one entry appears in the device history.

17

Wouldn’t the single entry in the device history just be the expected behaviour given that the two events emitted would have the same state? Or have you set state_change to true to test it?

I find the device history doesn’t show the events emitted, it shows those that have been propagated further.

18

In the event history of the app, events in which there is any change are shown, if the new event that arrives is the same as the last one, it is not shown.

In fact, in the zigbee default libraries, duplicate events are emitted by driver in some cases, which are not seen in the app, but are seen in the logcat. I don’t know if this has to be bad or not.

  • The color defaults, set_color send the hue and saturation command to the device:
function color_control_defaults.set_color(driver, device, command)
  switch_defaults.on(driver, device, command)
  local hue = math.floor((command.args.color.hue * 0xFE) / 100.0 + 0.5)
  local sat = math.floor((command.args.color.saturation * 0xFE) / 100.0 + 0.5)
  device:send_to_component(command.component, zcl_clusters.ColorControl.server.commands.MoveToHueAndSaturation(device, hue, sat, 0x0000))
  • 2 seconds later it reads the hue and saturation attributes:
  local color_read = function(d)
    device:send_to_component(command.component, zcl_clusters.ColorControl.attributes.CurrentHue:read(device))
    device:send_to_component(command.component, zcl_clusters.ColorControl.attributes.CurrentSaturation:read(device))
  end

  device.thread:call_with_delay(2, color_read, "setColor delayed read")
end

results:

  • 3.0 devices normally respond by themselves to the color set command and an event will be emitted.
  • 2 seconds later the attributes are read and with the response the same event will be emitted again.

For others libraries, level, color temperature, If it is a ZLL device, in its specific subdrivers code, a refresh function is done 2 seconds delay for the on/off, level, color temperature, hue and saturation attributes are read again. The same event is emitted again.

local function do_refresh(driver, device)
  device:refresh()

  for capability, attributes in pairs(REFRESH_ATTRIBUTES) do
    if device:supports_capability(capability) then
      for _,attr in ipairs(attributes) do
        device:send(attr:read(device))
      end
    end
  end
end

local function handle_switch_on(driver, device, cmd)
  device:send(OnOff.commands.On(device))

  device.thread:call_with_delay(2, function(d)
    do_refresh(driver, device)
  end)
end

local function handle_switch_off(driver, device, cmd)
  device:send(OnOff.commands.Off(device))

  device.thread:call_with_delay(2, function(d)
    do_refresh(driver, device)
  end)
end

local function handle_set_level(driver, device, cmd)
  local level = math.floor(cmd.args.level / 100.0 * 254)
  device:send(Level.commands.MoveToLevelWithOnOff(device, level, cmd.args.rate or 0xFFFF))

  device.thread:call_with_delay(2, function(d)
    do_refresh(driver, device)
  end)
end

local function handle_set_color_temperature(driver, device, cmd)
  local temp_in_mired = math.floor(1000000 / cmd.args.temperature)
  device:send(OnOff.commands.On(device))
  device:send(ColorControl.commands.MoveToColorTemperature(device, temp_in_mired, 0x0000))

  local function query_device()
    do_refresh(driver, device)
  end
  device.thread:call_with_delay(2, query_device)
end

when a refresh is performed in app a read attribute is performed for all capabilities of device, visible events are emitted in the logcat, but they are not seen in the app if there has been no change.

19

I’m not familiar with Zigbee library. This duplicate events were not seen in the Lan device. This is affecting most/all custom handlers, and will trigger 2 HTTP calls to wifi devices. ON/OFF, setcolor are probably fine. A single push/toggle / IR remote button are not, since it will become ON, follow by OFF.

Using the main device to create child devices will also end up with 2 child devices.

20

I don’t know LAN drivers, that’s why I remarked that I was referring to zigbee and similar things happen too.
In zigbee, I don’t see that it affects the operation or automations, I just see an increase in traffic between device, hub and platform

21

Did you find out what was causing this?

Trying to fix the same problem in one of my drivers (that i actually think you reported to me ages back, but i couldn’t repeat so guessing firmware update triggered)

Louis