HOW TO: Use a FIWARE Smart Data Model for creating devices

FIWARE Foundation drives the definition – and the Open Source implementation – of key open standards that enable the development of portable and interoperable smart solutions in a faster, easier and affordable way, avoiding vendor lock-in scenarios. The Foundation also provides to Smart Data Models (SDM) for each domain of interest, such as Smart Cities, Smart Energy and so on.

Snap4City allows to create devices according to:

The solution is based on Snap4City IoT Directory which allows to:

  • Collect the Smart Data Models from the GITHUB, where they are defined, versioned and listed
  • List, search and browse FIWARE Smart Data Models, manage them
  • Edit and customize the Smart Data Models, if needed
  • Automatically register IoT Devices which are registered in External IoT Brokers, according  to their Smart Data Model or any data model they have
  • Recognize automatically  IoT Messages of devices which are compliant with Smart Data Models or custom data models
  • Register automatically Smart Data Model, IoT Device Model or custom model to Knowledge base and storage to be immediately used in the creation of Dashboards and tools.
  • Any registered device including those of Smart Data Model, IoT Device Model or custom model can be managed into IoT Applications for data processing, data transformation, adaptation, and Data Analytics
  • Delegate in read, read/write messages  on devices, and also modify the model.
  • Define rules for mapping undefined Value Types, Value Units and Data Types of Smart Data Models which can change according to the developers towards formally defined types in the Snap4City Dictionary to make the data directly exploitable in tools and math transformations.

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 BrokersThe 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.

To understand better this guide, we suggest you to follow the guides “HOW TO: add a device to the Platform” and “HOW TO: Create an IOT Device Model” .

FIWARE Foundation drives the definition – and the Open Source implementation – of key open standards that enable the development of portable and interoperable smart solutions in a faster, easier and affordable way, avoiding vendor lock-in scenarios. The Foundation also provides to Smart Data Models (SDM) for each domain of interest, such as Smart Cities, Smart Energy and so on…

To our scope, we can see the SDMs as Model device. Their main difference is that they don’t be associated to a specific Broker, but in addition they have explicit: domain, subdomain and version.

The purpose of this guide is give an example ready to use for the registration of a device from a known and well define SDM. We use a main case use to make easier following steps.

CASE USE. An user should register an Alert for discount of an organization X in Snap4City Platform and wanted to instance on them a known SDMs called ‘Alert’ with subdomain ‘Alert’ and domain ‘CrossSector’. To understand the work flow, he starts to register one device and display its data history on a Dashboard.

FIRST STEP: verify and chose the Smart Data Model

After the log in into the Platform Snap4City, the path that the user must following is:

“MENU -> IOT Directory and Devices >FIWARE -Smart Data Models Library”

Here he/she can browser the FIWARE Smart Data Model.


If the type of user isn’t Tool Admin or Root Admin, the user can only view the model and can edit it only when he/she instances the device.

In other case, he/she can edit directly the model from this form.

In the first tab we can see the general info of the Smart Data Model, such as: name, version, domain, subdomain and subnature. In particular, the subnature is the semantic part of the information and it is specific for the Platform Snap4City.

In the second tab, the user must assign for each attributes the value type, the value unit and the data type. Also, if you want, you can change the healthiness criteria and healthiness value.

Once the model is well define, you can follow step.

To have a better and in-depth point of view about Model definition, you can see “HOW TO: Create an IOT Device Model”. 

SECOND STEP: Device Instance

Following the path:

“MENU -> IOT Directory and Devices >IOT Devices

And then click on the button “Add new device”.

Then the usual form will pop up. So, the user can fill the whole fields while paying attention about the model and the Broker. As is shown in the below figure. For an in-depth study see “HOW TO: Create an IOT Device Istance”.

Once you have the instance of device, you need to make the link for the data flow.


THIRD STEP: IOT APP for the data flow

Following the path:

“MENU > IOT Applications > IOT Applications

And clicking on the button “Create New” and filling the setting fields as shown.

Then, the user can be able to make own Nodo-RED flow to address data from device with their visualizzation. A simple example is below:

The main block of the flow is ‘SalesAlertTrend’, which builds automatically the dashboard and give you its URL.

We suggest you to follow the guides for a deeply comprehension.

FOURTH STEP: Shown data on a dashboard

Once the dashboard is ready, the user can be able to customize it and to see the plot of data. Following is shown a basic dashboard

Read more on: