New Rhasspy Mobile App - Beta

Development
#21

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.

#22

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 :wink:

Thanks for the amazing work

#24

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?

#26

@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.

#27

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.

#28

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
#29

Hi.

How could send the audio answer from Rhasspy to Rhasspy mobile app?

Thanks.

#30

There are 3 was:

  • MQTT: send Audio with topic hermes/audioServer//playBytes/ (see Reference - Rhasspy)
  • HTTP: call /api/play-wav with the data (see Reference - Rhasspy)
  • MQTT: setup text-to-speech service in app and send text via hermes/tts/say (Reference - Rhasspy) the app will then use the text-to-speech service to generate the audio and then send it to the defined audio-output
#32

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

#33

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.