International Journal of Electronics and Communication Engineering and Technology

(IJECET)
Volume 9, Issue 1, January-February 2018, pp. 1–12, Article ID: IJECET_09_01_001
Available online at
http://www.iaeme.com/IJECET/issues.asp?JType=IJECET&VType=9&IType=1
ISSN Print: 0976-6464 and ISSN Online: 0976-6472
© IAEME Publication

A VISION OF INTERNET OF THINGS IN

INDUSTRY 4.0 WITH ESP8266
Carlos M. S. Rodrigues, Bruno S. L. Castro
UFPA - Telecommunications Engineering,
Department of Federal University of Pará, Belém, Brazil

ABSTRACT
This article presents a case study with the introduction of ESP8266 module,
observing the types and levels of bandwidth and communication challenges with
wireless network sensors and the necessary requirements in hostile environments in
the industry 4.0 era, switching between QoS levels. The module may suffer when
applied in industry 4.0, using a communication type machine-to-machine (M2M) to
establish connectivity IoT (Internet of Things). The chosen protocol for
sending/receiving routing of messages was the Message Queuing Telemetry Transport
(MQTT) to be extremely light weight, simple to implement, and running on an
architecture publish/subscribe ideal for this type of environments.
Key words: Industry 4.0, ESP8266, IoT, MQTT, M2M
Cite this Article: Carlos M. S. Rodrigues, Bruno S. L. Castro, A Vision of Internet of
Things in Industry 4.0 with ESP8266. International Journal of Electronics and
Communication Engineering and Technology, 9(1), 2018, pp. 1–12.
http://www.iaeme.com/IJECET/issues.asp?JType=IJECET&VType=9&IType=1

1. INTRODUCTION
With the advent of the Internet of things, appears slowly the Industry 4.0, that raises many
curiosity and doubts in the research community. More and more reviews and research
conducted by industry-related institutes observe that the penetration and the progress of the
Industry 4.0 concept is very slow [1].
It is a slow process, science boosts the industry and the industry boosts the global
economic standards, since the great industry revolution, for over 300 years, the industry
pushes the economic markets around the world, but right now after many years later, a new
revolution is happening, it is named by many as Industry 4.0.
On the other hand, the evolution of the industrial Internet of Things (IoT) [2] and Industry
4.0 [3]-[4] creates the possibility of connecting computer automated control systems for
remote monitoring and rapid response to events requiring real-time handling [5] creating large
opportunities of business for companies and organizations.

http://www.iaeme.com/IJECET/index.asp 1 editor@iaeme.com
 A Vision of Internet of Things in Industry 4.0 with ESP8266

It is necessary watching new forms of communication that suits to the companies needs
because a Machine-to-machine (M2M) communication plays a critical component of Industry
4.0 and, thus, resulting in Internet or Intranet of Things (IoT) [6-7].
There is a growing interest in using IoT Technologies in various industries [8].
Organizations massively invest to develop applications that interact with hardware, such
Cyber-Physical Systems (CPS) technologies and Cyber-Physical Production Systems (CPPS)
platforms to create smart factories.
However, quite a few IoT applications are being developed and/or deployed in various
industries including environmental monitoring, health-care service, inventory and production
management, food supply chain, transportation, workplace and home support, security, and
surveillance. Atzori et al. [9] and Miorandi et al. [10].
Another protocol that emerged after 10 years of existence is MQTT, it was created at the
end of 90‟s, developed by Andy Standford-Clark; MQTT is original from IBM, and since its
creation has been send to the Organization for the Advancement of Structured Information
Standards (OASIS) for standardization, where the current version of the standard protocol is
3.1. [11].
It is the type of lightweight M2M protocol, that works into the meaning of message
exchange between Publisher and Subscriber. Making an analogy relative to the traditional
architecture Client/Server, it is asynchronous, that is, it does not need to know where each
node is.
Publisher works as the client, usually represented by wireless sensor networks (WSN) that
transmits the data to a centralized location, Broker works as the Server that keeps the data
temporarily or permanently, and lastly there is a Subscriber that receives the reading of these
data through asking, working as the end client. That is the big differential of this protocol,
because the internet is not a reliable place, where inbound communications normally are
blocked by firewalls or gateway applications, as shown in Figure 1

Figure 1 MQTT Protocol traffic flow

This way any Subscriber that knows the topic path, since it is not private, can request to
the Broker the desired data, and starts to receive all messages published by sensor.
Examples of subscriptions:
 AIO_USERNAME/feeds/temperature
 AIO_USERNAME/feeds/+/temperature
 AIO_USERNAME/feeds/#

