Device LED Control


Coming from Snips, I miss a feature that was awesome : control the device (respeasker, matrix etc) LEDs to have a visual feeback of what rhasspy is doing. Listening, wake word detected, thinking, speaking, etc

Here is the repo that works awesome on snips. It is bases to listening to hermes mqtt topic, so we would find another way, but integrating it into the Rhasspy Core with some settings in the UI to activate it would be just amazing.

Some infos on which topic does what :


1 Like

I think this would just work with Rhasspy if Rhasspy would publish all the Hermes MQTT messages that snipsLedControl needs.

1 Like

Agree, but I think it would be cumbersome to have rhasspy post to a mqtt topic, when it could just handle this directly, internally, being enabled in settings for all users using respeakers, matrix and such. If we can live without mqtt, could be better.

1 Like

I agree with @koan

Using a centralized message bus (Websockets, MQTT, HTTP2) and a protocol like Hermes/Hermod allows for a more modular approach.

Rhasspy could be more easily splitted into isolated modules (wake word, asr, nlu, dialogue, tts, etc.) that do not have to be in the same process. It would probably help with code maintenance.

Everyone could use his/her own implementation of some part of the system. For example, I want to use the wake word, audio server and ASR but I want to do my own NLU, no problem. I just have to handle the part of the Hermes protocol required for this myself.

It will be easier to add new modules/components (Led control for Respeaker or Matrix, Intent Handlers for HA, Jeedomor OpenHAB, Sensors, etc.) without having to change or implement additional stuffs in a single bloated system (microservices anyone?).

Also, using a centralized message bus will surely help for a Base/Satellite configuration.

As you may have guessed, I would really like Rhasspy to fully embrace the Hermes protocol :slight_smile:

What do you guys think?


I’m a big believer in MQTT, and using a protocol like Hermes would make it easier to modularize Rhasspy even further, indeed. At first I was reluctant to go the Hermes route for Rhasspy, because Snips hasn’t even published the protocol in full, but we have to start somewhere and I agree that Hermes is a good starting point. As a bonus, programs like snipsLedControl should work with Rhasspy when we reach enough compatibility with Snips. In the longer term we’ll probably have to diverge further from the Hermes protocol, like Hermod has done.


Yes you’re right, but then we would indeed need to plug different things on mqtt to get rhasspy more modular, and make mosquito and its dependencies installing right with rhasspy from scartch.

1 Like

Maybe Rhasspy can provide a builtin simple Websocket server (like today but with a single endpoint) that publish and receive the Hermes protocol events and provide an option to use an MQTT external server instead?

Abstracting the communication layer (Websocket/MQTT) should not be hard.

1 Like

That can be solved easily by installing Mosquitto together with the Rhasspy services in a Docker Compose file for people who want an all-in-one install.

1 Like

I really like docker so … :slight_smile:

1 Like

Nah, me don’t :innocent:

Would be a great feature. Also great if it would apply for standalone Matrix voice with the ESP.

1 Like

This is exactly my plan. I can expose websocket endpoints that mirror the Hermes topic structure that you can send/receive to. Internally, Rhasspy will merge all messages and publish to both MQTT and Websockets. Additionally, we can have a set of Hermes HTTP endpoints that you can POST to.


I’m wandering if a single websocket endpoint with all events is not easier to work with…

With a single endpoint if I want to react to multiple events, I won’t have to create multiple connections. It should also avoid the cost of opening/closing/maintaining multiple connections.

It will be easier to handle and mimick an MQTT broker behavior without the additional overhead of running an actual broker.

For the advanced users that want to use MQTT, Rhasspy could indeed listen and forward these websocket events to and from an external MQTT broker.

1 Like

Just throwing my vote in here that device LED control should be something that gets in here sooner than later. It seems a bit silly but it’s such a valuable piece of feedback that, for better or worse, we’ve all become used to thanks to Google, Alexa, etc.


Hey folks, not as technical as y’all, but if the seeed speaker connects to the GPIO of say a “client” pi3, would it not be possible to serve up the addresses of those LEDs to the Rhasspy system?
Some use HA web socket, some use MQTT, some node-red. So I’m guessing (and someone may have already said this WAYYY more elegantly), that if Rhasspy can access the LEDs, then a user (however they build their network) can utilize them.
Wake work (lights up)
Heard me (ring lights)
Actioned (flashes)

For me this is the missing piece of the puzzle to evict alexa :wink: (well that and a 3D printed case for it all)