An example of connecting a device using the MQTT protocol

Model configuration

Consider the following case. Let’s say you are given a room in which you need to constantly adjust the temperature. If the room temperature exceeds 22 degrees and the window is closed, you will need to turn on the air conditioner. If the temperature drops or a window opens, the air conditioner should turn off.

So, the following devices are given:

  • air conditioning;
  • window opening sensor;
  • room temperature sensor.

Devices may not be able to connect to the Internet. Such devices cannot receive commands from the platform and send data to the platform directly. They must be connected to a controller that has Internet access and can connect to the platform to route data and commands.

In our example, devices communicate with the platform through a controller. The controller sends data using the MQTT protocol. Therefore, it is the controller in this case that will be the object of control from the point of view of the platform, and the model will be created alone.

Let’s create a new MQTT model.


It will look like this. As you can see, by default there are two parameters available: Temperature and Humidity – and two commands: turn on and off the LED lamp (Turn-on LED and Turn-off LED).


The air conditioner should be controlled based on data sent by sensors, which should collect current readings about the temperature in the room and about the open or closed state of the window.

You should understand that for two sensor data, you need to add arguments with different data types. The temperature sensor can report different temperature values. Accordingly, it must be a numeric argument, the value of which must be expressed in degrees Celsius. Since a window can only be in two states: open or closed, the data type for this argument is a boolean type. Data from a sensor on a window can either be sent with a value of 1 if the window is closed and with a value of 0 if it is open. In this case, the air conditioner itself is able to carry out two commands: on and off.

So, when configuring the model, you need to add a new argument for the sensor on the window and add some information about the Temperature argument (for example, specify the source). The default Humidity parameter added to the model is useless, so it can be removed.

For more details on the purpose of fields, see the section Model of the object of control.

When creating a new parameter, all required fields are filled in. The argument is selected as the type. The “ID” field can be left unchanged (since the API is not intended to be used in this example).

If you need to use the platform API, it is recommended to change the identifier automatically generated by the platform to a more understandable one.

Next, enter a name convenient for further viewing in the interface. Since the value 0 is transmitted from the sensor if the window is open, and 1 – if it is closed, then the boolean type must be selected as the data type. The “Source” field indicates the topic on which the device sends the window parameter value.

To describe the commands sent to the air conditioner, you need to edit the default commands for turning on and off the lamp.


Action is specified as the parameter type. Each team has a meaningful identifier and name. The type of action is set – a command to the device. When you send a message to execute a command, you must specify the PUBLISH command. The message will be sent and published on the prescribed topic’у – base/air_con. When sending on this topic a value of 1, specified in the payload as text, the controller will turn on the air conditioner, since the window will be closed, upon receiving 0, it will turn it off.

Creating an object

For this case, the main device is the controller, which controls the operation of the air conditioner and reads the readings from the sensors. Therefore, you only need to create one object per controller.

To do this, go to the “Objects” menu and open a dialog box for creating a new object. A model is selected from the drop-down list. Then an identifier is entered, which is used as a ClientID when flashing the device to connect to the platform. Next, the name of the object is entered, if necessary, its type and status are indicated.


After the model and the object have been created, and the device itself has been configured and configured, it can be considered connected to the platform. Now it remains to make sure that the data from the device is actually sent to the platform and displayed in its interface.


Designing an automation scenario

In this case, the key points are turning the air conditioner on and off. It is they who will act as states when designing an automation script.

When the automaton is started, the object is in some “Initial state”. The transition from this state to the “Air conditioner on” state (first turning on the air conditioner) must occur when two conditions are met simultaneously: if the temperature in the room exceeds 22 degrees and if the window is closed.

Then a cycle is formed. The air conditioner can be either on or off. The transition from the “Air conditioner on” state to the “Air conditioner off” state occurs when one of the conditions is met: either the temperature drops below 22 degrees, or a window opens. The reverse transition occurs under the same conditions as in the transition from the “Initial state”.


It remains to run the designed script for execution by creating a container at the controlled object.

We use cookies to improve your experience. Let’s accept it and move on.