willow
templates
willow | templates | |
---|---|---|
37 | 83 | |
2,376 | 309 | |
2.2% | - | |
9.6 | 9.2 | |
2 months ago | 6 days ago | |
C | HTML | |
Apache License 2.0 | Eclipse Public License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
willow
-
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...
-
Should I Open Source my Company?
> - 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/
-
Jarvis: A Voice Virtual Assistant in Python (OpenAI, ElevenLabs, Deepgram)
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!
-
Any “Google Home” type solutions that work offline?
Look into https://heywillow.io/ - still early in the project but they are getting good results.
- Open Source Smart Device
-
Home Assistant 2023.11
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/
-
Distil-Whisper: distilled version of Whisper that is 6 times faster, 49% smaller
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/
-
What's New in Python 3.12
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
- Show HN: Willow: the fastest and most private open source voice assistant
-
A Raspberry Pi 5 is better than two Pi 4S
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...
templates
- ESPHome
-
Custom on off times/Api
Setting two on/off cycles with 50 discrete schedules seems like a very inefficient way of doing this when the same thing could be accomplished with two rules. Any compatible device flashed with Tasmota or similar FOSS firmware would make this possible.
-
We made a database of Smart Switches
Have a look at https://templates.blakadder.com
- Exploitable Vulnerability CVE-2023-27217 Found in Wemo Smart Plug Mini V2 Home Device
-
Looking for a specific light switch solution.
Another WiFi based option is any compatible smart relay or switch flashed with Tasmota. In Tasmota, SwitchMode 15 decouples the switch state from the relay and sends status changes via MQTT to HA.
-
What component can I use to programmatically control a button press?
2) If you want to switch on/off the light switch in your room, your best bet is to replace your regular light switch with a WiFi light switch. (Yes, you must have some electrical knowledge to do this. But trust me, this is best, most reliable way.) See https://templates.blakadder.com/ for some good devices. Many of them can be re-flashed, so instead of using "their app", the light switch can be a web server that you can talk to from any computer on your network (including your laptop, your phone, etc).
-
recommend me Smart switcheees
If you're familiar programming ESP boards take a look at this repository of compatible devices.
-
Done... Ender 3 S1 is coming
Wifi switch, I suggest one that runs tasmota. Blakadder website seems to help.
-
Smart plug toggles power when it loses MQTT connection
I cannot find the correct model for this plug. On the back it says "WiFi Smart Plug / TWSP017" but I cannot find any reference to this online. I looked at the (long) list of pictures of plugs and sockets at the templates.blakadder.com site, but without finding anything that looks quite like it. There is one power socket, one LED (that never seems to be lit) and one button on the left side. It is a square shape with rounded corners; too generic a description to be useful I'm afraid.
-
Should I ditch WiFi for Zigbee if I'm getting my devices from Aliexpress?
You mention incompatibilities. I am not 100% what you mean but here's a link of Zigbee2Mqtt supported devices and Heres a list of tasmota supported devices . i'd reference these before buying anything.
What are some alternatives?
piper - A fast, local neural text to speech system
Tasmota - Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
esp-box - The ESP-BOX is a new generation AIoT development platform released by Espressif Systems.
esphome - ESPHome is a system to control your ESP8266/ESP32 by simple yet powerful configuration files and control them remotely through Home Automation systems.
mycroft-core - Mycroft Core, the Mycroft Artificial Intelligence platform.
localtuya - local handling for Tuya devices
rhasspy3 - An open source voice assistant toolkit for many human languages
ESP8266-HTTP-IR-Blaster - ESP8266 Compatible IR Blaster that accepts HTTP commands for use with services like Amazon Echo
vllm - A high-throughput and memory-efficient inference and serving engine for LLMs
mgos-to-tasmota - A minimal firmware for OTA (over the air) flashing Tasmota, HAA, or ESPurna from Mongoose OS or compatible firmware types.
willow-inference-server - Open source, local, and self-hosted highly optimized language inference server supporting ASR/STT, TTS, and LLM across WebRTC, REST, and WS
espurna - Home automation firmware for ESP8266-based devices