Wyoming vs. ESPHome - My experience

[MichaelaMer]

This isn’t meant as a complaint. Quite the opposite. I’m grateful for the developers who built Home Assistant and the surrounding ecosystem. What follows is simply a log of what I ran into while trying to get a satellite voice assistant running.

Years ago I built my own home automation environment called Lumosur. It handled lights, sensors, and even voice commands. It served me well for a long time. A few weeks ago I decided to retire it and move everything over to Home Assistant.

The transition took some effort. The learning curve is real. Still, with some persistence (and a helpful AI assistant), I eventually got a solid setup running. The microphone and speaker were attached directly to the Home Assistant hardware. Speech-to-text ran through Whisper on another machine, a local LLM handled responses, and everything talked over Wyoming. It worked.

Yesterday I thought it would be a good time to add a voice assistant satellite.

I started by pulling the sources from GitHub. Right away I noticed the deprecation notice. Installation failed because of Python version conflicts. After some searching I found someone else with the same issue. The advice they received was simple: the old Wyoming satellite was considered dead, and the recommended path now was ESPHome.

Alright then. I switched directions.

I checked the Linux-Voice-Assistant repository but couldn’t immediately find clear installation instructions. Back to the AI helper. Eventually I pulled the repository from:

https://github.com/OHF-Voice/linux-voice-assistant.git

I configured my old ReSpeaker 4-mic array, installed the recommended dependencies, and watched ffmpeg pull what felt like half the Linux multimedia stack along with it. Nearly a gigabyte later the system started.

Sort of.

The first problem appeared immediately:

pa.PA_CONTEXT_READY Assertion Error

So it expected PulseAudio. I would have preferred sticking with plain ALSA, but fine—installed PulseAudio and tried again.

Next attempt: Home Assistant actually detected the satellite. It heard the wake word. Then it stopped with:

Cannot find libmpv in the usual places

Fair enough. Installed mpv.

Another run produced:

microwakeword.py:207: RuntimeWarning: invalid value encountered in cast

That looked like an issue with the microphone data coming from the ReSpeaker array. After some tinkering I managed to get past that.

Then the next log entry appeared:

DEBUG: LibMpvPlayer:_on_end_file: reason=4 (is_eof=False), state=PlayerState.ERROR
DEBUG: LibMpvPlayer:_on_end_file: ignoring non-eof event (reason=4)

The strange part: running mpv directly from the shell played audio just fine.

After about an hour of experimenting with different workarounds, I decided to stop for the night.

This morning I started fresh and went looking for a cleaner path. Eventually I landed on Florian Asche’s PiCompose project. After a couple of tries I managed to load the provided image into rpi-imager.

Then I hit another wall.

The setup options were built around specific hardware: 2MicHat, ReSpeaker Lite, and a few others. My situation is much simpler. I have a Raspberry Pi 4 and a USB microphone. That’s all I want to use.

At this point I had spent roughly five hours on the problem.

The takeaway, at least from my perspective, looks something like this:

The old Wyoming satellite was straightforward. Installation was simple and could be configured to use a wide range of microphones and audio hardware. Tons of YT videos are available to help. The newer ESPHome-based approach appears far more flexible and powerful. At the same time it feels much harder to get started with unless you happen to own the exact hardware the guides assume and find the link to click on.

That leaves people like me in an odd spot. I’m sitting here with a perfectly functional Raspberry Pi and a USB microphone, yet I can’t get a satellite running. For newcomers who watch a YouTube video showing how “easy” it is to install a Wyoming satellite, the experience might also feel be a real bummer. I wonder – was it really .. well .. smart … to abandon the “old” way before the new system is debugged and available for most environments?

[florian-asche]

Hi,

yeah this project is still experimental and far from finished and perfect but if you follow the documentation it is working.

I am wondering why you run into problems with libmpv. In the documentation it should be installed here: https://github.com/OHF-Voice/linux-voice-assistant/blob/main/docs/install_application.md#b-bare-metal
Feel free to open a MR or issue if you see a error there.

The new LVA has built in wake word detection. If you compare LVA with something you should add the installation for openwakeword in order to compare it. Then it should be almost the same.
But that is the reason why i think using docker here is the best option. You just download the docker container, run that and worst outcome you have a permission or pulseaudio issue but you dont have to look for all the other stuff that can go wrong.

The PiCompose Base Image can be used for non specified hardware: https://github.com/florian-asche/PiCompose/?tab=readme-ov-file#usage

But the Respeaker 2-MicHat should also work for your 4-MicHat. It is currently just untested.
And we have a open bug florian-asche/PiCompose#27 if you make that changes yourself and follow the PiCompose docs you should have a working version of LVA.

But in recap yeah i am also currently thinking about how can we make this better. I was thinking about building packages.

But you dont even know half of all the stuff that can go wrong. I had to put so much effort in the 2MicHat.
The SeeedStudio devices are good but the drivers and documentation is really bad.
The installation script you find there is broken in multiple ways. At some point i build a fixed version: https://github.com/florian-asche/PiCompose/blob/main/02-stage-audiodriver-2michat-v1/01-driver/03-run-chroot.sh

I just joined this project to make it better. I am working on a PiCompose Version in combination with the FutureProofHome Hardware which has open source firmware and opensource hardware on all ends. No stupid errors with USB connection on the Respeaker Lite.

[MichaelaMer]

Like I said Florian (keine Beschwerde :) Liebe Grüsse aus der Wüste in den USA. Everything needs time to be perfected. Maybe we should keep the "old" Wyoming up and running so that users at least have the chance to get a satellite running for the time being. It gives you more time to sort things out too 🗡️

[omaramin-2000]

Wyoming satellite support is over already, and might stop working at some time over the updates. Therefore, LVA is the newest option for now and the replacement for wyoming as it's always up to date with the latest new features. The best to installation is using docker on your own linux OS or flashing the SD card using the complete PiCompose image... and let us know how everything is going and don't hesitate to inform when you notice any point.

[MichaelaMer]

As I just have a plain vanilla Raspi 4 + USB microphone, I wasn't sure which (and where) to download an image. There's a lot of information, but none (that I found) that said: Here's your bin. Install it on your vanilla (no hardware extensions) raspberry and enjoy :D

[MichaelaMer]

Not quite, @florian-asche .

Here's my log to get the client running bare bone:

install vanilla raspian-light
reconfigure wifi via raspi-config (it didn't carry over from PI-Imager)
apt update
apt upgrade

sudo apt-get install \
  avahi-utils \
  pulseaudio-utils \
  alsa-utils \
  pipewire-bin \
  pipewire-alsa \
  pipewire-pulse \
  build-essential \
  libmpv-dev \
  libasound2-plugins \
  ca-certificates \
  iproute2 \
  procps \
  git \
  jq \
  curl \
  wget \
  vim \
  python3-venv \
  python3-dev
  
apt install pulseaudio

git clone https://github.com/OHF-Voice/linux-voice-assistant.git
cd linux-voice-assistant
chmod +x docker-entrypoint.sh
script/setup


Start pulseaudio (if not running)

USER: replace with your username, eg. charly

sudo usermod -a -G audio USER

in docker-entrypoint.sh:

export PULSE_COOKIE="$HOME/.config/pulse/cookie"
export PATH=/home/USER/linux-voice-assistant/.venv/bin:/usr/bin:/bin

Create 
/etc/systemd/user/linux-voice-assistant.service

[Unit]
Description=Linux-Voice-Assistant
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
WorkingDirectory=/home/USER/linux-voice-assistant
Environment=WAKE-MODEL="okay_nabu"
Environment=WAKEUP_SOUND="sounds/wake_word_triggered.flac"
ExecStart=/home/USER/linux-voice-assistant/docker-entrypoint.sh
StandardOutput=null
StandardError=null
Restart=always
RestartSec=5
[Install]
WantedBy=default.target

as USER:

systemctl --user daemon-reload
systemctl --user enable linux-voice-assistant
sudo loginctl enable-linger USER

Since all processes (pipewire .. ) run in user-space, we have to start the stuff in user space as well.

Greetings,

m.

[florian-asche]

And the last error was that you hear for example the wake sound but no music playback? I also had this issue. Too long ago. Mh it was pulseaudio config error or missing package. One of that two things.

[Hedda]

@MichaelaMer this is as mention a new bleeding-edge experimental project in very early development stage (as in even way before pre-alpha in maturity and not recommended to beginners who want a simple solution with low maintenance).

If you instead were looking to try a relatively more mature solution then you should really buy the Home Assistant Voice Preview Edition (or alternativly the FutureProofHomes Satellite1 Dev Kit) that by default have ESP32-based hardware running customized ESPHome firmware which have plug-and-play configuration flows and pipelines compared to this project:

• https://www.home-assistant.io/blog/2024/12/19/voice-preview-edition-the-era-of-open-voice/

  • Note that while the official Home Assistant Voice PE hardware is sold as ”preview edition” product it ships preflashed with a special ”production-ready” firmware which makes it much easier to get started (for reference see https://github.com/esphome/home-assistant-voice-pe ).

Again even that is advertised as a ”preview” product so it can also only be said to be mature relatively speaking however that have at least have the benefit of both more developers and more development time. Regardless, that is the recommended solution to get started with with native voice control Home Assistant and is what newcomers should try first:

• https://www.home-assistant.io/voice_control/

That is, unless you are purposefully trying to make it hard on yourself because you like the extra challenge and want to help contribute to this brand new experimental project 😜

[MichaelaMer]

I am aware of the bleeding edge. But here's the thing: There are ton of videos on YT to explain how to install a Wyoming client on a Raspi. All those users are now experience the same .. interesting times ... I had. I am not complaining or arguing against the new way of doing things. But as long as ESPHome voice satellites are not as reliable or easy to install as the Wyoming satellites, I think it would make sense to keep Wyoming alive.

[Hedda]

But as long as ESPHome voice satellites are not as reliable or easy to install as the Wyoming satellites, I think it would make sense to keep Wyoming alive.

For the record, ESPHome voice satellites like the Home Assistant Voice Preview Edition (or alternativly the FutureProofHomes Satellite1 Dev Kit) can be said to be both easy to install and reliable (at least compared to other things in Home Assistant in general, but sure if could of course be made much easier if compare to getting started with Google Nest speakers or Amazon Echo and Alexa).

Or maybe you are confusing those with this Linux Voice Assistent project which is using ESPHome’s API but is in fact not a ” ESPHome voice satellite” solution.

Anyway, personally I do not think that makes sense to pit countinued development efforts on the old Wyoming satellite framework if would mean developers would spend time on maintaining a dead-end solution instead of spending time on what will hopefully become a mainstream solution in the future. Also note that Wyoming satellites was only ever experimental too and promised to be maintained as a production-ready solution.

[Solarunit]

The setup options were built around specific hardware: 2MicHat, ReSpeaker Lite, and a few others. My situation is much simpler. I have a Raspberry Pi 4 and a USB microphone. That’s all I want to use.

I use mini PC and USB-mic. The transition from Wyoming-satellite to LVA was very simple and painless (I use docker method of course)

[rolyantrauts]

Usb mics even if you turn up the gain to max are generally engineered to work on that near-field of broadcast style.

The el cheapo max9814 boards from adafruit or even cheaper aliexpress clones (exactly the same but support adafruit if you can) have a preamp and 1st stage analogue AGC. That if you plug into any soundcard also el cheapo CM108 it considerably boosts range to give you a single mic on a budget.

[Solarunit]

What about shotgun directional microphones? Do they outperform those 2 or 4-mic array mics? What if you add another shotgun mic to form 2-mic array?

[rolyantrauts]

Depends on alg but with 2/4 MVDR its not about directionality of the target its about the null they fire at noise.
2 mic mvdr you get 1 null and targets 1DOF, 4 mic mvdr 3 null target 3DOF.
With 2mic https://github.com/rolyantrauts/mvdr_2mic it manages -30db on 1 null so the noise x 0.0316

endfire which is shotgun as opposed to broadside with a delaysum

Much with mic arrays was the minimum and max frequency due to mic spacing where approx 40mm would give effective frequency range will be locked between roughly 150 Hz at the low end and 4,300 Hz as the longest diagonal would be approx 80mm in early 6/7 mic designs.
Amazon then dropped to 4 mics square neural guided MVDR and with latest followed the Google nest Audio with small 3 mic Differential Microphone Array (DMA).
As 2nd stage TSE targeted speech extraction on neural accelerators provides better results as is the optimum solution to the cocktail party problem of double talk.
you will often see arrays with 1 central mic and you can hazard a guess its for MVDR as the center to each point gives the short high frequency dimension and diagonals longest low freq dimension's, which with the differing geometries giving differing long/short ratio's of mic spacing and number of mics giving nulls and DoF (Degrees of Freedom) of targets.
I don't know that much about Differential Microphone Array (DMA) as all arrays are the math behind them than mic types, but with DMA the tolerances have to be ultra tight and only big tech are likely to have the economies of scale to order and dictate same binnings of ultra close sensitivity tolerances. They don't suffer the same frequency restrictions of mic spacing and tolerate much higher levels of noise.

MVDR your target your not actually beamforming in how many think your telling the math don't null this. The math is actually quite lite if optimised for vector SIMD instructions, the problem shifts to getting accurately targeting user voice so you don't null it, where neural MVDR make a much more informed choice of what is voice and what is noise.
Its why VoicePE and Sat1 are likely low end cul-de-sacs as even on Xmos MVDR + targeting is prob too much of an ask in compute or for the devs and why sat1 still uses the 2mic alg from Xmos.
Certainly isn't going to do neural MVDR or TSE that both Google / Amazon rolled out custom AI accelerators and in-house highly quantised models to provide.

[LLBR88]

@MichaelaMer I had the previous wyoming-satellite running on my pi zero 2's and transitioned over to LVA when I got it working some time ago. I don't exactly follow all of the advice here because some things are - in my opinion - overcomplicated when there are simpler options available. However, I recently reinstalled one of my pi's from scratch and got LVA working without an issue now that I know how to do it. As follows:

Dependencies to install:
pipewire
pipewire-audio
pipewire-pulse
pulseaudio-utils
wireplumber-doc
git
libportaudio2
libmpv-dev
python3-dev
build-essential

Note that Pipewire is a good step up from PulseAudio and pipewire-pulse provides compatibility with PulseAudio applications. If you can avoid it, don't install PulseAudio!

Clone the repo
Run script/setup
Create the user systemd service as you did above
Enable / start the service and also do loginctl enable-linger so that it runs on boot.

I know that the docs recommend to start LVA with the docker entrypoint script but I use script/run and command-line parameters instead. It just feels more natural that way, and it still works perfectly.

For input device I use the device name but for output I can use "pipewire" and then route the audio to my usb soundcard using a Pipewire config snippet. That allows me to use other audio apps on the device and Pipewire handles all of the tricky stuff.

In summary - LVA is doable bare-metal and I would say that actually it is a better platform than Wyoming Satellite, even though it still has a few features to catch up on. This project in particular is a bit all over the place if I may say so, but there are a plenty of devs and users interested in it that I'm confident it will get to a good place eventually. Dyaxler and mricharz both have very interesting forks of the project on the go which I'm keeping an eye on.

[MichaelaMer]

@LLBR88 Thank you for your write up. I got it running bare bone a few days ago (see install log in the thread) . I am sure LVA has it's advantages over Wyoming, but as a fairly new HA user (I was previously running my self-programmed home environment) I failed to understand why one would kill an old working protocol when the new environment is still rough around the edges. But if that's the way it is, fine with me. I am grateful for the work all the devs put in, so I just follow their lead :)