Introduction
In recent versions of the Zebra FX firmware, Zebra added support for IoT to their fixed RFID readers. In addition to AWS and Azure IoT -- GCP IoT is being discontinued -- Zebra added support for general MQTT. MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe message communication system designed primarily for Internet of Things (IoT) environments. It consists of a broker and one or more clients who issue commands on, and listen to specific communication topics. The broker disseminates the messages to the listening clients.
The Zebra FX reader that is configured to use MQTT is an MQTT client. It will connect to a broker such as RabbitMQ, Mosquitto, EMQX, Rumqqtd or others. The TallyFlow-Client software is also a client that connects to the same broker. The broker will pass the messages between the two clients based on the message topic queues.
Running a MQTT demo
MQTT Setup
To use the MQTT features of the Zebra FX reader, you will need a MQTT broker. MQTT testing can be done with the EMQX MQTT docker image.
I also tried the Rust rumqttd broker and it worked well. You can run rumqttd with the following build command:
Additionally, you can use Mosquitto or other MQTT brokers.
Here is a sample Rust app that will verify that the EMQX docker or rumqttd service is running correctly. E.g. use `cargo new mqtt`, then put the code into the resulting main.rs file.
In your Cargo.toml file, you will need the following dependencies:
Testing and Experimentation
Following the Zebra guide, let’s create the following MQTT topics. Use your reader name, or however you’ve decided to configure the topics, but we recommend using unique names for each reader. The broker can listen for an individual reader or for all of them.
/FX7500EECCA8/ctrl/cmd
/FX7500EECCA8/ctrl/resp
/FX7500EECCA8/mgmt/cmd
/FX7500EECCA8/mgmt/resp
/FX7500EECCA8/mgmt/events
/FX7500EECCA8/data/events
The Zebra documentation was not clear about what channels should be used for the Raw MQTT data. After some experimentation, patterns emerge. For example, what was unexpected was the following: sending certain commands to ‘ctrl/cmd’ resulted in a response on ‘mgmt/resp’. E.g. ‘get_status’ on ctrl/cmd caused the reader to respond on mgmt/resp. When the same command was sent on mgmt/cmd, the response also came back on mgmt/resp. So, perhaps we don’t need ctrl/cmd or ctrl/resp? Not so. The start and stop tag reads commands are expected on the control (ctrl) topics.
It seems that the Zebra reader wants the requesting MQTT client to wait for a response when a command is sent. When we send two commands, get_status and get_version back-to-back (1 second between) on mgmt/cmd, it crashes the FX7500. But, if we wait for the response for one, then send the other, all is well.
On ‘mgmt/events’ you will receive heartbeat packets, as expected. Here is an example partial JSON heartbeat message:
Note that a MQTT client could subscribe to “/+/mgmt/events” (and the other channels) and wait for a heartbeat, then extract the reader name and map that to an internal database or ID. The responsibility then falls on the Zebra reader setup administrator to configure the MQTT broker address information and the client will just listen for all readers.
Troubleshooting
When the Zebra FX reader loses connection to the MQTT broker, the STAT light will turn on. Restart or otherwise correct the connection to the MQTT broker.
Conclusion
The support for MQTT and other IoT mechanisms greatly modernizes and enhances the Zebra FX RFID readers.
We are offering sample Rust code to communicate with the Zebra reader at no cost. If you are interested in obtaining access to this code, please contact us.
To obtain a broader introduction to the Zebra FX firmware and IoT configuration,
Zebra documentation may be found here:
Zebra sample source code: