MQTT (MQ Telemetry Transport) is a Message Queuing system for machine to machine communications. It allows communication of mobile systems over high latency, low bandwidth and poor quality networks. It manage communications over TCP (not over Http) to optimize the size of messages and it manages different quality of services. Depending of it, messages can be dropped, received multiple times of you can have the insurance to receive the message one and only one time.
It makes this protocol really interesting for the communication between a raspberry PI and a server when this communication is event driven and the communication link looks like a Edge/3G channel.
Mosquitto is an open source implementation for MQTT.
Here are some tips on how I implemented it, for a demonstration purpose
Installation of Mosquitto on Raspberry PI
The current version at the day of this article is the version 1.2, here is a small script you can run to install mosquitto on a RPI.
# mosquittoVersion="mosquitto-1.2"
# apt-get -y install libwrap0-dev libssl-dev
# wget http://mosquitto.org/files/source/${mosquittoVersion}.tar.gz
# tar zxf ${mosquittoVersion}.tar.gz
# cd ${mosquittoVersion}
# make
# make install
# ldconfig
# cd ..
# ## rm -rf ${mosquittoVersion}
# rm ${mosquittoVersion}.tar.gz
Now you have some mosquitto client program in /usr/local/bin including mosquitto_pub and mosquitto_sub and the mosquitto server deamon in /usr/local/sbin
Installation of mosquitto on an OpenSuse server
To act as a broker, on the server side, I installed mosquitto on a Linux server (based on OpenSuse). Here are the command used
# mosquittoVersion="mosquitto-1.2"
# zypper install libopenssl-devel
# wget http://mosquitto.org/files/source/${mosquittoVersion}.tar.gz
# tar zxf ${mosquittoVersion}.tar.gz
# cd ${mosquittoVersion}
# make
# make install
# ldconfig
# cd ..
# ## rm -rf ${mosquittoVersion}
# rm ${mosquittoVersion}.tar.gz
# useradd mosquitto
# groupadd mosquitto
The next step is to open the 1883 port on your firewall (this is a graphical operation in yast2, then go in security/firewall setup, then allowed services, then select advanced and add 1883 in the tcp port list)
Now, you can run mosquitto command and the broker is listening.
Send a message to the broker from the raspeberry PI
To send a message to the broker, you will use the mosquitto_pub command a simple example is the following one :
mosquitto_pub -h myBrokerName -m myValue -t sensors/value -q 1
Here
- myBrokerName is a host name or IP where mosquitto broker has been started
- myValue is the message you want to transmit
- sensor/value is the topic you want to discuss on
- -q 1 is the quality of service you want (here message can be delivred more than once but confirmation is required)
The topic is what you want but it is a kind of tree with “/” as node. For example you can send to house/kitchen/sensors/temperature .
In this example, the message is not retained on the broker, this means that if no subscribers are actually connected to the topic, the message will be lost. You can send a message with retain option (-r). In this case, the message will be stored in the broker and will be sent to the subscriber when they will connect. As a consequence, subscriber will get the message each time it connects to the topic. Only the last message sent to the topic is retained. To clear the retained value, send a retained empty message.
Get the message on the server, from the broker
To get a message, you need to subscribe to the topic, it is possible to subscribe to a node instead of a leaf in the topic tree :
mosquitto_sub -h myBrokerName -t myTopic/+
Here, myTopic/+ is a wild card to listen on myTopic/mySubTopic1 and myTopic/mySubTopic2 …
Each time a message is send to this topic, it will be received and print on screen with this command.
Store message on broker
With what is described before, when the subscriber disconnects, all the messages received are dropped from the queues. If you want the broker to store the published messages to push them when the subscriber will reconnect you have to deal with some option.
This is important for exemple if you want to send command to a mobile device (subscriber) your are not sure is connected.
The first thing is to use on the subscriber side the –disable-clean-session option, this request the broker to keep the messages. It works if you give a name (id) to the subscriber with the option –id. Broker will use this id to know what messages have been pushed or not. Then, you must add the option -q 1 or -q 2 to the subscriber command to make it works.
mosquitto_sub --disable-clean-session --id myid1 -h myBroker -t myTopic -q 1
Now with these options you can kill mosquitto_sub, send message, restart mosquitto_sub and get the messages sent with a QoS 1 or 2. QoS 0 messages are dropped.
MQTT over Nating (firewall)
On the broker side, the firewall port 1883 must be open.
For the clients (publishing and subscribing) there is, regarding the tests I’m done so far, no specific requirements. The clients can be behind a nat system and work correctly.
Some references used to build this article
- Dosquitto installation on Raspberry PI (old version) : http://mqtt.org/
- Download mosquitto : http://mosquitto.org/download/
- MQTT documentation : http://mosquitto.org/man/mqtt-7.html