Need some help please

I had a rhasspy failure today - its been 100% for a very long time, so long in fact, it took me hours just to figure out how it works, sort of :frowning:

I use it with home assistant, HA listens for MQTT intents etc, the HA setup runs an MQTT service, Rhasspy runs on a separate Raspberry Pi

I sort of managed to get it working again, but its now flooding MQTT with large messages and I’m pretty certain it never used to do this.

It is managing to send responses to HA and Node Red again but the flooding does not seem right?
Maybe i have set it up in a different (wrong) way this time?
To get it working again, I entered my MQTT IP, user and PW into rhasspy setup - they were blank, and it started working - no idea why they were blank unless they were previously blank and it was working in a different way?

I know this is a tricky one and i’m just as confused myself, thats the trouble when things work - you forget how to fix them :wink:

ANy tips?

Just guessing here :wink: Your UDP ports in combination with an external mqtt?

1 Like

Thanks but I have no idea about UDP ports, I can’t see how they would have magically altered settings alone?

Is there a picture or some other guidance to help me here - I’m totally rusty on this now :frowning:

Have you read the thread (and preferably the soultion in post #2 from that thread) I linked above? :slight_smile:

It is about spamming your MQTT. That happens because you might have not linked the ports, if you’re using an external MQTT broker. :slight_smile:

1 Like

Yes, i did, but see no example of what goes in the two port boxes - is there a way to find a unused port number etc?

I see the two places in Rhasspy but they have different formats - host and port on one and host:port:siteid on the other, i may be looking in the wrong place though?

I dont do any external voice processing, i just listened for intents etc - is this info still correct?

As far as I understand that thread (and doing it the same way myself), the UDP ports need to be linked in order to not send every wav chunck via mqtt. With these settings the chuncks will only be sent, after the wake-up (not always).

This is how I’ve set it up, port 12111 seem to work on a standard install, and a quick google search didn’t bring up something, that is using 12111 by default.

1 Like

Thanks all, that seems to have stopped it.

I am baffled though why it needed reconfiguring - I just can not remember how it was set up,

If i am using node red to listen for intent messages do i need the MQTT details logged in to Rhasspy - they were all blank so it seems a bit odd to me?

is there a way to stop it sending ANY audio out? I’m not using it so it seems pointless as i will not have a sattellite system

1 Like

Sure, if you put that UPD port on Audio Input it should be ok

Can you expand a little, i have both ports on the same value - its stopped the mass flood traffic but still sends once the wake word is recognised - can that be stopped too?

Yes, add it to the wakeword as well, I thought you already had that.

You can read it here:
https://rhasspy.readthedocs.io/en/latest/audio-input/

and here:
https://rhasspy.readthedocs.io/en/latest/wake-word/

Yes its in wake word and audio but still spits out MQTT/wav data once the wake word is recognised until the end of the converstaion

OK, it migtht work differently then. I you do not want any MQTT messages over the network, you can use the internal broker.

If its set to internal, does it still send intents etc?

This is where i’m confused, somehow this setup altered itself and stopped working, i use MQTT listeners in node red on hermes/intent/# etc and it all worked before.

Im not sure what changed, could i have been looking at the Rhasspy broker instead og my own broker maybe, and had rhasspy set to internal???

Its all very odd and a bit confusing :slight_smile:

Hmm good point. It will, but to the internal broker so that will cause issues with the connection to HA.
You can connect HA to rhasspy broker, but that also leads to some troubles if you use MQTT for other stuff.

If you are really keen on not sending audio data at all to the broker, you could set it to internal and use events in Rhasspy.
But I would not be to worried about the MQTT audio, since it only sends when the hotword is detected

1 Like

Nice, I am pretty certain now that i had it internal with node-red looking at the Rhasspy broker. I altered the MQTT on node red to look at my server and that must have been what broke Rhasspy.

Its working well again and i’ll just ignore the traffic when its active, not like its used all the time anyway.

Good you have it working again. :slight_smile: Would you mind sharing your actual settings now, so others can take a look at them, if needed? :wink: Just out of interest :slight_smile:

Here we go…
Node red just looks at my local MQTT broker running on the Home Assistant Pi, Rhasspy runs on its own Pi




1 Like