[Direct Connected Device] Auto-generated Timer button and component primary capability background color in detail view

Hello,

I’m developing a direct-connected device (ESP32) using the SmartThings IoT SDK and have a couple of questions about the device detail view UI behavior.

1) Auto-generated Timer button when using Switch capability

When I add the switch capability to the main component, a “Timer” button appears automatically in the device detail view — even though I never configured it in my device configuration JSON.

  • Is this timer automatically generated by the platform for all switch capability devices?

  • Is there any way to hide or remove it?

  • If it cannot be removed, is there a way to control its position in the detail view?

2) First capability per component has a highlighted background color

In my device detail view, the first capability of each component is always rendered with a different (highlighted) background color compared to the others. This happens consistently across all my components (main, cycle, sensor).

  • Is this a fixed platform behavior where the first capability in each component is treated as the “primary” tile?

  • Is there any way to change the background color or disable the highlight for a specific capability?

My setup:

  • Direct-connected device (ESP32, SmartThings IoT SDK)

  • Multiple components: main, cycle, sensor

  • Device status: DEVELOPMENT

Thank you in advance!

I don’t see it if I have another capability in the main component alongside the switch, but otherwise it does get automatically imposed on us. I don’t have any multi-component devices with switches to see what they do.

I personally believe that it shouldn’t be on the Controls tab as it is basically a single use automation. I think the same about the extra controls for buttons, the history on some attributes, and the Connection Path. We have a Routines tab, a History tab and an options menu for all those. On Galaxy devices we get a Bixby button thrust upon us too.

I don’t know of any way to hide or remove it, and nor am I aware of any way to control its position.

The highlighting just appeared one day and again we seem to have no control over it. It is particularly annoying as they seem to think the switch attribute should come first and then they highlight it, so they are doubly wrong.

What I actually want is the mobile app to respect the SmartThings API. No changing of the display order, no replacing of my controls with custom controls, no extra controls, and no highlighting that I don’t have control over. I shouldn’t have to guess what my device pages are going to look like.

@orangebucket

It seems I’ve found a fellow pioneer who’s already been through this! Thank you for the kind response.

It’s a shame that things are as I feared — completely out of our hands.

Have you ever received an official response from the SmartThings team on this?

Yes, it is part of a custom UI for the Switch capability, and we cannot add a configuration to hide it.
As mentioned in the document below, the content in the detail view is ordered based on 3 groups. Within each group, they follow the order of the device configuration. However, since this is part of a custom UI, it isn’t an element we can define there:

I’ll check with the engineering team if we can confirm that’s the only condition to color the capability’s background, but there’s no property in the device config to set a different one either.

Hi, @JohnJo
Can you share your device profile ID, please?
I was revisiting this and checking the description of the “Main capability” group, it says the background will be defined based on the status of the capability so I was thinking on this being related to the “active”/“inactive” state, so I wanted to check which capabilities are on each component to check their presentation and compare something to complement my question to the engineering team.

Thank you, @nayelyz !

The Device Profile ID is: c90dcf30-be49-4231-8dae-adc79dc936ed

I see — so the background color changes based on the active/inactive state! The intention makes sense to me. However, I feel that having the background color change solely based on the active/inactive state somewhat disrupts the overall design consistency. It’s not a critical issue, but I wanted to share my thoughts.

Thank you as always for your quick and kind responses!

Hi, @JohnJo
Thank you for sharing the profile ID.
I see it’s a different version from your screen capture since I don’t see the “cycle” and “sensor” components.
I was curious about the “mode” capability since the value “1h30m” was marked as “active”.
Since this capability doesn’t have pre-existing modes defined as well as temperatureMeasurement, I’m guessing the default status is “active”.
So, I’ll confirm with the team and share your comments with them.

Hi, @JohnJo
Sorry for the delay.
The engineering team confirmed that the main capability will have the blue background by default. This means even when there are no “active”/“inactive” alternatives.
If there are “inactive” alternatives, the background will turn gray when that option is selected.