http://www.iaeme.com/IJECET/index.asp 2 editor@iaeme.com
 Carlos M. S. Rodrigues, Bruno S. L. Castro

In the first example, it is shown a basic subscription of a topic named temperature, in the
second there is a symbol wildcard (+) that allows accept any data on that level, in the third
example the (#) allows accept any data below of a determined level, thus to have access to
any data on the feeds topic, without to know the total topic path is extremely required use this
symbol at the end.
The used module at the proposed scenario is the ESP8266, a low cost, high performance
System on Chip Wi-Fi to serial module, part of Espressif System‟s „Smart Connectivity
Platform‟ that aims to provide mobile platform designers to innovate systems with embedded
Wi-Fi Capabilities at the lowest cost with the greatest functionality [12].
This module operates in 802.11 g/b/n modes. It is comprised of 32bit processor Tensilica
Xtensa LX106 running at 80 MHz, 512KB SPI Flash, 64KB SRAM, 96KB DRAM, 16 GPIO
Pins, 2.4 GHz Wi-Fi that supports WPA/WPA2 and one 10 bit ADC[13]. It can operate
within a temperature range of -40C to 125C, according to the manufacturer ESPRESSIF
Systems.
Other research does not address issues related to interference that may be caused by
electronic devices and things in the concept of Industry 4.0, but in this first scenario we will
address the behavior of the MQTT protocol, changing the quality of service.
The proposed model starts to simulate the environment of Figure 2 in laboratory
environment with the introduction of TCP (transmission control protocol) traffic within the
LAN, registering the values with IPERF [14] a tool for active measurements of the maximum
achievable bandwidth on IP networks.
This tool supports various parameters related to timing, buffers and protocols (TCP, UDP,
SCTP with IPv4 and IPv6). For each test it reports the bandwidth, loss, and other
parameters. for further analysis. [15].

Figure 2 Proposed scenario for environment simulation IoT

For the setup proposed to measure the publication of the topics with QoS expected were
used:
 Client iperf: Windows 7, with Intel processor i686 @ 3,2Ghz and 6GB of RAM.

http://www.iaeme.com/IJECET/index.asp 3 editor@iaeme.com
 A Vision of Internet of Things in Industry 4.0 with ESP8266

 Server iperf: Linux version 3.2.82-1, with Intel processor i686 @ 2,8Ghz and 3GB of RAM.
 Publisher: ESP8266 32-bit Xtensa @ 80MHz and 64KB of RAM.
 Subscriber: Windows 7, with Intel processor i686 @ 3,8Ghz and 4GB of RAM.
 Router AP: Motorola SVG1202, working in 802.11n, frequency 2412 MHz and channel 1.
 MQTT Broker: Adafruit website. [16]

The feeds in the MQTT broker can be seen in the Figure 3.

Figure 3 Dashboard in Adafruit website

This paper is organized as follows: Section II shows, a study about the sensor and the
MQTT protocol communication for the Industry 4.0 era. In section III an analysis is made for
QOS types in relation to the availability of the bandwidth. Section IV, provides the
conclusion.

2. SENSOR AND MQTT PROTOCOL

The module used in the proposed scenario is the board, official for development Node MCU
v3.0 with the chip ESP8266-12 built-in, as it is shown in Figure 4.

Figure 4 Node MCU firmware with a ESP8266-12 version 3.0

Nodev MCU is a elua based firmware for the ESP8266 WiFi SOC from Espressif. The
firmware is based on the Espressif NON-OS SDK 1.5.4.1 and uses a file system based on
spiffs. The code repository consists of 98.1% C - code that glues the thin Lua veneer to the
SDK.
The Node MCU firmware is a companion project to the popular Node MCUdev kits,
ready-made open source development boards with ESP8266-12E chips [17].
ESP8266EX integrates Tensilica L106 32-bit micro controller (MCU) which features
extra low power consumption and 16-bit RSIC, reaching a maximum clock speed of 160
MHz. With the Real-Time Operation System (RTOS) enabled and Wi-Fi stack functional,

http://www.iaeme.com/IJECET/index.asp 4 editor@iaeme.com
 Carlos M. S. Rodrigues, Bruno S. L. Castro

about 80% of the processing power is still available for user application programming and
development [18].
The pinout scheme follows the presented in the Figure 5.

Figure 5 Pinout ESP8266 NodeMCU Dev-Kit [19]

For the purpose of our analysis in TCP/IP communication it was chosen the MQTT
protocol because it is extremely light, and it is ideal to environment with limited bandwidth
network and high latency probability in their transmissions.
Another reason is that the protocol is open, simple, and designed so as to be easy to
implement. These characteristics make it ideal for use in many situations, including
constrained environments such as for communication in Machine to Machine (M2M) and
Internet of Things (IoT) contexts where a small code footprint is required and/or network
bandwidth is at a premium [20].
Each MQTT Control Packet contains a fixed header [21] of 2 bytes, Figure 6 illustrates
the standard fixed header format.

Figure 6 Fixed header format [21]

On the position 1 (byte1) from the header bits [7-4] represents the type of control that the
MQTT establishes in the sent and received packets, the function defined for each one can be
seen on the table 1.

http://www.iaeme.com/IJECET/index.asp 5 editor@iaeme.com
 A Vision of Internet of Things in Industry 4.0 with ESP8266

Table 1 Message Type

Name Value Direction flow Description
RESERVED 0 Forbidden Reserved
Client request to connect
CONNECT 1 Client to Server
to server
CONNACK 2 Server to client Connect acknowledgment
PUBLISH 3 Client to Server Publish message

Client to Server
PUBACK 4 Publish Acknowledgment
or
Server to Client

PUBREC 5 Client to Server or Publish received

Server to Client

PUBREL 6 Client to Server or Publish release

Server to Client

PUBCOMP 7 Client to Server or Publish complete

Server to Client
SUBSCRIBE 8 Client to Server Client subscribe request
Subscribe
SUBACK 9 Server to Client
acknowledgment
UNSUBSCRIBE 10 Clien to Server Unsubscribe request

MQTT protocol delivers messages according to the level of established Quality of Service
(QoS), there are 3 levels as follows describe:
 QoS level 0 – At most once delivery
 QoS level 1 – At least once delivery
 Qos level 2 – Exactly once delivery

In the level 0, according Figure 7, the data are delivered following the Best Effort
perspective, the protocol tries to deliver a message, but as it does not have received
confirmation this message may possibly be lost, and there is no guarantee that the receiver
will receive it. Following uploads with the same contents of the message are not made.

Figure 7 QoS level 0 protocol flow

In the level 1 according figure 8, already exists a knowledge (PUBACK) from the broker
to the Publisher, ensuring, this way, the client knows that the message was successfully
delivered to the subscriber.

http://www.iaeme.com/IJECET/index.asp 6 editor@iaeme.com
 Carlos M. S. Rodrigues, Bruno S. L. Castro

Figure 8 QoS level 1 protocol flow

When there is a fail during the message communication, by the link of node or the
Publisher does not receive the confirmation during a specific Time-to-Live (TTL) the
Publisher back to send the message using the header mechanism on position 1 (byte 1) bit [3]
with the set flag DUP, it is also important to refer that in the case of QoS level 1 and 2 exist a
specific Message ID to each sent message that works as an identifier in the Broker.
On the level 2, according Figure 9, all the process is a few more complex to guarantee that
the duplicated messages will not be delivered to the Broker.
This level of service qualities applied in systems where the duplicated sends are not
tolerated or possible to happen, as banker systems or space navigation.

Figure 9 QoS level 2 protocol flow

In a network where there are several communication failures, MQTT only provides
recovery with QoS 1 or 2. If the client device fails, it is typically a catastrophic failure, rather
than a transient one [21].
The confirmation answer from the broker to the publisher is made by the message
(PUBREC) it guarantees to the client that the message was successfully stored, the broker
does not send immediately to the subscribers, it sends only when it receives the message
(PUBREL) from the client, after that the broker sends a (PUBCOMP) to the client, than
discards the original message because it knows that the message was successfully delivered
exactly once to the subscribers of the topic delivering.

http://www.iaeme.com/IJECET/index.asp 7 editor@iaeme.com
 A Vision of Internet of Things in Industry 4.0 with ESP8266

At the level of impact on the performance of the sending of messages the choice of QoS
has special importance in the total transmission times, the following equations will be
considered:

)
+

