Is there a way to present a dynamic list as the detailView display type? My device will have custom options that the user will need to select, but those options won’t be known until runtime. I would much prefer to have a list of options as opposed to a text input and expect the user to know the specific value, especially when the device will already have that information and can set it via an attribute.
Hi, @joecoolish!
No, building a list dynamically isn’t currently possible.
What others have done is that they define a long list of possible options and they only show the supported ones using an extra attribute for this purpose and the supportedValues attribute in the presentation.
The value of the attribute can be set when the device is joined after you get the supported values.
You can take a reference from the capability thermostatMode and this sample: Display Types | SmartThings Developers
1 Like
Are there plans to make the capabilities and presentations more dynamic?
Hi, @gsabran
Can you provide details about what you’re trying to achieve to ask the engineering team, please?
I’m trying to develop a driver for my smart lock. I was thinking of representing each user code as a new capability (which could be independently changed, activated, deactivated, deleted, scheduled etc each of those actions having their own buttons / inputs).
Another much more general usecase I thought of that such capacity would start allowing is a much more programable and dynamic UI.
For instance you could hit a “configure” button, which would change the device’s state to be in configuration mode. There the presentation would become different, showing only the inputs to configure the device (ie some sort of form). Once you’ve completed or cancelled this configuration, the device would get out of configuration mode back to the initial presentation with an updated state.
A parallel is general frontend development. A website doesn’t show all the buttons a user could press on at once, but depending on its current state it’ll show a different UI.
ok, I think the use case you mention is not so much about custom capabilities but the device presentation itself.
Currently, you cannot make things disappear from the UI, but there’s an option to change the device profile used by a device (try_update_metadata), however, to see the change, you might have to reopen the app or go back to the dashboard and enter the detail view again.
This only works if the device profile you want to use is already part of the driver package.
There’s also the possibility of “disabling” capabilities with the visibleCondition property in the device-config but it needs a specific value, it cannot be changed on the run.
A way of having some values to be available is using the supportedValues property I mentioned above because you can change the attribute value and the view would only show the enums allowed.
Also, if you wanted to create a capability per access code created for your lock, you would need extra tools since you cannot make requests to the API within the driver, so, you won’t be able to create/change a custom capability from there, add it to the device profile and then change it for the device.
The lockCodes capability can help you to manage lock codes for the device add/delete and I’ve heard users use the Smart Lock Guest Access app (located in the “Life” tab) to manage their codes as well.
About changing the UI like color, fonts, design, etc. it isn’t possible and there’s no info on plans about it.
1 Like
Thanks for the response. I’ll give try_update_metadata a try and see how far I can go with it.
I did see the visibleCondition, but as far as I can tell this is more about disabling than visibility (the component remains visible, but in a disabled state)
I’m trying to build a UI to interact with the lockCodes capability directly, instead of needing to use an other app which didn’t feel quite right.