Model of control object is a formalized representation of devices logic and hardware functions managing the object of control. The model has a tree-like structure containing subsystems, arguments, events and actions.
A fundamental assignment of model consists in increasing of an abstraction level from protocols and hardware realization to legible, human-transparent names of the object functions that makes the work of a programmer easier relieving from the necessity to explore the protocol. The data processed in this way take a shape of the RESTful API request in json format which is handy for mobile applications developers.
The device model figures in processes of data serialization and deserialization, data normalization, interface rendering, also in scenarios of automation designing.
There is no need to create the model for every one of the same type objects. Once created model may be used for both one and several objects if they keep a similar set of identified parameters and executed functions.
The process of control object model configuring consists in model parameters definition in the form of the next tree-like structure nodes:
arguments are the parameters values of that are transferred by the object of control in the system of sensors. The arguments may have number, string, boolean data type, represent an object or an array. What is more, it is able to point an unit of measure for the number arguments;
events are committed actions that either were independently recorded by the object of control itself and, in accordance with established behavior logic, were sent in the system or occurred in external applications also participating in a business process;
actions are operations that device perform. They divide to several types:
subsystem is not a configurable type of node which serves for the model structure organization allowing to unite parameters in groups.
In establishing new commands, parameters and events in the model, "inheritance" is always performed from the basic protocol. To create a new command, it is necessary to "inherit" from the basic command of the protocol on which the device operates, and enter the arguments with which the one or several commands will execute. In a similar way, it works for the events and the parameters. For example, if data is transmitted from the device to the platform and back via the MQTT protocol, it is necessary to specify the data source for the arguments. In case of MQTT this source is called a topic by which the data is transmitted.
For the convenience of subsequent use of the model parameters newly created, it is better to give them associative names. The identifier of the parameter is applied for normalization in json as an argument key. Eventually, the structure of data acquired as a result of the normalization will correspond with the model structure.
Due to the models, the hardware operating according to different protocols, but installed in the similar objects of control, may be used in one scenario of automation. Comparing identifiers of nodes with the models structures, the platform will normalize data in equivalent json objects.
The process of model configuring represents a creation of a tree-like structure consisting of parameters. At the same time, the parameters are set from basic functions of the protocol by which the device works.
Configuring of the model for specified protocols is considered in the section of examples.
ATTENTION! If a user does not have appropriate access rights to the device model which is assigned to the control object, the rendering of interfaces associated with the data viewing will not be performed.
The virtual model creation of a physical device includes the next steps:
Following that, it is necessary to fill the next fields:
The model of widely spread protocols, such as MQTT, offers a structure just for instance, in any case, the user will have to modify it for yourself. In event of a proprietary protocol, for example, Wialon IPS, the model already represents the structure ready for using.
After clicking the "Create" button, a new model will be created. Now the user can start to configure it.
By default the created model will looks like this:
The external software modules are added in the model by default. They represent the list of pre-established functions that describe a business process in a logic template. The external software modules include:
Any node of model may be deactivated by deselecting check box. After that, the system will stop to process the node.
It is possible to add new parameters by clicking on "+" icon. Notably, the new parameter will be a branch from the node from which building of this parameter occurred (i. e. the new node will be lower on one level then initial). Besides that, the parameter can be deleted or the analogous one can be created by coping. All nodes of the structure are free to rename.
type: the node can be configured as the subsystem, the argument, the event or the action. Depending on chosen type, there will be offered corresponding separate fields to fill in (see below);
identifier: it is generated by the system itself automatically. The identifier is used for the node indication in the system. It may be changed by the user;
The identifier is the name of the field for an internal device state accessed via API.
name: it is used for displaying of the device name in all the platform sections;
description: it provides a brief representation of the parameter. It is convenient to use the description in preparing the final state machine where it will display as a tooltip on mouseover.
The "On parse" and "Display" tabs open the additional fields.
execute: here the type of action is chosen that is necessary to be executed;
in case of choice of an automaton or a custom action (severless), in the last field should be pointed such automaton or action that are necessary to be executed;
in event of a command of device selection, the message publication is specified in the "Send" field, after that, the corresponding parameters are pointed: