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.
Samsung SmartThings Hub 2015 (Hub v2)
Samsung SmartThings Hub 2018 (Hub v3)
**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:
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:
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.
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.
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
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.
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.
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.
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.
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.
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.