|
Test Case Title |
TC9.1 - IOT Discovery overview |
|
Goal |
I can Discover IOT devices |
|
Prerequisites |
…access to an IOT application The following functionalities are available only for specific Snap4city users with specific privileges. |
|
Expected successful result |
To see where the IOT devices are. |
|
Steps |
The IoT Directory manages, from a single point, sensors belonging to different IOT Brokers and adopting different formats and communication protocols in a common and uniform way. However, the need arises to identify a common and uniform approach for accessing and discovering devices (sensors/actuators) by means of the Snap4City Application Builder independently from the context broker that manage them. For this reason, we have developed two MicroServices (implemented as nodeRED blocks -- named IoT Directory IN and IoT Directory OUT) that have the purpose to make easy the access to and enquiries of the information provided by sensors/actuators and for easy sending commands and notifications to several actuators (belonging to different Context Brokers) by means of a single message. Moreover, we have developed microservices for the registration of new device that leverage the user from the burden of manually configuring the access to the context broker and specifying all the mandatory fields required for the registration of a device in the contest of snap4city. They are accessible from Snap4City Applications.
The MicroService block “IOT Directory” is used for reading events from sensors and notifications from actuators independently from the Context Broker that is in charge of their management. By double-clicking on it, the following form is shown:
By mean of which the user can explore the IoT directory from two points of views:
- Device-based search: through this point of view it is possible to retrieve devices according to their properties (parametric search) and using the map (map search);
- Value-based search: through this point of view, it is possible to retrieve the single values (sensors/actuators) that are contained in the devices according to their properties (parametric search) and using the map (map search).
By using the “map-search” on the device-based search tab, a map is shown to the user. The pin on the map can be clicked and information about the device is shown. Blue pins identify public devices, whereas red ones represent those that are private. The user can select the devices along a polyline 
, within a polygon 
, within a circle
, closer to a point 
on the map for identifying the devices available in such an area.
The devices contained in the selection area (depicted in blue in the figure) are reported in the following list that the user can further refine:
By using the “parametric-search” on the device-based search tab, the obtained list of devices can be further refined relying on their types (humidity, temperature, …), kind (sensors or actuators), and Context Broker (e.g., OrionUNIFI, MosquittoUNIFI, …).
In the “value-based search” similar facilities to those presented for devices have been developed with the purpose to access to the single values belonging to devices.
Once the user has terminated the selection of the devices (or values), he clicks the “done” button and a flow is automatically created for reading observations from the selected devices/values. The flow is positioned into another tab (automatically generated) for leaving room in the current tab for the development of the IoT application. The flow contains Context Broker nodeRED blocks (one for each selected sensor) that are automatically configured and a transform node that collects the events generated by the devices/values and produce events in a common format. Such events are made available in the current tab by means of “links” that are automatically positioned. Moreover, and event-log block (developed by us) is included in the flow for keeping track of the amount of messages that are exchanged by this flow. The data produced by the sensors are parsed and organized in a common and uniform JSON-based format that facilitates the development of code for processing the events generated by devices/values. The following example shows an example of flow automatically generated by the system.
The MicroService block “IOT Directory” is the equivalent of the previous one for the discovery and selection of devices/values to which commands or notifications should be delivered. It offers the same discovery options and produces a nodeRED flow containing a collector of events that distribute the commands/notification to the actuators belonging to different Context Brokers (in case of the Orion Context Broker the message is formatted in its JSON representation). The following figure shows an example of nodeRED flow generated by selecting two actuators.
In this last example, we have adopted another option developed for the generation of the flow for sending commands/notification: the “aggregation by value_type”. By means of this option it is possible to send a command to the specific values of a device and thus making easier the development of IoT application for final user that has just to wire the command to the specific actuator.
The MicroService block “Device Registration” has been realized for supporting the user in the registration of a new device. Two versions have been realized: one for non expert user and one for experts. Their purpose is to support the user in the registration of a new device in the snap4city environment. The first one requires the minimum number of information required for generating a device (its name, model, and position on the map), the other one gives to the user the possibility to create custom devices that are not included in the list of supported models. When the device is created for personal use (i.e. it is private of the current user) a couple of keys should be specified (k1 and k2). For certain model of devices, these keys are automatically generated. In case of the model SigFox, these keys should be acquired by the SigFox server. Instructions are provided to the user in the following link for the generation of the management of the available models (https://www.snap4city.org/drupal/node/76). The following screenshot show an example of registration of a device for final user:
The general/abstract view of services on the field is obtained by using the Blocks/MicroService referring to the Advanced Smart City API. The user in that case can discover services (IOT, ETL data, etc.) on the map, identify them and use them in the context of the IOT Application.
