[solved] Intents appear twice


My setup: 1 snips satellite running o RPi 0w, connected to snips running in docker container on x64. Hass.io docker container running on same server as the snips docker container. Mosquitto is running in the snips container to bridge between snips and hass.io.

Before I had the bridge working, the snips setup was working well. The snips app I had installed would understand my request, and reply appropriately. After much confusion, I finally got the MQTT bridge working. Initially, the configuration I used was bridging hermes/intent/# in both directions. This resulted in getting 4 replies for one request to the snips app. My first thought was to change the bridge configuration, so that hermes/intent/# was only bridged for “out”. That reduced the replies from snips to only 2 per request. Additionally, any intent that is handled by hass.io works just fine.

By running mosquitto_sub to see what’s going over MQTT on my snips server, I can see two identical intents when I tell snips to do something. If I connect to hass.io’s mosquitto server instead, I see the intent only once (which is why hass.io doesn’t do things twice).

I’m pretty sure I’ve simply misconfigured something, but I have no idea how to fix it. :frowning: Because of that, I’m not sure what other configuration information would be useful to include.


You only need to bridge on one of the two mqtt server instances. Here is a good configuration to use on your snips MQTT instance to bridge the relevant topics back and forth.

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

There is only one bridge. That is, only the mosquitto server running in the snips container is configured to bridge. The mosquitto server running in the hass.io container has no bridge configuration.


I found it. The suggestion of multiple bridges gave me a hint on where to look. It was a docker misconfiguration, with the hass.io container running mosquitto exposing port 1883 by mistake. I’ve not tried to think it through all the way, to determine why/how that was causing the problem, but since that was not how I intended to configure it, I’m not too concerned for now.


Hi can you give me please someore details about your configuration. I plan snips server on a synology Ds913 an will use rasp2 as sattelit


The hass.io container has the mosquitto broker add-on installed. The configuration includes a certificate and private key (you can use openssl to create a simple self-signed certificate for initial setup). Also set a username and password in the config. Under the “Network” settings, blank out the settings for 1883 and 1884. Be sure 8883 and 8884 are set. Create two files in the share/mosquitto directory for hass.io (install the samba share if you don’t have other access). The two files are:

acl_file /share/mosquitto/acl
— end file—

user <username>
topic hermes/intent/#
—end file—

Replace <username> with the username you set in the config earlier.

Now, on to the snips setup. Set up your snips server and satellite and make sure that’s working first. Next, if you’re running your hass.io docker container on the same system as your snips server (in a docker or not), there’s some additional setup and non-standard settings to use. Otherwise, you can follow any of the myriad of directions for bridging MQTT between snips and Home Assistant (but don’t bother publishing topics other than “hermes/intent/#”, and maybe the TTS topics, if hass.io needs to respond verbally, in which case, adjust the ACL above).

Now, for a use case like mine, you’ll need to set up the bridge. This means you need to install mosquitto on the snips server (ignore all the comments about how snips does this for you; they’re either out-dated or just plain wrong, AFAICT). Make sure to connect to the proper IP address of your add-on container, and port 8883. Copy the certificate you created above to someplace on your snips server, and specify that as bridge_cafile (note: if you aren’t using a self-signed certificate, configure the appropriate root certificate instead). Comment out any listener and protocol lines for the mosquitto configuration, too.

snips.toml on the snips server should be configured properly already, since you had the satellite working. Don’t mess with it.

Now, because you’ve got a docker container running mosquitto on port 1883 and your snips server is also running mosquitto on port 1883, there will be problems. If you’re not running the snips server in another container, you’ll have to see if you can convince mosquitto to NOT listen on port 1883 (it seems like a bug to me, but I couldn’t do that – it always listened on port 1883, no matter what I configured). So, when I start the docker container for the snips server, I re-direct port 1883 to port 9883. Additionally, I make sure it’s on the same network as the hass.io containers (–net hassio when starting the container). Additionally, in your docker file, make sure you don’t EXPOSE 1883/tcp. It might not hurt, but it won’t help anything.

Finally, because you now expose the snips server’s mosquitto on port 9883, instead of 1883, you’ll have to change snips.toml on the satellite. Simply change the mqtt setting in snips-common to point to port 9883.

Additionally, I don’t use the snips add-on for hass.io – it doesn’t include snips-injection, is out of date (last I checked), and the container itself isn’t as configurable as I’d like. The major draw-back to that is that when you install your assistant, any skills for home assistant have to manually installed. It’s not hard, and this part isn’t really documented nicely.

Installing the skills – you need to ensure that the skills are installed correctly on the snips server (assuming you’ve set up your snips server correctly, this is easy). Then copy the skills from the snips server’s /var/lib/snips/skills/ directories, and place them in the config/python_scripts for hass.io (again, the samba share add-on can help you locate the config directory, and you probably need to create python_scripts). You’ll need to add the “python_script” and “snips” components to your HomeAssistant configuration.yaml file. They don’t need to be configured, just add them to the file. Finally, you need add the intent_script component. I set mine to like this:

intent_script: !include intent_script.yaml

That lets me keep all of the intent scripts in a separate configuration file. Be sure to read the documentation to configure the intent scripts correctly. It’s excellent documentation, but there’s nothing to tell you that this (along with the other two components) are what you need to enable all this stuff. Like a lot of what I’ve found, HomeAssistant and snips both have a lot of good documentation for individual parts, but almost nothing that tells you how to put it all together. :frowning:

Finally, restart everything. I usually make sure hass.io is running first, but I’ve restarted it several times while the satellite and snips server are running without any issues. Likewise, I’ve restarted the snips server with the satellite and hass.io running without any problems. I almost never have to touch the satellite – I don’t run any skills on it, and it’s the one piece that “just works”. :slight_smile:

1 Like

Wow, thank you.

Very much input. I think my raspi2 is not fast enough for snips!? What docker can I use on my synology for snips? .



I use a modified version of this one: https://github.com/dYalib/snips-docker. I don’t know enough about synology model numbers to know if that’s really appropriate or not. Please note that this one does export port 1883, so you’ll have to comment that out before creating the container. My modifications aren’t really ready for anyone else to see yet, so I’ve not published them.