Unrecognized commands/silence incorrectly return intent

[Rad]

I just upgraded both my master and satellites from 2.5.5 to Rhasspy 2.5.9 and everything seems to be working. However, I noticed that Rhasspy will return an intent for unrecognized commands or silence after the wakeword has been detected instead of Intent not found. All defined commands are recognized correctly. Is this a configuration issue?
Master configuration (English):
MQTT: External
Audio Recording: Disabled
Speech to Text: Kaldi
language Model Type: Text FST
Voice Command Settings:
Silence Method: VAD
VAD Sensitivity: 1
Current Energy Threshold:
Max/Current Energy Ratio Threshold:
Max Energy:
Skip Before: 0
Minimum Duration: 1
Maximum Duration: 10
Speech Before: 0.3
Silence After: 0.5
Record Before: 0.5

Intent Recognition: Fsticuffs
Fuzzy text matching (checked)
Text to Speech: PicoTTs
Audio Playing: Disabled
Dialogue Management: Rhasspy
Intent Handling: Disabled

Thanks in advance.

[koan]

I noticed this too recently, and it’s more pronounced with a satellite with lower-quality audio:

Rebranded the Matrix Voice to esp32-rhasspy-satellite

@romkabouter I now noticed the same behaviour when using my laptop as a satellite, but just once. So I don’t think it’s an issue in your code: it’s just that it’s triggered much more frequently with the Atom Echo’s lower-quality microphone and/or speaker.

I haven’t found the culprit yet, but because it happens much more frequently on the Atom Echo device and just once on my laptop, I suspect it has something to do with noise in the audio stream.

[Rad]

My satellites (3) consist of a Raspberry Pi 3b with respeaker 2-mic hat, all of which had been working for months without any issues using Rhasspy 2.5.5. The issue is repeatable in that any invalid command spoken will trigger an intent.

[daywalker1180]

Could that be connected to this:

How does the Confidence Score work?

I read somewhere that Kaldi does not implement confidence score yet, which is why it can’t do IntentNotRecognized.

I just read quickly through the discussion, but that seems to fit the undesired behaviour you’re encountering… @Daenara also uses the combination Kaldi + Fsticuffs.

Just as I stumbled across the linked discussion I thought it would maybe an idea to post a reference here…

BR
Martin

[J_J]

I´m facing the same issue with 2.5.9 and fsticuffs (no fuzzy text matching) with spanish profile. When no sentence is spoken or it´s not recognized, rhasspy triggers a random intent.
I have tried different configurations with no luck.
Has anybody been able to solve that ?
Thanks!

[Rad]

I am still having the problem. I’ve tried adjusting the input level with no success. Listening to the recorded audio I do not hear noise.

[schnopsi]

Same here using Kaldi/fsticuffs. If I wake up Rhasspy using the wakeword and then stop speaking, a random intent is recognized.

And also intents are recognized although not speaking a whole sentence.

The Rhasspy-Sentence:

(schalt|schalte) $de.fhem.Device{Device} [um] [(0..10){Value!float}] [dezibel{Unit}] (leiser|niedriger){Change:volDown}

If I only speak leiser after the wakeword, the result is:

hermes/nlu/query

{"input": "schalt licht leiser", "siteId": "wohnzimmer", "id": null, "intentFilter": null, "sessionId": "wohnzimmer-snowboy-2fb88deb-e210-47e4-84b7-bb7f41aaf8e5", "wakewordId": "snowboy", "lang": null}

No idea, where “schalt” and “licht” is coming from.

[loupiote]

Hello.
I had the same problem as you and the solution was given by Fastjack in a previous post.
Make the {name} slot optional and return an error in your intent handler when it is not definied.

Random word gets added to spoken sentence

Hi, I have the following sentence in my sentences.ini using Kaldi/fsticuffs: \[set] (timer|countdown) in [$Room{Room}] to (0..60){Value} (seconds|minutes|hours){Unit} If I speak a sentence omiting the unit like set timer to 2 there is always a random unit added. How can I avoid this? I want such a sentence resulting in an error. Thanks Stefan

[mkcologne]

Put me on the list with that error.

[Light]

I was originally going to make a post about false positives, but got busy and then I saw that this thread has been bumped. I have also been having this problem a lot, even with silence after wake word recognition. Although my setup is new so it is not an issue of “it was working and now it isn’t.” I am running on a Raspberry Pi 4 with a Matrix Voice for the microphone. I am also using Kaldi and Fsticuffs with default settings. Has a solution to this problem been found yet?

[Guillaume_Duveau]

Same here, although it’s quite rare. I’m suspecting it has something to do with too lax sentences definition that I just added, with a lot of optional words. Will have to check this.

[DaveKearley]

@loupiote

Hello.
I had the same problem as you and the solution was given by Fastjack in a previous post.
Make the {name} slot optional and return an error in your intent handler when it is not definied.

Nice - this seems to work, have been playing in Node Red and it seems looking at
payload.slots[0].rawValue

then comparing to being either “empty” or “not empty” works well, it does mean that there must be an optional slot in every sentence so a simple “what is the time” is now “what is the [time] {time}”

But it does seem to function.

[Light]

That seems quite unintuitive. In my case this is happening with sentences of the form “do (options1) {slot1} to (options2) {slot2}”. You would think if none of the options from either slots were recognized, that the intent itself would not be recognized.

On top of that, if I speak the wake word it will listen for quite a long time even if there is no speech. Afterwards, a seemingly random intent will be recognized.

[DaveKearley]

Yes the silence seems to create the first intent on my list.

It seems there is a difference between the words in a list and and [optional] word - the random selection still chooses a sentence but it cannot fill that optional slot so you get a blank or empty slot come through which can be trapped. I’m too new to even guess how it works internally but for me a fix is fix, until its fixed