Missing presentation for Mode capability

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 profile:

name: fan
components:
- id: main
  capabilities:
  - id: fanSpeed
    version: 1
  - id: switch
    version: 1
  - id: mode
    version: 1
  - id: refresh
    version: 1
  categories:
  - name: Fan

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
    device:emit_event(capabilities.mode.supportedModes({Fan.Modes.Continuous, Fan.Modes.Breeze}))
else
    device:emit_event(capabilities.mode.supportedModes({Fan.Modes.Continuous}))
end

Shouldn’t emitting this event populate those menus? Shouldn’t the default presentation show the current mode for the device?

When a capability status is “proposed” it means it is mutable, it is supported in the API but there might be bugs so you should use it at your own risk.

So, you send the event (it appears in the logs) but when you query the value of supportedModes in the device status, is it empty ?
What is the content of Fan.Modes.Continuous in your code?

I will ask the team for more details about this capability’s functionality.

Yes, the event is emitted and visible in the logs

emitting event: {"component_id":"main","state":{"value":["Continuous"]},"attribute_id":"supportedModes","capability_id":"mode"}

emitting event: {"component_id":"main","state":{"value":"Continuous"},"attribute_id":"mode","capability_id":"mode"}

The value are defined here:

Modes = {
    Continuous = 'Continuous',
    Breeze = 'Breeze'
}

This is the output from device.state_cache for that device:

{
    "mode": {
        "mode": {
            "value": "Continuous"
        },
        "supportedModes": {
            "value": [
                "Continuous"
            ]
        }
    },
    "fanSpeed": {
        "fanSpeed": {
            "value": 0
        }
    },
    "switch": {
        "switch": {
            "value": "off"
        }
    }
}

@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:

name: room
components:
- id: main
  capabilities:
  - id: switch
    version: 1
  - id: scenes
    version: 1
  - id: refresh
    version: 1
  categories:
  - name: Light

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.

How were you able to determine this? I don’t see the point of a capability with no presentation at all. I was excited to see scenes since I am working on a scene controller driver.

There is an API to query -

Or you can refer to this, it uses the API to get all capabilities and presentations.

You can use the CLI to see any capability or capability presentation. Same with device configs and presentations. Doesn’t matter who created them.

You can also query the API directly.

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?

Yes. The scenes are externally available. Sounds like I’ll need to make a presentation for those. How can I setup the presentation for modes or scenes when I don’t own those capabilities?

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:

  1. Import all Hue light groups (rooms/zones) as devices in ST. This allows groups on/off and automations
  2. 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.

1 Like

Try using the mediaPresets capability. It has a unique design that lets you populate the list of options at run-time.

1 Like

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.

1 Like

I’d like to see that design open up as something we could use in custom capabilities.

This was on my list to look at after I finish with my TV. Looking forward to seeing what you’ve put together.

1 Like

Just added it with mediaPresets. Worked like a charm. I suppose I could convince myself this is “media”. :slight_smile: 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.

1 Like

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.