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 ?
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
ERROR:main:NotFound(404)
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
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. …
@synesthesiam
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 ?
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:
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.
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)
Still have to get service starting at boot.
seems:
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.
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:
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.
Many gracious thanks to @KiboOst and everyone who contributed to this thread.
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.
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?