The device connection via MQTT

The next case is considered. There is given a room in which it is necessary to adjust a temperature constantly. If the temperature exceeds 22 degrees and a window is closed, an air conditioner must be turned on. If the temperature decreases or the window is opened, the air conditioner must be turned off.

Thus, there are the following devices:

The devices may not exhibit Internet access. Such devices cannot receive commands from the platform and send data to the platform directly. They should be connected to a controller that has Internet access and can connect to the platform for data and commands routing.

In this example, the devices communicate with the platform through the controller. It sends the data using the MQTT protocol. Therefore, in this case, the controller will be an object of control on the platform, and only one MQTT model will be created.


The model will look as follows. As it is seen, there are enable two parameters (the Temperature and the Humidity) and two commands (Turn-on LED and Turn-off LED) by default.


The air conditioner management should be carried out based on data sent by the sensors, which should collect readings about the temperature in the room and about the opened or closed window.

It should be noted that arguments with different data types must be added for two current sensors. The temperature sensor is able to message various temperature values. Accordingly, it must be the numerical argument, the value of which should be represented in degrees Celsius. Since the window can be only in two states: opened or closed, the data type for this argument is the boolean. The data from the sensor on the window can be sent both with the value 1, if the window is closed, and with value 0 if it is opened. At the same time, the air conditioner itself may send two commands: turning on and turning off.

So by configuring the model, it is necessary to add the new argument for the window sensor and supplement the information about the Temperature argument (for example, to state the source). The Humidity parameter, added in the model by default, will not be used; therefore, it can be deleted.


For more information about the fields assignment see the Model of control object section.

When the new parameter is created, all the necessary parameters are filled. An argument is selected as a type. The ID field may be left with no alterations (because this case does not intend to use API).

If it is necessary to use the platform API, it is recommended to change the ID, which is generated by the platform automatically, to more useful.

Following that, the name is entered that is more convenient for further viewing of the interface. Since the sensor transmits the value 0, if the window is opened, or the value 1 if the window is closed, the boolean type should be selected as the data type. In the Source field, a topic is specified by which the device sends the value of the window parameter.

For describing the commands sent to the conditioner, the commands for turning the LED on and off should be edited exhibited by default.


An action is selected as a parameter type. The understandable ID and name are assigned to every command. Next, the type of action, a command to a device, is set. In order to send a message about the command execution necessity, the command "PUBLISH" should be specified. The message will be sent and published to set topic base/air_con. If the message is sent to this topic and with a payload equal to one, the controller will turn the conditioner on, because the window will be closed. And alternatively, if the message will be sent with the payload equal to zero, the air conditioner will be turned off.

The object creation

In this case, the primary device is the controller that manages the conditioner operation and reads sensor readings. Therefore, only one object should be created for the controller.

For that, it is necessary to move to the Objects menu and open the dialogue box of the new object creation. The model is chosen from the drop-down list box. After that, the ID is entered used as ClientID in the device firmware to connect it to the platform. Next, the object name and, if necessary, its type and status are specified.


After the model and the object have been created, and the device itself was configured, it can be considered as connected to the platform. It remains to be known that data from the device are sent to the platform and displayed in its interface.


Designing the automation scenario

In this case, key points are turning the conditioner on and off. They will act as states precisely by designing the automation scenario.

When the scenario is started, the object is in the Initial state. The transition from this state to the state "Conditioner is turned on" (first start of the air conditioner) must be executed while fulfilling two conditions: if the temperature in the room exceeds 22 degrees and if the window is closed.

Following that, the cycle is started. The conditioner may be or turned on, either turned off. The transition from the state "Conditioner is turned on" to the state "Conditioner is turned off" is carried out while fulfilling one of the conditions: or the temperature falls below 22 degrees, either the window is opened. The backward transition occurs on the same conditions as the transition from the "Initial state".


Now the scenario of automation may be started, and the constructed logic may be executed.