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?