V2/V3 Hub Beta Firmware 50.X

Developer Programs Hub Firmware Beta
1

Hub Firmware 0.50.6 Beta

Hey everyone!

We’re excited to announce the start of a new SmartThings Hub Firmware Beta. Version 0.50.6 will begin rolling out in batches starting on Sep 22, 2023 for V2/V3 Hubs** . 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.

Version

  • 0.50.6

Hub Target

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

Release Date

  • **Release Date: Sep 22, 2023

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:

  1. Go to SmartThings Web (my.smartthings.com)
  2. Log in to your Samsung Account
  3. Select the Menu (⋮) and choose Settings
  4. Toggle on Account Data Access
  5. Select the time period and choose Confirm

Release Notes

50.6

  • Various bug fixes and enhancements

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

If you are reporting issues, please help us triage faster by having impersonation access granted and private message me your account that you use to log-in to Smartthings. Please complete the following steps:

Can you please private message me your email address that you use to log-in to your account? I would like to create a ticket and investigate.

Please also turn on impersonation access by doing the following:

  1. Go to the SmartThings Web (my.smartthings.com)
  2. Log in to your Samsung Account
  3. Select Menu (⋮) and choose Settings
  4. Toggle on Account Data Access
  5. Select the time period and confirm - In this step, please select “Until turned off”, once the team finishes, we’ll let you know so you can disable it again.
  6. Message me your email address
8 Likes
2

Just noticed my hub has updated to this firmware level, Last friday i had about 3 smart sockets switching on and off continually every second, turned off all automations for these sockets, an hour later enabled automations and all has been ok since,dont know how to check when the hub updated now its all on edge drivers.

3

Hey @uncledaveghr Thank you for reporting this. I am sorry that was your experience.

Can you please private message me your email address that you use to log-in to your account? I would like to create a ticket and investigate.

Please also turn on impersonation access by doing the following:

  1. Go to the SmartThings Web (my.smartthings.com)
  2. Log in to your Samsung Account
  3. Select Menu (⋮) and choose Settings
  4. Toggle on Account Data Access
  5. Select the time period and confirm - In this step, please select “Until turned off”, once the team finishes, we’ll let you know so you can disable it again.
  6. Message me your email :slight_smile:

Thank you kindly!

1 Like
4

Hi
Done as requested
Thanks in advance
Dave Parkes

5

Hi @alissa.dornbos

Because the improvements in beta 50.06 were so brief and unexplanatory, I have a question about a behavior I’ve seen.

Has a routine been established in the firmware that reads the on-off attribute of devices that have not received messages without the driver controlling it?

Let me explain, I have observed in the Zigbee Switch Mc driver that approximately every 20 minutes, without a message < ReportAttribute of cluster 0006, attribute on-off, being received, a message < ReadAttributeResponse is received without the driver having read of the attribute.

2023-09-25T18:20:51.878422410+00:00 TRACE Zigbee Switch Mc Received event with handler zigbee
2023-09-25T18:20:51.879715410+00:00 INFO Zigbee Switch Mc <ZigbeeDevice: bac7ca02-f812-487c-9fa6-1cc3096380e3 [0x588B] (Lidl Plug)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x588B, src_endpoint: 0x0B, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: OnOff >, lqi: 0xD4, rssi: -46, body_length: 0x0008, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x08, ZCLCommandId: 0x01 >, < ReadAttributeResponse || < AttributeRecord || AttributeId: 0x0000, ZclStatus: SUCCESS, DataType: Boolean, OnOff: false > > > >
.
.
.
2023-09-25T18:41:52.965983258+00:00 TRACE Zigbee Switch Mc Received event with handler zigbee
2023-09-25T18:41:52.967393591+00:00 INFO Zigbee Switch Mc <ZigbeeDevice: bac7ca02-f812-487c-9fa6-1cc3096380e3 [0x588B] (Lidl Plug)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x588B, src_endpoint: 0x0B, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: OnOff >, lqi: 0xBC, rssi: -80, body_length: 0x0008, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x1B, ZCLCommandId: 0x01 >, < ReadAttributeResponse || < AttributeRecord || AttributeId: 0x0000, ZclStatus: SUCCESS, DataType: Boolean, OnOff: false > > > >

Normally a message < ReadAttributeResponse was received when the Health Check was executed and then the reading of the attribute and the response of the device were seen in the log.

