I’m not afraid of a little fabric 
@formatBCE – Thanks for all your work on this. Hoping to get reflashed and up and running tonight.
1 Like
Thank you!
I will give it a shot on my bambu printer and will let you know how I make out.
1 Like
I have just received my respeaker lite, updated the firmware to 1.09, and added it to esphome using the latest yaml from the formatBCE repo.
It respond to all voice commands fine, (plays a tts response on the media player) however, all of the entities including the media player in the esphome configuration are greyed out and unavailable.
However, the media player does goes to idle in the log when i say the wake word, and plays the tts when I ask a question.
All the time the media player entity in the configuration shows as unavailable.
I cannot use developer tools to play tts using this media player as it doesn’t show up
I tried reinstalling, but no change in this behavior.
Any ideas on how to make the media player entity ( and all the other entities) available for use?
Edit: the entities appeared on their own after about a hour! False alarm I guess.
Weird stuff, never experienced that. In any case, if I see something like this, I:
- reboot device
- reboot HA
It helps in 60% of cases
I noticed you updated the buttons and grill step files yesterday. What was changed?
Yeah they were too big, ugly made them a bit smaller.
Wow! what a great job you did on the case design!
And yes, music streaming sounds really good with the new firmware!
The mute button and associated sounds) work fine, but I am having some difficulty with pausing and restarting music via the front panel button. a single press will pause the music, but a second press starts the assistant instead of resuming the music.
perhaps it is only pausing but not resuming in the yaml logic?
btw is the wake word supposed to work when the media is playing? (It doesn’t on my device)
name: "User button"
on_multi_click:
- timing:
- ON for at most 1s
- OFF for at least 0.25s
then:
- if:
condition:
lambda: return !id(init_in_progress);
then:
- if:
condition:
switch.is_on: timer_ringing
then:
- switch.turn_off: timer_ringing
else:
- if:
condition:
lambda: return id(nabu_media_player)->state == media_player::MediaPlayerState::MEDIA_PLAYER_STATE_ANNOUNCING;
then:
- lambda: |
id(nabu_media_player)
->make_call()
.set_command(media_player::MediaPlayerCommand::MEDIA_PLAYER_COMMAND_STOP)
.set_announcement(true)
.perform();
else:
- if:
condition:
voice_assistant.is_running:
then:
- voice_assistant.stop:
else:
- if:
condition:
media_player.is_playing:
then:
- media_player.pause:
else:
- if:
condition:
and:
- switch.is_off: mic_mute_switch
- not:
voice_assistant.is_running
then:
- voice_assistant.start:
Thanks!
Yes, it’s not designed to start playback again. I don’t think ESP itself knows anything about the stream from HA/MA to resume playback. If it does, probably we could add pause->play behaviour. But guys from NabuCasa didn’t do it, and I think it’s for a reason.
My device does catch wake word while playing (though it’s much harder to achieve, I guess noise cancelation can’t cope with it).
P.S. I’m working on new enclosure right now, basing on Respeaker Lite with Devkit-C board instead of XIAO. It will fit XIAO variant too. I noticed that if I turn speaker to the bottom instead of front, it helps adding a bit of lower treble and reducing hight frequencies. So the sound is better with bottom-facing speaker. New enclosure will do that. As a consequence, I guess, it will help with recognizing wake word while it’s playing.
too bad, it would have been nice to have a resume feature.
Personally, I don’t see much need for microphone muting as it only responds to the wake word anyway, and the play buttonb is really just a hardware wake word.
Would it be possible to design a variant of the enclosure that uses the two buttons for volume up/down? I would find that more helpful.
There buttons are defined by XMOS board (at least mute, it can’t be reassigned).
Action button works same way it does for Nabu PE. You always can redefine it in YAML.
I tried to add other buttons with XIAO, but there’s no pins. I implemented resistance-based cradle with 3 buttons (action, vol+/vol-), but found it to be too hard to solder, place inside and calibrate.
Will try to add buttons to Devkit-C version - there’s plenty GPIO to use. But that’ll require separate 6x6 buttons I guess.
i cannot find the devkit-c variant on ali express.
Do you have a link to the new board?
I‘m currently trying to design a multi-sensor (temp/humidity, pressure, AQI, mmWave presence, …) board using an ESP32-S3. For this I need UART and I2C plus 2 more pins freely available.
Now I was thinking if it wouldn‘t be possible to also integrate mics and a speaker to use the board as a voice assistant as well.
I wasn‘t able to find exact details of the ReSpeaker Lite board and whether I have enough pins available?
Looking at the pinout of the chip itself, there are enough but checking the board layout I‘m not sure if they aren‘t used solely for the mics and speakers. Can someone shed a light on that, or has an idea of how it might be possible to add mics and speakers in an - more or less - easy way?
Respeaker Lite board takes a lot pins to work properly. Not all of them required, I guess, but I’m not sure on exact minimum for it to work.
You can check pinout in their repo: GitHub - respeaker/ReSpeaker_Lite
Also you can use any i2s speaker and microphone.
There are plenty tutorials out there to build voice with INMP144 mic and MAX98357 amplifier.
But still each of them needs 3 GPIO pins (WS, CLK and DATA). In this manner Respeaker can be better I guess, as it’s using duplex I2S connection, so requires 4 pins instead of 6. Which brings its own troubles, but they’re solvable…
Hi, my ReSpeaker Lite arrived this week and today I put everything together based on the information found in formatBCEs git repository (many thanks for your efforts). Everything, including the mute button, works nicely, except of the user button, which is “on” the whole time. The documentation says that mute button and user button have to be soldered. But since the mute button works without soldering, I want to ask what I have to do, before I damage anything.
1 Like
Physically mute button works. Soldering it to GPIO pin will add ability to mute/unmute from HA, programmatically.
USR button, on the other hand, doesn’t have any assignment at all, until you solder it to GPIO - then it becomes actual sensor in ESPHome, and all the logic written for it’s click starts to work.
Thanks for your input here!
Looking at the pinout in the repo, connecting an “external” ESP32 via a few lines to their board might be possible, but I am not sure without proper schematics.
I was hoping for an XMOS-compatible design, as it seems to work better with voice quality and can also process 48kHz, which makes more sense looking at it long-term.
I think you are right, my quick checks suggest better sound facing down. Please let me know when you have a prototype design I could test.
1 Like