merci @kiboost pour ce super boulot sur Jeerhasspy.
Il me reste à optimiser mais ça fonctionne chez moi sur un PI2 (Kaldi lent me reste à optimiser) …
Pour la fiabilité dans le temps, à voir à l’usage…
J’ai une question, @kiboost => Que peut-on, peux-tu ou jeedom core pourrait faire afin que le SpeechToText « alimente » (=interagit avec) directement les interactions de Jeedom ?
A mon niveau un TTS (Facile avec playTTS) et STT me suffirait amplement…
À mon avis le seul truc serait que le plugin rebalance le text dans le moteur d’interaction. Comme le faisait je pense le plugin snips.
Mais n’ayant jamais utilisé les interactions et n’en ayant absolument pas besoin, je ne compte pas le faire sur le plugin. Je ne pourrai de toute façon pas le maintenir, n’utilisant pas de telles fonctions.
OK.
Dommage c’était la seule solution d’assistant vocal personnel offline non « legacy », à ma connaissance. Cela aurait permis de capitaliser sur les conf des interactions déjà existante (SMS et telegram) sans avoir à dupliquer en scénarios…
J’imagine que ce n’est pas une priorité de l’équipe jeedom non plus?
Vue les solutions actuelles Google/Alexa et des rhasspy pour ceux qui veulent du offline entièrement customisable, je ne pense pas non.
Je regarderai dans les sources du plugin snips a tout hasard, mais je veux pas créer de faux espoirs non plus. Et c’est tellement puissant avec un véritable asr/nlu et les scénarios …
Céquoidonc ?
Face à Google/Alexa, Rhasspy me semble être aujourd’hui la seule solution locale, opensource et maintenue disponible sous jeedom (si l’on utilise des services TTS et STT locaux et open source bien sûr) et grâce à ton plugin d’ailleurs… Il y a bien SARAH mais qui il nécessite windows.
ps : si je suis le seul intéressé par le lien avec les interactions, ne te fatigue pas 
La gestion des intents sur la box jeedom ou sur le device Rhasspy nous ramène à l’éternelle choix A/R de l’informatique centralisé/décentralisé…
L’ASR transforme l’oral en texte, puis le nlu en intent avec les slots demandés. Donc une fois dans ton scénario tu sait exactement ce que tu a demandé donc c’est très simple de faire des si/alors. Plus fiable que les interactions et ça continuera d’évoluer.
Oui tu est le seul à en parler mais c’est vrai que snips le proposait dans le plugin. Je regarderai si c’est simple mais je ne pourrai pas vraiment tester pour ça que je ne me suis pas aventurer la dedans.
Pour gérer les interactions ça a l’air bizarre de loin mais quand on n’y regarde de plus près c’est très simple.
J’essaie de trouver le temps de te mettre un bout de code exemple demain.
çà a l’air d’être un truc comme çà :
$res = interactQuery::tryToReply($payload->{'query'})
Il faut ensuite récupérer la réponse avec $res[‹ reply ›] et l’envoyer sur le tts du siteId
Si c’est que çà, je peux ajouter une checkbox sur les intents ‹ Use interact › et dans ce cas il fait çà ?
C’est la base oui.
Il faut commencer par avoir une commande (jeedom) qui correspond à l’utilisateur (ou une commande général d’envoi de message p-e dans ton cas? je ne sais pas si jeerhasspy peut identifier un utilisateur).
Je vais prendre l’hypothèse que tu as la commande dans la variable $cmd_user:
$cmd_user = $this->getCmd('action', xxxxx);
// quelques params à set:
$parameters = array();
$parameters['reply_cmd'] = $cmd_user;
$parameters['plugin'] = 'jeerhasspy';
// si la commande est liée à un user (en supposant qu'il est sauvé dans une config "user" de la commande donc:
$user = user::byId($cmd_user->getConfiguration('user'));
if (is_object($user)) {
$parameters['profile'] = $user->getLogin();
}
//et finalement l'interact:
$reply = interactQuery::tryToReply($message, $parameters);
if (trim($reply['reply']) != '') {
$cmd_user->execute(array('message' => $reply['reply']));
}
si tu gères le « ask », il faut faire le ask avant l’interact
Et tu peux conditionner tout ce code par une config pour savoir si les interactions sont activées ou pas comme tu disais; a toi aussi de voir si tu fais cela avant ou après les intents, ca c’est toi qui peut savoir/décider en fonction du plugin.
J’ai pas de notion de user dans jeerhasspy. Mais des siteID pour les devices rhasspy, donc je pense que la commande est la commande tts du device sur lequel répondre. Si c’est çà pas de soucis.
Pour le ask çà devrait marcher.
Et pour les intents, en gros si interact est coché, il balance le text dans les interactions, sinon il execute le scenario en callback.
Je vais essayer mais j’y connais vraiment rien en interaction jeedom 
Après pour tester tu n’es même pas obligé de créer une interaction: tant que t’as la réponse « désolé je n’ai pas compris » en retour sur le device ayant recu la demande, c’est bon pour ta part du boulot => c’est que ton plugin a envoyé la demande au moteur et à recu une réponse, à l’utilisateur d’avoir une interaction qui fonctionne
Ben çà a l’air de marcher 
[2020-02-28 13:56:03][DEBUG] : [jeerhasspy] <event> Event received: {"intent":{"name":"getTime","confidence":0.75},"entities":[],"text":"quelle heure est il","raw_text":"quelle heure est il","recognize_seconds":0.034188717999996,"tokens":["quelle","heure","est","il"],"raw_tokens":["quelle","heure","est","il"],"speech_confidence":1,"wakeId":"snowboy\/lunaNicolas.pmdl","siteId":"salle","slots":[]}
[2020-02-28 13:56:03][DEBUG] : [jeerhasspy] <event> Send query to interact engine!
[2020-02-28 13:56:03][DEBUG] : [RhasspyUtils] <textToSpeech> _text: Désolé je ne comprends pas la demande | _siteId: salle | lang:
J’ai bien un TTS « Désolé je ne comprends pas la demande »
C’est bon d’après toi ?
Je viens de pousser une nouvelle beta.
Peut tu essayer ? Il faut, sur l’intent souhaité, cocher « Interaction » et sauvegarder.
Oui ca fonctionne.
Incompréhension sur ma proposition:
Le moteur d’intention/interaction jeedom a la même fonction que le moteur d’intent de Rhasspy. On pourrait donc envoyer le flux STT directement à jeedom (la gestion des commande est ainsi centralisé pour les appel SMS, telegram, Rhasspy…). Et si une interaction match la réponse est envoyé au flux TTS :
Si j’execute un ask vers Rhasspy (en forçage manuel ou sur appel d’un intent de Rhasspy) :
Si j’exécute ce scénario sur un appel d’intent + intercation (via ta modif) le scénario ne fonctionne pas et fait planter le wakeword snowboy de rhasspy. Si je force le wake, l’intent est ok mais jeedom n’exécute plus l’interaction issue de l’intent.
Après reboot du rhasspy, tout repart…
J’espère être assez clair…
Euh … non 
Et si rhasspy ne reconnait pas d’intent, je suis pas sur qu’on récupère le text. En gros tu voudrai désactiver les intents sur le rhasspy et envoyer le flux audio ou le texte direct ? Le flux audio je sais pas si c’est possible, et pour avoir le texte, l’asr a besoin d’un training donc d’intents (un language model) pour reconnaitre le texte.
Sinon je vire l’option et je repasse comme avant. Perso je ne vois absolument pas l’intérêt des interactions avec un truc aussi puissant que Rhasspy et qui continuera de s’améliorer …
Là je ne comprend pas bien. La fonction Ask déclenche simplement l’écoute de rhasspy, puis sur le retour enregistrer les deux variables Je vois pas le lien avec le fait que wakeword plante sachant que le ask et son retour, les interactions n’entrent pas en compte.
Le texte direct et donc profiter du wake word et du STT
Cela permet de centraliser les échanges avec Jeedom. Rhasspy (par la voix et son) à la maison (en open source), telegram ailleurs et SMS si pas dez 4G (éventuellement vocaldom mais via google) 
De mon point de vue cela à du sens!
En fait ce que tu cherche, c’est plutôt un script sur ton rhasspy qui va récupérer le texte et l’envoyer direct à jeedom. Même sans intent sur le Rhasspy. Tu peux le faire en python assez facilement.
https://rhasspy.readthedocs.io/en/latest/speech-to-text/#open-transcription
https://rhasspy.readthedocs.io/en/latest/intent-recognition/#command
Et là tu fera ce que tu veux.
Mais ce n’est vraiment pas l’objet du plugin, qui est fait pour gérer les actions en fonctions des intents / slots sur Rhasspy.
Exact. Je regarde, merci pour le lien.
