Verbesserte Integration externer Dienste

Funktionsanfrage
2

Hallo @Will_71,

Vielen Dank für dieses Feedback, es ist sehr konkret und es freut mich zu sehen, wie deine Pellet-Integration Form annimmt!

Ich möchte klarstellen, dass Claude mir geholfen hat, diese Nachricht zu schreiben, aber ich habe selbst über jeden Punkt nachgedacht :joy:

1. Ein Haus aus einer Liste auswählen

Ja, das ist eine gute Idee. Heute können dynamische Listen (source) nur Geräte der Integration vorschlagen. Wir werden "source": "houses" hinzufügen: Die Liste zeigt die Namen der Häuser an und speichert ihren selector, also die ID, die dir GET /house bereits zurückgibt. Du kannst also direkt die Entsprechung herstellen.

Es wird überall funktionieren, wo dieses Feldformat verwendet wird: Konfiguration, Aktionen, Widget-Einstellungen und Szenen. Ich bereite einen PR vor.

Einziger Nachteil: Du musst die minimale gladys_version deiner Manifest-Datei erhöhen, da ältere Versionen von Gladys eine Quelle ablehnen, die sie nicht kennen.

2. Dezimalwert in der Konfiguration

Es handelt sich tatsächlich um einen Fehler. Der Server akzeptiert bereits Dezimalzahlen, aber das numerische Feld des Formulars hat kein Attribut step: Der Browser akzeptiert daher nur ganze Zahlen und blockiert die Speicherung. Selbst das Beispiel der Dokumentation (eine Breite von 48.85) funktionierte nicht :sweat_smile:

Ich habe ein Ticket eröffnet: Issue · GitHub

Die Korrektur besteht aus einer einzigen Zeile und wird auf alle Formulare der Integrationen angewendet (Konfiguration, Aktionen, Widgets, Szenen).

3. Einen Wert über das Widget eingeben

Der Bedarf ist real, dein aktueller Weg (in die Integration gehen, den Preis ändern, zum Dashboard zurückkehren) ist nicht praktisch.

Ich möchte jedoch keine Eingabefelder, die ständig in den Widgets angezeigt werden. Wir haben uns dafür entschieden, dass die Widgets im Lesemodus + Tastendruck bleiben: Das ist es, was Gladys ermöglicht, eine saubere Darstellung überall zu garantieren (mobil, Wandtablett, helles oder dunkles Thema).

Mein Vorschlag: Eine Widget-Schaltfläche kann Felder deklarieren. Wenn man darauf drückt, öffnet sich ein kleines Formular in der Karte, das von deiner Integration vorgefüllt wird, und Gladys validiert die Werte, bevor sie dir übermittelt werden.

Auf deinem Widget würde es so aussehen (Mockup):

2-formulaire-ouvert
2-formulaire-ouvert912×1720 86.7 KB

Wenn ein Wert außerhalb der Grenzen liegt, die du deklariert hast, wird der Fehler unter dem Feld angezeigt:

3-erreur-de-saisie
3-erreur-de-saisie912×1720 89.1 KB

Und nach dem Speichern wird deine Rückmeldung angezeigt und die Karte wird aktualisiert:

4-livraison-enregistree
4-livraison-enregistree912×1416 72.4 KB

Auf der Integrationsseite erhält die Schaltfläche eine Tabelle fields, im gleichen Format wie die Felder der Aktionen des Manifests. Da der Inhalt des Widgets bei jeder Anfrage aufgebaut wird, kann der Standardwert der zuletzt gespeicherte Preis sein:

{
  "type": "button",
  "label": { "en": "Pallet delivered", "fr": "Palette livrée" },
  "icon": "truck",
  "action": {
    "key": "delivery",
    "fields": [
      { "key": "bags", "type": "number", "required": true, "min": 1, "max": 200, "default": 72,
        "label": { "en": "Bags delivered", "fr": "Sacs livrés" } },
      { "key": "price_per_bag", "type": "number", "required": true, "min": 0, "max": 50, "default": 7.3,
        "label": { "en": "Price per bag", "fr": "Prix par sac" } }
    ]
  }
}

Und du erhältst die eingegebenen Werte, bereits validiert, in values:

gladys.onWidgetAction('pellets', async (actionKey, params, { settings, values }) => {
  if (actionKey === 'delivery') {
    await stock.addDelivery(values.bags, values.price_per_bag);
    return { message: { fr: `+${values.bags} sacs enregistrés` } };
  }
});

Einige geplante Regeln:

  • maximal 4 Felder, vom Typ Zahl, Text, Kontrollkästchen oder Liste;
  • das Formular erscheint erst nach dem Drücken, die Karte im Ruhezustand ändert sich nicht;
  • wie die aktuellen Widget-Schaltflächen ist es für jeden angemeldeten Benutzer verwendbar: Diese Werte sind also wie ein Ereignis (eine Lieferung) zu behandeln, nicht wie eine Änderung der Integrationskonfiguration.

Das ist noch nicht spezifiziert oder entwickelt. Was hältst du davon? Würde das deinen Fall abdecken?

4. Geräte in Wetterintegrationen deklarieren

Für die Verwendung in Szenen ist kein Gerät erforderlich: Seit Gladys 5.1 kann jede Integration, einschließlich einer Wetterintegration, ihre eigenen Szenenauslöser und -aktionen deklarieren (scene_triggers und scene_actions im Manifest). Zum Beispiel:

  • eine Aktion „Aktuelles Wetter abrufen“, die die Temperatur, den Druck, den Wind usw. in outputs zurückgibt. Die folgenden Aktionen der Szene können diese Werte verwenden, und eine Bedingung „Nur fortfahren, wenn“ ermöglicht das Filtern;
  • ein Auslöser, der von deiner Integration ausgelöst wird, wenn etwas passiert („Regen in der Stunde vorhergesagt“, zum Beispiel).

Für Diagramme kann eine Wetterintegration auch ein Widget mit einer Komponente chart deklarieren, die mit ihren eigenen Daten gefüttert wird.

Ich bin jedoch nicht sehr dafür, die Konzepte von Geräten und Wetter zu mischen. In Gladys ist ein Gerät etwas Physisches: eine Ausrüstung, die man steuert, oder ein Sensor, der bei dir misst. Das Wetter sind Daten, die von einem Dienst bereitgestellt werden, mit eigenem Format (aktuelle Bedingungen, stündliche und tägliche Vorhersagen, Warnungen) und eigenem Widget. Wenn wir die Vorhersagen in Geräte umwandeln, landen wir mit falschen Sensoren, die mit den echten vermischt sind (in den Räumen, Diagrammen, Szenen…), und jeder Wetteranbieter würde seine eigenen auf seine Weise erstellen.

Wenn du eine echte gemessene Außentemperatur benötigst, bleibt ein physischer Sensor die richtige Lösung, und er wird definitiv ein Gerät sein.

Nochmals vielen Dank für dieses Feedback!