Bonjour,
j’ai développé plusieurs interactions, intégrant des ask, et celle que j’utilise le plus concerne la gestion de l’absence de la maison.
J’en profite alors pour activé la sécurité, réduire le chauffage, simuler ma présence, …
Et remettre le chauffage avant mon retour !
Pour cela, je dois indiquer à Jeedom quand est-ce que je compte rentrer. J’ai donc mis en place la fonction ask (via Telegram) et j’avais développé un petit script pour analyser ma réponse qui pouvait être une durée (dans 2 heures, dans 3 jours, pendant 1h30, …) ou une date/heure de fin (demain matin, dimanche à 12h, le 21/08, …).
Mais cela n’est malheureusement plus fonctionnelle suite à l’évolution du ask (introduite dans la 4.3.8) qui limite les réponses aux réponses proposées :
# 4.3.8
Correction de bugs.
Amélioration de la sécurité des ask lors de l’utilisation de la fonction generateAskResponseLink par les plugins : utilisation d’un token unique (plus d’envoi de la clef api du core) et verrouillage de la réponse uniquement parmi les choix possible.
Idem pour la température demandée. Cela oblige à prévoir tous les cas de température possible dans le ask.
Je comprends que cela puisse constituer une avancée dans un sens (sécurité ou fiabilité), mais cela a pour inconvénient de limiter les interactions.
Est-ce qu’il serait possible de faire évoluer le « ask » pour gérer les 2 cas ?
L’utilisation par défaut sera celle avec vérification de la réponse (utilisation la plus répandue). Et une option permettrait de ne pas se limiter aux réponses proposées. Ceci permettra ainsi d’avoir des réponses libres (ce qui se rapproche des Interactions de jeedom).
Je suis dans le même cas. J’ai un cabinet où je met à jour la présence via le plugin agenda depuis la fonction Ask avec des réponse libre ( supression rendez vous ou ajout de rendez vous ) ce qui me permet de gérer le chauffage.
Ex :
Je demande le nom du rdv
Je demande la date
Je demande l’heure
Cela rajoute via un code le rendez-vous dans le calendrier.
Depuis la mise a jour je ne peux plus faire cela, avez vous une solution de contournement ?
Ce n’est malheureusement pas la première fois qu’une mise à jour mineur (en plus, là, il s’agit même d’une màj mineur.mineur) casse la compatibilité … Les bonnes pratiques en terme de gestion de version ne semble pas être connu.
Et j’aimerais bien qu’on m’explique l’apport au niveau sécurité …
Cependant, je n’ai pas reçu à saisir une réponse libre …
Déjà sur la configuration, est-ce qu’il faut mettre uniquement « * » dans le champ « réponses » ? Ou est-ce qu’on peut le mettre à la fin (ou début) de la liste des réponses ?
J’ai testé les 2 possibilités et quand je saisis une réponse autre que celle de la liste (ou une simple réponse libre si j’ai seulement autorisé « * »), cela relance une interaction Telegram et n’est pas interprété dans le ask …
Quelqu’un a-t-il un exemple fonctionnel ?
Bonjour,
le caractère * peut-être n’importe ou dans la réponse.
par exemple : Oui;*;Non
Telegramme proposera Oui et Non, et si tu répond par un message, le Core le prendra aussi en compte car tu aura utilisé l’option *
Edit:
Je vient de tester en 4.3.11, il semble que la modif que j’ai apporté au Core en alpha n’est pas suivi vers la stable, je confirme donc que le * ne fonctionne pas en 4.3.11…