2023-09-25T18:25:37.006945760+00:00 INFO Zigbee Switch Mc Doing health check read for [0901]:0006:0000
2023-09-25T18:25:37.018010427+00:00 INFO Zigbee Switch Mc <ZigbeeDevice: 92d80935-27ff-4d7f-ba4d-70ac7c0db9e7 [0x0901] (Caldera)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000,< AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x0901, dest_endpoint: 0x01, profile: 0x0104, cluster: OnOff >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x00, seqno:0x00, ZCLCommandId: 0x00 >, < ReadAttribute || AttributeId: 0x0000 > > >
2023-09-25T18:25:37.183733427+00:00 TRACE Zigbee Switch Mc Received event with handler zigbee
2023-09-25T18:25:37.184876427+00:00 INFO Zigbee Switch Mc <ZigbeeDevice: 92d80935-27ff-4d7f-ba4d-70ac7c0db9e7 [0x0901] (Caldera)> received Zigbee message: < ZigbeeMessageRx || type: 0x00,< AddressHeader || src_addr: 0x0901, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: OnOff >, lqi: 0xC8, rssi: -86, body_length: 0x0008, < ZCLMessageBody ||< ZCLHeader || frame_ctrl: 0x18, seqno: 0x0F, ZCLCommandId: 0x01 >, < ReadAttributeResponse || < AttributeRecord || AttributeId: 0x0000, ZclStatus: SUCCESS, DataType: Boolean, OnOff: false > > > >

I could swear I had not seen this behavior with previous firmware versions.

All this is because I have established a maximum reporting interval of 1800 sec (30 minutes) on these devices for the on-off attribute, to reduce traffic and hub work and it was working perfectly for more than 3 weeks and now it is that every 20 minutes the new firmware reads the attribute and it is no longer useful to increase the interval above 20 minutes.

I have not seen this behavior either in the Zigbee Contact Mc and Zigbee Motion Sensor Mc drivers, which I am also testing and monitoring because I have increased the maximum IASZone report to 30 minutes and they continue to work perfectly

6

Is anyone seeing battery drain on their zigbee devices? Odd how I am seeing most of my zigbee devices going down fast. It could be a coincidence and the devices are hitting the low battery status at the same time but rather odd. Replaced a few batteries and they are down to 67/51% in 3 days.

7

Hello - We will be rolling out 50.7 shortly. Stay tuned!

2 Likes
9

I can confirm that 50.7 fixed the issue where my Aqara temp sensor wasn’t showing any readings via my Aqara bridge to SmartThings.

1 Like
10

Hello - We will be rolling out 50.8 today.

2 Likes
11

I’ve already got 50.9, though the mobile app thinks it is 49.9 (update: I’ve restarted the app and it has caught up).

1 Like
12

shows as 50.9 on the iOS app. I do wish the app developers would select a darker color for the text… the current light grey along with small text is hard to read :slight_smile:

1 Like
13

I must have gotten 50.9, but I don’t know when since hub event logs no longer exist for stuff like this.

What was introduced/fixed in 50.9?

1 Like
14

More information coming soon!

2 Likes
15

must be top secret SDC related changes :shushing_face:

2 Likes
16

Ive just checked and im on 50.9 now, smartthings are still monitoring my hub, had some strange stuff going on last night, Smart sockets switched off in afternoon for no reason, a smart socket that would switch off as soon as it was switched on eventhrough i had switched all @utomations off to this smart socket, also had motion sensors that was saying no motion in history but not reporting the motion it had received 30 seconds before, wonder ifits linked to the latest firmware update.

17

Im the same here

18

Hi @nayelyz

I’m making some changes to a driver and something that I don’t remember happening before is driving me a little crazy.

In one driver I have several profiles.
In the fingerprints.yml file I change a device from one profile to a different one and package the driver.

With the CLI I publish it and install it in the Hub.

I see in the logcat that the new version is installed, but the new profile is not assigned.

At first I thought it was because the capabilities were identical and only the preferences were different, but then I tried to change to a profile with different capabilities and the same thing happens.

I have tried two different drivers.

You can also check in my.smartthings.com advanced users, that the new profile has not been assigned

The only way for the new profile to be assigned is to make a change from any other driver or by reinstalling the device.

Has anyone else noticed this?

19

I can’t say I have experienced it but I wouldn’t expect anything different. The device has already been initialised with the profile in the fingerprints.yml file so that has made its contribution. The device’s profile could have been changed by the driver since then.

20

As you say, you could expect exactly that because you have no experience in that.

Device Profile changes in fingerprints.yml have been made daily to the stock drivers, the driver is updated in the Beta channel and the device is assigned a new profile when the driver is started after the update.
You can see a multitude of PRs in the github smartthings repository, this is one of the latest: muli-sensor.yml added a garagedoor preference and assigned this profile to old smartthings multipurpose sensors model: PGC313EU and model: PGC313, with smartsense-multi.yml profile assigned in previous driver version:

This has been happening for more than two years and I think it is a mistake since it would make corrections in profile assignment impossible without having to change the device to another driver or reinstall the device.

21

The latter seems desirable to me. As I say, the profile in the fingerprints file is just a starting point. If you have changed the profile since the device was initialised, either using the driver itself or via manipulation of the device object (which I think is possible, though I haven’t tried for a while), why would you want a change to the initial profile to be able to affect your running device? It would be a mistake to allow it.

If there has been an error in the profile assignment then you could always get the driver itself to change it.