// DESIGN
Design Decisions
The technical choices behind OMEGA, and why they were made. Each decision here has a reason — some obvious, some the result of significant pain.
Running Home Assistant OS directly on Proxmox rather than in a container or on a Pi gives full HA functionality, easy snapshots, and the ability to run other workloads on the same hardware without compromise.
A Raspberry Pi is the default recommendation. It’s also a single point of failure
on underpowered hardware with an SD card that will eventually die. The NiPoGi P2
runs Proxmox, HAOS gets a dedicated VM with full hardware passthrough where needed,
and the whole thing snapshots cleanly before any major change. Boring infrastructure
done right.
Cloud-dependent WiFi devices (Govee, Ring, Tado) are being systematically replaced with Zigbee. Local control, no subscriptions, works when the internet doesn't.
The trigger was a single incompatible light. The conclusion was that the entire
approach was wrong. WiFi smart devices almost universally require cloud accounts,
have opaque privacy policies, and can be bricked by a vendor decision. Zigbee with
a local coordinator (SONOFF Zigbee 3.0 USB Dongle, EFR32MG24) and Zigbee2MQTT
means the devices speak to HA directly. The SONOFF S60ZBTPG smart plug controlling
the 3D printer is the first production Zigbee device on the network.
Wake word processing runs on the ESP32-S3 itself using micro_wake_word. Audio never hits the network until after the wake word fires.
Server-side wake word detection via the openWakeWord add-on was the obvious path.
It also turned out to be a dead end — openWakeWord v2.0.0 removed preload model
support, making the server-side approach unreliable for ESPHome satellites on
current HA versions. On-device micro_wake_word is architecturally cleaner anyway:
the microphone data stays on the chip until you’ve deliberately invoked the assistant.
Both the microphone (ES7210) and speaker (ES8311) share a single I2S bus with the ESP32-S3 driving all clocks. The two-bus secondary/slave topology causes persistent hardware timeouts on this board.
The reference configs floating around for this hardware use a two-bus topology
with the ESP32-S3 in secondary/slave mode. That approach produces persistent
ESP_ERR_TIMEOUT errors on mic reads — the hardware simply doesn’t behave as
documented. A single shared i2s_shared bus with the ESP32-S3 in primary mode,
driving MCLK, BCLK and LRCLK, is the confirmed working topology.
A 500ms boot delay prevents LED automations crashing before the API server is ready. Wake word detection starts after 30 seconds to allow I2S bus stabilisation.
Two separate timing issues, two separate fixes. Without the boot delay, LED
automations fire before the API server initialises and crash the device on first
flash (but not on restart, which makes it a fun one to diagnose). The 30-second
wake word delay gives the I2S bus time to stabilise before micro_wake_word starts
polling — skipping it produces unreliable detection on cold boot.
8MB PSRAM must be explicitly enabled on the ESP32-S3 board. Without it, API connection instability occurs regardless of other configuration.
This one is not obvious from the hardware docs and not consistently mentioned in
community configs. The Waveshare board has 8MB PSRAM. Without it enabled in ESPHome
(mode: octal, speed: 80MHz), the API server becomes unstable under the memory
pressure of running audio processing and wake word detection simultaneously.
Enable it. Don’t skip it.