HomePort Introduction

Table of Contents

• Overall architecture
  • Public header files
• Use cases covered by the API
  • Configurator
  • Adapter Developer
  • Application Developer
  • Sub-tasks

Overall architecture

A HomePort Executable

In general, a HomePort installation consists of the HomePort library, one or more adapters and applications, and a main program that combines everything into one executable.

• Adapter: A module that provides a connection to one or more devices.
• Application: A module that utilises this data, typically by providing an interface to a cloud.

Public header files

The header files provided by HomePort (excluding the common utilities) are structured in the following way:

Their purpose:

• hpd_types.h: Only type definitions, can be used in header files to obtain the types without the functions.
• hpd_shared_api.h: Functionality shared between adapters and applications, used in libraries that may be used for both.
• hpd_adapter_api.h: Adapter functionality, should only be included by adapters.
• hpd_application_api.h: Application functionality, should only be included by applications.
• hpd_daemon_api.h: Daemon functionality, should only be included in file defining main().
• hpd_api.h: Everything in one file for the lazy, sometimes used inside HomePort when it is not possible to separate between adapter and application functionality.

Use cases covered by the API

Actors involved:

• Configurator: Collects a set of modules into an executable file with a main function.
• Adapter developer.
• Application developer.

Configurator

Functionality provided by: hpd_daemon_api.h

Tasks:

• Start and stop HomePort [Main Program].
• Add modules to HomePort [Main Program].

In addition, the configurator needs the module definitions (hpd_module_def_t) as provided by the adapters and applications to add them to HomePort.

Adapter Developer

Functionality provided by: hpd_adapter_api.h

Tasks:

• Define a HomePort module for the configurator [Modules].
• Manage the appropriate models in HomePort (adapters, devices, ...) [Adapter API].
• Answer to a request for a value [Adapter API - Communication].
  • Read contents of PUT value [Shared API - Value structure].
  • Construct the value [Shared API - Value structure].
• Report that a service have changed value [Adapter API - Communication].
  • Construct the value [Shared API - Value structure].

In addition, the adapter developer may need to browse the models provided by the adapter, when communicating with the underlying network (as they can store data within these models) [Shared API (Adapters and Applications) - Part II].

Application Developer

Functionality provided by: hpd_application_api.h

Tasks:

• Define a HomePort module for the configurator [Modules].
• Browsing available services in HomePort [Shared API (Adapters and Applications) - Part II].
• Request a value [Application API - Communication].
  • Construct the value for PUT request [Shared API - Value structure].
  • Read the response [Shared API - Value structure].
• Listen to events [Application API - Communication].

Sub-tasks

The following tasks may be a sub-component for those mentioned above:

• Functions for logging (error) messages [Logging].
• Functions for managing indirect references [Indirect references].

HomePort data model

The model layer in HomePort remains consistent with previous version, and from the outside looks like this:

HomePort Data Model