I have a device with an ESP32, mic, speaker, that I used to be able to use as Speaker (for voice agent) and Media Player. That was very nice.
An update complicated things (for me) in that I could no longer have both easily like before, and I had to use some kind of mixer, but after some work that also seemed to work.
Then another update made it impossible to build it as such on ESP32 and would require ESP32-S3, so I had to give up the media_player functionality.
All the while things were optimized, made better, smaller, faster, etc.
By (un?)luck, I once noticed that at startup some RGB LED was being set to something, but I have no RGB LED either on the board, or in YAML.
This made me think that non core functionality was baked into either the speaker, or media_player, that not everybody wants or needs, at the expense of requiring more capable HW.
Also, I’m thinking that’s not the only thing that may have been added; it was just the thing I noticed.
I spent a lot of time (and used nice loudspeakers) making my devices, and something with a microphone and a speaker should be able to do both.
Is it possible to remove what doesn’t belong there, so anybody that needs it (like an RGB LED but maybe not only) can add it themselves, AND it can be again both media_player and speaker?
One of the great things about Esphome is devices do not need to be updated, they will just carry on working. I have 3 esphome devices i drag out at Xmas to do the lights, they have not been updated for at least 5 years and just work.
With your device, install and older version of esphome and install your devices firmware from there and it will no doubt work again.
@Arh That may be so with simple things, but I think more complex things need updating.
Also, new features, etc benefit from updating the builder, and it’s not OK to have to install an old version just to modify an old thing.
And I don’t see any reason to bake things in where not needed.
Why? If certain thing works can be most complex piece of hardware and still doesn’t need to be updated. Only update if you add new functions or change/update existing ones, never “just because you can”!!!
And, as always: READ changelog BEFORE updating! It’s all there… especially read breaking changes.
I think you need to realise that you were creating a device using parts of esphome that were in development, and updating to keep up with the developments meant you would need to use the hardware recommended for media stuff in the docs.
As I said it would still work if you had not updated it.
My ESPhome devices connect to Home Assistant. Sometimes Home Assistant changes in ways that may need devices connecting to it to be updated. I think the voice assistant may be like that.
Also, one reason they make BIOS updates for PCs is they discover ways to make things better, faster, safer. Same may apply here.
Also, like I said, I may need to add/change the old device.
Also, none of you explain why things like (maybe not only) RGB LEDs have to be baked in, likely on some fixed pin(s), when they can be added through YAML.
It’s even possible that whatever pins are (maybe) dedicated to the RGB LED(s) can’t be used for other stuff that I may already be using.
So please stop repeating the same “you don’t have to upgrade” thing; there are many reasons to upgrade, and I can’t see ANY to add things that may not be needed into the build.
I used board type “esp32dev” which, AFAIK has no RGB led. If I have none in my YAML code; the build should not include any.
@Arh You don’t know if my voice satellite (or whatever it would be called) would still work.
Just because simple devices that turn lights on/off, maybe even send other control bytes continue to work, doesn’t mean everything would continue to work.
I know MQTT devices would work, but things that talk to the API or whatever it may be called here need updating when API changes.
Why do they list “braking changes” in many types of updates?
Hm… never happened to me on any of my 50+ devices in all these years using esphome and HA. Yes, there were some warnigns (especially for btproxy), but i could simply disregard them and device would work on.
Can you post that line.
There’s not RGB-led config on boards.py for esp32dev.
Some other boards have though.
@Karosm Thank you for looking into this; here are a few lines around it, and in fact it’s not at startup, but every time I use it:
[14:15:49.744][D][voice_assistant:795]: STT started
[14:15:49.862][S][light]: ‘Assisting LED’ >> ON
[14:15:49.862][S][light]: Brightness: 100%
[14:15:49.862][S][light]: Red: 100%, Green: 100%, Blue: 100%
[14:15:50.735][D][voice_assistant:773]: Event Type: 11
I don’t think it’s relevant that other boards have it. They may have many other things that shouldn’t be built in.
I’m pretty sure that is configured in yaml. Some package, external component…?
You didn’t include what you are using for your YAML. Presumably you are using something related to this: Home Assistant Voice Preview Edition - Home Assistant
Note the Preview Edition. That means it isn’t a final version and there are likely to be breaking changes until it gets to a real stable release.
Also note the picture, which shows a device with a light ring
The block diagram also clearly shows a WS8212 string, so I expect that it is configured by default.
Months (maybe a year or more) ago I made the decision to wait to use this component because I didn’t want to take the time to follow it closely enough to make it work and keep it working.
The YAML. I tried many things. Arduino, ESP-IDF… speaker only, media_player only…
esphome:
name: "espvoice2"
friendly_name: ESPvoice2
esp32:
board: esp32dev
framework:
type: arduino
# type: esp-idf
# version: recommended
logger: # Enable logging
baud_rate: 115200
level: DEBUG
# level: VERY_VERBOSE
api: # Enable Home Assistant API
encryption:
key: "***"
ota:
- platform: esphome
password: "***"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
fast_connect: on
ap: # Enable fallback hotspot (captive portal) in case wifi connection fails
ssid: "Espvoice2Hotspot"
password: "***"
manual_ip:
static_ip: 192.168.0.***
gateway: 192.168.0.1
subnet: 255.255.255.0
dns1: 1.1.1.1
dns2: 8.8.8.8
i2s_audio:
i2s_lrclk_pin: GPIO15 # MIC-WS SPK- LRC
i2s_bclk_pin: GPIO17 # MIC-SCK SPK- BCLK
microphone:
- platform: i2s_audio
i2s_din_pin: GPIO27 #sd
id: inmp441_mic
adc_type: external
pdm: false
sample_rate: 16000
bits_per_sample: 32bit
channel: left
#media_player:
speaker:
- platform: i2s_audio
id: big_speaker
dac_type: external
i2s_dout_pin: #DIN
number: GPIO16
allow_other_uses: true
# Next for Speaker only
channel: mono
# Next for MediaPlayer only
# name: ESPvoice2 Media Player
## mode: mono
# on_pause:
# then:
# - media_player.stop
voice_assistant:
microphone: inmp441_mic
# media_player: big_speaker
speaker: big_speaker
# use_wake_word: false
noise_suppression_level: 2
auto_gain: 31dBFS
volume_multiplier: 0.2
on_listening:
- light.turn_on: response_light
on_end:
- light.turn_off: response_light
binary_sensor:
- platform: gpio
id: voice_switch
name: Voice Switch
pin:
number: GPIO14
inverted: true
mode:
input: true
pullup: true
on_press:
# - media_player.stop
- voice_assistant.start:
silence_detection: false #Jan'24
on_release:
# - delay: 7s # Add a small delay to ensure audio processing is complete
- wait_until:
not:
voice_assistant.is_running:
- voice_assistant.stop
light:
- platform: binary
id: response_light
name: "Assisting LED"
output: onboard_led
output:
- id: onboard_led
platform: gpio
pin: GPIO22
inverted: true
- id: I2SoutToEliminateNoise
platform: gpio
pin:
number: GPIO16
allow_other_uses: true
captive_portal:
@neel-m EXACTLY!
I think they baked in code for their own device, without consideration for those that don’t need light rings and who-knows what else.
Voice Assistant (satellite?) existed/could be made before they made that device, and they should respect that while I’m sure theirs looks and likely works much better than mine; not everybody wants such fancy stuff.
That audio-processing must make things much better but i can’t justify paying for it.
So they should remove everything that’s not in the minimal configuration for such a device.
A plain ESP32 without PSRAM, etc could handle this work very well, as indeed it did.
looks like it is related to this open issue with logging:
You are using light and it appears to have some broken logging. Does not appear to be anything to do with voice assistant.
The bug code HAS RGB. mine doesn’t.
I said it’s Speaker (or media_player), not the voice assistant itself, but I think that’s the only place it might be used; I’m not sure. It can also just announce things, I suppose, but I spent long time trying to play media on the speaker, to no avail.
I don’t even know why separate “things” are needed, as they both afaik play “media”.
Esphome is literally created device firmware.
It’s not for lite of heart
I’m not sure what that’s supposed to mean.
Can you be more verbose, like for “lite of heart” people?
WHAT device do YOU actually have ? I see that others have assumed that it is a HA Voice Preview Edition, but you never said that. Is it a custom built device ?
Is this the same device but with upgraded CPU, or are you confusing several devices ?
What firmware are you running on the device ? Is it firmware that came with your device, firmware you have assembled, or firmware from some other device ?
The yaml you finally uploaded includes a light: component connected to onboard_led on GPIO22, and turned on and off in the on_listening: and on_end: actions under voice_assistant:.
I think you have one device, and are complaining that the firmware for a different device is not working as you expect. Do you often buy a pants suit in a shop, then complain that the skirt is too long, and it’s not the correct color ?
esphome is NOT a “it just works” kind of product/thing. Don’t get me wrong, it is great. esphome makes it MUCH easier to create device firmware. But, creating device firmware is still an incredibly hard job for anything more complicated than blinking an LED.
Perhaps this post will help you get more help: