Cannot disable listen for wakeword

Rhasspy version: Rhasspy 2.5.0 docker rpi4

when i use the API
curl -X POST “” -H “accept: /” -H “Content-Type: text/plain” -d “off”

i get this

[DEBUG:2020-06-15 14:38:03,533] rhasspyserver_hermes: Publishing 38 bytes(s) to hermes/hotword/toggleOn
[DEBUG:2020-06-15 14:38:03,533] rhasspyserver_hermes: -> HotwordToggleOn(site_id=‘salon’, reason=‘tv_on’)
[DEBUG:2020-06-15 14:38:03,532] rhasspyserver_hermes: Publishing 38 bytes(s) to hermes/hotword/toggleOff
[DEBUG:2020-06-15 14:38:03,532] rhasspyserver_hermes: -> HotwordToggleOff(site_id=‘salon’, reason=‘tv_on’)

I have a toggleOn immediately after the toggleOff and Rhasspy continues to detect the wakeword. Why?
I would like rhasspy to stop listening.

sorry for my English and thanks Google :smile:
Thanks for your help.

i got the same problem.

I tried to disable the wakeword over MQTT with
{“siteId”: “J4-K4”, “reason”: “xyz”}

and also over http with

I’m watching the MQTT topics:

if i’m using mqtt method, nothing happens, but the wakeword is still active and works.
after reading the code, i found out, that i have to use
{“siteId”: “J4-K4”, “reason”: “”}
it seems that i can’t use a custom string for a reason.
If using that method, i can disable the wake word detection! =)

if i’m using the http api, i get the
hermes/hotword/toggleOff {“siteId”: “J4-K4”, “reason”: “”}
and immediately an
hermes/hotword/toggleOn {“siteId”: “J4-K4”, “reason”: “”}

Yes, the only supported reasons for hermes/hotword/toggleOn and hermes/hotword/toggleOff are:

    Overrides all other reasons
    Dialogue session is active
    Audio is currently playing
    Text to speech system is currently speaking


DIALOGUE_SESSION = "dialogueSession"
PLAY_AUDIO = "playAudio"
TTS_SAY = "ttsSay"

See rhasspyhermes/

Is there a reason why you would like to use a custom string for the reason? Are you using this string in other code?


I have exact same problem with a command that worked nice previsouly

without specifying a reason (which worked nice before)

[DEBUG:2020-11-15 15:19:55,278] rhasspyserver_hermes: Publishing 33 bytes(s) to hermes/hotword/toggleOn
[DEBUG:2020-11-15 15:19:55,278] rhasspyserver_hermes: -> HotwordToggleOn(site_id='salle', reason=<HotwordToggleReason.UNKNOWN: ''>)
[DEBUG:2020-11-15 15:19:55,275] rhasspyserver_hermes: Publishing 33 bytes(s) to hermes/hotword/toggleOff
[DEBUG:2020-11-15 15:19:55,274] rhasspyserver_hermes: -> HotwordToggleOff(site_id='salle', reason=<HotwordToggleReason.UNKNOWN: ''>)

If I specify a supported reason, doesn’t work eigher

url = 'http://%s:12101/api/listen-for-wake?siteId=salle&reason=dialogueSession'%host

[DEBUG:2020-11-15 15:25:54,449] rhasspyserver_hermes: Publishing 48 bytes(s) to hermes/hotword/toggleOn
[DEBUG:2020-11-15 15:25:54,449] rhasspyserver_hermes: -> HotwordToggleOn(site_id='salle', reason='dialogueSession')
[DEBUG:2020-11-15 15:25:54,442] rhasspyserver_hermes: Publishing 48 bytes(s) to hermes/hotword/toggleOff
[DEBUG:2020-11-15 15:25:54,442] rhasspyserver_hermes: -> HotwordToggleOff(site_id='salle', reason='dialogueSession')

So how to disable wakeword, with or without a supported reason, now ?

And why no custom reason ? When disabling/enabling wakeword from different points we could get a trace of what/why disabled it.

Yes same problem, don’t work with API

But work with Mqtt.
mosquitto_pub -h $1 -p $2 -t ‘hermes/hotword/toggleOff’ -m ‘{“siteId”: “chambre”, “reason”: “”}’

Is this has been fixed in 2.5.8 ?

