Hi @Pyrylamo
Could you please confirm if you would like to join the beta group?
Also, have you already enrolled in the beta program? If so, could you let us know approximately when you enrolled?
Hi, never mind… I don’t want the beta…
Initially i wanted just for try statelessSwitchLevelStep on my zigbee devices. Later i realized that just need to install beta driver. DONE…
Thank you anyway…
Is the knob functionality exclusive to the Bilresa device? I have an Aqara rotary dimmer and the Smartthings Beta driver with this capability, but I can’t find any new features in the app.
It’s not but since it’s a new capability right now the only stock drivers supporting it are for the IKEA scroll wheel (Matter) and the Aqara Wireless Knob Switch H1 (Zigbee). They were going to support the Hue Tap Dial (via Hue bridge) but apparently they left it for later.
As for custom drivers, I believe so far none support it (except for BILRESA, that is).
I have Aqara Wireless Knob Switch H1, I have the official driver installed, but I don’t see any new controls. I’m using iOS app and my wife has a Samsung device.
weird
Is it this fingerprint? What profile is it using then?
You are a developer, @veonua! You should know how to check the profile and the capabilities of the device! 
Indeed, you should check the profile in the website, check if the knob capability is there, check the supportedAttributes is not empty and whether the rotateAmount has a non-zero value and changes when performing different rotations.
I think the capabilities are good, but the app has a limit. I suspect it’s similar to the Energy App, where only devices that have been pre-approved are displayed.
That’s different, this is nothing more than the user interface for a production capability, not a whole service. If you checked the attributes and they’re correct it should display.
So your H1 detail view displays the button events but not the Control devices by rotating. That’s something to report through the SmartThings app or here so they look it up.
Meanwhile you can create the JSON rule, in the end it’s the same and at least you check that the knob capability is working as expected.
So I tried the beta zigbee switch driver for the “step brightness” feature.
On a generic Zigbee wall dimmer, controlled from an IKEA BILRESA rotary dial, it works. There is a latency, and the sloppy haptics of the BILRESA, but it works well enough.
edit: So can we have that on C2C lamps as well?
Yeah, the scroll wheel takes around 500 ms to report the scroll and, on top of that, the Zigbee driver adds 300 milliseconds of transition to smoothen the step so in total it’s almost a second not counting other latency sources.
The new step brightness also adds an “Adjust brightness” routine action, you can use that one with any button and feels better if the button driver has an Auto-repeat Held option or repeats the events by itself.
I hope eventually SmartThings adds the new relative brightness feature to every light in SmartThings, including groups and cloud integrations.
I’m a little disappointed about this… I realize now that new feature need to be introduced in all custom drivers… I tested innr bubble with oficial zigbee switch beta driver and worked very well for brightness and temperature…
But all my wall switches at home use custom driver and have cluster EF00… Cannot see a good end to my needs… Wesley member stop working on the driver last year and now i cannot see a way to add this cool feature on my ecosystem…
The driver code is public on GitHub but I’m a noob and can’t update it by myself…
I don’t see smartthings team working on drivers for devices with EF00 cluster…
i would check but my history is always blank when tapping filter and selecting individual devices on iOS. 
At least in the past seven days my V4 has been stable on 61.3.
While I fully understand that this is a beta test and that we, as participants, accept a certain degree of risk and responsibility for joining, there’s still a serious issue several of us are experiencing with the current beta version. It keeps flipping back and forth between two versions, which is causing repeated and disruptive downtime for our hubs.
It’s disappointing that no one at SmartThings appears to be monitoring or supporting the platform over the weekend. For a beta release of something as central and critical as the device hub, this level of oversight really feels essential. These kinds of problems shouldn’t be left unaddressed for days at a time.
To help prevent similar issues in the future, I’d like to suggest a few improvements:
- Implement a 24/7 on-call rotation specifically for beta firmware releases so that critical problems can be caught and resolved quickly, even outside normal business hours.
- Add stronger automated monitoring and alerting for version stability and rollback triggers.
- Consider more conservative staged rollouts or a dedicated beta support channel/team for high-impact components like the device hub.
I appreciate the work the SmartThings team does and hope these suggestions can help strengthen the beta testing process.
Since it looks like I’m unwillingly part of an A/B test between 0.61.2 and 0.61.3, I wanted to share some concrete observations on reboot/recovery behavior.
61.3 handles hub reboots noticeably better than 61.2.
- On 61.3, devices come back online reliably and quickly after the hub restarts. No extra intervention needed in my experience.
- On 61.2, devices stay offline for significantly longer. In multiple cases - including a very stable device like the Eve Energy - some of them required a manual power cycle before they would reconnect. This has not happened on 61.3.
It’s a clear and welcome improvement in stability during the update process that I have to endure up to four times a day.
On a separate note: what happened to the detailed changelogs between beta versions?
Back in the 5x.x series, SmartThings used to clearly document what changed from one beta build to the next. With the current 6x.x betas it’s become much harder to understand exactly what’s new, fixed, or improved between point releases. Any chance we could get that level of transparency back?
Edit: a new record today:
That’s really odd as historically going back a version has always required manual intervention.
I see the V4 hubs profile includes the firmware update capability. Does that get populated with anything? I’m just curious why it is there.
Click here:
smartthings devices:component-status bccf8b047-813xxxxxx069 -j
{
"wifiInformation": {
"supportedWiFiAuthTypes": {
"value": [
"OPEN",
"WEP",
"WPA-PSK",
"WPA2-PSK",
"SAE"
],
"timestamp": "2026-05-25T15:33:13.177Z"
},
"ssid": {
"value": "LOL",
"timestamp": "2026-05-25T15:33:13.176Z"
},
"supportedWiFiFrequencies": {
"value": [
"2.4G",
"5G"
],
"timestamp": "2026-05-25T15:33:13.181Z"
}
},
"sec.networkConfiguration": {
"activatedNetwork": {
"value": "ethernet",
"timestamp": "2026-05-25T13:38:30.749Z"
},
"supportedNetwork": {
"value": [
"ethernet",
"wifi"
],
"timestamp": "2026-05-25T13:38:30.748Z"
}
},
"samsungim.devicestatus": {
"status": {
"value": {
"modelNumber": "IM6001-V4P22",
"serialNumber": "LOL",
"wifiMac": "68:3A:48:...",
"btAddr": "68:3A:48:...",
"mnId": "0AFD",
"setupId": "427",
"productionDate": "",
"swVer": "000.061.00003",
"hwVer": "Test",
"mnmo": "hubv4-EU"
},
"timestamp": "2026-05-25T14:41:03.317Z"
}
},
"sec.diagnosticsInformation": {
"logType": {
"value": [
"errCode",
"dump"
],
"timestamp": "2026-05-25T13:38:30.731Z"
},
"endpoint": {
"value": "PIPER",
"timestamp": "2026-05-25T13:38:30.729Z"
},
"minVersion": {
"value": "5.0",
"timestamp": "2026-05-25T13:38:30.720Z"
},
"signinPermission": {
"value": null
},
"setupId": {
"value": "427",
"timestamp": "2026-05-25T13:38:30.730Z"
},
"protocolType": {
"value": "ble_stdk_hub",
"timestamp": "2026-05-25T13:38:30.732Z"
},
"tsId": {
"value": "MX01",
"timestamp": "2026-05-25T13:38:30.727Z"
},
"mnId": {
"value": "0AFD",
"timestamp": "2026-05-25T14:41:03.320Z"
},
"dumpType": {
"value": "file",
"timestamp": "2026-05-25T13:38:30.730Z"
}
},
"bridge": {},
"firmwareUpdate": {
"lastUpdateStatusReason": {
"value": null
},
"imageTransferProgress": {
"value": 0,
"unit": "%",
"timestamp": "2025-10-08T13:38:44.790Z"
},
"availableVersion": {
"value": "hubv4@3.38.10-0-g056c4029",
"timestamp": "2025-10-08T13:36:34.237Z"
},
"lastUpdateStatus": {
"value": "updateSucceeded",
"timestamp": "2025-10-08T13:38:44.789Z"
},
"supportedCommands": {
"value": null
},
"state": {
"value": "normalOperation",
"timestamp": "2026-05-25T14:41:03.315Z"
},
"estimatedTimeRemaining": {
"value": 0,
"timestamp": "2025-10-08T13:38:44.788Z"
},
"updateAvailable": {
"value": false,
"timestamp": "2025-10-08T13:38:44.785Z"
},
"currentVersion": {
"value": "hubv4@3.41.3-0-g2d9441e4",
"timestamp": "2026-05-25T14:41:03.319Z"
},
"lastUpdateTime": {
"value": "2026-05-25T14:39:46.213Z",
"timestamp": "2026-05-25T14:41:03.318Z"
},
"supportsProgressReports": {
"value": false,
"timestamp": "2025-10-08T13:38:44.791Z"
}
},
"sec.wifiConfiguration": {
"autoReconnection": {
"value": true,
"timestamp": "2026-05-25T13:38:30.733Z"
},
"minVersion": {
"value": "1.0",
"timestamp": "2026-05-25T13:38:30.725Z"
},
"supportedWiFiFreq": {
"value": [
"2.4G",
"5G"
],
"timestamp": "2026-05-25T13:38:30.727Z"
},
"supportedAuthType": {
"value": [
"OPEN",
"WEP",
"WPA-PSK",
"WPA2-PSK",
"SAE"
],
"timestamp": "2026-05-25T13:38:30.744Z"
},
"protocolType": {
"value": [
"ble_stdk_hub"
],
"timestamp": "2026-05-25T13:38:30.743Z"
}
}
}
BTW:
“hwVer”: “Test”
Sweet…