How to build IIoT architecture with your own hands. Part 2: “Things”

    In the previous article, we briefly reviewed the organization and processing of IoT data using the Apache NiFi project. With this article we will open a series in which we will describe in detail about each stage, starting from the devices themselves and ending with DataLake platform analytics, machine learning, prediction of anomalies, etc.



    Now let's start with the very first level, the “things” itself, the letter T from the abbreviation IoT. From the device itself, the organization of the communication channel and the use of the MQTT protocol. IoT trend for several years, but for the most part, the idea of ​​it as a light bulb and a socket that is turned on from the phone. But in production, mining, and in various other industries for decades, a variety of sensors have been used, the values ​​of which are collected in production SCADA . Just connect the data stream to the Internet, and we get the same IoT, more precisely IIoT - the industrial Internet of things.


    Why is all this necessary if all these decades of SCADA successfully manage the production cycle?


    There are several reasons:


    • The possibilities of using sensors are expanding, for example, logistics, where a location sensor is installed on a specific truck or car, as well as various additional ones, such as fuel consumption or idle time (waiting at the train station until the car is attached) is all beyond the local production network
    • The number of sensors on devices is growing, they require more sophisticated processing, which is not always possible to make enterprise capacities
    • The capabilities of machine learning and artificial intelligence that have developed due to the growth of computing power, which can be used to optimize production, search for bottlenecks, and identify anomalies

    As a result, sensors in production are no longer simply sending values ​​to SCADA. We need a software architecture that will allow us to build a chain from the end sensor on any machine to a computing cloud, in which, based on the machine’s operating history, with the help of a trained model, the message “37% probability of failure of the mechanism will arrive to the operator, you need to send an engineer ".



    And now back to things! Usually for demonstration of such systems open sets of historical indicators of sensors of any industry are used. But unfortunately, in this variant, it is impossible to “touch” the system. No, we will not get to the plant, but we will do our simple “thing with the Internet”.


    Our field of activity is connected with server infrastructures, but we still have some hobby-electronic skills, so the “thing” will be self-made.
    We choose the simplest monitoring option - a climate sensor; we will collect data on temperature, humidity and pressure.


    Component base


    For the sensor, take the BMP280 .


    A very sophisticated thing, it is intended not only for weather data, but also, thanks to a sensitive barometer, for GPS assistance, for navigating in the building (to determine the floor), for games to help the accelerometer. We will use it only for weather data.


    Take as a module the following:


    As a controller and a communication channel at the same time, we’ll take, probably a cult one, esp8266 ( https://en.wikipedia.org/wiki/ESP8266 )


    In our case, the ESP-07 module:


    As power - 9V battery "Krona". Since all devices operate from 3.3V, a down converter is needed. Hand stretches to put everyone's favorite linear LD1117 :



    But everything that lowers the linear transducer - it simply dissipates into heat. The peak current of esp8622 is about 0.4A, which means with a linear transducer (9-3.3) * 0.4 = 2.28W to nowhere. Also melt.


    Therefore, we assembled a pulse down converter on the LM2576 :



    3 amps just enough for everyone (for real, that of the component base was, then soldered).


    Scheme


    Eagle was used as CAD, the scheme was as follows:


    To run esp8622, you need to pull RESET and CH_PD to a plus (includes the module), GPIO15 to a minus. When GPIO0 is pulled to the ground, the module goes into programming mode, so there is a jumper there.


    GPIO02 and GPIO15 are used as SDA / SDL I2C bus lines for connecting the BMP280, as well as any other devices to the bus (JP5 pin connector), for example, a display, for debugging right on the spot.
    JP1 is used to connect via UART (via a UART-USB converter) to a computer for programming and debugging a module.


    Resistors R6 and R5 assembled a voltage divider for the ADC, so that you can monitor the battery charge.


    Pay


    The layout turned out like this:



    Most likely, in the best traditions of hobby circuitry, violates all possible rules, but most importantly - it works :)


    The device itself turned out like this:



    The board is made using laser-iron technology (one of thousands of examples: http://cxem.net/master/45.php ).


    Device programming


    For a quick start for esp8622, they took NodeMCU firmware .


    NodeMCU is a Lua interpreter for esp8622 and a bunch of libraries for various devices, sensors, displays, etc.


    To flash a device, you first need to get this firmware. The documentation offers several options, but the simplest of them is the nodemcu-build.com service , which allows you to simply get the firmware by mail by simply selecting the modules you need.



    For our device, it is necessary to choose MQTT, I2C (because the sensor is located on this bus), well, the BME280 sensor itself (we have the BMP280, but the library is universal), and also the ADC to monitor the battery. After the firmware is assembled, the service will send it to the specified mail.


    Next you need to close the GPIO0 to the ground and put the module into programming mode (jumper JP2), connect the USB-UART adapter and distort the power.


    Firmware download is performed using NodeMCU PyFlasher . You need to select the appropriate serial port, the firmware itself, and for the ESP-07 module - Quad i / O, the other modes will not work.



    Have a little patience until the firmware is complete, then remove jumper JP2, distort the power and as a result, our device is ready for user code.


    Code


    UART settings for connection - 115200 8N1, by connecting to a terminal for a serial port (for example, terminalbpp ), you can directly enter lua commands, a sort of REPL.



    But we are still interested in less ephemeral firmware, so that after the reboot it remains :)
    When you start NodeMCU it starts to execute the init.lua file (if any) from the flash card. Here we write it.


    For an example, take an example from the documentation:



    To load, we used a simple utility Asmodat ESP LUA Loader . It simply pushes into the file.open terminal and Lua writes it line by line with commands.


    The logic is as follows:


    1. We initialize devices
    2. Connect to WiFi
    3. Read the sensors
    4. Connect to the MQTT broker and send readings to the appropriate topics.
    5. Turn off WiFi, fall asleep until the next measurement

    Lua script, we laid out the scheme and layout of the board , in principle everything is quite transparent there.


    Places that I would like to mention:


    The ADC esp8266 input requires a voltage in the range from 0 to 1V and gives the corresponding number from 0 to 1024 at the output. For resistors 39kOhm and 470kOhm - the conversion factor is approximately 13. That is, in order to estimate (not very accurately measure) the voltage on the battery - the resulting value should be multiplied by 13 and divided by 1024.


    Since the BMP280 sensor is universal, it has several configuration options for different applications. For NodeMCU, the sensor initialization for climate measurements is as follows (only magic numbers):


    bme280.setup(1, 1, 1, 1, 7, 0) -- weather mode

    More information about these numbers in the documentation . Well, in the datasheet on BMP280 above.


    So it was not possible to go into Deep Sleep mode, for some reason the module does not wake up.


    The library for working with MQTT is quite specific, it is impossible to determine exactly when to close the connection. In the community a lot of questions about this without any decision. There are various workarounds, such as this article .


    But in our case, we just wait for a few seconds, and then turn off WiFi.


    Also, TLS support, though stated, failed to get it, the data is sent unencrypted.


    Sending data


    Once a minute, the module connects to WiFi and sends MQTT to the broker readings from sensors.
    Topics in MQTT in the following format:


    /device_location/device_name/sensor

    This allows you to subscribe to data streams from sensors both by location and specific sensors, for example, the temperature outside the window:


    /outdoor/#/temperature

    MQTT broker


    As an MQTT broker, we use Eclipse Mosquitto. To install, for example, Debian needs two packages: mosquitto and mosquitto_clients.


    In /etc/mosquitto/mosquitto.conf you need to register


    require_certificate false# отключаем tls
allow_anonymous true# пускаем всех:)

    Next, we launch our device, using the mosquitto_sub utility, subscribe to the topics of the devices, monitor the weather)


    root@baikal:~# mosquitto_sub -v -t "/outdoor/#"         
/outdoor/iottest/temperature 30.07                      
/outdoor/iottest/pressure 713                           
/outdoor/iottest/humidity 38.765                        
/outdoor/iottest/voltage 439                            
/outdoor/iottest/temperature 30.09                      
/outdoor/iottest/pressure 713                           
/outdoor/iottest/humidity 38.445                        
/outdoor/iottest/voltage 451                            
/outdoor/iottest/temperature 29.93                      
/outdoor/iottest/pressure 713                           
/outdoor/iottest/humidity 38.400                        
/outdoor/iottest/voltage 452

    Baikal is mentioned here for a reason. We are nevertheless geographically located near Baikal, so for the base station there were no other options for the device except using BFK 3.1 on the Baikal T-1 core :)


    In subsequent articles, we turn to the transfer of data received from IIoT to the system of analytics and visualization and tell you about the queues. And about Baikal, of course :)
    Tags:

    Also popular now: