Dans les scènes, pouvoir faire un choix aléatoires entre une série de textes

Quand je lance une scène Gladys avec un bouton, je trouve sympa sur certaines de ces scène d’avoir une confirmation audio que la scène a été lancée, ou qu’une étape a été réalisée. Par exemple, je lance la scène qui fait circuler l’eau chaude afin qu’elle monte à la salle de bain de l’étage, et j’ai une première confirmation qui me dit « Ok, je m’en occupe », puis une deuxième qui me dit « Voilà, la douche est prête ».

Sauf que ces phrases sont toujours les mêmes !

Je me suis débrouillé avec node-red pour amener un peu de variations (voir ce tuto). Mais ça serait chouette d’avoir cela directement dans Gladys.

Une façon de pouvoir le réaliser serait d’avoir une nouvelle action dans les scènes, nommée par exemple « Texte aléatoire », dans lequel on pourrait définir plusieurs textes (avec possibilités d’y inclure des variables), et dont le résultat serait l’un de ces textes choisit aléatoirement et utilisable comme une variable dans les blocs suivants.

Par exemple, je définirais les textes suivants dans cette action :

  • texte 1 : « Ok, je m’en occupe »
  • texte 2 : « Je fais monter l’eau chaude. Et elle est à {{ 1.1 Température eau }} degrés »
  • texte 3 : « Vos désirs sont des ordres »
  • texte 4 : « J’vais voir c’que j’peux faire… »

Et dans le bloc suivant, je pourrais utiliser l’action « Parler sur une enceinte » avec comme texte {{ 2.1 Texte aléatoire}}

@pierre-gilles Est-ce qu’avec ta façon de t’appuyer sur l’IA pour développer il est encore utile de créer une maquette ou ce n’est pas nécessaire ?

Tu utilises Gladys Plus @StephaneB ? :slight_smile:

Si oui, c’est déjà possible avec l’action « Demander à l’IA » !

En bonus, tu auras une réponse entièrement personnalisé car c’est une IA qui l’écrit, avec des variations à chaque fois :wink:

@pierre-gilles, J’ai testé avec Demander à l'IA et techniquement ça fonctionne, effectivement.

Sauf que cette action passant par l’IA, elle a un temps de réaction beaucoup trop long (entre 5 et 10 secondes) pour que ça puisse être perçu comme une confirmation de la prise en compte de l’appui sur le bouton.
Et donc quand une personne appuie sur le bouton, elle a tendance à croire au bout de 2-3 secondes sans réaction que l’appui a été mal fait et appuie à nouveau…

Donc j’aimerais maintenir ma demande.

Bonjour @StephaneB et @pierre-gilles

Je vais dans le sens de @StephaneB, déjà au niveau de la demande (il m’a devancé, je l’aurais proposé durant ce WE …) et de l’interactivité avec l’IA (latence dans la réponse). J’ajoute une réflexion tout à fait personelle concernant l’IA : je tente tant que possible de rendre Gladys autonome chez moi (au moins pour le pilotage des bidules connectés), donc introduire de l’IA dans le cloud va forcement aller à l’encontre de ma démarche. Je vais d’ailleurs profiter de ce WE pour tenter de formuler une demande allant en ce sens :stuck_out_tongue:

Belle journée à vous deux,

Jean

Je serais curieux de comprendre ce qu’il se passe chez toi, car l’API d’IA répond en général en 500ms pour des réponses relativement simple :slight_smile:

Quel est le prompt ?

Dans ce cas, la bonne réponse est probablement l’IA en local, non ? :slightly_smiling_face: C’est d’ailleurs un sujet qui est déjà prévu, et même en partie développé.

Pour revenir à la demande initiale, je dois avouer que je ne suis pas convaincu par l’approche proposée.

On est à une époque où il existe des modèles d’IA extrêmement légers, capables de tourner directement sur un téléphone. Je ne vois pas vraiment l’intérêt de revenir à une logique de “choisir aléatoirement une phrase parmi 3 ou 4”, comme on le faisait il y a une quinzaine d’années.

À mon sens, le vrai besoin n’est pas d’avoir des réponses prédéfinies, mais d’obtenir une réponse naturelle et contextualisée. Par exemple :

  • « Ok, je m’en occupe. »
  • « Je lance la circulation d’eau chaude. Elle est actuellement à 24 °C. »
  • « C’est parti, l’eau chaude sera prête dans quelques instants. »

