Object oriented Data Model which covers the interactions between users and objects

B2C user:

• End-user of the solutions. He/She can manipulate devices at a site.
• This business object is always associated with a user account to authenticate it.

B2B user:

• B2B user of the solutions. He/She can manipulate devices across a fleet.
• This business object is always associated with a user account to authenticate it.

Site:

• A site corresponds to a user's home or building.

Fleet:

• A fleet corresponds to the fleet of devices managed by a B2B user.

Gateway:

• Connected product allowing access to the various devices associated with it.

Device:

• Product enabling to capture information or to carry out actions. The device also presents status and configuration data.

Asset:

• An asset here is a device that is declared in the platform. It is declared to authorise a device or a gateway to access the platform.

Business-oriented Data Model which hosts the different business ontologies around buildings (connected home, collective housing...).

User:

• User of the solutions. He can manipulate devices at a site.
• This business object is always associated with a user account to authenticate it.

Space:

• Element of physical representation of a building: room, floor, exterior...

View:

• Element of logical representation of a building. It allows the creation of groupings independent of the physical dimension of the building: thermal device fleet, common space...

Device:

• Product allowing the capture of information or to carry out actions. The device also presents status and configuration data.

Here are 2 examples of topology that could be defined for a twin
"building".

Once the topology framework is defined, you can instantiate it to represent your actual buildings. Thus, you can develop your applications by manipulating the twin, and optimise the use of data for new services.

Because privacy and security are essential, you should follow the OAuth 2.0 protocol which is the industry-standard protocol for authorisation and the most secure authorisation protocol.

Finally, never store users’ credentials. This is strictly unauthorised. You can only store the access token/refresh token

Scope:

Your app isn’t automatically granted a scope, users give you scope permission while authorising your app. During the OAuth process, you will be able to request the scope you need for your users, your token will be limited to those scopes. So only use the scope you need.

All the platform's services are accessible via REST APIs.

The use of the REST technology makes it possible to standardise the exchanges relating to the data and business objects handled by our platform. This facilitates the adoption and integration of our services into your applications.

The REST APIs are based on the HTTPS protocol and only allow synchronous exchanges between your applications and our services.

Some use cases require the use of asynchronous exchange such as a return requiring long processing on the backend side, event feedback....

In this case, you can use:

• Web Hook: Mechanism to configure callbacks to your backend (HTTPS callback with authentication via API key)
• MQTT: API available via an MQTT endpoint allowing synchronous & asynchronous exchanges. These endpoints are also secured by an OAUTH 2.0