IoT using Eclipse Paho for Java, Mosquitto MQTT and ESP8266


Hello! The focus of this video
presentation will be on the Eclipse Paho library for Java and its application in
building IoT systems. IoT or the Internet of Things is a technology that lets
electronic devices communicate over the Internet using the MQTT protocol in order to build systems such as smart houses for
example. The protocol requires a message broker and one or more client nodes. One
such free message broker is the Eclipse Mosquitto. It’s available for all of the most
popular platforms including the Raspberry Pi. I’m running it on 64-bit
Windows. Obviously, I already have it installed. It’s best to install it as an operating
system service and then check in the task manager to make sure that it’s running. The IP address of the message broker we
can look up using the “ipconfig” command. On my network that address is 192.168.1.70 on port 1883. Let’s verify that the MQTT
broker is running. Let’s open two console windows — in one we will subscribe to
listen to all of the MQTT traffic, and in the other one we’ll generate MQTT
messages. The “t” switch is for “topic” the pound sign is a wild card and the “v”
switch is for “verbose output”. On the publishing side the “m” switch is for
messages. And, as you can see, the broker works. The
hardware client node that I’m using is an ESP-01 module. It’s made using
the ESP8266 microcontroller, and it’s very inexpensive. There are other similar
modules like the Sonoff module, that are more practical for real projects. ESP8266
microcontroller is designed by Espressif. It’s a very capable and fun
little microcontroller however not sufficiently reliable for industrial
applications, in my opinion. It’s based on the Tensilica Xtensa processor.
Competing Wi-Fi enabled microcontrollers that are based on ARM Cortex M
architecture have recently become available in the market, but I haven’t
had a chance yet to try them out. On the Espressif website there are technical
documents, SDKs and various tools available for download. For this
experiment we’ll need the memory flashing tool. I already have it. The
firmware that we’re going to want to flash into the microcontroller is called
ESP Easy. And again, of course, I already have it.
For uploading the bare-metal firmware onto the microcontroller I’m using an FTDI
USB-to-serial converter. Make sure you set the voltage to 3.3 volts. On the
Internet I’ve seen recommendations to set the SPI
mode to DOUT. The flash size of 8 megabits is equal to 1 megabyte. I forgot to
connect the GPIO-zero pin to ground for flashing. Let’s try it again.
Ok, I bought two of these ESP-01 modules, one for transmitting, and one for
receiving, but one of them is busted. It’s showing this e-fuse error that appears
to be quite common with these microcontrollers. For flashing we’ll
select the 1024 bytes firmware version and we’ll put it at the address of 00000 — at the beginning of the flash memory. The second module works fine, I’ve
already flashed it. For deployment, we’ll need a 3.3 volt
power supply and a switch on the general-purpose in/out port, pin number
two. I used the mobile telephone to get the ESP-01 module logged on to the
Wi-Fi network. Using the IP address provided at logon you can access the
configuration pages for the ESP-01 module. The name that you set here for
the client node will be included in the topic string.
Select the OpenHAB MQTT protocol, and in the controller IP field enter the IP
address for the Mosquitto message broker that we’ve looked up earlier. On my
network, that address is 192.168.1.70, and the port number is 1883. Then click “submit”. On the “Hardware” page, you can
select the pins for I2C communication. This time we’re not gonna need it. On the “Devices” page, we’re gonna want to
set up an input sensor. Let’s keep things simple and make it just a simple switch.
The name that you set here for the input sensor will also be included in the
topic string. Per the schematic that we saw earlier, we’ll connect the switch to the
GPIO-pin-2. The message data format will be simple binary 1 and 0. The name of the
value that you set here will also be included in the topic string. In the “Advanced” menu of the “Tools” page
you can adjust the format of both the receiving and the sending topic text
string. In this experiment, we’re not going to
use serial communication — just Wi-Fi. Okay, let’s verify if our little client
node is working as intended: Let’s subscribe to all topics in order
to monitor all incoming messages, then let’s toggle the GPIO-2 switch on
the node on-and-off, on-and-off… Good! The node is correctly sending the topic text
string and the payload value. Okay, let’s create a new Java project in
Eclipse, but not just a regular Java project — let’s create a “Maven” project. We’ll make it a QuickStart project, and let’s give it a meaningful name.
Let’s call it “IoT Application”. From the project tree, I’m going to
delete all of the testing classes. That “JUnit” stuff is way too complicated for me, I never use it. The library that we’re going to use in
Java to connect to the Mosquitto message broker is
Eclipse “Paho”. Currently the latest version is 1.2.1 So, let’s add the Maven dependency to the
“POM” file. I’ll delete the JUnit dependency — I’m not going to do any
testing. Let’s navigate to the Eclipse Paho page
in the Maven repository. Let’s copy the dependency, and let’s paste it in the POM file. I’ll adjust the formatting a little, make
it look nice. Then, hit “control-s” on the keyboard to
save it, and we’re done. Now we need to update the project to
reflect the changes that we’ve made to the Maven dependencies: Right click on the application root
folder… it won’t fit — let’s scroll down a little. Okay. Right click on the
application root folder and select Maven update project. Hit “okay”. It’ll take a moment for the update process to run its course And, we’re done.
Let’s scroll the window back up, and let’s open the main application class. I’m going to delete the auto-generated
boilerplate code. We’ll replace it with something much
more interesting. Let’s look up the JavaDoc
files to see what methods we have at our disposal in the Paho library. I want to
communicate with the message broker in an asynchronous, non-blocking manner. Let’s instantiate a new asynchronous client object. We’ll call it “myClient”. Eclipse IDE will automatically provide
suggestions on how to fix the errors in syntax. It will automatically take care
of all the relevant imports. Let’s make this object a field in the
main application class. We’ll need to provide the MQTT-asynchronous-client class constructor the IP address of the Mosquitto message
broker, and we’ll also need to supply it with an IP identifier string for the
client. This string can be any unique identifier. I’m gonna use a random value. Once again, Eclipse IDE will
automatically correct the syntax. Let’s correct the declared type of the
client object — The correct object type should be MQTT asynchronous client. This field we’re going to want to be
able to access from another class, so let’s make it “public”. And, that other class is the “callback”
class — let’s create it. The callback class will implement the
MQTT callback interface. There are probably better, more elegant
ways to do this, by using a lambda expression, or by passing an interface as
an object, but I’m not a professional programmer, and that stuff is way too
complicated for me. I’ll just stick to the mechanism that I can understand and
that makes sense to me, so, I’ll create a callback class that
implements the MQTT callback interface. There are three methods that we’re going
to have to create because they’re mandated by the callback interface, but
that’s a good thing, because we’ll need those methods. Then, we’ll create an instance of the
callback object — let’s call it myCallback And then, let’s link that callback to the
MQTT client that we created earlier Now we can establish a connection to the
Mosquitto message broker. We chose to use the asynchronous,
non-blocking method of communication with the message broker, but we want the
“connect” method to block — We want the communication to wait until connection
is successfully established. Next, we’ll have my client subscribe to
the topic that the ESP-01 microcontroller node is set up to
publish to. (I could have just copied this string
from the console) For the purposes of this exercise, I
don’t really care about data integrity — the lowest level of the quality of
service is fine. I’ll set the quality of service to zero. Alright, let’s compile and see if it works. I don’t have any launch configurations, yet. Fine. It compiles and runs. Cool, let’s add some functionality to the “message-arrived” method, and see if we’re receiving any messages from the
microcontroller node. Let’s print all received messages to the system console. The first argument passed to the “message
arrived” method is the topic, and the second argument is the message. Hmm… What am I doing wrong here? Oh, right! You use the “plus” sign to concatenate strings. Great! Let’s save everything and run it. It runs. That’s a good sign. And, when we
flick the switch connected to the GPIO-2 pin of the microcontroller node, we’re
getting input. Messages are coming in. Let’s compare that input to the messages
being published by the microcontroller node. Great! We have a match. Okay, the messages are coming in nicely,
but the purpose of this application is not to simply print those received
messages out to the system console. We want our application to act on those
inputs, and to provide directives to other client nodes.
So, let’s go ahead and publish this data. Same as before, we’ll set the quality of
service to zero. Let’s save our changes. One thing that you don’t want to do is
to publish to the same topic that you’re subscribed to, because that’ll create an
infinite loop. So, let’s create a new topic: We’ll copy
the format of the topic that we’re subscribe to, but we’ll change it. We’ll publish to a topic that’s
addressed to a different client — client two, and, the device that we publish to
will have an output switch, like a relay, perhaps. Let’s save it all again, and let’s see what happens when we
toggle the GPIO-2 input switch on-and-off. First we’ll toggle the input switch
on-and-off while the java application is not running.
We can see messages coming in from the ESP-01 module, and there is no other
activity. Now, let’s start the java application. Look, we’re processing the input received from the ESP-01, and we’re publishing it to another client node, to another topic, to client two that has an output switch. Since my other hardware node is faulty,
and we cannot use it to receive this published data, let’s make a virtual
software node for that. To accomplish this, let’s use Node-RED. I already have it installed on my computer. The graphical user interface is
accessible in a web browser Just HTTP to the localhost address shown in the console. Here it is. Let’s set it up. We want our Node-RED client to receive MQTT input that’s been published by the Java
application. Let’s enter the IP address of the Mosquitto message broker, and the topic that our Java application
is publishing to. We can just copy and paste without the quotation marks. Again, let’s set the quality of service to
zero, and then, let’s add a “debug”
node that will allow us to monitor this MQTT traffic. We need to give it a name. We can imagine something like the Sonoff module, with a
relay switch built-in. Let’s deploy this setup, and then, let’s view the MQTT traffic in
the debug window. Once again, let’s flick the input switch on-and-off repeatedly… Beautiful. Let’s clear the debug window and do it
again. It works perfectly. Thank you for watching this video, I hope that it’ll inspire you to make your own IoT projects in Java.

Leave a Reply

Your email address will not be published. Required fields are marked *