Application settings

1. Message Formats

   Several standard formats are provided with the initial installation. They are optimized for optimal and fast exchange. The administrator can modify them to suit his needs or add others. The screenshot below shows some formats with their descriptions. By enabling or disabling formats, we can control their use by brokers. Formats can be of JSON exchange type, XML  or Protobuf.

   

    

   The detail screen is used to add, view, or edit message formats. The fields visible on this screen depend on the type of exchange selected.

   Each Format, whatever its type, must have generated an equivalent schema in JSON giving the platform the possibility to understand and convert the message into JSON. For each type we then find:

   1. Name : Unique code of the format, it is used in the conversion process.
   2. Exchange type : JSON, XML or Protobuf
   3. Message definition : Proto structure for protobuf type or an example message for JSON or XML types.
   4. JSON Schema :  the equivalent of the message in JSON schema, allows you to describe a standard structure for the exchanged message. The schema can be generated automatically by clicking on the "Generate from message" button.

    

       - JSON exchange sample

     

       - Protobuf sample

   

   For a protobuf exchange, you must define the proto schema in the left pane. The system then generates the equivalent schema into which the received message will be converted and deserialized into JSON.

   The format name must be the same as the main proto type in the schema.

   PMS Format  

   

   Creating a message format with the PMS box checked means that the message is aligned with the default structure on the platform side. Therefore, no conversion is necessary and the message acquisition will be smooth and optimized. PMS messages can be of type Json, Proto or XML.

    

2. Messages lifecycle

   The IoT message lifecycle corresponds to a succession of stages or statuses through which these messages pass, from their emission by the devices to their final processing. It makes it possible to structure and model the message journey, by defining the different phases of reception, validation, processing, and possibly storage or archiving. This mechanism facilitates the management, monitoring, and execution of the necessary processes throughout the processing chain of data transmitted by connected objects.

    

3. Attribute Value Interpreters

   Attribute Value Interpreters are processes for analyzing or comparing attribute values sent by connected objects in IoT messages. 

   Depending on the IoT domain and the attributes involved, they allow the received values to be classified into levels. This allows system flows to immediately identify urgent messages or those with critical values and provide timely notification or execute a defined process.

   Levels are configured in the application as shown in the screenshot below. A value level is defined by the level number, name, description, and a color that will be displayed in KPIs or analysis tables.

   The example below shows a level '5' with the name 'Critical', in red, for a value that significantly exceeds the standard value.

   

    

   The application offers two modes for interpreting values received from connected objects. The simple mode automatically compares each value to predefined thresholds, to determine whether it is normal, high, or critical. This mode is easy to use and suitable for traditional data such as temperature or pressure.

   

   Advanced mode, on the other hand, is intended for administrators or developers. It offers the ability to write custom functions using an integrated development language. This allows for more advanced analysis, especially for processing complex data such as images, audio files, or other types of media.

    

4. Entities

   Entities in IoTRoutes are hierarchical in structure and represent groups, divisions, or individuals, and are divided into two categories: internal (such as subsidiaries, departments, or services) and external (usually customers).

    Their main role is to associate connected objects with a specific group, in order to restrict user access only to the data assigned to them. In a shared environment, for example, this allows a client to access only their own objects and a user in a department to have access only to their department's data.

   Accessible from Application Settings >> Entities, the screen below allows you to view and manage the list of entities.

   

    

   The detail screen shown in the screenshot below allows the creation and modification of entities as well as the association of devices, the assignment of users and the linking of sub-entities. A user assigned to an entity in the hierarchy will have access to the entity and all child entities.

   

    

5. General Settings

   Allows you to define and manage a set of parameters essential to the operation of the IoTRoutes platform and the processes that run on it. This section serves as a central configuration point to adapt the application to different environments or usage contexts.

It offers the ability to create and save multiple distinct configurations, for example:

One setup for production environment, One for testing, Another for training or demonstration, etc. 

However, only one configuration can be active at a time, ensuring that the application always operates according to a consistent and controlled set of parameters. This flexibility allows the application's behavior to be quickly adjusted as needed without having to manually change parameters with each context switch.

There are two groups of settings as shown in the screenshot: Application settings and running process settings.

• Intra-server event topic: The topic used for events communicated between servers or internal services.
• Maximum allowed payload: Maximum message size sent by connected devices.
• Save payload as blob from: Size limit, beyond which attributes will be saved as a blob (media database) managed by the file storage manager.
• Timestamp calculation: A specific timestamp calculation method converts a date value into a small integer value used for optimized communication between the platform and devices. For example, the date will be represented by the number of milliseconds, seconds, or minutes since January 1, 2020.

• Parameter Refresh Interval: Continuously running services load their configurations at platform startup, any configuration changes are automatically taken care of at a specified interval in number of minutes

Next :  Workflows