Troubleshooting Connectivity between Impinj Readers and MQTT Brokers

Message Queuing Telemetry Transport (MQTT) is a message broker that enables a decoupled publish/subscribe mechanism for software applications. Impinj Products have MQTT as an option for transmitting tag and health reports to third party applications. From time to time, users might run into problems getting tag and health reports from this message broker. The goal of this article is to assist with troubleshooting problems with the MQTT broker. 

First, the user should identify and isolate the underlying source of the problem.

1. Check MQTT

1.1 Try Connecting to the Same MQTT Broker and Topics

Connect a generic MQTT client (e.g. MQTT Spy, and MQTT Explorer) to the same broker that the reader is communicating with. Subscribe to the topics that the reader should be publishing and see if the broker receives the reader data.

1.2 Take the Reader out of the Picture

Write your own publisher and subscriber MQTT programs. Use the publisher to write data to MQTT and use the subscriber to listen for that data.

There are also free MQTT tools you can find (E.g. MQTT.fx) to test with.

1.3 Check the MQTT Server for Issues

The Mosquitto MQTT broker comes with command line utilities (like `mosquitto_pub, mosquitto_sub, and mosquitto_rr`) which can help ensure that you can write data to and receive it from the broker. Use those commands to verify the MQTT Server is operational.

Check the memory usage, CPU usage, and disk space to see if there are any issues. 

You can also configure your broker to log specific events to a file.

2. Check the Network

2.1 Check the network communication between MQTT and the reader

Use Wireshark/tcpdump to scan the network and confirm if the reader is sending packets to the MQTT server.  We have used wireshark to find out no communication was occurring due to firewall rules. 

2.2 Check the network communication between MQTT and the host application

Use Wireshark/tcpdump to scan the network and confirm if the MQTT server is sending packets to the Host Application.

We have used wireshark to find out the communication showed the wrong username and password were being sent.


3. Check the Reader

3.1 Test the Reader with a Different Application

Disconnect your application from MQTT. Attempt to connect another application, like ItemTest or using the HTTP Stream on the reader /data/stream endpoint, to the reader and verify tag reads are indeed being reported.

3.2 Use API Calls to Debug Connections to the Broker

We include some examples of Impinj R700 RESTful API commands you can use to verify that your reader is working correctly.

We will be using the "curl" utility to assist with this checkout. The curl utility is a command line tool that can transfer data from a server via many supported protocols, including HTTP. Both the MacOS and Linux operating systems have always included the curl command, and since 2018 the Windows 10 operating system also includes the utility.

3.2.1 Get the Reader Status

Retrieve the reader's current status with the following command:

curl http://<IP Address or Impinj R700 Hostname>:80/api/v1/status

Example output is below.


3.2.2 Retrieve the MQTT Settings

Retrieve the current MQTT configuration settings for publishing data to an MQTT broker with the following command:

curl http://<IP Address or Impinj R700 Hostname>:80/api/v1/mqtt

Example output is below.


Note: As of if you plan to use MQTTS, you need to set "tlsEnabled" to true using this api when CA certs are used. You cannot set "tlsEnabled" from the Web UI.

You can also get the configuration by visiting the Configuration section of the Web UI Preview Screen:


In the above image, MQTT has NOT been configured. You need to Enable it and enter the appropriate information.

3.2.3 Verify the Advanced settings are specified

If the system starts by connecting to MQTT initially but disconnects a few days later, it is possible keepalives and Event Buffer Size are missing.  Please make sure these Settings are specified in the MQTT Advanced Settings.  (Event Buffer Size of 100000, Event Per Second Limit of 0, Event Pending Delivery Limit of 10, and keep alive of 0 seconds)


3.2.4 Verify no other reader is using the same Client ID

If two or more devices are connected to the MQTT Server with the same Client ID, you may encounter a situation where the reader will disconnect and reconnect over and over.   So, please make sure no other devices are using the same Client ID.

3.2.5 Read Tags from the Impinj R700

If tag reads aren't coming through, check that the reader is collecting tag reads. The RESTful API stream can help see if the reader is reading tags.

    • Open a command prompt or Terminal Window on your computer
    • Run the following command
curl -G -4 http://<IP Address or Impinj R700 Hostname>:80/api/v1/data/stream
    • Note: Replace “<IP Address or Impinj R700 Hostname>” with the IP Address or Reader Hostname that can access the Impinj R700.
    • The curl command will now connect to the reader RESTful API to receive Tag HTTP outputs from this endpoint.mceclip3.png

4. Check the Reader for Issues

Please refer to the Reader Troubleshooting Guide ( and check the reader logs for troubleshooting Reader-related issues. 

5. Set the Connection Keep Alive Interval

We have encountered situations where the reader could not connect to an MQTT broker. The MQTT status indicator in the web UI did not turn green (it stays grey), but no error messages appeared in the UI.  

We found the connection worked if we set the Keep Alive Interval to a positive value.


6. Known Issues

5.1 Changing Configuration the First Time Fails

On Octane Firmware 7.3, when setting up MQTT configuration for the first time, you are unable to submit without "Clean Client Session on Disconnect" enabled.


  • Enable Clean Client Session. Then disable it before submitting the form.
Was this article helpful?
0 out of 0 found this helpful



Article is closed for comments.