Rhasspy Pi zero


I just received two new pi 0WH (very difficult to find in stock here) to test rhasspy satellite.

Installed raspbian buster lite, picoTTS, seed respeaker driver, mosquitto, etc.

Then, tried running docker container:

  • it create .config\rhasspy\profiles folder but that’s all, no http interface, no error, nothing

So I tried with venv:

curl: (22) The requested URL returned error: 404 Not Found
Can't download https://github.com/synesthesiam/kaldi-docker/releases/download/v1.0/kaldi_armv6l.tar.gz

Just wanted to test wakeword, and send intent handling and such to the base.
Anyone achieved this ?

Seems kaldi-docker no longer exist, found this one but dunno wich arch to choose:

So I edited download-dependencies.sh and turn ‘Install Kaldi’ to false :face_with_raised_eyebrow:

finally install got to end.


~/rhasspy $ ./run-venv.sh --profile fr
DEBUG:main:Namespace(host=‘’, log_level=‘DEBUG’, port=12101, profile=‘fr’, set=[], ssl=None, system_profiles=’/home/pi/rhasspy/profiles’, user_profiles=’/home/pi/.config/rhasspy/profiles’)
Traceback (most recent call last):
File “app.py”, line 1064, in
assert web_dir.is_dir(), f"Missing web directory {web_dir}"
AssertionError: Missing web directory dist

Ok, had to rename rhasspy/public folder to dist. This path is hardcoded in app.py …

Now it start, but not much

ModuleNotFoundError: No module named ‘snowboy’

and then

Traceback (most recent call last):
File “/home/pi/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py”, line 1471, in full_dispatch_request
result = await self.dispatch_request(request_context)
File “/home/pi/rhasspy/.venv/lib/python3.7/site-packages/quart/app.py”, line 1513, in dispatch_request
raise request_.routing_exception
File “/home/pi/rhasspy/.venv/lib/python3.7/site-packages/quart/ctx.py”, line 45, in match_request
self.request_websocket.url_rule, self.request_websocket.view_args = self.url_adapter.match() # noqa
File “/home/pi/rhasspy/.venv/lib/python3.7/site-packages/quart/routing.py”, line 272, in match
raise NotFound()
quart.exceptions.NotFound: NotFound(404)

Will put back my pi zero into fresh raspbian waiting state :rofl:

I finally found a tar gz file which I uncompressed into rhasspy/dist and now I get the interface on the pi zero ! Wow !

Will see hi can I make it work as a satellite tomorrow.

If I manage to get such setup working I will see how to integrate satellites into the jeedom plugin.
But dunno if once rhasspy get full Hermes/serviced it will work the same do integrating satellites into jeedom may be too early. …

Any eta for such full Hermes full seviced rhasspy ? Will we have a ready to use docker-satellite container ? Will it works the same, basically containing a minimal wakeword + TTS services and dispatch all asr/nlu/stt/intent recognized / handling to the master ?

1 Like

I’ve run into some complexity with deciding how training will work across the services in v2.5. I’m estimating another two weeks for a full prototype now (with training and most wake/ASR/NLU/TTS systems supported).

The docker-satellite container is a good idea. I’d probably include:

  • PyAudio and arecord microphone services
  • Snowboy/porcupine wakeword services
  • eSpeak/picoTTS/flite/remote text-to-speech services
  • Web UI

ASR/NLU would be set to dispatch to a remote Rhasspy server over MQTT or HTTP.


Don’t forget the audio OUT service. :wink:

I’m not sure there is a need for the TTS service on the satellite as it should only create WAVs and pass them to the audio output service (the same way the feedback sounds are handled).

As all the pieces communicate via MQTT, there is no need for a web UI either as long as the audio IN/OUT and wakeword services are configured on a specific siteId it is just a matter of addressing them.

We might need a per service MQTT topic for pushing configuration updates that is not part of the Hermes protocol (something like rhasspy/hotword/setConfig?) so the web UI can handle the settings for each service like monolithic Rhasspy does today. The web UI can use the —siteId multiple parameter as a satellite declaration system.

I guess having TTS on the satellite and sending directly the tts text, or to the master than forward it to sat with mqtt, would be a lot more efficient than having the master generating all waves files and stream them to several satellites on the network, all this while detecting hotword and doing text recognition/intent at the same time.

Regarding venv service, I’ve set up the service like this : https://rhasspy.readthedocs.io/en/latest/installation/#virtual-environment

It works as the interface is there but

systemctl --user enable --now rhasspy

Failed to enable unit: Unit file /home/pi/.config/systemd/user/multi-user.target.wants/rhasspy.service does not exist.

Any idea ? Not settings it automatically starting at boot is pretty useless.

The TTS service will send the generated wav through the MQTT broker either way… I don’t see the use for multiple TTS services but it can be done using limited siteId scope if needed. I don’t think the TTS service should be part of the « satellite » standard deployment.

The wakeword service should be done on the satellite and not on the « master » to avoid spamming the network with useless audio frames messages.

The standard satellite deployment should be:

  • audio IN
  • audio OUT
  • wakeword

The rest can be deployed anywhere (even a satellite if desired)

1 Like

Here is how to install picoTTS on pi zero buster:

wget http://archive.raspberrypi.org/debian/pool/main/s/svox/libttspico-utils_1.0+git20130326-3+rpi1_armhf.deb
wget http://archive.raspberrypi.org/debian/pool/main/s/svox/libttspico0_1.0+git20130326-3+rpi1_armhf.deb
sudo apt-get install -f ./libttspico0_1.0+git20130326-3+rpi1_armhf.deb ./libttspico-utils_1.0+git20130326-3+rpi1_armhf.deb

pico2wave -l fr-FR -w test.wav "Bonjour"
aplay test.wav

Still have to get service starting at boot.

There is no multi-user.target in --user mode. User services should by WantedBy=default.target .

changed it to default.target but same message:

systemctl --user enable --now rhasspy
Failed to enable unit: Unit file /home/pi/.config/systemd/user/default.target.wants/rhasspy.service does not exist.

Ok, finnaly got venv as a service working at reboot !!!

sudo nano /etc/systemd/system/rhasspy.service
-> paste service file

sudo systemctl daemon-reload
sudo systemctl enable rhasspy
sudo systemctl start rhasspy

Here is my service file. You need to set host and user profile.

After=syslog.target network.target

ExecStart=/bin/bash -lc './run-venv.sh --profile fr --host --user-profiles /home/pi/.config/rhasspy/profiles'







The full actual docker a Master and a rhasspy-satellite would also make things really easy to setup and update. Then use interface for settings and it would make it easy for newbies to have something working.
Maybe integrate installers for things like picotts tdn250 kaldi mqtt and such and we could just burn raspbian and start the container either version we want.

I also think interface is important on the satellite. It is reassuring to see log, problems and such. And could have a minimal version with wakeword and tts settings, and of course MQTT setting for siteID and master IP (not sentence/slots etc).

Endpoints should be there also, at least:

  • /api/listen-for-command
  • /api/text-to-speech

Also, wakeword detected webhook is indeed very important from satellite profile also:

"webhooks": {
        "awake": [

If you want to insall snowboy on zero in virtualconf you have to change a script

change line 276 to: (add “l armv6l”)

271-# -----------------------------------------------------------------------------
272-# Snowboy
273-# -----------------------------------------------------------------------------
275-case “${CPU_ARCH}” in
276- x86_64|armv7larmv6l)

This Installation script checks the cpu.
armv6 is used by zero. If you don’t add this, it will stop because it would compare the actual cpu architecture (armv6) with x86_64 (pc) and armv7 (raspberry pi 3)
Snowboy is in repository for zero debian.

1 Like

Many gracious thanks to @KiboOst and everyone who contributed to this thread. :slight_smile:

Question: Should the setup.py for openFst take so very long? I understand the Pi Zero W is a single core processor, but it’s been quite a long time already. :frowning:

on master (

  • Speech to Text: kaldi
  • Intent Recognition: OpenFST

on zeros:

Were you able to get this to work? My install is also stuck on this step. I’ve left it over night and its still not progressing. Do I just keep waiting?

1 Like

Openfst took days to compile on my pi zero. This is why I have prebuilt binaries: https://github.com/synesthesiam/docker-openfst/releases

1 Like

What was the tar.gz file that you found?

I meant what was the tar.gz file you found to get the web interface working?

Don’t worry, I found it.

It was rhasspy/download/rhasspy-web-dist.tar.gz