Le tout généré dynamiquement en fonction du contexte, plutôt que de maintenir une liste de variantes à la main.

Je pense que cette approche sera plus simple à utiliser, plus flexible et donnera un résultat bien plus naturel.

Mon prompt est le suivant :
"Je viens de lancer le circulateur d’eau chaude pour qu’elle monte à la salle de bain et que je puisse prendre une douche. Crée une phrase courte mais originale pour m’informer que ce sera prêt dans une minute, en précisant que la température de l’eau chaude (pas celle de l’air ambiant de la salle de bain) est à {{variable récupérée}} degrés. Inutile de me donner les dixièmes de degrés.

Donne-moi seulement cette phrase en réponse, sans autre explication. Ne diffuse aucun message, et ne crée pas de scène."

Ça me donne des réponses de ce style :

  • Préparez-vous ! Dans 1 minute, l’eau de votre douche sera à 46°C.
  • Votre douche sera prête dans 1 minute ! L’eau chaude atteint déjà 46°C.
  • Comptez jusqu’à 60… et plongez ! Eau chaude à 46°C dans 1 minute !

… et c’est vrai que c’est sympa plutôt que de définir quelques phrases à tirer au sort.

Mais je confirme mes mauvaises perfs : la scène a pris entre 15 et 20 secondes à chaque fois pour me générer ces 3 phrases (simple affichage dans Telegram, donc pas de délai lié à l’enceinte).

Je précise que j’ai fait ces tests à un moment où mon serveur Gladys est bien réactif (donc sans le souci peut-être lié à Enedis, décrit dans l’autre sujet).

est se qu’il est possible de demander à l’IA de proposer des phrases pour les dire sur google cast?

Avec le prompt que j’ai donné plus haut (ou un autre du même genre), l’action « demander à L’IA » génère une phrase. Et ensuite si tu utilises l’action « parler sur une enceinte », tu peux mettre dans le champ ‹ phrase › la variable {{ réponse de l’ia }}. Et ça marche. :wink:

Bonne nouvelle @StephaneB :smiling_face:
On peut fermer la demande alors ?

Ben j’aimerais bien avant ça l’avis de @pierre-gilles pour comprendre pourquoi ce prompt d’IA met 15-20 secondes à réagir chez moi, là où cela prend 0.5s chez lui…

Je n’avais pas précisé ma config, si ça peut aider à comprendre : mini-pc Intel NUC5PPYB, processeur N3700 4 cœurs 1.6GHz, 8Go de RAM, sous Ubuntu 22.04, relié à mon réseau fibre en ethernet.

Merci, ça marche.

Salut @StephaneB, désolé pour le délai.

Sur le fond, je ne partirai pas sur une liste de phrases pré-écrites tirées au sort. La direction de Gladys, c’est l’IA : une réponse générée et contextuelle, pas un dictionnaire figé. Donc le sujet à régler ici, ce n’est pas « comment contourner l’IA », c’est « pourquoi l’IA met 15 s chez toi ».

Et 15-20 s, ce n’est pas normal. Pour être transparent sur l’architecture : l’action « Demander à l’IA » ne fait pas un seul appel. Il y a d’abord un appel rapide de classification d’intention, puis l’appel principal, puis un ou plusieurs allers-retours supplémentaires si le modèle décide d’appeler un outil (aller lire une température, par exemple). Mais même à 3 allers-retours on devrait être autour de 1,5-2 s, pas 15. Il se passe donc autre chose de spécifique à ton installation.

Je manque de temps pour mener l’enquête moi-même, mais la bonne nouvelle c’est que tu as tout ce qu’il faut pour la mener sans m’attendre — sans ligne de commande, et Gladys enregistre déjà tout le nécessaire. Voici les clés.


1. Voir exactement ce que l’IA a fait, appel d’outil par appel d’outil

C’est le cœur du diagnostic. Déclenche ta scène, attends la réponse vocale, puis va dans Intégrations → Intelligence Artificielle, section « Debug IA » → « Télécharger le contexte JSON pour debug ».

