IOT Directory and Devices

×

Warning message

  • You can't delete this newsletter because it has not been sent to all its subscribers.
  • You can't delete this newsletter because it has not been sent to all its subscribers.

       Snap4City IOT Directory and Devices

click the image to access the tool (for registered users), see the video

The new version of the IoT Directory added more feature to manage the Smart Data Model and multiple brokers

Snap4City Platform provides support to:

  1. Manage different kinds of IoT BrokersIoT Devices and IoT Edge Devices. based on different protocols, formats, and modalities to establish connections with the IoT Platform.
  2. Connect External and Internal Brokers. Internal Brokers are deployed, registered and managed, while the External Brokers would be only registered to use them since are managed by some third party. In general, the brokers could be multiservice, for example the Orion Broker with NGSI V2/LD protocol.
  3. Register, manage and use messages conformant to any Data Model with any data type. Providing, receiving, managing, storing, and retrieving messages for any IoT Device (of any Data Model) with its attributes and data types, and related access control. It is difficult to manage the huge variety of data kind. It includes the capability of addressing Smart Data Models, IoT Device Models of Snap4City, and any custom model.
  4. Verify the correctness of IoT Messages of IoT Devices. 
  5. Semantic Interoperability. This requirement is fundamental to achieve the coherence among different IoT Devices (e.g., provided by different builders, addressing the same concepts, information on attributes). An IoT Platform should be capable to recognize/classify/retrieve information/attributes and behave accordingly to the semantic data model and types.
  6. Support automatics cloud deploy of Internal IoT Brokers. The Internal Brokers are directly managed by the Platform to directly performs the registration of IoT Devices. The result is a simplified experience for the users to populate the network
  7. Register External BrokersSnap4City can register IoT Devices/Services of an External Broker into the IoT Platform. Brokers can be single- or multi-tenant and to recover the IoT Devices data model managed by the Broker is the first step to perform their registration.
  8. Discover IoT Devices on IoT Brokers. Snap4City can harvest IoT Devices from IoT Brokers to  automate registration and for their classification and search, which is based on their position, nature, value types and units, etc. In other words, it should be possible to discover/search (subscribe, get, send data) to/from IoT Devices independently from their position/ connection in the IoT Network. The process of discovery is manageable in the sense that its execution time can be scheduled, and possible with external brokers that support a process for device discovery. The result consists of an automated or semi-automated registration process of IoT Devices and matching the semantic model.
  9. Semantic identification and matching. Snap4City recognizes automatically the model’s device and its semantic information for attributes. In this way, when the discovery is performed, the devices’ messages are automatically understood and add, problems are minimized.  
  10. Easy management to list and test IoT Brokers, and IoT Devices and query them for example via a graphic user interface. For each IoT Device, it has to be possible to perform testing activities.
  11. Manage IoT Device Model and Device Data Type ownership and access grant. This permits assignment/changing of the ownership and the creation of access grants to the entities (IoT Brokers, Devices, and Data Models). In delegation management, it must be possible to grant, list and revoke them. According to GDPR, any entity must start as private of the owner. The delegation should be possible for organizations, groups of users, and single users and can be different types. In particular, it can be about:
  • a.     messages - delegated  users can read and write or only read the messages of a certain IoT Device;
  • b.     IoT Device Models – delegated users can modify or only read the model structure;
  • c.     IoT Devices – delegated users can modify or just view the device structure.

Other notes:


The IoTDirectory is a web application developed for monitoring and managing the devices (sensors/actuators) that are available in the city by means of their Context Brokers.  The IOT Directory allows you to see IOT devices at level of devices and single sensors/actutora with their ValueType (temperature, pression, velocity, humidity, etc.): and ValueUnit (float, integer, etc.). So that the value type is concept that goes in the semantic of the data, while the value unit is something more technical that describe how the value is coded and represented. Depending on the Context Broker a device (sensor/actuator) is identified by means of specific id field (as in Orion Context Broker) or through the name of the channel/topic according to which their values are published (as in MQTT, NGSI e AMQP, and other protocols as well).

