willow VS esphome

Fair points but with all due respect completely misses the point and context. My comment was a reply to a new user interested in esphome on a post about esphome.

You're talking about CircuitPython, 35KB web replies, PSRAM, UF2 bootloader, etc. These are comparatively very advanced topics and you didn't mention esphome once.

The comfort and familiarity of Amazon for what is already a new, intimidating, and challenging subject is of immeasurable value for a novice. They can click those links, fill a cart, and have stuff show up tomorrow with all of the usual ease, friendliness, and reliability of Amazon. If they get frustrated or it doesn't work out they can shove it in the box and get a full refund Amazon-style.

You're suggesting wandering all over the internet, ordering stuff from China, multiple vendors, etc while describing a bunch of things that frankly just won't matter to them. I say this as someone who has been an esphome and home assistant user since day one. The approach I described has never failed or remotely bothered me and over the past ~decade I've seen it suggested to new users successfully time and time again.

In terms of PSRAM to my knowledge the only thing it is utilized for in the esphome ecosystem is higher resolution displays and more advanced voice assistant scenarios that almost always require -S3 anyway and are a very advanced, challenging use cases. I'm very familiar with displays, voice, the S3, and PSRAM but more on that in a second...

> live with one less LX7 core and no Bluetooth

I'm the founder of Willow[0] and when comparing Willow to esphome the most frequent request we get is supporting bluetooth functionality i.e. esphome bluetooth proxy[1]. This is an extremely popular use case in the esphome/home assistant community. Not having bluetooth while losing a core and paying more is a bigger issue than pin spacing.

It's also a pretty obscure board and while not a big deal to you and I if you look around at docs, guides, etc, etc you'll see the cheap-o boards from Amazon are by far the most popular and common (unsurprisingly). Another plus for a new user.

Speaking of Willow (and back to PSRAM again) even the voice assistant satellite functionality of Home Assistant doesn't fundamentally require it - the most popular device doesn't have it either[2].

Very valuable comment with a lot of interesting information, just doesn't apply to context.

[0] - https://heywillow.io/

[1] - https://esphome.io/components/bluetooth_proxy.html

[2] - https://www.home-assistant.io/voice_control/thirteen-usd-voi...

> - People might criticize my messy/bad/unfinished code

As someone who has created and maintained open source projects (most recently Willow[0]) for two decades I get a kick out of this.

Of course when interacting with users and feedback I keep it polite but in my head I'm thinking "You like to talk. I actually DID this. Shut up or submit a PR".

Surprise surprise they almost never do.

[0] - https://heywillow.io/

Also check out Willow- https://heywillow.io

It doesn’t synthesize voice back (yet) but open source and runs all offline on ESP32-based hardware and works with HomeAssistant!

Look into https://heywillow.io/ - still early in the project but they are getting good results.

Very nice!

Would you be interesting in integrating with my project Willow[0]?

Willow supports Home Assistant, OpenHAB, and generic REST+MQTT endpoints today. With Home Assistant and OpenHAB we benefit from their specific API support for providing speech to text output and processing through things like the HA Assist Pipelines[1].

From our standpoint we handle wake word, VAD+AEC+BSS, STT, TTS, user feedback, etc. All we really do is send the speech transcript to the Willow command endpoint (like HA) and speak+display the execution result. Other than all of the wild speech stuff and our obsession with speed and accuracy Willow is really quite "dumb" - think of it as a voice terminal.

OpenHAB has something similar but it's significantly more limited.

[0] - https://heywillow.io

[1] - https://developers.home-assistant.io/docs/voice/pipelines/

I'm the founder of Willow[0] (we use ctranslate2 as well) and I will be looking at this as soon tomorrow as these models are released. HF claims they're drop-in compatible but we won't know for sure until someone looks at it.

[0] - https://heywillow.io/

Shameless self-plug but with my project Willow[0] we have a management server implementation to deal with multiple devices, etc. We have a new feature called "Willow One Wake" that takes the incoming audio amplitude when wake word is detected and uses our Willow Application Server (python) to only activate wake on the device closest to the person speaking. Old and tired compared to the commercial stuff but a first in the open source space.

The asyncio improvements in Python 3.12 especially (plus perf generally) have been instrumental in enabling real world use of this. With Python 3.12 asyncio, uvloop, and FastAPI it works remarkably well[1]. As the demo video shows not only does it not delay responsiveness, it has granularity down to inches.

[0] - https://heywillow.io/

[1] - https://youtu.be/qlhSEeWJ4gs

For most people with self-hosting tasks amd64 is back as the way to go.

As you say, there are a ton of "minipcs" on the market that directly compete with the Raspberry Pi on cost and power usage. They're typically slightly larger but the expansion options (bring your own RAM/storage) plus real I/O (with real PCIe), disk, etc IMO significantly outweighs this. They're also typically more performant and while aarch64 platform support is increasing dramatically there are still the occasions where there's a project, docker container, etc that doesn't support it.

Taking it a step further, there are a TON of decommissioned/recycled corporate/enterprise SFF desktops on the market. They don't compete in terms of size (13" x 15" or so) but they can actually get close in power usage. Many of them have multiple SATA ports, real NVMe, multiple real half-height PCIe slots, significantly better USB and PCIe bandwidth, etc.

