Amélioration intégration externes

Demande de fonctionnalités
2

Salut @Will_71,

Merci pour ces retours, ils sont très concrets et ça fait plaisir de voir ton intégration pellets prendre forme !

Je précise que Claude m’a aidé à écrire ce message mais c’est bien moi qui ai réfléchi à chaque point :joy:

1. Choisir la maison dans une liste

Oui, c’est une bonne idée. Aujourd’hui, les listes dynamiques (source) ne savent proposer que les appareils de l’intégration. On va ajouter "source": "houses" : la liste affichera le nom des maisons et enregistrera leur selector, c’est-à-dire l’identifiant que te renvoie déjà GET /house. Tu pourras donc faire la correspondance directement.

Ça marchera partout où ce format de champ est utilisé : configuration, actions, réglages de widget et scènes. Je prépare une PR.

Seule contrainte : il faudra relever la gladys_version minimale de ton manifest, car les versions plus anciennes de Gladys refusent une source qu’elles ne connaissent pas.

2. Valeur décimale dans la configuration

C’est en fait un bug. Le serveur accepte déjà les décimales, mais le champ numérique du formulaire n’a pas d’attribut step : le navigateur n’accepte donc que des nombres entiers et bloque l’enregistrement. Même l’exemple de la doc (une latitude à 48.85) ne passait pas :sweat_smile:

J’ai ouvert un ticket : Issue · GitHub

Le correctif tient en une ligne et s’appliquera à tous les formulaires des intégrations (configuration, actions, widgets, scènes).

3. Saisir une valeur depuis le widget

Le besoin est réel, ton parcours actuel (aller dans l’intégration, changer le prix, revenir sur le tableau de bord) n’est pas pratique.

Par contre, je ne veux pas de champs de saisie affichés en permanence dans les widgets. On a fait le choix que les widgets restent en lecture + appui : c’est ce qui permet à Gladys de garantir un rendu propre partout (mobile, tablette murale, thème clair ou sombre).

Ma proposition : un bouton de widget peut déclarer des champs. Quand on appuie dessus, un petit formulaire s’ouvre dans la carte, pré-rempli par ton intégration, et Gladys valide les valeurs avant de te les transmettre.

Sur ton widget, ça donnerait ça (maquette) :

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

Si une valeur est hors des bornes que tu as déclarées, l’erreur s’affiche sous le champ :

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

Et une fois enregistré, ton message de retour s’affiche et la carte se met à jour :

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

Côté intégration, le bouton gagne un tableau fields, au même format que les champs des actions du manifest. Comme le contenu du widget est construit à chaque demande, la valeur par défaut peut être le dernier prix que tu as enregistré :

{
  "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" } }
    ]
  }
}

Et tu reçois les valeurs saisies, déjà validées, dans 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` } };
  }
});

Quelques règles prévues :

  • 4 champs maximum, de type nombre, texte, case à cocher ou liste ;
  • le formulaire n’apparaît qu’après l’appui, la carte au repos ne change pas ;
  • comme les boutons de widget actuels, il est utilisable par tout utilisateur connecté : ces valeurs sont donc à traiter comme un événement (une livraison), pas comme une modification de la configuration de l’intégration.

Ce n’est pas encore spécifié ni développé. Qu’est-ce que tu en penses ? Est-ce que ça couvrirait ton cas ?

4. Déclarer des appareils dans les intégrations météo

Pour l’usage dans les scènes, il n’y a pas besoin d’appareils : depuis Gladys 5.1, n’importe quelle intégration, y compris une intégration météo, peut déclarer ses propres déclencheurs et actions de scène (scene_triggers et scene_actions dans le manifest). Par exemple :

  • une action « Récupérer la météo actuelle » qui renvoie la température, la pression, le vent… en outputs. Les actions suivantes de la scène peuvent utiliser ces valeurs, et une condition « Continuer seulement si » permet de filtrer dessus ;
  • un déclencheur déclenché par ton intégration quand quelque chose se produit (« pluie annoncée dans l’heure », par exemple).

Pour les graphiques, une intégration météo peut aussi déclarer un widget avec un composant chart alimenté par ses propres données.

Par contre, je ne suis pas très favorable à mélanger les concepts d’appareil et de météo. Dans Gladys, un appareil, c’est quelque chose de physique : un équipement qu’on pilote ou un capteur qui mesure chez toi. La météo, c’est une donnée fournie par un service, avec son propre format (conditions actuelles, prévisions par heure et par jour, alertes) et son propre widget. Si on transforme les prévisions en appareils, on se retrouve avec de faux capteurs mélangés aux vrais (dans les pièces, les graphiques, les scènes…), et chaque fournisseur météo créerait les siens à sa façon.

Si tu as besoin d’une vraie température extérieure mesurée, un capteur physique reste la bonne solution, et lui sera bien un appareil.

Encore merci pour ces retours !