Support for a dynamic “Select” field in integrations

Context

Today, an integration can expose:

  • numeric values (binary, temperature, volume, …)
  • text values (category: text, type: text)

However, there is currently no way to expose a dynamic list of selectable values.

The supported_options mechanism addresses a different need: it is designed for enumerations known to the core of Gladys (air conditioning modes, ventilation speeds, etc.). The values are fixed and defined by Gladys’ taxonomy.

Problem

Some integrations need to expose lists that:

  • are dynamically discovered;
  • are specific to each device;
  • use string identifiers;
  • can evolve over time.

Example with an LG webOS TV

Installed applications vary from one TV to another and can evolve:

  • Netflix
  • Disney+
  • Prime Video
  • YouTube
  • Plex

Each application has its own identifier:

netflix
com.disney.disneyplus-prod
amazon
youtube.leanback.v4
cdp-30

The same applies to sources:

  • HDMI 1
  • HDMI 2
  • PlayStation 5
  • Nintendo Switch

with identifiers such as:

HDMI_1
HDMI_2
com.webos.app.hdmi3

Mapping these values to integers would be dangerous: after installing or removing an application, the order can change and a scene might launch a different application than expected.

Proposal

Allow integrations to publish a dynamic list of options based on strings.

For example:

{

« category »: « text »,

« type »: « select »,

« options »: [

{

  "value": "netflix",

  "label": "Netflix"

},

{

  "value": "youtube.leanback.v4",

  "label": "YouTube"

},

{

  "value": "amazon",

  "label": "Prime Video"

}

]

}

The interface would simply display:

▼ Netflix
▼ YouTube
▼ Prime Video

and the integration would directly receive Netflix instead of a numeric index.

Use Cases

This feature is not limited to TVs. It could be useful for many integrations:

  • TV applications
  • HDMI sources
  • Rooms of a robot vacuum
  • Playlists or favorites
  • Native scenes of a device (e.g., Roborock)
  • Charging modes of an electric vehicle
  • etc.

In my case, this would allow me to directly offer a selector to launch an application (Netflix, Plex, YouTube…) or change source (HDMI 1, HDMI 2, PlayStation 5…) instead of asking the user to enter a technical identifier like netflix or HDMI_1.
But I also see many other use cases. For example, for my Roborock integration, I could offer the list of rooms discovered on the vacuum (Kitchen, Living Room, Bedroom…) or even the routines/shortcuts configured in the Roborock app. The user would simply select a value from a list, without having to know or enter the corresponding internal identifier.
In my opinion, this need is generic and could be used by many integrations whenever a device exposes a dynamic list of elements (applications, sources, rooms, playlists, favorites, native scenes, routines, etc.).