For those having the same issue with the listen part closing too quickly, the answer is actually in Rhasspy itself. In the text-to-speech option, there is a default for “silence after” of only 0.5s, so this needs to be raised in order to not be cut off too quickly, especially if your phone isn’t very close.
UUUUUUOOOO man, works incredible. In fact the wake word detection with Porcupine works better that in raspeberry (may be because the microphone of the mobile its better and nearest).
If you want I can help us to translate de app to catalan 
Thanks for the amazing work
Once I set it up as a satellite according to this, things pretty much worked. Awesome app, thanks @Nailik! Already had a Home Assistant dashboard on an old tablet, and now I don’t need another RPi just for the Rhasspy satellite.
Same here. Not a huge deal, but it would be nice. Anybody have any pointers?
@Arnau_Dunjo You can make a Pull Request on Github, just translate the file rhasspy_mobile/strings.xml at master · Nailik/rhasspy_mobile · GitHub into a cat folder.
@arbrandes unfortunately i am not yet sure where the issue is, i still try to investigate this.
Some more info: TTS via MQTT actually worked for me, but only once, after force-stopping the app, reloading it, then using the wake word and issuing a command.
Relatedly, after trying to use the app more often, I notice that almost always after the second or third command issued after a force-stop-restart it will simply stop playing audio altogether, and commands stop working. I no longer hear the local notification, the remote start-recording playback sound, TTS, or anything.
I’m going to try more combinations of silence detection options (currently have MQTT silence enabled, and Automatic Silence Detection as well), and will also try on newer hardware and more recent Android version, and report back with some logs.
I think this happens due to a bug i did fix but not release yet.
In some circumstances when the Audio Player did already play sound (like the beep) and would then start to play another sound (like tts) it would hang and the tts would never succeed and could hang the app. I’ll build a release and publish it now - could take some hours until it is available in the playstore.
1 Like
Hi.
How could send the audio answer from Rhasspy to Rhasspy mobile app?
Thanks.
There are 2 ways currently:
- MQTT: send Audio with topic hermes/audioServer//playBytes/ (see Reference - Rhasspy)
- HTTP: call /api/play-wav with the data (see Reference - Rhasspy)
Thanks for your anwer @Nailik.
I have try via remote HTTP and works, thanks. But If I would that the answer sound plays on the same device wich initiate the flow… I don’t understant wich configuration I must use.
I have all services in app redirected to server via HTTP. In th server I use Google STT and TTS.
I tried changing a lot of configuration in app, also only the TTS service to MQTT, but I have only eard the answers from server speakers.
Can you help me?
Thanks
It depends how you handle the intent.
For example when using node-red, i would check the incoming event for the siteId (event.siteId) and then depending on this you could call http://siteId:12101//api/text-to-speech with the text that should be spoken.
This works when using MQTT and when using Intent Handling by the app.
When you use HTTP and Intent Handling “With Recognition” you will get your base siteId inside the event.
I managed to get this work flawlessly with TTS and Wakeword on Samsung S21 as satelite and want to share the configuration here:
Sorry for the 2nd comment, new user policy only 1 embed media per reply, The Dialog Management should be disabled, “Rhasspy” option was the culprit behind the 2 sounds and laggy thing. I’m trying to find a way for the mobile app to adapt to this
I’m trying to set up satellites using Android phones. I’m starting with just one phone for now.
I configured the app connect to my Rhasspy for MQTT communication but it keeps failing with an error message that the “URI path must be empty” and even lists my Rhasspy server URL AND port number.
You have to remove the “http://” inside the the Mqtt host settings. The error message may not be the best because currently they are not optimized and just prints out whatever the mqtt library says.
Thanks. That got rid of that error. But it still doesn’t communicate with the server. If I press the microphone, I hear an acknowledgement sound and say my command. Then I hear the error sound.
When using MQTT remember to add your satellite id to the base server “Satellite siteIds” field for every service that you want to use via MQTT. You can also use the Arrow button on SpeechToText to see if this works.
That’s odd. I was sure I had entered that. I just went and looked – nope it wasn’t there. I added it and now it does work.
The only remaining issue that I currently know about is telling the mobile app that the intent has been handled. The server is throwing errors when I try to send the message back.
This first image shows setting the global.sessionID variable.
This image shows TRYING to set the payload to send the sessionID back to the client.
So i assume you want that the app then speaks the text.
So you have to post the text to “:/api/say”
Yes. That I the EVENTUAL goal. But the current issue is acknowledging to the satellite that it has been handled.
Okay so when the app uses it’s internal “intent handling” service, then the app will end the session after calling the configured service.
When you don’t use this you need to publish an mqtt topic to "hermes/dialogueManager/endSession "(Reference - Rhasspy)
I think this is a problem when someone doesn’t use mqtt so i created a issue to keep track of it. Add endSession HTTP endpoint · Issue #310 · Nailik/rhasspy_mobile · GitHub