[Demande d’évolution] Intégrations externes : listes déroulantes alimentées par l’intégration dans les scènes et les widgets

Développement
1

Bonjour à tous,

Avec Gladys 5.1, une intégration externe peut déclarer ses propres actions de scène et ses widgets, c’est top. Il manque une chose pour que ce soit vraiment confortable : des listes déroulantes dont l’intégration fournit le contenu.

Le constat

Aujourd’hui, un champ select de manifeste ne peut prendre que deux formes :

  • des options écrites en dur dans le manifeste, identiques pour tout le monde ;
  • "source": "devices", la liste des appareils de l’intégration.

Le reste de ce que connaît l’intégration doit donc être tapé au clavier, et bien orthographié. Quelques exemples :

La description d’un champ est figée elle aussi. On ne peut même pas y afficher les choix possibles.

La proposition

Ajouter une seconde valeur à l’énumération source, par exemple "integration", avec une clé de liste :

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

Côté SDK, l’intégration pousse la liste quand elle change (modèle push, comme publishState) :

await gladys.setFieldOptions('zones', [
  { value: 'cuisine', label: 'Cuisine', parent: 'ext:lubluelu:vacuum:eb111' },
  { value: 'salon', label: 'Salon', parent: 'ext:lubluelu:vacuum:eb111' },
]);
  • Stockage par le cœur : la liste est conservée par le cœur. L’éditeur de scène s’affiche donc sans appeler l’intégration, même si elle est arrêtée.
  • depends_on (optionnel) : filtre les options selon un autre champ du formulaire, ici les zones de l’aspirateur choisi (parent = external_id de l’appareil).
  • Valeur stockée : la value, une chaîne. Le handler la reçoit comme aujourd’hui, et les variables de scène restent possibles.
  • Option disparue : une valeur qui n’existe plus reste affichée telle quelle, avec un avertissement. On ne veut pas casser une scène parce qu’une zone a été renommée.
  • Bornes : comme pour le reste du contrat, par exemple 200 options par liste, des libellés de 100 caractères maximum et des appels limités en débit.

Ce que ça apporte

  • Plus de faute de frappe ni de nom à retrouver : c’est la même expérience que source: "devices", sans créer de faux appareils pour ça.
  • Le même mécanisme sert aux réglages des widgets et aux actions de configuration, puisqu’ils partagent le format de champ.
  • C’est rétrocompatible : options et source: "devices" ne changent pas, et un manifeste qui n’utilise pas "integration" n’est pas concerné.

Contournements actuels, et pourquoi ils ne suffisent pas

  • Créer un appareil par zone, pour profiter de source: "devices" : ces zones apparaissent alors partout, y compris dans le sélecteur « Aspirateur » des widgets.
  • Un bouton par zone sur l’appareil, utilisé avec l’action native « Contrôler les appareils » : ça marche pour une action simple, mais on ne peut pas y ajouter de paramètres (nombre de passages, aspiration…).
  • Le texte libre, rendu tolérant (majuscules, accents, début de nom) : c’est ce que fait mon intégration aujourd’hui, mais ça reste du texte libre
2 « J'aime »