With my project Willow and Willow Inference Server[0] we're trying to drive this approach in the self-hosting community with an initial emphasis on Home Assistant. They're generally sick of Raspberry PI supply shortages, very limited performance, poor I/O, flaky SD cards, etc. The Raspberry Pi is still pretty popular for "my first Home Assistant" but generally once people get bitten by the self-hosting bug they end up looking more like homelab very quickly.

For Willow particularly we emphasize use of GPUs because a voice assistant can't be waiting > 10 seconds to do speech recognition and speech synthesis. There are approaches out there trying to kind of get something working using Whisper tiny but in our ample internal testing and community feedback we feel that Whisper small is the bare minimum for voice assistant tasks, with many users going all out and using Whisper large-v2 at beam size 5. With GPU it's still so fast it doesn't really matter.

The Raspberry Pi is especially poorly suited for this use case (and even amd64). We have some benchmarks here[1]. TLDR a ~seven year old Tesla P4 (single slot, slot power only, half-height, used for $70) does speech recognition 87x faster, with the multiple increasing for more complex models and longer speech segments. A 3.8 second voice command takes 586ms on the Tesla P4 and 51 seconds on the Raspberry Pi 4. Even with the Pi 5 being twice as fast that's still 25 seconds, which is completely unusable. Not fair to compare GPU to Raspberry Pi but consider the economics and practicality...

You can get an SFF desktop and Tesla P4 from eBay for $200 shipped to your door. It will idle (with GPU and models loaded) at ~30 watts. The CPU, RAM, disk (NVMe), I/O, etc will walk all over a Raspberry Pi anything. Add the GPU and obviously it's not even close - you end up with a machine that can easily do 10x-100x what a Raspberry Pi can do for 2x the cost and power usage. You can even throw a 2.5gb Ethernet card in another slot for $20.

Even factoring in power usage (10-15w vs 30, 2-3x) the cost difference comes down to nearly nothing and for many users this configuration is essentially future-proof to anything they may want to do for many years (my system with everything running maxes out around 50% of one core). Many also gradually grew their self-hosted situation over the years with people ending up with three or more Raspberry Pis for different tasks (PiHole, Home Assistant, Plex, etc). At this point the SFF configuration starts to pull far head in every way including power usage.

Users were initially very skeptical to GPU use, likely from taking their experience in the desktop market and assuming things like "300 watt power usage with a huge > $500 card". Now they love having a GPU around for Willow and miscellaneous other CUDA tasks like encoding/decoding/transcoding with Plex/Jellyfin, accelerated Frigate, and all kinds of other applications. Willow Inference Server (depending on configuration) uses somewhere between 1-4GB of VRAM so with an 8GB VRAM card that leaves for plenty of additional tasks. We even have users who started with the Tesla P4 and then got the LLM bug and figured out how to get an RTX 3090 working with their setup.

[0] - https://heywillow.io/

[1] - https://heywillow.io/components/willow-inference-server/#ben...

For the ESP32, an hero is in the process of adding LVGL to ESPHome. You can try it out now: https://github.com/esphome/esphome/pull/6363

Here's the (very good!) preview documentation: https://deploy-preview-3678--esphome.netlify.app/components/...

This is such a game-changer for me that I'll be using the ESP32 over the ESP8266 for any projects involving displays from now on.

Solid state relay is probably a bad idea with all the extra heat-sinking, extra cost, and chance of getting counterfeits.

I do this with ESPHome & a J115F21C12VDCS.9 relay (note only the NO side is rated for 40A resistive): https://i.imgur.com/MqqOkoY.png

Choose any of the temperature sensors here for air temperature sensing: https://esphome.io/

Configuration is so easy. For the sensor, just copy the config from here, for example: https://esphome.io/components/sensor/bme280. Add a gpio output (https://esphome.io/components/output/gpio) and a bang-bang climate controller (https://esphome.io/components/climate/bang_bang.html)

You might want to take a look at https://esphome.io/ for an easy integration of an ESP32/8266 into home Assistant.

You can do this with a $30 Sonoff S31 running ESPHome [0]. Since the Sonoff wall switch can run a ping sensor against your server you could create a watchdog automation right on the S31 to shut off the mains power to the S31 switch and turn back on after X seconds.

There are other ways you could have the S31 do operational checks but ultimately ESPHome is probably an interesting consideration and supported by tons of off the shelf hardware.

[0] https://esphome.io/

They're pretty great and compatible with most things. ESPHome [1] is a great resource for getting ESP32's working nicely with HA and you can find lots of projects using it to learn from.

You'll likely need to do soldering if you want to connect sensors, batteries and the like.

Personally I really like what SEEED Studio [2] does with their ESP32 boards and they have nice docs.

1. https://esphome.io/

Maybe you could set up ESPHome on the ESP32. It might make connecting those components easier, plus a decent web server built in. Then your app can be set up to access data provided by the ESPHome web server.

# # Setting pins for sda and scl will be required until https://github.com/esphome/esphome/pull/2970 is released

Probably an unpopular opinion, but for the simple stuff you may just want to use something like EspHome where you just need to create a yaml file. Once you’re comfortable with that maybe get into something a bit more advanced, but esphome make it a breeze. It integrates with home assistant if you already have that in place as well.

ESPHome