From 9bd8a8e123c59ee3a1db3aa5db89177069f025c5 Mon Sep 17 00:00:00 2001 From: Joshua Boniface Date: Tue, 13 Mar 2018 00:52:24 -0400 Subject: [PATCH] Some additional info about the systemd unit files --- content/post/self-hosted-voice-control.md | 28 ++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/content/post/self-hosted-voice-control.md b/content/post/self-hosted-voice-control.md index a2806e1..85d699f 100644 --- a/content/post/self-hosted-voice-control.md +++ b/content/post/self-hosted-voice-control.md @@ -73,7 +73,7 @@ One downside is, however, that the ReSpeaker technically supports directional au The LED portion of the ReSpeaker requires a little more work. The [examples library for the 4-mic hat](https://github.com/respeaker/4mics_hat) provides all the basic tools needed to get the LEDs working, including several samples based on Google and Amazon device patterns. In my case, I went for a very simple LED feedback design: the LEDs turn on blue while listening, then quickly turn either green on a successful command, or red on a failed command, giving some sort of user feedback without having to listen to the unit try and talk! -To do this, I created a simple Python "daemon" running under Systemd to listen for commands on a FIFO pipe and perform the required action, as well as a helper client utility to trigger the pipe. The code for these can be found [on my GitLab](https://dev.bonifacelabs.ca/joshua-automation/respeaker-led) for convenience. +To do this, I created a simple Python "daemon" running under Systemd to listen for commands on a FIFO pipe and perform the required action, as well as a helper client utility to trigger the pipe. The code for these can be found [on my GitLab](https://dev.bonifacelabs.ca/joshua-automation/respeaker-led) for convenience. One interesting feature of this configuration is the Systemd unit file. It performs a git pull inside the service directory (e.g. the repo directory) to ensure the service is automatically up-to-date when the service is started. I do the same thing in my Kalliope unit file for its configuration. ### Kalliope configuration @@ -145,6 +145,32 @@ The next step is to actually configure Kalliope. The examples are a good startin Using this configuration as a jumping-off point, you can add multiple other options, and including the various shell commands you can ensure that the LED ring shows the status of every task. +I use a custom Systemd unit to ensure everything is started correctly, including output buffering, and as mentioned above ensures the configuration repository is always up-to-date with the origin, making configuration updates on-the-fly to multiple devices quick and painless. + +``` +# Kalliope service unit file +[Unit] +Description = Kalliope voice assistant +After = network-online.target + +[Service] +Type = simple +WorkingDirectory = /srv/kalliope-config +User = kalliope +ExecStartPre = /usr/bin/pulseaudio --daemon +ExecStartPre = /usr/bin/ssh-agent bash -c 'ssh-add /srv/git-deploy.key; git pull; exit 0' +ExecStart = /usr/bin/stdbuf -oL /usr/local/bin/kalliope start + +[Install] +WantedBy = multi-user.target +``` + +Install and enable the systemd unit file using a full path; this is a relatively unknown feature of systemctl that comes in handy here: + +``` +pi@kalliope:~$ sudo systemctl enable /srv/kalliope-config/kalliope.service +``` + ## The Next Steps With all of this assembled, you can test out the ring and make sure it's doing what you want. Here's a sample video of my ring in action!