Ability to not reject unrecognized speech to text

I have tried both open transcription and custom recognition modes with Kaldi and prefer the recognition rate with custom. I am primarily using Rhasspy for home automation.

I am sending all of the recognition results to node-red via MQTT to act upon them.

In node-red I am able to communicate with Alexa. What I would like to do is have any command that is not recognized by Kaldi still sent to node-red but it seems that if Rhasspy receives a command that it does not recognize it issues an error tone and does not send it to MQTT.

If there a way for me to use custom recognition and yet have no commands be rejected?

What topics are you listening on on MQTT?
There should be a message on: hermes/nlu/intentNotRecognized


Sorry about the late response.

I am watching hermes/intent/# in node-red but I do not think that is the problem?

I want Rhasspy to NOT reject any speech because it does not recognize it. I want it to send all speech to node-red. What is happening now is that if Rhasspy does not recognize the command then it issues a ‘boink’ and does not send the command to MQTT.

I did try the hermes/nlu/intentNotRecognized and that worked to receive the command but the translation was not even close.

Yes it does, in the topic hermes/nlu/intentNotRecognized

What do you mean with translation not even close?

Thanks. Yes, I do see it in hermes/nlu/intentNotRecognized, but the text that gets translated is not very accurate. For example, I asked “What is the population in Minneapolis” and I got something about Manilla.

BTW, I am just starting down this path. So learning as I go along.

yeah well, that is basically why the intent was not recognized :wink:
If you do not have created sentences for command, translation will not be accurate.

I think that I can figure out my solution now. Is there a way to tell Rhasspy to not issue the error sound when a command is not recognized?

Sure, just remove it from Error WAV in the settings

That was too easy. Thanks!!

Note - also wrt. to

(I am interested as well). There’s two places where intentNotRecognized messages can be received. Besides the already mentionned nlu topic, there’s also hermes/dialogueManager/intentNotRecognized. This has one advantage and one disadvantage: There, the siteId seems to be included, but it’s only delivered in case the session had been started with the init.sendIntentNotRecognized-flag.

@romkabouter: Is there any option to enable to get also the siteId information included in the “generic” nlu topic? It’s mentionned in the docs, but effectively at least partly not there (tested in my standard environment, default NLU option active, when using the mobile app to send in some arbitrary written text).

To have the siteId info available whenever possible imo would be really helpfull, as otherwise one could not really decide on what to do with which message, e.g. to “whom” to forward any information requested from “alexa”…?

I am not sure which topic you refer to with this?
All the hermes/nlu/# topics have the siteId property. On which topic did you miss it?

Also, it is possible with Node Red to fille the customData, which will be copied over to all following messages with that sessionId. Maybe that is helpful

Ups, sorry, seems I missed that somehow - I’ll have to doublecheck my code then, seems sth. goes wrong there…