Where,
→ Number of messages.
→ Time of publish message.
→ Time of publish acknowledgment.
→ Time of assured publish received.
→ Time of assured publish release.
→ Time of assured publish complete.
For the transmission of 100 topics, taking into consideration that the takes approximately
0.5 sec. and the messages , , take approximately 0.4 sec. on a network without bottlenecks,
we can observe the following message delivery times:
100 * 0,5 = 50 seconds
100 * (0,5 + 0,4) = 90 seconds
100 * (0,5 + 1,2) = 170 seconds
We can observe that the choice of QoS may have certain limitations in networks with time
restrictions, another limitation verified during the review process is that the MQTT, besides
being a protocol that predicts QoS, it does not present no queue mechanisms, or periodization
in the message urgency.
The protocol only speaks with topics [22] does not exist no queue proposals to the
management of the topics send to the broker, neither its internal treatment as its delivery to
the subscribers, that are clients of this same topic.

3. MEASURING BANDWIDTH WITH QOS

For all the tests, we used wavemon on the linux, near to module ESP8266 to register the
values of link quality, signal level, noise level and Signal-to-noise (SNR) and those values can
be seen in Figure 10.

http://www.iaeme.com/IJECET/index.asp 8 editor@iaeme.com
 Carlos M. S. Rodrigues, Bruno S. L. Castro

