[Feature request] External integrations: dropdown lists fed by the integration in scenes and widgets

Development
1

Hello everyone,

With Gladys 5.1, an external integration can declare its own scene actions and widgets, which is great. One thing is missing to make it really comfortable: dropdown lists where the integration provides the content.

The situation

Today, a select field in a manifest can only take two forms:

  • options written directly in the manifest, identical for everyone;
  • "source": "devices", the list of devices from the integration.

The rest of what the integration knows must therefore be typed manually and spelled correctly. A few examples:

The description of a field is also fixed. You can’t even display the possible choices there.

The proposal

Add a second value to the source enumeration, for example "integration", with a list key:

{
  "key": "zone",
  "type": "select",
  "source": "integration",
  "list": "zones",
  "depends_on": "vacuum",
  "label": { "en": "Zone", "fr": "Zone" },
  "required": true
}

On the SDK side, the integration pushes the list when it changes (push model, like publishState):

await gladys.setFieldOptions('zones', [
  { value: 'cuisine', label: 'Kitchen', parent: 'ext:lubluelu:vacuum:eb111' },
  { value: 'salon', label: 'Living room', parent: 'ext:lubluelu:vacuum:eb111' },
]);
  • Storage by the core: the list is kept by the core. The scene editor is therefore displayed without calling the integration, even if it is stopped.
  • depends_on (optional): filters the options according to another field in the form, here the zones of the chosen vacuum cleaner (parent = external_id of the device).
  • Stored value: the value, a string. The handler receives it as today, and scene variables remain possible.
  • Disappeared option: a value that no longer exists remains displayed as is, with a warning. We don’t want to break a scene because a zone has been renamed.
  • Limits: like the rest of the contract, for example 200 options per list, labels with a maximum of 100 characters and calls limited in throughput.

What it brings

  • No more typos or names to find: it’s the same experience as source: "devices", without creating fake devices for this.
  • The same mechanism serves for widget settings and configuration actions, since they share the field format.
  • It is backward compatible: options and source: "devices" do not change, and a manifest that does not use "integration" is not affected.

Current workarounds, and why they are not enough

  • Create a device per zone, to take advantage of source: "devices": these zones then appear everywhere, including in the « Vacuum » selector of widgets.
  • A button per zone on the device, used with the native action « Control devices »: it works for a simple action, but you cannot add parameters (number of passes, suction…).
  • Free text, made tolerant (uppercase, accents, beginning of name): this is what my integration does today, but it remains free text
2 Likes