LEDs stuck on, but all services are running, no errors in the services

[1liminal1]

Pi Zero 2 W with Keyestudio 5V ReSpeaker 2-Mic Pi HAT V1.0

Seems to crash in listening mode. But I cant see any errors from

journalctl -u enhanced-wyoming-satellite.service

I actually cant see any errors in any of the related services, just wont respond until I restart the service, but then crashes again.

Any ideas where to start looking?

[jerblack]

I ran into pretty much the same thing and ended up creating a script to turn the lights off, and made that script run on every conversation finish and error.

sudo apt install python3-pip 
pip install apa102-pi
git clone https://github.com/respeaker/mic_hat.git
cd mic_hat/interfaces
nano lightsoff.py

And the lightsoff.py I adapted from an example looks like this

import RPi.GPIO as GPIO

from pixels import pixels

GPIO.setmode(GPIO.BCM)
GPIO.setwarnings(False)
GPIO.setup(5, GPIO.OUT)
GPIO.setup(6, GPIO.OUT)
pixels.off()

And then I have a line in my tts_end script that calls python3 ~/mic_hat/interfaces/lightsoff.py. I call that script in my wyoming-satellite arguments for --tts-stop-command, --error-command. This addressed the issue for me, and now it shuts the light off no matter if the conversation ended successfully or not.

Having said all that, this is not optimal and shouldn't be necessary. Right now it looks like the LEDs don't shutoff when an error is received at the end of exchange and that should probably be fixed. It would also be helpful to have a user accessible endpoint into the wyoming-event service that gave us more direct control of the lights. I'd like to be able send TTS announcements to the MPD instance on my satellite and turn on the LED while it's speaking. Is this possible?

[1liminal1]

Hey, sorry its taken a while to respond. Thanks so much for that info :)

Ive actually just wiped the SD card and am going to start again and see how it goes.

Did you find a more perm solution, or get to the bottom of the actual issue?

Thanks again

[llluis]

Right now it looks like the LEDs don't shutoff when an error is received at the end of exchange and that should probably be fixed. It would also be helpful to have a user accessible endpoint into the wyoming-event service that gave us more direct control of the lights.

The satellite itself and the leds are different "entities", it's not an integrated product per se, and the user must customize it to behave like wanted or to handle all error scenarios. There's no fix to be made, just improvements. ;) However, it's hard to do it right now without any programming knowledge to modify the event service and control the leds. The existing code is the bare minimum as an example only.

One solution could be to create an script similar to- what you did to receive a color parameter and send to the leds. This script could then be called modifying the command line of the satellite. This would allow to control the leds without any programming skill. You would have to indicate the LED status for each of the events described in https://github.com/rhasspy/wyoming-satellite?tab=readme-ov-file#event-commands

I'd like to be able send TTS announcements to the MPD instance on my satellite and turn on the LED while it's speaking. Is this possible?

Yes and no. :) It can't be done right now using MPD as we are not able to capture the events of this. However, I did implement the media_player entity for the wyoming integration, which would allow to send TTS to the satellite without MPD and be able to capture the events to control the leds. This is in test right now and it could take a while to make the cut to the main branch of Home Assistant.

[TomasKliner]

Solution, that worked for me

I managed to solve it after enabling logging for the wyoming integration and looking through the home assistant logs.