I imagine that the vast majority of users will eventually want several satellites around the house, and it makes sense to use cheap dedicated devices. The combination of Raspberry Pi Zero WH + reSpeaker 2-mic HAT seems to be a popular combination for this; just add Rhasspy, a speaker, power supply and case. But there area couple of drawbacks:
Rhasspy on the RasPi Zero takes over 5 minutes to start up
Rhasspy incorporates a lot more options than are appropriate for RasPi Zero
I do admire Rhasspy’s flexibility - and am not suggesting changing anything on the Base station end; or removing the current ability to configure a satellite any way a user likes - but I am suggesting also offering a tailored solution for this specific use case.
I suggest a separate IMG file which can be burnt direct to the microSD card for RasPi Zero W. This image would be more optimised for the slower hardware:
trimmed down OS with unnecessary processes and programs removed
no Docker or venv
Rhasspy (and hermesLedControl ?) pre-installed
version of Rhasspy with some of the settings pre-set
MQTT set to External,
Dialogue Management Disabled
Speech-to-Text, Intent recognition, and Text-To-Speech pre-set to Hermes MQTT
instructions to install audio hardware driver, and update software
It is feasible that even with these optimisations a RasPi Zero might be considered underpowered - in which case consider changing the recommendation in Rhasspy documentation to a RasPi 3A.
Sorry guys, but I have realised that my assumption may be incorrect.
How are people actually using Rhasspy - in particular base-satellite systems ? Here I consider a satellite to have mic and speaker.
Are the satellites low powered and dedicated to that one task ?
Are you also running STT, intent recognition and/or TTS on the same machine ?
Or are you running other tasks on the same machine ?
I note that Rhasspy docs includes several comments like
A common usage scenario for Rhasspy is to have one or more low power satellites connect to a more powerful central server (called the “base” station). These satellites are typically Raspberry Pi’s …
yet both examples show Rhasspy running in Docker on the satellites.
@donburch
I used Zeros at the beginning with reSpeaker 2-mic and small speakers. Rhasspy starts in docker. It was quicker than 5 minutes, but this maybe was because of an earlier version of rhasspy.
Now, I`m using RASPBERRY PI A+, which is arround 2-3€ more expensive than zero with wifi, but powerful as the normal RP3.
audio recording, wakeword and audio playing is activated on this satellites. Everything else is running on the master, which is now the rhasspy AddOn in Home assistant.
I can highly recommend to use docker.
For your questions on how people use Rhasspy satellites, I think @romkabouter got it right on the head. Satellites are low powered, single purpose devices, that maybe just handle wake or stream audio.
It’s funny that you bring this up! I was starting to look into satellites for Home Intent, and am starting to go down this path of a custom satellite intended for a pi 0. Similar to you, I wanted the bare minimum of an OS/setup to get Rhasspy to function as a satellite. However I’m still going at it with a docker container (https://github.com/JarvyJ/HomeIntent-Satellite/blob/main/Dockerfile).
For now I’ve stripped out everything except what’s needed to run a porcupine satellite, and am getting the images building using GitHub Actions (for all the different platforms).
Once that’s working, I want to use SkiffOS to basically boot as quick as possible and startup the container. I’ve only started looking at/playing with SkiffOS in the past few weeks, but the ideas behind it seem really promising (just enough OS to launch a container and one set of configs to get things running on pi 0, 3, 4, odroid, others).
I know some folks might not want to use Home Intent, so if I get to the point of it working on SkiffOS (creating an OS is new to me and it seems a bit harder than shipping software!), I’ll try to keep it working with base Rhasspy as well (and document it for folks who are interested)
Nice setup! Very useful for a low powered device like a Pi 0. Using docker should be no problem, the overhead for running a container is small.
One thing with is that you are fixed to porcupine, but there are more and also better ways to do wakeword detected.
You are not bound to Rhasspy for this, as ling as you can do local hotword detection and on a wake stream audio to Rhasspy.
But that might be something for a later stage
Oh yeah, good point! If this proves to be too slow to get going on a pi 0, I may just have to go with a more custom setup without any interface and a bare minimum of libraries.
What are some other wakeword options? I’m only really familiar with the ones baked into rhasspy (snowboy, raven, porcupine, etc)
I like the idea of a lightweight satellit image, but I would suggest it was a debian package instead to increase flexibility in the users options for hardware choice,
And ditch the docker image, since it is an extra layer and it will take up ressources,
Maybe the best solution would be a modular installation, so the user can select which modules should be installed, so their will be only one package, but it can be costumized to the situation.
Hi Wally,
What you are describing - a debian package for wide hardware choice, modular installation, customisable - is the current Rhasspy. Its flexibility is great, and I wouldn’t want to restrict the main project.
Ok, I can see that I was a bit too unclear here. Something got lost on the way from my brain to my hands when I typed it.
I were actually trying to describe the next step of the current form.
I know that it is modular in the code build, but I was trying to explain I would like something modular in the run situation too, so I could prevent modules and library from loading.
What I am trying to do is get a smaller ressource usage footprint.
If the user select to use another MQTT.service, then the internal MQTT server and its libraries are not load and so on.
Even the GUI should be possible to unload, which can be done with a script, that shuts down the service 15 minutes after a boot unless there have been a connection to the GUI and a press on a button to disable the feature this time.
I wrote that I would like a modular installation, but I was a bit too much in the Windows world then.
The Debian packages is not that flexible and I meant modular loading instead.