The IoTDirectory allows the developers to:

  1. see and manage the list of sensors and actuators according to their valuetype, valuename, healthiness criteria, etc. providing also the evidence about its status, and position on the map, if any. It also provide some descriptors about the device and sensors kind. 
    1. it is also possible to add a new sensor to a device/actuator, to add your private values. 
  2. see and manage the list of devices automatically associated to a Context Broker and update of their properties (producer, model, geo-localization, etc.) by means of a web form. Moreover, the system identifies the presence of possible attributes that constitute the device schema of the sensors. For each attribute the system automatically infers its basic type (string, integer, decimal, date, etc. )  when the produced values are organized according to a list of basic templates (available for comma-separated values, JSON and XML).
    1. is is also possible to add a new device, to add your own device
  3. Semantic labelling on the attributes in the device schema. There is a huge variability on the names adopted in different devices for tagging the observations. For this reasons we have included in the Km4city Ontology a set of basic concepts (like “latitude”, “longitude”, “timestamp”, “status”, “temperature”) that can be exploited for describing the concept that an attribute wishes to express. In this way, we can facilitate the retrieval of sensors relying on them. For example a mobile phone can produce its position by means of a pair (“lat: 45.4642,long: 9.1900”). The two tags can be semantically labelled with “latitude” and “longitude”. The system offers facilities for the automatic inference of the semantic labelling and further facilities will be developed in the next version of the system for limiting the user intervention in this activity.
  4. see the available context brokers independently from the communication protocol (either MQTT, NGSI, AMQP, etc.).
  5. Activate the monitoring of a Context Broker and updating of the current available devices; this is an important feature for automatically loading in the IoTDirectory the devices (sensors/actuators) exposed by the Context Broker and keep them updated each time a new device appears. 

The IOT Directory can be accessed at the following links: https://iotdirectory.snap4city.org/management/ssoLogin.php?redirect=mydevices.php%3FshowFrame=false

We suggest you to follow these examples and readings in the order:

Comments

I tried following the video guide (link) to add a device from the IoT Directory to the IoT App and create a simple Dashboard.

In the video, when using the IoT Directory Node and select the devices you want to add an extra flow is automatically generated. However, in my case this extra node is not generated and therefore I cannot add any device to my IoT App.

roottooladmin1's picture

that mechanism for generating the automatically the Flow is partially obsolete since the it has been rplaced by new NGSI V2 blocks that are not managed. 
i suggest you to follow the training course from the slide and not the older versions that you find on the web pages.... they may include some mistakes..

paolo

Thank you very much for your reply.

By checking in the slides, I've found a lot of valuable information on how to ingest data.

However, I wasn't able to find information on how to consume data with the IoT App. (Import in real0-time, historic data of a sensor in the IoT App and use it in the flow).

Would you be kind to direct me to the respective resources (articles, videos, etc.)

Thank you.

PS. On some flows trying to use fiware orion blocks with orionUNIFI (broker1.snap4city.org), I get an ERRCONNREFUSED error.

Is it maybe that the broker is not online?

roottooladmin1's picture

You can consume data from IOT App in several different manners:

-- exploiting the connection with the IoT Device connecting with the Broker, using the IOT Nodes, even driven

https://www.snap4city.org/download/video/course2020/iot/Snap4City-3rd-slot-IOT-Applications-v6-9.pdf

see slide 370: orion broker of V2 NGSI syntax .....

-- accessing the historical data from serviceinfo dev node, which is not even driven but in a single call can provide you last real time and historical data, referring to t he serviceURI, the serviceURI of IOT devices can be recovered from the IOT Directory (IOT Device list of you devices,) from data  inspector, from servicemap, etc. 

https://www.snap4city.org/download/video/course2020/iot/Snap4City-3rd-slot-IOT-Applications-v6-9.pdf

slides 257 around there 

-- exploiting the MyKPI data with Load MyKPI, historical and event driven
 

paolo

 

 

 

 

roottooladmin1's picture

If you have specific problem on some IOT App we can enter on it and solve it with you when needed,

PN.