Skip to content

MQTT

History of MQTT MQTT was developed by Andy Stanford-Clark (IBM) and Arlen Nipper (Eurotech; now Cirrus Link) in 1999 for monitoring an oil pipeline through the desert. The goals were to have a bandwidth-efficient protocol that used little battery power, because the devices were connected via satellite which was extremely expensive. The protocol uses a publish/subscribe architecture in contrast to HTTP with its request/response paradigm. Publish/Subscribe is event-driven and enables messages to be pushed to clients. The central communication point is the MQTT broker, it is in charge of dispatching all messages between the senders and the rightful receivers. Each client that publishes a message to the broker, includes a topic into the message. The topic is the routing information for the broker. Each client that wants to receive messages subscribes to a certain topic and the broker delivers all messages with the matching topic to the client. Therefore the clients don't have to know each other, they only communicate over the topic. This architecture enables highly scalable solutions without dependencies between the data producers and the data consumers.
Why use MQTT? MQTT can power realtime communication between IoT endpoint systems and applications (either on mobiles or on computers), so that users can control their devices from anywhere, thus reducing the need for on-site visits, ensuring that machines are operating optimally and reducing the risk of endpoint damage. Today, MQTT is the preferred protocol for M2M systems because it is well-known, almost universal, easy to manage and very flexible.
How does TapNLink use MQTT? To keep the footprint as small as possible, IoTize propose 2 MQTT interfaces:
  • One gives access to the main LwM2M 'command processor'. The mobile apps provide the exact same features when connecting remotely with MQTT than when connected locally (with NFC, BLE or WiFi). By this way, MQTT can be used to control your system with the same generated mobile apps for local access. MQTT also allows to upload new configuration, new firmware, or to send/receive 'single packets' that are secured (both encrypted and authentified) packets containing data, commands, ...
  • One is more generic and provides link between IoT platforms and the embedded Java Virtual Machine (if you write Java code). By this way, MQTT can be used to: - sending alarm or datalogging to a cloud platform, - receiving non-LwM2M commands. In this case, the Java code has to authenticate the source and the validity of the command.
Which MQTT broker should I use? If you develop with a Primer or for a TapNPass, you can use the predefined IoTize Developer's broker: user.cloud.iotize.com You can connect on this broker using your TapNLink serial number as login, and its 'product key' as password. There are also several free brokers. IoTize started using test.mosquitto.org, but is a victim of its own success and is now so slow (and regularly broken) that it can't maintain a monitoring session. We often use broker.mqttdashboard.com or www.hivemq.com/public-mqtt-broker. Note that there is no guarantee for these free brokers for a 24/7 service. For a production context, we recommend using a private broker with a backup solution.
Which connection/login mode should I use? Standard brokers are highly configurable. For example, there are different ways for connection, authentication and encryption: - IoTize Developer's Broker requires a login/password (your 'serial number' and 'product key'). It can be used either with or without SSL. - Mosquitto.org accepts fully anonymous login. - IBM Watson requires a 'token' to be specifed in the password, - AWS works only with certificates... You can also secure the communication thanks to a SSL connection. But pay attention: SSL will secure the communication; not the access to the broker that depends on the authentication method.

Refer to Eclipse Mosquitto for an introduction to MQTT protocol and how to setup a lightweight MQTT Broker.

Operating process

Using a WIFI TapNLink (IOTZ-TAPNLINK-PRIMER-NBW & TnL-FIW103) it is possible with very little effort to create an application that communicates via MQTT with your system.

TapNLink NFC-WIFI acts as a gateway to the MQTT broker, which resides in the Cloud. On the other side is a second device, the control center, that also has an MQTT client and enables the monitoring of the system through this communication.

Use Case

We are going to configure and simulate a remote monitoring session of 'Sensor Demo target application' using the public HiveMQ MQTT broker.

Prerequisites

  • TapNLink NFC-WIFI Primer Evaluation Kit, IoTize Studio installed on a PC,

  • Open the following project: [Install Directory]\IoTize\IoTize Studio\Examples\Sensors_STM32_Demo\Sensor_demo.iotz

Step 1. Connect IoTize Studio to your Tap

  1. Launch Sensor Demo on your phone and look at Connectivity settings to find out which Current Tap IP/Host name and Network mode your Tap is using.

  1. Set Studio | Connection To Tap | Protocol to Socket.
  2. Set Studio | Connection To Tap | Socket host name\IP to the Local WIFI Network.

  1. Test the connection between Studio and the Tap using the Test Connection button.

Step 2. Configure your Tap to connect to HiveMQTT broker

  1. In IoTized Application | Incoming communication (Wireless):

  2. Set WiFi | Network mode to Network(Station).

  3. Set WiFi | Network Configuration | SSID to your network.
  4. Set WiFi | Network Configuration | WEP key to your networks password.
  5. Set MQTT Communication Relay | Enable Relay to Yes
  6. Set MQTT Communication Relay | URL address to broker.hivemq.com (was user.cloud.iotize.com)
  7. Keep MQTT Communication Relay | Client ID as the Serial number of your Tap
  8. Empty the Username and Password.
  1. In IoTized Application | Mobile App | Communication Protocols:
  2. Set MQTT Enabled to Yes.

Step 3. Configure and Reboot the Tap

  1. Click on Configure.
  2. Click on Test | Reboot Tap to restart the Tap with the new configuration that enables the connection between the Tap and the Broker.

Step 4. Connect IoTize Studio to your newly configured Tap using MQTT

Change the Studio | Connection to Tap to use MQTT:

Step 5. Build a mobile App using the 'App Generator'

  1. Click Generate App button to build the app.

Step 6. Install the APK on your phone

Download the APK from the gmail and import it into Goggle Drive. Open Google Drive on your phone and install the APK.

Step 7. Spy on the MQTT communication

Several free programs can spy on the MQTT communication, for example MQTTlens which is a Google Chrome app, we show here how to use MQTT.fx.

  1. Click on the Cog next to the Connect button, then the + button to add a new profile.
  2. Copy the Broker Address and Broker Port from IoTized Application | Incoming communication (Wireless) | MQTT Communication Relay into the MQTT Broker Profile Settings, click on generate to create a Client ID, and click Apply.
  3. Connect to the profile you created.
  4. To observe all IoTize Taps (within range), subscribe to this Topic: IOTIZE_DEV/#
  5. To observe only one Tap, subscribe to this Topic: IOTIZE_DEV/YourTapSerialNumber_DEV/# where YourTapSerialNumber is defined in Studio | Connection to Tap | Tap specific topic (prefix).

If you only see Commands, there is a Tap connection problem.

To reinforce security in MQTT mode (for advanced users):

  • Netkey encrypts the communication in MQTT mode.
  • This is a shared key mechanism.
  • This key can be copied to the Tap (or read from the Tap) when you configure it in 'Socket mode'.
  • To bypass the recovery of this key from the Tap by the smartphone:
  • copy the BRK file (generated in the project directory on your PC)
  • install this file in the IoTize Directory in your smartphone
  • Contact IoTize for more details.

See also

Back to top