PS : just tested, and still got same bug.

Seems I have exact same problem with mosquitto

from subprocess import call
call('mosquitto_pub -h %s -p 1883 -t "hermes/hotword/toggleOff" -m \'{"siteId": "studio", "reason": ""}\''%host, shell=True)

wakework still get detected

mqtt explorer:

Capture d’écran 2020-11-27 182633

rhasspy UI log:

[DEBUG:2020-11-27 18:28:45,848] rhasspyserver_hermes: Publishing 34 bytes(s) to hermes/hotword/toggleOn
[DEBUG:2020-11-27 18:28:45,847] rhasspyserver_hermes: -> HotwordToggleOn(site_id='studio', reason=<HotwordToggleReason.UNKNOWN: ''>)
[DEBUG:2020-11-27 18:28:45,840] rhasspyserver_hermes: Publishing 34 bytes(s) to hermes/hotword/toggleOff
[DEBUG:2020-11-27 18:28:45,838] rhasspyserver_hermes: -> HotwordToggleOff(site_id='studio', reason=<HotwordToggleReason.UNKNOWN: ''>)


will all previous rhasspy version I used:
call('sudo curl -d "off" http://%s:12101/api/listen-for-wake'%host, shell=True)

Always workd flawlessly … :confused:

v2.5.8 docker

mosquitto_pub -h $1 -p $2 -t ‘hermes/hotword/toggleOff’ -m ‘{“siteId”: “chambre”, “reason”: “”}’
Ok with v2.5.8 docker


Doing the same, and it does toggle on back immediately.

When you toggle off and say the wakeword does it indeed never trigger ?

Ah, sending through api seems to work

url = 'http://%s:12101/api/mqtt/hermes/hotword/toggleOff'%host
payload = '{"siteId": "salle", "reason": ""}', payload)

Is there a way to know if wakeword is activated or not ?

le wake word est réellement Off je dois le remettre à On pour qu’il fonctionne à nouveau.

mosquitto_pub -h $1 -p $2 -t ‘hermes/hotword/toggleOn’ -m ‘{“siteId”: “chambre”, “reason”: “”}’

Je ne sais pas si il y à un moyen de vérifier si le wake word est On ou Off avec Rhasspy. mais avec le plugin mqtt sous jeedom on peut executer un sénario lorsque les évenements hermes/hotword/toggleOn ou hermes/hotword/toggleOff sont publiés pour le site concerné.

the wake word is really Off I have to reset it to On for it to work again.

mosquitto_pub -h $ 1 -p $ 2 -t ‘hermes / hotword / toggleOn’ -m ‘{“siteId”: “room”, “reason”: “”}’

I don’t know if there is a way to check if the wake word is On or Off with Rhasspy. but with the mqtt plugin under jeedom we can run a scenario when the hermes / hotword / toggleOn or hermes / hotword / toggleOff events are published for the site concerned.

Ok, finally get it working.

So in case anyone need HLC button to disable/enable wakeword:

def onButton1(self, *args):
		#mute hotword detection:
		if self.muted:
			self.muted = False
			topic = "hermes/hotword/toggleOn"
			self.muted = True
			topic = "hermes/hotword/toggleOff"

		payload = '{"siteId": "'+self._controller._mainClass._me+'", "reason": ""}'
		self._controller._mainClass._mqttClient.publish(topic, payload)

Anyway, api/listen should be fixed.


Should be fixed in the next update. Thanks! :+1:

1 Like

As we can now easily disable/enable wakeword listening with respeaker button or api, is there a way to get the listening state ? Can we know if wakeword is enable or disable ?

Why not allow GET on /api/listen-for-wake ? And get a 0 / 1 response ?

Thanks for all the hard work :wink:

@synesthesiam ? Would it be possible ?

is there anything new?


_________ :beers:

This is possible, but has some complications. The GET could simply return what Rhasspy’s HTTP server believes is the current wakeword state (enabled or disabled). But if the wake word service is restarted, it and the HTTP server could be out of sync.

I’ll go ahead and implement this simple version, since I think it will be rare for the out-of-sync problem to occur:

The “best” solution would be to create a have the HTTP server ask the wake word service about its current state and wait for a response. That would require a new MQTT message or two and some timeout. Plus, it wouldn’t work with satellites that are only connected over HTTP :frowning: