Bonsoir à tous,
Après une bataille acharnée avec JeeRhasspy, le respeaker et le moissonage litéral de divers forum; j’ai fini par arriver à quelque chose de pas mal 
Problèmes 1 & 2: – reglé
Tout venait des intentions qui ne remontaient pas dans JeeRhasspy parce que je sais pas lire ^^
Il suffisait de décocher la case « Filtrer les Intents Jeedom » du menu de configuration de JeeRhasspy pour que tous les intents de Rhasspy remontent et soient exploitables.
On n’est pas forcé de décocher la case en realité (là encore j’au lu trop en diagonale) car comme le dit très bien l’auteur du plugin:
Filtrer les Intents Jeedom : A l’importation de l’assistant, seuls les Itents donc le nom finit pas jeedom seront crées ( TurnOnJeedom , LightSetJeedom , etc).
Maintenant si je fais reconnaitre un mot clef qui déclenche un intent depuis Rhasspy (bouton Recognize), celui-ci va déclencher l’exécution du scénario configuré dans JeeRhasspy et celui-ci sera donc executé !
Il me reste le problème 3 à régler:
J’ai toujours l’erreur suivante lorsque je fais un « Test TTS » sur le Rhasspy satellite (le respeaker):
[2020-06-01 15:51:20][ERROR] : [RhasspyUtils] jeeRhasspy:textToSpeech error → 0
Là je sèche 
J’ai également deux autres soucis:
- Problème 4: Les logs Rhasspy sur le respeaker sont blindés de messages de ce type depuis que j’ai tenté de configurer le « wake word » avec Porcupine:
2020-06-01 20:50:59,690 INFO success: wake_word entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-06-01 20:51:00,021 INFO exited: wake_word (exit status 1; not expected)
2020-06-01 20:51:01,040 INFO spawned: 'wake_word' with pid 30370
2020-06-01 20:51:02,048 INFO success: wake_word entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-06-01 20:51:02,404 INFO exited: wake_word (exit status 1; not expected)
Je pense que c’est le process qui reste en écoute du wake word qui essaie de démarrer et n’y arrive pas.
Cela explique certainement pourquoi la reconnaissance du wake word ne marche pas pour l’instant sur mon installation.
J’ai essayé de configurer le wake word ainsi sur Rhasspy:
- wake word → Porcupine
- key word file → americano_raspberry-pi.ppn
- UDP audio input → IP_RESPEAKER:PORT_LIBRE:ID_DU_SITE_DU_RESPEAKER
- Available Keywords: → je me prends un timeout quand j’essaie de faire un refresh. Je ne peux rien selectionner
Après le timeout suite au refresh, je vois ça dans le slogs Rhasspy:
[ERROR:2020-06-01 21:15:02,165] rhasspyserver_hermes:
Traceback (most recent call last):
File "/usr/lib/rhasspy/lib/python3.7/site-packages/quart/app.py", line 1821, in full_dispatch_request
result = await self.dispatch_request(request_context)
File "/usr/lib/rhasspy/lib/python3.7/site-packages/quart/app.py", line 1869, in dispatch_request
return await handler(**request_.view_args)
File "/usr/lib/rhasspy/lib/python3.7/site-packages/rhasspyserver_hermes/__main__.py", line 728, in api_wake_words
hotwords = await core.get_hotwords()
File "/usr/lib/rhasspy/lib/python3.7/site-packages/rhasspyserver_hermes/__init__.py", line 814, in get_hotwords
handle_finished(), messages, message_types
File "/usr/lib/rhasspy/lib/python3.7/site-packages/rhasspyserver_hermes/__init__.py", line 898, in publish_wait
result_awaitable, timeout=timeout_seconds
File "/usr/lib/python3.7/asyncio/tasks.py", line 449, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
[DEBUG:2020-06-01 21:14:32,160] rhasspyserver_hermes: Publishing 71 bytes(s) to rhasspy/hotword/getHotwords
[DEBUG:2020-06-01 21:14:32,158] rhasspyserver_hermes: -> GetHotwords(site_id='séjour', id='f3ea0c29-4909-4391-b32f-c575bee457e7')
[DEBUG:2020-06-01 21:14:32,153] rhasspyserver_hermes: Subscribed to rhasspy/hotword/hotwords
- Profile Rhasspy (extrait de la section « wake » du profile.json ci-dessous):
"wake": {
"porcupine": {
"keyword_path": "americano_raspberry-pi.ppn",
"udp_audio": "IP_RESPEAKER:PORT_LIBRE:ID_DU_SITE_DU_RESPEAKER"
},
"satellite_site_ids": "ID_DU_SITE_DU_RESPEAKER",
"system": "porcupine"
},
J’essaie de dire « americano » (je suppose que c’est ça le wake word ?) Et Rhasspy ne réagit pas.
Une idée là-dessus quelqu’un ?
- Problème 5:
Lorsque je fais lire un texte à Rhasspy (bouton Speak), celui-ci le lit bien mais systématiquement 2 fois.
J’ai l’impression que c’est depuis que j’ai installé un broker MQTT externe en docker sur mon serveur Jeedom et que j’ai configuré mes Rhasspy pour pointer dessus.
Pourquoi un MQTT externe ?
- Je me suis dit que ça déchargerait un peu le respeaker (limité en ressources)
- J’ai rencontré ce problème:
[ERROR:2020-06-01 20:57:10,988] rhasspyserver_hermes: mqtt connect
Traceback (most recent call last):
File "/usr/lib/rhasspy/lib/python3.7/site-packages/rhasspyserver_hermes/__init__.py", line 223, in start
self.client.connect(self.host, self.port)
File "/usr/lib/rhasspy/lib/python3.7/site-packages/paho/mqtt/client.py", line 937, in connect
return self.reconnect()
File "/usr/lib/rhasspy/lib/python3.7/site-packages/paho/mqtt/client.py", line 1071, in reconnect
sock = self._create_socket_connection()
File "/usr/lib/rhasspy/lib/python3.7/site-packages/paho/mqtt/client.py", line 3522, in _create_socket_connection
return socket.create_connection(addr, source_address=source, timeout=self._keepalive)
File "/usr/lib/python3.7/socket.py", line 727, in create_connection
raise err
File "/usr/lib/python3.7/socket.py", line 716, in create_connection
sock.connect(sa)
**OSError: [Errno 99] Cannot assign requested address**
J’ai l’impression que le broker MQTT embarqué dans Rhasspy ne réussit pas à démarrer.
On dirait que le port sur lequel il essaie d’écouter (1183) ne lui est pas accessible.
J’avoue ne pas avoir cherché à comprendre pourquoi car la solution d’un MQTT déporté sur le serveur Jeedom (plus puissant) me paraissait ne pas être une si mauvaise solution.
Quelqu’un a-t-il un avis ? Bonne/mauvaise idée ?
Merci d’avance pour vos lumières.
(et je suis plus têtu que lui ^^)