Data Model

The N-Hub data model is built around devices, users or API keys and groups

Devices

In N-Hub Sensors and actuators are all considerd devices.

All devices support data uplink - sending data to N-Hub - but only some devices have downlink capabilities for remote control or configuration.

Most devices on the market come with multiple sensors. To support this N-Hub groups device readings - where the parsing takes place - in channels (one per sensor).

Depending upon the device all or only some channels may be reported with each uplink so a device reading may contain a variable number of channel readings.

Users and API Keys

A valid user or API key is needed to interact with N-Hub.

They both behave very similary and share a nearly identical data model.

Access Levels

There are 3 levels of access: reseller, admin and readOnly

Enterprises

An enterprise represents a Neura client in the multitenanted architecture. Each device is owned by one enterprise.

Enterprises are organised in a hierarchy or tree model where the non-leaf nodes are called resellers .

Each enterpriseId contains the names of the resellers above like in the following example:

Groups

N-Hub groups are the most interesting and powerful features in the N-Hub data model: they govern access to devices, users, api-keys and enterprises.

Every entity in N-Hub belongs to one or more group.

Master groups

Every enterprise has an associated master group.

For example the enterprise n-hub has a n-hub.master group

Every device that belongs to n-hub will belong at least to n-hub.master

Subgroups

Within an enteprise subgroups can also exist.

Roughly speaking every group name that doesn’t end in .master is considered a subgroup.

Example:

enterpriseId: n-hub

master group: n-hub.master

subgroup: n-hub.water

Access to devices

Users and API keys gain access to devices, other users and API keys by belonging to 1 or more matching groups (either master or subgroups)

Users and API keys can belong to multiple groups like in the following example:

Example:

user test@test.com belongs to n-hub.client1.master and n-hub.client2.master.

It can access all devices linked to enterprises n-hub.client1 or n-hub.client2

In order to delete or update a user or API key the same level of access (group list) or superior is required.

Groups and hierarchy

Group membership automatically expands and cascades according to the hierarchy

Given the following hierarchy:

Example:

n-hub -> client1

n-hub -> client2

n-hub -> client3 -> client4

n-hub -> client5 -> client6

If a user has access to group n-hub.client3.master it automatically gains access to n-hub.client3.master, n-hub.client4.master - cascaded access

If a user has access to group n-hub.master it automatically gains access to n-hub.client1.master, n-hub.client2.master, n-hub.client3.master, n-hub.client4.master, n-hub.client5.master, n-hub.client6.master

Subgroups and access

Users are considered with limited access if have access only to subgroups like in the following example:

Example:

user: test@test.com

groupList: n-hub.binsensors

Subgroup access does not cascade.

Subgroups and enrollment

LoRaWAN device enrollment requires access to 1 or more master groups.

Subgroup access only is only for data sharing.