For large or expensive deployments, a hand-developed protocol may save costs. However, in the case of smaller installations in particular, it is often more sensible to rely on a ready-made implementation in the interests of cost avoidance.
The MQTT released a few weeks ago in version 5 is a classic in the field of event-oriented protocols.
It implements the event architecture described, for example, in Ted
Faison’s classic “Event-Based Programming” and also allows for the
advantage of using a reduced coupling and is easy to maintain.
MQTT was regarded as a quasi standard in the embedded area – there was
hardly a process computer for which there was not a more or less
Even if one or the other is now writing a letter to the editor: MQTT 5.0 plays only a very minor role at the time of printing this issue. While server publishers have published letters of intent to eventually support the new version of the protocol, virtually all practical implementations are currently working with the previous version 3.1.1. The problem is that the version of the open-source server Mosquitto offered by most Linux distributions is extremely old and can not work with current clients. Anyone who uses an X86 machine as a server can avoid the problem by including an additional repository:
sudo add-apt-repository ppa:mosquitto-dev/mosquitto-ppa sudo apt-get update sudo apt-get install mosquitto mosquitto-clients
This command-line, which appears standardized for Linux users, is
hawkish in that the repository does not provide packages for alternative
processor architectures. For example, if you want to host your MQTT server on an ARM-based process computer, you must manually compile the code. The problem here is the need to hold divere libraries for WebSockets and Co.
Since this article is not meant to be an explanation of Unix
administration, in the following steps we assume that a correctly
configured MQTT instance is available at the IP address 192.168.1.106. Also note the configuration file /etc/mosquitto/mosquitto.conf – it contains various parameters for activating logging functions that output status information to the system log. These can not be harvested by dmesg. The log viewer shown in Figure 1 is responsible for collection.
Fig. 1: If configured correctly, you will find various information about the process here
In the next step, as usual, we need to do a version synchronization of Node.js and NPM. The following versions were included on the machine used to create this article, but newer variants generally work without any problems:
[email protected]:~$ node -v v8.11.3 [email protected]:~$ npm -v 5.6.0
In the next act, we need to create a demo project and equip it with the MQTT package. Both are tasks that can be delegated to NPM with confidence. For reasons of space, we print here only the commands to be entered and do not go further to the actual execution of the wizard:
[email protected]:~/demo1$ npm init [email protected]:~/demo1$ npm install mqtt --save . . . + [email protected] [email protected]:~/demo1$ touch index.js
The Touch command used in the script causes Unix to create an empty file named index.js . It will contain the entry point of the program. Open the file in a text editor of your choice and customize its code:
var mqtt = require('mqtt') var client = mqtt.connect('mqtt://192.168.1.106')
As with almost all Node programs, this example also starts loading the external library, which is now available in the MQTT variable. Next is a call to the connect function to animate the client to connect to our server.
In addition to the MQTT prefix used here, the framework also knows six more strings that describe the protocols to use to communicate with the server. In addition to classic and secure MQTT, there are even WebSockets-based versions that allow you to tune down firewalls: