Sonos ayant racheté SNIPS et l’ayant tué (Merci Sonos, je ne serai jamais client), je me penche sérieusement sur Rhasspy et il semble pouvoir le remplacer, même si certaines choses sont encore en développement.
J’ai donc publié un plugin JeeRhasspy, actuellement seulement en beta, le temps que Rhasspy murisse encore un peu. Mais j’ai déjà pu convertir tout mes intents et slots de snips vers Rhasspy !
Merci beaucoup pour ce plugin, de plus je suis actuellement les avancements sur https://community.rhasspy.org (et tes travaux ;)), et effectivement Rhasspy est une bonne alternative à SNIPS.
Un truc sympa à avoir dans le plugin serait d’avoir si possible « rhasspy variables » comme avec le plugin SNIPS.
En effet cela permettrait d’avoir un scénario pour mettre en « muet » télévision ou autres lors d’une détection de mot clé, ainsi que d’avoir l’id du message démarré et l’id du message terminé.
Exemple « Rhasspy Variables » : « rhasspyMsgSession », « rhasspyMsgSiteId », et « rhasspyMsgHotwordId ».
Dernier chose, je remarque dans la capture écran de tes intentions sur le plugin « JeeRhasspy » un point orange devant certaines. A quoi cela correspond ?
Pour le point orange c’est les intent n’ayant pas de scenario callback.
Je viens de pousser une nouvelle beta avec l’affichage plus explicite et le nom et tags du scenario au survol quand y’en a un.
Pour les variables, actuellement je ne peux pas sans avoir un broker mqtt ou un demon qui écoute sur le websocket. J’en parle avec le dev de rhasspy car je souhaiterai éviter çà pour le plugin. Le plugin snips est une usine à gaz avec plein d’install de dépendance qui ont posé pas mal de problème. Donc pour l’instant je prend le chemin de pas de dependance/demon, le dev a déjà ajouté des trucs pour çà. Mais rassure toi j’en ai aussi besoin donc je suis dessus. Avec snips, dès qu’il detecte le hotword, si la musique est trop forte il mute le temps qu’on parle. Super pratique et j’aimerai retrouver la même chose
Petite question sur le « Wake Word » dans rhasspy tu utilises quoi ?
Personnellement je suis avec le model « alexa » sous Snowboy avec une sensibilité à 0.4 mais je trouve la détection moins bonne qu’avec SNIPS.
Aurais tu une piste ou une idée ?
Perso j’ai fait un wakeword personnalisé sur le site de snowboy, sensibilité 0.38 çà marche bien. Après je suis en test, le rhasspy n’est donc pas au même endroit et j’ai pas fait les wakeword de toute la famille, mais çà semble pas mal. Peu être plus de false positive, faudra peu être que je refasse le wakeword mais je verrai plus tard.
Hello! j’avais vu des messages passés mais je n’avais pas eu cette info du rachat par sonos. Effectivement autant choisir autre chose!
Ma question, un PI 3b+ peut faire tourner conjointement jeedom+rhasspy ou il est préférable d’avoir un PI4 pour pas avoir de soucis? ou bien encore 2 machines distinctes obligatoirement d’après vos expériences/tests?
J’ai deux PI3. Un dédié exclusivement à jeedom et l’autre à rhasspy.
Personnellement, j’ai pas trop mettre mes œufs dans le même panier, sauf si le panier est un environnement de virtualisation comme proxmox, ESXI, docker (containers), … etc
Rhasspy tourne sous un environnement docker ou un environnement virtuel avec la création d’un service manuellement. Pour plus d’info voir par ici => https://rhasspy.readthedocs.io/
Après cela tu peux ajouter une squeezebox avec queezelite et/ou un serveur LMS sous docker par exemple sur ton Pi3 qui héberge rhasspy.
Je suis familier docker donc c’est aussi pour ça que ton sujet m’a attiré (je vais dockeriser mon jeedom aussi) mais faut que j’investisse dans un nouveau rasp dans ce cas
encore merci, j’interviendrais à nouveau quand j’aurais mis tout ça en place pour donner mon avis, mais ça sent le super taff merci @geekGoldfish et participants
@kiboost
Hello,
Merci pour l’ajout de la détection du « WakeWord » en variable.
Mais est-il possible d’en avoir un peu plus ?
En effet, sous « snips » j’utilisais les « Session id started », « Session id ended » combiné avec « MsgSiteId ». Ce tout dans jeedom avec gestion par scénario pour me permait de diminuer le son lors en message est diffusé sur les Snips (maître et/ou satellites).
Ainsi lorsque qu’un Snips « parlé » (exemple notification) le son de ma squeezebox ou TV était diminué.
Bon il est vrai que j’utilisais le courrier MQTT .
Bref, rhasspy semble bien parti, mais la route est peut-être encore longue pour avoir toutes les fonctionnalités de Snips (satellite, groupes de satellite, WakeWord multiples, etc…)
Je pense pas qu’il faille en ajouter d’autres dans le plugin. çà nécessiterai en plus de le faire coté rhasspy.
Mais tu peu faire la meme chose en te faisant un scenario ‹ talk ›. Tu lui renvoit tes requetes TTS en tag, le scenario check la musique etc, et envoit la commande tts.
Pour les wakeword multiple, c’est deja géré avec snowboy. Pas encore essayé, j’en ai qu’un pour l’instant, mais mon snips est comme çà.
Pour le reste, master/satellites, c’est un gros chantier, et c’est en cours. Le plugin suivra les évolutions bien sur.
Parce que ma prod actuelle avec snips fonctionne avec Et à la fois Rhasspy et le plugin seront alors complet. Le contrôle des LEDs c’est secondaire (mais un vrai plus au quotidien), c’est pas le plugin qui le gèrera donc çà bloquera pas une stable du plugin.
Mais si les futures versions de Rhasspy avec base/satellite nécessite de réécrire tout le plugin, je vois pas l’intérêt de passer en prod et en stable maintenant Et actuellement il me manque les builtins slots (duration etc) pour avoir l’équivalent de mon install snips, et les satellites.
Oui je vois le principe, mais le temps de diffusion des notifications est variable.
Le fait d’avoir le retour sur la fin d’une diffusion d’un mesage permet de mette un « wait » dans le scénario.
Par exemple, mon scénario récupérait l’id du message en début de diffusion (msgIdStarded) et attendait ce même id en fin (msgIdEnded).
Ainsi le son de la TV ou squeezebox est en “muet" durant la durée de diffusion du message, pas plus ni moins.
Cela me servait aussi si j’utilisais d’autres « skill » avec snips (hors jeedom).
Maintenant je comprends bien que cela nécessite des ajouts côté rhasspy.
MQTT reste peut-être possibilité. Je vais regarder de se côté.
Merci @kiboost pour ce plugin ! Je m’intéressais aussi à Snips mais vu le rachat, autant investir du temps dans une solution qui en vaut la peine !
Je viens tout juste de réinstaller Jeedom sur un RPi 3 B+ ; auparavant, j’avais un Odroid C1+ que j’aimerai bien réinvestir pour éventuellement un Rhasspy (pas fan du nom ). Je suis limité par l’OS et je me pose donc la question, il semblerait que je puisse installer Ubuntu 18.04 dessus. Je vais tester le mode Environnement Virtuel Python, mais cela me semble bien compliqué en première instance, et surtout, est-ce que je vais trouver un micro compatible, that is the question
Et sinon, votre fil utilise plein de mots techniques liés à ce type de techno, c’est facile à prendre en main et configurer ? Merci
Très intéressé par ce projet suite à la mort de SNIPS, je galère à mettre en oeuvre Rhasspy avec un reaspeaker mic array v2. J’ai bien ma sortie son, en revanche je n’ai pas de micro … Dès que j’ai solutionné ce point, j’arrive pour tester tout cela !
Courage pour le développement
Edit : j’ai maintenant le micro mais pas de wake word fonctionnel avec snowboy !
Edit : le wake word fonctionne de temps en temps.
Edit : La reconnaissance d’intents ou le STT beaucoup moins par contre …
.
Et actuellement il me manque les builtins slots (duration etc) pour avoir l’équivalent de mon install snips, et les satellites.
). Je suis limité par l’OS et je me pose donc la question, il semblerait que je puisse installer Ubuntu 18.04 dessus. Je vais tester le mode Environnement Virtuel Python, mais cela me semble bien compliqué en première instance, et surtout, est-ce que je vais trouver un micro compatible, that is the question 