Ouvre le fichier obtenu (un éditeur de texte suffit) et regarde la section _debugconversationHistory. Elle contient deux choses :

  • toolCalls : la liste exacte de tous les outils que l’IA a appelés, avec pour chacun son nom (tool_name), son résultat (tool_status : success ou error), les arguments qui lui ont été passés, et l’heure précise (created_at).
  • messages : la conversation complète dans l’ordre chronologique — ton message, chaque appel d’outil, la réponse finale — chaque entrée horodatée.

En soustrayant les created_at, tu vois précisément combien d’outils ont été appelés pendant ton exécution de scène, lesquels, et lequel a mangé le temps. Deux signaux à guetter :

  • plusieurs appels d’outils pour une simple phrase de confirmation → chaque appel est un aller-retour complet vers le modèle, c’est probablement là que partent tes secondes ;
  • un tool_status: "error" → un outil qui échoue fait repartir le modèle pour un tour supplémentaire, ce qui peut doubler ou tripler le temps total. C’est le genre de chose qu’on ne soupçonne pas et qui saute aux yeux dans ce fichier.

Les appels déclenchés par une scène sont bien enregistrés ici : l’historique est celui de l’utilisateur choisi dans l’action « Demander à l’IA ». Pense donc à déclencher la scène avant de télécharger le fichier.

Accessoirement, la section tools du même fichier liste tous les outils envoyés au modèle à chaque appel. Si elle est très volumineuse (beaucoup de devices), ça alourdit aussi chaque requête.

2. Compléter avec les logs si besoin

Si le fichier ci-dessus ne suffit pas à trancher, Paramètres → Système → Télécharger les logs, puis cherche [AI_CHAT] dans le fichier. Tu obtiens la trace côté serveur, horodatée ligne par ligne :

[AI_CHAT] New request userId=... message=...
[AI_CHAT] Forcing tool_choice=required for categories=device_query
[AI_CHAT] Assistant turn iteration=1 tool_calls=1 tool_choice=required tools=[...]
[AI_CHAT] Running tool=...
[AI_CHAT] Tool finished tool=... status=success resultLength=...
[AI_CHAT] Assistant turn iteration=2 tool_calls=0 ...
[AI_CHAT] Completed answerLength=...

La grille de lecture :

Où part le temps Ce que ça veut dire
Entre New request et le 1er Assistant turn Préparation locale (Gladys reconstruit la liste des outils depuis ta base) + appel de classification
Beaucoup de lignes Assistant turn iteration= Le nombre d’allers-retours vers le modèle explose
Entre Running tool= et Tool finished tool= L’exécution de l’outil sur ton instance qui rame
Un seul Assistant turn, mais 10 s pour l’atteindre Le modèle ou ta liaison réseau

3. Un test comparatif immédiat

Dans le chat avec Gladys, pose successivement ton prompt complet, puis une version courte sans aucune référence à un capteur : « Donne-moi une phrase courte pour confirmer que tu t’occupes de la demande ». Chronomètre les deux à la montre.

Si le court répond en 2 s et le long en 15 s, c’est confirmé : c’est ton prompt qui déclenche des appels d’outils. Mentionner la température de l’eau fait comprendre au modèle qu’il doit aller lire un capteur avant de répondre. Dans ce cas tu as un gain immédiat en réécrivant ton prompt pour qu’il n’ait besoin d’aucune donnée — et le fichier de l’étape 1 te le montrera noir sur blanc.


Fais-toi aider par une IA pour dépouiller tout ça

C’est typiquement le genre de tâche où Claude (ou ton assistant préféré) est très efficace, et ça t’évite d’attendre après moi. Donne-lui le contenu de _debug.conversationHistory avec une consigne du style :

« Voici l’historique horodaté d’un appel IA dans Gladys Assistant, au format JSON. Liste les outils appelés dans l’ordre, calcule la durée entre chaque étape, et dis-moi où part la majorité du temps total. Signale tout outil en erreur. »

Gladys est open source, donc tu peux aussi lui donner le fichier qui gère tout ce flux pour qu’il raisonne sur le code réel : server/lib/gateway/gateway.forwardMessageToAiChat.js dans le dépôt GitHub du projet.

Petite précaution : ce fichier contient tes messages, tes noms de pièces et de devices. Retire ce que tu ne veux pas partager avant de le coller quelque part, ici comme ailleurs.

Merci pour les pistes d’analyse Pierre-Gilles. Je vais explorer ça ce week-end.