Elecrow-CrowPanel-Advance-7.0-HMI-Voice-assistant-and-control-panel-HA

Control panel and voice assistant running on crown panel 7 advance v1.2.The project is not completely perfect, some adjustments are still needed, but it works.
I combined these two things:

All credits to the authors

Hi - thanks for sharing this - its given me a good starting point for the CrowPanel Advance 5“ HMI that I just got

My board is a v1.2, and with your asistent7.yaml file which has the mic in PDM mode, I was able to get "ok nabu" to trigger the voice assistant. But the display itself goes all flickery as soon as I set the micro_wake_word to on while the wake word engine is local, even if mic is muted. Did you see anything similar in your testing, or have any suggestions how else I could deal with it?
(I also found that I could not use the advance features and set the psram to 120MHz - I don't know if things are just running too slow for it to all work)

The flickering when local micro_wake_word is enabled is a known-ish symptom, not really a mic issue. Here’s what I’d try, in order:

1. Revert PSRAM to 80MHz
This is very likely your main culprit. 120MHz Octal PSRAM is only reliably supported on boards with specific strapping/trace tolerances, and board revisions (v1.2 vs later) can differ enough that 120MHz just isn’t stable. Set it back to:

yaml

psram:
  mode: octal
  speed: 80MHz

Test wake word again with just this change first — it often resolves the flicker on its own.

2. Check CPU frequency
Make sure you’re running full speed:

yaml

esp32:
  cpu_frequency: 240MHz

3. If flicker persists — reduce contention between LVGL and the wake word model
Both LVGL’s framebuffer and micro_wake_word’s tensor arena live in PSRAM and compete for bus bandwidth. Try:

  • Increasing the LVGL update_interval slightly so display refresh has more headroom
  • Checking whether double buffering is enabled for the display — if PSRAM budget allows, it can smooth things out; if PSRAM is tight, disabling it can also help (worth testing both ways)

4. Core pinning (ESP-IDF framework only)
If you’re building with esp-idf rather than Arduino, the mic I2S task and LVGL task can end up on the same core. This isn’t something you set directly in ESPHome YAML, but if the above doesn’t fix it, it’s worth checking sdkconfig options for task/core affinity.

Start with step 1 — I’d bet that alone fixes most of it. Let me know how it goes.

You can find more examples for the panel there: xiaozhi esphome and xiaozhi esphome.

I already see a clear error, the yaml is for v1.3!!! yours is 1.2
use this

 esphome:
  name: asist23
  friendly_name: "asistent 1"
  min_version: 2025.5.0
  name_add_mac_suffix: true
  platformio_options:
    build_flags: "-DBOARD_HAS_PSRAM"
    board_build.esp-idf.memory_type: qio_opi
    board_build.flash_mode: dio
  on_boot:
    priority: 600
    then:
      - lambda: |-
          uint8_t cmd_backlight[1] = { 0x10 };
          id(bus_a).write(0x30, cmd_backlight, 1);
          uint8_t cmd_spk[1] = { 0x18 };   // vypnutý na startu
          id(bus_a).write(0x30, cmd_spk, 1);
      - delay: 300ms
      - script.execute: draw_display
i2c:
  sda: 15
  scl: 16
  scan: true
  id: bus_a

i2s_audio:
  - id: i2s_spk_bus
    i2s_lrclk_pin: GPIO6
    i2s_bclk_pin: GPIO5

  - id: i2s_mic_bus
    i2s_lrclk_pin: GPIO2
    i2s_bclk_pin: GPIO19

microphone:
  - platform: i2s_audio
    id: box_mic
    i2s_audio_id: i2s_mic_bus
    i2s_din_pin: GPIO20
    adc_type: external
    bits_per_sample: 24bit
    channel: left
    mclk_multiple: 384

speaker:
  - platform: i2s_audio
    id: box_speaker
    i2s_audio_id: i2s_spk_bus
    i2s_dout_pin: GPIO4
    dac_type: external
    sample_rate: 16000  
    bits_per_sample: 16bit
    channel: mono
    buffer_duration: 200ms
    timeout: 1000ms