Figure 10 Capture quality condition for WiFi transmissions

With the IPERF tool utilization, were sended TCP packets types to occupy the bandwidth
during 100 sec. with the following command:
iperf -c 192.168.0.2 -P 1 -i 1 -p 5001 -f m -t 100
From the other end of the local network (LAN) another computer listen to the packets on
port 5001 through the following command:
iperf -s -t -P 0 -i 1 -p 5001 -f m

Table 2 The bandwidth server analysis

ID Interval Transfer Bandwidth
4 0.0-30.0 sec 158 13.2Mbits/sec
MBytes

With this test, it can be observed from Figure 11, the values of channel occupation vary
between the values of 11,0 to 13,8 Mbits/sec, with a slight drop of a packet in the instant of
time 13 sec., marking the value of 1,3Mbits/sec.
Being the average bandwidth for the channel used equal to 13,2 Mbits/sec.

Figure 11 Bandwidth used on server

http://www.iaeme.com/IJECET/index.asp 9 editor@iaeme.com
 A Vision of Internet of Things in Industry 4.0 with ESP8266

After the band be filled, tests were performed for topics publications with the protocol
MQTT, the ping, rssi, temperature and humidity, in order to verify its behavior in wireless
sensor congestion network.
As the study is based on QoS 0 and QoS 1 utilization, the variations and losses of
packages are registered by the Internet Control Message Protocol (ICMP).
As shown in Figure 12, that the packet lost variation varies from 202 to 237,6 ms during
the periods of time of 21:01:40 – 21:04:45 with the publisher sending the data to the Broker
on cloud by the utilization of QoS 0.

Figure 12. QoS level to protocol flow

After this period, the network is flood by TCP SYN packets, that make a bottleneck on the
communication line, causing a channel failure. It´s possible to observe that between the period
of 21:04:45 to 21:08:10 there was an effective failure on reception by the subscriber from the
topic ping, and therefore in all the others topics, because the local network was loaded of TPC
SYN packets.
From the instant 21:08:10 to 21:09:35, the module ESP 8266 was configured to change
the service quality to QoS 1, and this way you can verify that the packets start to be delivered
to the subscriber again, however in the message headers of the publisher a flag DUP was set
up to 1, instead of DUP 0, that is the protocol working standard.
This fact is verified because the MQTT Broker tries to send many times the PUBACK to
the publisher, but it finds congestion on the network and the delivery fails, then, the client sets
up the DUP to 1, and tries publish the message to the MQTT broker several times until its
receipt acknowledgment.
From 21:05:50 to 21:08:10 all the messages have been lost, because QoS 0 has no
mechanism to know if the messages were delivered successfully or not, already in QoS 1, this
guarantee is assured, the fact of the messages starting to be delivered again was not only
because the QoS was changed, but because the channel congestion decreased, however, even
if network congestion lasts longer with high values of traffic, all messages would be delivered
later in a certain time.
This is possible because with QoS 1 the MQTT broker stores the messages in the cloud
and after that publish the messages to the subscriber and in the end deletes them.

http://www.iaeme.com/IJECET/index.asp 10 editor@iaeme.com
 Carlos M. S. Rodrigues, Bruno S. L. Castro

4. CONCLUSIONS
In this paper, we discussed some aspects referents to the service quality, and the transmission
reliability. Industrial communication requires very high reliability especially for control, and
safety applications [23].
Thus, it was possible to conclude that through the MQTT protocol utilization, even if
there is a band occupation filling almost all the channel, the verified bottlenecks cannot
prevent the subscriber of receive the topics, providing a resilience to a reliable package
delivery with QoS .
About the less reliable transmissions, the QoS 0 configuration can be used, but there is no
package delivery guarantee, what does not fit the point of view to the industry 4.0, which as
one of its first objectives, to ensure a reliable environment.
For further works, it is intended to continue to use the quality of service in MQTT,
introducing and analyzing interferences on transmissions, in order to study their behavior in
hostile environments, subject to failure on data transmission.

