[Anforderung für Weiterentwicklung] Externe Integrationen: Dropdown-Listen, die durch die Integration in Szenen und Widgets gespeist werden

Entwicklung
1

Hallo zusammen,

Mit Gladys 5.1 kann eine externe Integration ihre eigenen Szenenaktionen und Widgets deklarieren, das ist super. Es fehlt nur noch eine Sache, damit es wirklich komfortabel ist: Dropdown-Listen, deren Inhalt von der Integration bereitgestellt wird.

Die Feststellung

Heute kann ein select-Feld im Manifest nur zwei Formen haben:

  • options, die hart im Manifest geschrieben sind, identisch für alle;
  • "source": "devices", die Liste der Geräte der Integration.

Der Rest dessen, was die Integration kennt, muss also manuell eingegeben und korrekt geschrieben werden. Einige Beispiele:

Die Beschreibung eines Feldes ist ebenfalls fest. Man kann nicht einmal die möglichen Auswahlmöglichkeiten anzeigen lassen.

Der Vorschlag

Eine zweite Wert zur Aufzählung source hinzufügen, zum Beispiel "integration", mit einem Listenschlüssel:

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

Auf der SDK-Seite schiebt die Integration die Liste, wenn sie sich ändert (Push-Modell, wie publishState):

await gladys.setFieldOptions('zones', [
  { value: 'cuisine', label: 'Cuisine', parent: 'ext:lubluelu:vacuum:eb111' },
  { value: 'salon', label: 'Salon', parent: 'ext:lubluelu:vacuum:eb111' },
]);
  • Speicherung durch den Kern: Die Liste wird vom Kern gespeichert. Der Szeneneditor wird also ohne Aufruf der Integration angezeigt, selbst wenn sie gestoppt ist.
  • depends_on (optional): Filtert die Optionen nach einem anderen Feld des Formulars, hier die Zonen des ausgewählten Staubsaugers (parent = externe_id des Geräts).
  • Gespeicherter Wert: die value, ein String. Der Handler erhält ihn wie heute, und die Szenenvariablen bleiben möglich.
  • Verschwundene Option: Ein Wert, der nicht mehr existiert, bleibt so angezeigt, mit einer Warnung. Man will kein Szenario brechen, weil eine Zone umbenannt wurde.
  • Grenzen: wie für den Rest des Vertrags, zum Beispiel 200 Optionen pro Liste, Beschriftungen von maximal 100 Zeichen und auf Durchsatz begrenzte Aufrufe.

Was das bringt

  • Keine Tippfehler oder Namen mehr, die man sich merken muss: Es ist das gleiche Erlebnis wie source: "devices", ohne dafür falsche Geräte zu erstellen.
  • Der gleiche Mechanismus dient den Widget-Einstellungen und den Konfigurationsaktionen, da sie das Feldformat teilen.
  • Es ist abwärtskompatibel: options und source: "devices" ändern sich nicht, und ein Manifest, das "integration" nicht verwendet, ist nicht betroffen.

Aktuelle Umgehungen und warum sie nicht ausreichen

  • Ein Gerät pro Zone erstellen, um source: "devices" zu nutzen: Diese Zonen erscheinen dann überall, einschließlich im « Staubsauger »-Selector der Widgets.
  • Ein Button pro Zone auf dem Gerät, verwendet mit der nativen Aktion « Geräte steuern »: Das funktioniert für eine einfache Aktion, aber man kann keine Parameter hinzufügen (Anzahl der Durchgänge, Saugkraft…).
  • Freier Text, tolerant gemacht (Groß-/Kleinschreibung, Akzente, Anfangsbuchstabe): Das ist das, was meine Integration heute macht, aber es bleibt freier Text.
2 „Gefällt mir“