[Plugin][Stable]2018-11-07 17:53:59


#1

@coorfang
Bonjour,

Depuis cette mise à jour, il n’y a plus le passage automatique du tableau de tags au scénario du binding:

Tags : {"#plugin#":"","#identifier#":"","#intent#":"","#siteId#":"","#query#":"","#device_name#":"","#Nombres#":""}

Comment mettre ces tags dans le champ “tag” du scénario ?


#2

@coorfang
Just did the test:

No callback scenario, one binding calling a scenario the old way.
-> No tag passed to the scenario (even being checked in callback scenario).


#3

Je n’ai pas compris à quoi sert le callback scenario, si quelqu’un peut m’en dire deux mots.

La doc : https://snips.gitbook.io/documentation/home-automation-platforms/jeedom-fr n’en parle pas encore.


#4

Au lieu de faire des bindings, avec tout les house_room possible et un binding par combinaison de slots (sur certains intents j’avais 8 bindings!!), tu fait aucun binding, juste un scenario en callback. Donc dès que l’intent match, il lance le scénario, slots ou pas, house_room correspondant ou pas etc.
Par exemple, j’ai des scenario snips_onoff, snips_volets, snips_light etc et je fais les check directement dans le scenario (si intent on, si house_room salon, alors etc )

De toutes façon il fallait faire des scénarios assez complexes derrière (à moins de faire que des choses très simple) et c’était galère de devoir avoir un binding correspondant à chaque combinaison de slots possible. Là tu peux rajouter un slot dans un intent, t’a pas de binding à refaire, tu le gère dans ton scénario. Beaucoup plus rapide et simple.


#5

Donc, il faut faire un choix, soit binding, soit callback ?
Ou on peut mixer les deux, si aucun binding correspond, c’est le callback qui est appelé ?


#6

ah çà j’ai pas testé, j’ai mis des callbacks et viré tout mes bindings direct, enfin !
Mais tu risque d’avoir d’abord le callback éxécuté et ensuite les bindings. Donc attention à ne pas faire d’actions en double.

Mais je vois pas l’intérêt, fait tes bindings dans ton scénario en fait.


#7

Un des intérêts que je vois au binding, c’est de pouvoir le désactiver. D’ailleurs, cela serait bien d’avoir les commandes correspondantes d’activation et de désactivation dans Jeedom.


#8

Tu peux désactiver un bloc dans un scénario.
Mais jamais eu besoin, ni de désactiver un binding


#9

Oui, mais je ne pense pas que tu puisses désactiver un bloc de scénario via une commande.

Comment gères-tu la sécurité : interdire certains bindings en fonction d’évènements ?


#10

avec un bloc code ou un script, tu peux. Mais tu a un cas concret ? Tu ne peux pas faire un SI dans ce cas là ?

ex:
Dans tous mes scénarios callbakc, en haut j’ai un si alarme on, stop
autre ex:
Si mon fils demande à allumer sa lumière principale, et qu’il est plus qu’une certaine heure, snips lui répondra que non. Nous on peux tout le temps.


#11

Hello Jeandom,

The idea of the callback scenario is to replace the old way of calling scenarios in the bindings.

Which means that you can either use callback scenario to handle actions OR split bindings.

But yes, before we did not have a callback scenario setup, so we have to make the binding to call the scenario with all the possible conditions. Now this part can be simply replaced by the callback scenario

I am sorry that we did not update the documentation for the latest release yet. So that where confused you.

About the scenario called in the bindings, there is no pre-set tags passing to it anymore.

Not sure if my answer solves your question?


#12

Hi Kiboost,

I have noticed this problem as well. But since I though people will never call the scenario twice during 1 intent detected. So I did not do anything for it. Do you think it masters?


#13

@coorfang

Cette régression de ne plus avoir les pre-set tags est très dommageable pour moi, je dois tout refaire.
Pourquoi ne pas les avoir laissé dans les scénarios des bindings ?


#14

Yes, I can keep it still passed to scenario for bindings.

But the initial idea of having the callback scenario is to be able to control the tags passed to the scenario. In other word, different people has different requirements of snips_tags. But it was fixed. In the jeedom system, the total tag size is limited, which means that if I have all the tags passed by default and the query is too long, it will no be able to be passed to scenario anymore.

So the previous beta version has some options on the config page, which allows user select the tags they would like to pass. But this design will set the fixed passing tag for all the intents.

Then the idea comes is having the config for each intent separately, now we have the callback scenario.

If we add back the tag passing for binding scenarios, it can only pass the selected tags in the callback scenario for this intent. Do you think this will matter?


#15

Merci pour l’attention que tu portes sur mon problème.
Ta proposition me convient parfaitement.


Liaison snips avec scenario jeedom
#16

OK, I will put it back next week. But also, on your side, you should think about the new callback scenario. It can support multi slots values.

If you want to try out it, beware that change the fetching grammar in your scenario like this:


#17

J’ai bien compris l’intérêt du callback scénario.
Ce qui m’arrête, c’est d’avoir un seul scénario qui va gérer des objets hétéroclites.
Le scénario sera tellement gros qu’il deviendra difficilement maintenable (j’utilise beaucoup de blocs code).
Je préfère gérer plusieurs petits scénarios.
De plus, c’est plus modulable, comme est Jeedom.


#18

@coorfang @KiboOst

Quelques petits retours : :wink:

  • Lorqu’on sauvegarde les bindings, les paramètres liés aux scénarios ne se sauvegardent pas. Lorsque je recharge l’assistant (Load assitant) ou que je restaure (Import binding) je pers systématiquement les paramètres liés aux scénarios ( Scenario, Action et Tags)
  • dans la documentation, sur la commande ask il y a une erreur, ask n’est pas bloquant https://snips.gitbook.io/documentation/home-automation-platforms/jeedom-fr#k-commande-ask
    Je suis obligé de rajouter un wait variable(ans)!=“Aucune réponse” pour bloquer le déroulement du scénario sinon je n’ai jamais le retour de la réponse.
  • toujours sur ask, j’ai une latence énorme (plus de 14 secondes) entre le moment ou la commande ask est exécuté dans le scénario et le moment ou ma question est prononcée réellement par le tts (defaut ou custom) , une idée de quoi regarder pour debuguer et trouver ce qui ralenti la prononciation de ma question?

#19

Idem, très embêtant du coup je n’utilise que très la fonction ask.


#20

Hello,

1/ Yes, this is something not yet update for the latest feature. Will follow up ASAP

2/ I am not sure I understand the question. Does it mean when execute the scenario containing ask command, it does not wait to get the answer?

3/ Sounds wired, please check the snips log both on Jeedom and snips-watch.

On jeedom, find the line which contain [startRequest]asked question: balabalabalablaba.
On Snips, find the line where the session relating to your question started.