REFERENCE
[1] R. Frank, L. Caius, D. Anca, “Service Provision in the Framework of Industry 4.0”.
[2] R. Want, B. Schilit, and S. Jenson, “Enabling the internet of things,” IEEE Computer, vol.
48, no. 1, pp. 28–35, Jan. 2015.
[3] J. Lee, “Industry 4.0 in big data environment,” Harting Tech News, vol. 26, 2013.
[4] Intel Corp., “The Internet of Things (IoT) starts with Intel inside,” 2015. [Online].
Available: http://www.intel.com/content/www/us/en/internet-of-things/overview.html.
[5] Michael W. Condryand CatherineBlackadar Nelson “Using Smart Edge IoT Devices for
Safer, Rapid Response With Industry IoT Control Operations”.
[6] J. Höller, V. Tsiatsis, C. Mulligan, S. Karnouskos, S. Avesand, D. Boyle, ”From
Machine-to-Machine to the Internet of Things: Introduction to a New Age of
Intelligence”, Elsevier, 2014, ISBN 978- 0-12-407684-6.
[7] Jazdi N, "Cyber physical systems in the context of Industry 4.0", IEEE International
Conference on Automation, Quality and Testing, Robotics, 2014.
[8] Y. Li, M. Hou, H. Liu, and Y. Liu, “Towards a theoretical framework of strategic
decision, supporting capability and information sharing under the contexto of internet of
things,” Inf. Technol. Manage., vol. 13, no. 4, pp. 205-2016, 2012.
[9] L. Atzori, A. Iera, and G. Morabito, “The internet of things: A survey,” Comput. Netw.,
vol. 54, no. 15, pp. 2787–2805, 2010.
[10] D. Miorandi, S. Sicari, F. De Pellegrini, and I. Chlamtac, “Internet of things:Vision,
applications and research challenges,” Ad Hoc Netw., vol. 10, no. 7,pp. 1497–1516, 2012.
[11] IBM, “Desenvolva um sensor de Temperatura pronto para a nuvem com o Arduino Uno e
o IBM IoT Foundation, Parte 2.”. [Online]. Available:
http://www.ibm.com/developerworks/br/cloud/library/cl-bluemix-arduino-iot2/. Last
access in 19/11/16.
[12] Manan Mehta, “ESP 8266: A Breakthrough In Wireless Sensor Networks And Internet Of
Things”, in International Journal of Electronics and Communication Engineering &
Technology (IJECET) Volume 6, Issue 8, Aug 2015.

http://www.iaeme.com/IJECET/index.asp 11 editor@iaeme.com
 A Vision of Internet of Things in Industry 4.0 with ESP8266

[13] Wi-Fi Module, “ESP8266EX Datasheet”. [Online]. Available: http://www.adafruit.com.

Last access in 09/11/16.
[14] A Tirumala, F Qin, J Dugan, J Ferguson, K Gibbs, “Iperf-The TCP/UDP bandwidth
measurement tool”, http://dast.nlanr.net/Projects/Iperf/, 2005.
[15] IPERF “The ultimate speed test tool for TCP, UDP and SCTP”. [Online]. Available:
https://iperf.fr/. Last access in 12/12/16.
[16] Adafruit, “Dasboard”. [Online]. Available: https://io.adafruit.com/. Last access in
15/12/16.
[17] NodeMCU, “Lua based interactive firmware for mcu like esp8266”. [Online]. Available:
https://github.com/nodemcu/nodemcu-firmware. Last access: 10/12/16
[18] Espressif, “Low-power, highly-integrated Wi-Fi solution”. [Online]. Available:
http://espressif.com/products/hardware/esp8266ex/overview/. Last access: 21/11/16.
[19] ESP8266 NodeMCU, “Comparison of ESP8266 NodeMCU development boards”.
[Online]. Available: http://frightanic.com/iot/comparison-of-esp8266-nodemcu-
development-boards/. Last access: 13/12/16.
[20] S. Shubhangi, N.Pooja, S. Shubhangi, S. Vrushali, J. Yogesh, “MQTT- Messge Queuing
Telemetry Transport protocol”.
[21] MQTT, “MQTT v3.1 Protocol Specification”. [Online]. Available:
http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt- v3r1.html. Last access:
17/10/16.
[22] MQTT OASIS Standard, “MQTT version 3.1.1”. [Online]. Available: http://docs.oasis-
open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html. Last Access: 08/12/16
[23] A. Varghese and D. Tandur, “Wireless requirements and challenges in industry 4.0,” in
Contemporary Computing and Informatics (IC3I), 2014 International Conference on.
IEEE, 2014, pp. 634–638.

http://www.iaeme.com/IJECET/index.asp 12 editor@iaeme.com