I have been playing around with the mode capability. The link below doesn’t seem to go to the mode anchor when clicked, but you can see it in the index. It is marked as proposed. Does that mean ST doesn’t support it yet?
I am not using a custom presentation for this device to eliminate an issue on my end. I was expecting to see a selector for the mode in the detail view, and triggers for the mode in the automations view. Instead, I see nothing in the detail view, and the automation views present an empty list of modes.
Here is the code that determines the modes to support, and is called in the refresh for the device. I have also tried emitting this from the added and init lifecycle events without any success.
if allowBreezeMode then
Shouldn’t emitting this event populate those menus? Shouldn’t the default presentation show the current mode for the device?
@nayelyz I am seeing the same behavior with the scenes capability. Again, I can see it being emitted, but it doesn’t show up in the detail view nor the automation views. This is just using the stock presentation for this profile. No custom capabilities nor custom presentations:
scenes doesn’t have a capability presentation. There are a number of other faulty ones out there, in both “proposed” and “live” status. pHMeasurement, bypassable and tV come to mind immediately. There’s also a testCapability in “live” status that has no attributes, no commands and no presentation.
Yeah, the team confirmed that they don’t have a UI configured yet.
In the case of “modes”, it has a capability presentation but it doesn’t appear in the ST app because it hasn’t been configured yet, that’s why they are in “proposed” which equals to “bugs are expected”.
I believe that, even if they don’t appear, you can still use them to set some values in the API which you can use in your backend.
The scenes you mentioned are the ones that are available in the physical device, not the ones that exist in SmartThings, right?
Sorry, that’s not possible. The stock capabilities design cannot be edited or created, what we can do is to customize the available range and enums (based on the existing ones) using the custom device-config but in this case, that wouldn’t take any effect…
You need to create custom capabilities according to your needs, you can define their presentation using the different display types (list, slider, toggleSwitch) but you cannot edit their UI (color, size, etc.) like with the stock capabilities.
So I essentially need to create my own mode and scenes capability until those stock ones are live instead of proposed? Seems like they would both be list types. I assume once I get in there, I will be able to dynamically change the content of those lists. I don’t know the modes or scenes in advance.
Thanks for bringing that up, I forgot to mention that they cannot be populated dynamically. What I have seen is that you can define a list of possible values and then control them with the “supportedValues” property
That is pretty much a show stopper for me then. That is why I was excited about the scenes and modes capabilities. I was integrating with the Philips Hue hub and pulling over its scenes. I have a driver that grabs the light scenes defined over there and allows you to use them on lighting groups. My driver does the following:
Import all Hue light groups (rooms/zones) as devices in ST. This allows groups on/off and automations
Import Hue scenes for each group and allow the user to apply those scenes to the groups
The issue is that I don’t have a UI to allow the user to select these scenes to apply. A list in automations and the detail view would do the trick. I assumed this was possible. I saw @TAustin create a list of apps in his Roku driver. I assumed he pulled those from the Roku, but maybe he predefined all of those app names.
This looks perfect. The fact that it allows different ID and Name fields is fantastic as well. @nayelyz This would be a preferable design for modes and scenes if the ST engineering team is looking to change either of those. Separating the ID from Name is a lot better. I was having to maintain a local lookup table and rely on the user not re-using names.
Just added it with mediaPresets. Worked like a charm. I suppose I could convince myself this is “media”. The automation view allows for a text entry instead of the list which isn’t ideal, but it will work. Need to see if that expects a presetId or a presetName. Users won’t know the IDs and the names aren’t forced to be unique.
I have a RESTful version at the moment. I have to pull-to-refresh the lighting group so it pulls over the state. I haven’t hooked in the active state monitoring. That is the last piece before I planned to push it to a larger group. I was going to offer this version to a very early alpha group. Let me know if you want in on that. Maybe a couple of days away.
I did something similar in a different custom capability. I serialized a small json object and made it into a string attribute. Then I found the execute capability, so now I plan to take that out and replace it.