[Solicitud de evolución] Integraciones externas: listas desplegables alimentadas por la integración en escenas y widgets

Desarrollo
1

Hola a todos,

Con Gladys 5.1, una integración externa puede declarar sus propias acciones de escena y sus widgets, es genial. Falta una cosa para que sea realmente cómodo: listas desplegables cuyo contenido proporciona la integración.

El diagnóstico

Hoy en día, un campo select de un manifiesto solo puede tener dos formas:

  • options escritas en el manifiesto, idénticas para todos;
  • "source": "devices", la lista de dispositivos de la integración.

El resto de lo que conoce la integración debe teclearse, y con la ortografía correcta. Algunos ejemplos:

La descripción de un campo también está fija. Ni siquiera se pueden mostrar las opciones posibles.

La propuesta

Añadir un segundo valor a la enumeración source, por ejemplo "integration", con una clave de lista:

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

En el SDK, la integración envía la lista cuando cambia (modelo push, como publishState):

await gladys.setFieldOptions('zones', [
  { value: 'cuisine', label: 'Cuisine', parent: 'ext:lubluelu:vacuum:eb111' },
  { value: 'salon', label: 'Salon', parent: 'ext:lubluelu:vacuum:eb111' },
]);
  • Almacenamiento por el núcleo: la lista se conserva por el núcleo. El editor de escenas se muestra sin llamar a la integración, incluso si está detenida.
  • depends_on (opcional): filtra las opciones según otro campo del formulario, aquí las zonas de la aspiradora elegida (parent = external_id del dispositivo).
  • Valor almacenado: la value, una cadena. El controlador la recibe como hoy, y las variables de escena siguen siendo posibles.
  • Opción desaparecida: un valor que ya no existe sigue mostrándose tal cual, con una advertencia. No queremos romper una escena porque una zona haya sido renombrada.
  • Límites: como el resto del contrato, por ejemplo 200 opciones por lista, etiquetas de un máximo de 100 caracteres y llamadas limitadas en tasa.

Lo que aporta

  • Sin faltas de ortografía ni nombres que recordar: es la misma experiencia que source: "devices", sin crear dispositivos falsos para ello.
  • El mismo mecanismo sirve para los ajustes de los widgets y las acciones de configuración, ya que comparten el formato de campo.
  • Es retrocompatible: options y source: "devices" no cambian, y un manifiesto que no utilice "integration" no se ve afectado.

Soluciones actuales, y por qué no son suficientes

  • Crear un dispositivo por zona, para aprovechar source: "devices": estas zonas aparecen entonces en todas partes, incluido en el selector « Aspiradora » de los widgets.
  • Un botón por zona en el dispositivo, utilizado con la acción nativa « Controlar dispositivos »: funciona para una acción simple, pero no se pueden añadir parámetros (número de pasadas, aspiración…).
  • Texto libre, hecho tolerante (mayúsculas, acentos, inicio del nombre): es lo que hace mi integración hoy, pero sigue siendo texto libre
2 Me gusta