[SOLVED] Satellite (with hotword detection) is sending voice to MQTT all the time



not sure if this is by design but I noticed that satellite is sending voice data to the MQTT all the time. I would expect that voice data would be sent after hotword is detected as the satellite is running the hotword component. Is this an error in my configuration or something we have to live with at the moment?

My satellite config:

My master config:

Platform Update 1.0.2 (0.60.10) - 03/01/2018

Seems to be a general issue. I use a more basic configuration and can see too, that the satellite constantly send data to the server ( check with tcpdump).

How do you exactly determine that it’s voice data?


It should be on the Topic Hermes/audioFrame/#
It happens even without a satellite, but I‘m not sure if it was because I messed up my config. My guess is, it is the constant audio stream for hotword detection? (Not even ment for anybody else but the satellites asr component)


Hello @david195. Thank you for confirming. It is just an assumption, as when audio-server is not started on the satellite this is no longer happening. The worst thing about this problem is that both satellite and mosquito will eat
up a lot of CPU what is a really bad thing when you want to run this on devices with very limited resources (like raspberry)


Today, i spend some time to investigating this issue. Here my results:

Satellite does not run snips-hotword and snips-audio-server -> no traffic to “Snips Server”

Satellite run snips-audio-server only -> voice traffic to “Snips-Server”, hotword detection is performed by “Snips Server”.

Satellite run snips-hotword only -> no traffic to “Snips-Server”, but also no hotword detection

Satellite run snips-audio-server and snips-hotword -> more voice traffic to “Snips-Server”, hotword detection is performed by “Satellite”.

I think we have misunderstood the Satellite B configuration. I thought the voice data are only send to the server, when the satellite have detected the hotword. But it seems, that the voice data are always send, in both configuration methods! I guess configuration B sends the voice data BACK to the satellite for hotword detection. That would explain the traffic.
Can someone confirm or disprove this?

If it is so, i hope for a better solution in the future…



I stumbled across the same assumption. From my perspective it would be perfect to have all audio processing on the satellite until the hotword detection is triggered. Otherwise my wlan/lan could be flooded with audio-streams. Also the main mqtt broker would get under pressure.
The idea of using mqtt as the main interface between loose coupled subsystems sounds great for this problem. I hoped I could config (i.e. route) the audio to a different mqtt broker from ASR step on, as ASR has an own mqtt configuration option. But this doesn´t help.

Maybe a snips dev could point into a direction to look into?

Thanks in advance


Mmmmh, thought this was fixed/implemented



This is something we are working on. Should be implemented real soon :slight_smile:

Platform Update 1.0.3 (0.60.12) - 28/01/2018


thank you very much for your answer. These are great news :slight_smile:

Best regards


I’m seeing this issue as well. I’m using a remote rpi running snips pushgin mqtt to a homeassistant install. I’m flooded with audio mqtt messages. Is there a config that will turn those off?


Perfect! Thank you for the response!


This turned out to be my problem. I had configured snips.toml to point to my hassio mosquitto server. This resulted in a huge flood of audio traffic to my hassio server. This is the wrong thing for my setup.

(In case someone else runs into this.,…)
The correct configuration is to configure the mosquito server on my snips device with an mqtt bridge to my hassio mqtt server. The bridge configuration allows a subset of mqtt traffic to be shared between the two mqtt servers and keeps the noisy audio data local to the snips server.

sample mosquitto config:

connection snipsmqtt
address HASS_MQTT_ADDRESS:1883
#remote_username HASS_MQTT_USER
#remote_password HASS_MQTT_PASSWORD
remote_clientid snips
start_type automatic
topic hermes/dialogueManager/# in
topic hermes/asr/# in
topic hermes/hotword/# out

topic hermes/intent/# out
topic hermes/asr/# out
topic hermes/hotword/# out
topic hermes/nlu/# out


I don’t get it… I’ve configured snips on one rpi3b+ with Jabra MIC Array as full installation, and I’ve deployed an satellite with hotrod (Conf B) on an rpi3a+ with repspeaker 4-mic.
Whatever I do, the audio stream from satellite is always “spammed” to mqtt broker on the primary snips. Hotword detection on satellite is working, but it looks like audio is sent to broker an subscribed by satellite again.
Since I am deploying an satellite each room, this will be overwhelming for wifi.
I am quite sure, you already fixed this for your upcoming Snips Air???

What am I missing?

Greeting, Patrick


You’re not missing anything, this is still not implemented after all these month we’ve been asking for it. I did a separated wifi network for Snips


Thanks for your update. I also isolated snips to a separate wifi/vlan. Not as simple as it could be, but it is working.

Offtopic @Psycho I’ve used a lot of your code for my environment! Thanks for the good work :slight_smile:


Does anyone have a real fix for this by now? I thought that with the big update there might not be problems with Snips Satellites flooding the WiFi anymore but I guess I was wrong. It´s getting so bad, my Repeater is actually shutting down the connection of the Snips Satelitte to the Network, probably because its just too much to handle…


i thought the new VAD setting might have suspended the MQTT streaming when there was no voice… but no it still streams 24/7


The VAD is only used to reduce the Wake Word detector CPU load.


I do not known who set the title to solved, but as far as I can see this is not solved.

I am pretty sure my family and guests are not happy if they known that I have one point that I can listen in on all conversations in the house and record them.

Is there any sight on how this issue can be resolved.?

1 Like

Hi Vandaag,

It is not a bug.

There is a way to configure the setup so that the audio server acts has a real server.The ASR can then ask for an audio stream on demand. The configuration is a bit tricky and we need to document it properly and it may be deprecated soon.

In the coming releases, we will deliver a new satellite service to avoid the continuous stream audio over the network.

Meanwhile, it is possible to cypher the MQTT communication.