IoT Case #1 – Agile-gong
Today we all know what the Internet of Things is and why it is needed. But how many of us are familiar with cloud platforms, which represent one of the most significant layers in the IoT? Let’s figure it out.
It is no secret that the heterogeneity of protocols significantly complicates the processes of connecting smart devices, configuring them and processing data. Similar problems are solved thanks to the cloud platforms of the Internet of Things. Today, using one of the Russian Internet of Things platforms as an example, I will show how easy it is to connect devices with different protocols, as well as use the information received to build automation processes.
The platform that I usually use for my tasks has already implemented interaction with devices using such protocols as MQTT, Wialon Combine, Wialon IPS, Galileosky, Modbus and some others.
In addition to using the presented protocols, for devices that do not have Internet access, it is possible to write software agents – some intermediaries between the equipment and the platform that are installed on another device (for example, Raspberry Pi) and connected to this equipment.
Let’s say you need to ensure interaction with a device that works using one of the presented protocols. In this case, it will be enough to take three steps:
configure the model with the desired parameters and commands;
create an object with a unique identifier in the platform;
configure the device to connect to the platform.
Let’s analyze a few cases and see how it all connects.
Case №1 Agile-gong
To begin with, once our team seriously thought about how to automate work processes in the office.
So, in accordance with the Agile concept, at noon of the working day, all employees gather for the Daily meeting. It’s easy to miss the notification in Slack about an upcoming meeting in the process of work, and it’s not very convenient to be distracted by the clock… So the idea was born to create Agile-gong, an automated sound notification system.
How is it implemented? Hardware is a NodeMCU (a miniature analogue of Arduino with a built-in Wi-Fi module), a servo and a capacitor. Every weekday at 12 o’clock, the output shaft of the servo with the percussion equipment at the end must be rotated at an angle sufficient for the gong to ring and notify everyone of the rise.
The iron connection diagram is quite simple:
The code hardcoded on the NodeMCU provides:
establishing a Wi-Fi connection and connecting to the platform via the MQTT protocol;
setting the initial position of the servo to 0 degrees;
publication of messages with data on the current position;
subscription to commands and rotation of the servo by an angle on command.
On the platform side, a device model has been developed. It describes the parameters that can be received from the device and the commands that can be sent to it. In the interpretation of MQTT commands, these are messages for a client with a specific topic and data, in our case, the required rotation angle is found in the data.
Then an object was created with an identifier by which authorization on the platform takes place. Once connected, the display looks like this:
In commands, there is an option to send a command to rotate at an angle of 0 and 90 degrees.
Now we need to add the automation scripts. Let’s create an automaton that, when the desired time arrives, will go into the state of rotation by 90 degrees, then, in a cycle for a configurable number of repetitions, will make the required number of strokes and return to the initial state of waiting for 12 hours.
Each automation script is a kind of block diagram that defines the logic of the object’s behavior. By writing such a script, you can take into account all the changes that occur with the device, and based on what changes have occurred, the device will be able to perform the appropriate actions automatically, without sending a command by the user.
The resulting machine can be used not only for a specific device.
For example, you can make exactly the same system with a gong and install it in another room in your office. Then you will have the same model, two different objects, and one automaton running on two objects.
Case #2 – Carbon Dioxide Sensor
In the previous note, there was a conversation about the creation of Agile-gong’a – an automated sound notification system in the office. The second useful solution for us was the connection of a carbon dioxide sensor. Also connected via MQTT. Again, the iron assembly scheme is trivial.
Yes, by the way, we were engaged in the implementation of both the first and second cases as part of a hackathon within the company. And none of us plunged into the work of iron, and there was no need for this.
Then the procedure is the same. The model includes the ppm parameter (1000 ppm = 0.1% CO2 content), which is transmitted by the device, but it is not very clear, so another parameter is immediately displayed in the model – the percentage of CO2 content. It is calculated as ppm value divided by 10000.
Here you can also notice two commands to turn on the light bulb. It was decided to use it for indication. And we control it, of course, from the platform machine. After connecting the device, the parameter display is as follows. These values are received and displayed in real time, but you can also view past accumulated packets in history or display a graph of parameter changes over a certain period.
The automaton for this object works as follows. In the upper state, the light turns off. At the bottom – start the timer for a minute and turn on the light bulb. The transition from the first state to the second occurs on the event of receiving data from the device with the condition that the ppm value is greater than 600 units. Return (transition from the second state to the first) occurs when the timer expires.
You may have two questions.
Why an automatic? Isn’t it easier to prescribe such conditions on the piece of iron itself? After all, everything is so simple.
Why is there a timer?
In fact, the machine is useful even in such a simple case. I put this sensor with a light on my desk for the duration of the debugging, and every time I came to work, the light turned on, since the threshold value in the machine was quite low. For a while I tried different values in the machine and eventually came to the optimal value of 600 units. To select the desired value, I just had to change the value in the machine and save it. No device flashing. And if we transfer this device to an office where it is necessary to maintain a better air condition and frequent ventilation is necessary, then again the value can simply be changed. Fast and convenient.
Here is a timer set for one minute. This is necessary so that for a minute we are in a state of high CO2 and do not react to the fact that for some time the high value continues to come. Otherwise, we would be constantly blinking a light bulb, making transitions until the air condition is normal. You could already guess that you can make the transition to the initial state in another way. Also on the event of receiving data, but in which the opposite condition is met – ppm<600. Then we will be in the second state exactly until the normal value comes.