Creation Review

End Date of the Review Period

Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.


Eclipse HIP

Tuesday, January 23, 2018 - 07:19 by Mark Healy
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Working Group
Proposal State

I had been assisting a (now defunct) IoT startup in identifying bottlenecks in their data ingestion and aggregation process when I realised that a lot of the data processing could be managed by underutilised "Things", mainly Intel Edison devices used across the deployment. I started to examine how this could be implemented and managed as part of a new IOT ecosystem.


HIP (Hierarchical IOT Protocol) is a communication protocol designed to increase the scalability and interoperability of large scale IOT deployments and includes specifications for both Platform Side (e.g. SaaS solution) and Deployment Side (e.g. sensors and actuators in a "smart building") messaging. Core concepts within the protocol are Aggregators - which allow for "deployment-side" data processing, Commanders and Delegators (previously referred to as Brokers), which provide local (again,deployment-side) control of actuators and Health messaging which can be used in conjunction with Configuration messages to identify over and under utilised devices and spread roles across them.

Aggregators provide for a Hierarchical structure across a deployment, where relevent data from one or more sensors can be processed locally before being uploaded to the Platform. In theory, this enables data from unlimited numbers of sensors to be processed and fully addresses the practical issues within the scope of Fog computing. (Fog Computing refers to extending cloud computing to the edge of an enterprise's network)

The scope of the protocol includes all aspects of the configuration and management of a deployment. Health messages can be sent from devices to the platform to identify potential bottlenecks while Configuration messges can be used to transfer "roles" from under resourced device to devices with spare capacity. Functionality (or HIP roles) can be added or removed from devices through the use of "handler" messages, which include Base64 encoded compiled or interpreted classes or scripts.

The protocol is based around a number of defined roles which can be added or removed from individual devices. Each role has a specific set of messages associated with it.

To date MQTT has been used to implement the majority of the messaging (some REST APIs and websocket communication to support user-facing tools has been included but can possibly be considered optional)




Through HIP, localised processing or preperation of data is intended to reduce the connectivity and central processing requirements within IOT - much like the contemporary Fog computing paradigm, but without the need for sophisticated edge computing solutions. 

Base Device messages enable core functionality supports each "thing" in a deployment, with additional roles being configured through Configuration messages, and functionality enabled through Handler messages and files


In the above diagram, we have a very small and simple deployment (left of the dashed line) connected to the Platform on the right. Looking at the dashed line, all communication between the deployment and the platform is via a Coordinator on the deployment side [ CR ] and the Coordinator Link [ CrL ] on the Platform side, alllowing us to isolate other devices from the Internet.

The Orange Flow in the diagram is a command sent by a user to a particular actuator or controller (e.g. turn lights on/off), the blue flow represents data collection and aggregation across the deployment.

[ D ] - these are HIP enabled devices and can have a number of different roles which are described below. 

[ S ] - Sensors -  can be local sensors (e.g. temperature/lighting sensors connected to the GPIOs) or external, third party devices. Handler files are deployed onto the device to integrate with particular sensors and process telemetry data (e.g. read from a GPIO, make a REST call to an Arduino) - the use of handler files is intended to improve integration and interoperability.  


[ C ] - controllers, similar to Sensors, these can be directly connected or external - e.g. relays connected via USB or RF transmitters connected to the device to control lighting and heating/air con. - similar to sensors, the use of handler files is intended to improve integration and interoperability


[ A ] - Aggregators - the device configuration includes details of the MQTT topics to subscribe to (i.e. telemetry data from sensors or output from other aggregators) and publish aggregated output on. Handlers deployed to the device implement the operations to perform on the data (eg. read data from multiple sensors via subscriptions, process it and publish the output on a particular topic). For example, the Sensors connected to the aggregators in the diagram could all be temperature sensors - the first aggregator could compute mean, min and max temperatures for an open plan office, based on the readings from relevant sensors and the next aggregator could calculate the average temperature for a floor/building etc. Telemetry data from sensors can be subscribed to by any number of aggregartors, allowing the same data to be processed in multiple, independent ways.


[ B ] - Delegators (renamed from brokers as they could be easily confused with MQTT brokers) act as intermediaries between the platform and the controllers - so the delegator in the diagram could control all the lighting/heating controls for the open plan office. Delegators also allow multiple controllers to be included into the same command (for example, a "scene setting" command could manage or adjust lighting, blinds and AV equipment in a meeting room during a presentation/video-conference etc,). Delegators also allow other local devices (commanders, not in diagram) to interact with local controllers without having to interact directly with the platform


[ CR ] - Coordinator - essentially this is the edge device for a deployment - single point in and out of the deployment and the only local device which can communicate with the platform. In the event of a failure, this role can be moved to another device without the need for any sort of hot spares etc.



On the platform side, there are three main components, but in a practical implementation, these can be subdivided or combined.


[ CrL ] - Coordinator link - this sits between the core platform and the deployment and coordinates messages between the deployment and the platform (readings from the deployment and commands from the platform etc.)


[ P ] - this is the core Platform functionality and uses a combination of MQTT to communicate with the Coordinator Link and REST service and web-scokets to integration with client facing solutions


[ UI ] - this is any user facing solution.


[ DM ] - this is just a shared data layer used by both the platform and the Coordinator Link. It has no relevance in terms of the protocol, but is included here for completeness


Scalability is achievable through a hierarchical architecture whereby data collected from sensors can be processed and aggregated locally before being transferred to a central (cloud or on-premise) platform. Any device can be assiged the role of an "Aggregator" - allowing it to summarise, aggregate or otherwise process data from relevent sensors or aggregators so that the platform receives a single message with all the relevant readings (if desired) in addition to the processed output data. For example, rather than collecting and processing data from multiple sensors in an open plan office-space, HIP can transmit a single message summarising all the relevant data and store this without the need for further processing. In contrast to this, traditional IOT solutions tend to have a flat structure, whereby each sensor feeds raw data to the platform for subsequent, centralised processing.

Management is supported through the use of Health and Configuration messages. Roles such as "Aggregator" or "Controller" above can be assigned and configured centrally from the central platform UI. The "Health" messages update the central platform with the status of each device - allowing administrators to remove roles for under-provisioned devices based on their CPU or memory utilisation. For example, an Aggregator role could be moved from one device to another under-utilised device automatically from the central platform without the need for direct access to the relevant devices.

In addition to the protocol specification, a partial NodeJS implementation of the protocol is available across a number of GitHub repositories:

Platform: This is the main component within the ecosystem and is responsible for the vast majority of logic and control within HIP - it provides REST APIs for client (UI) solutions as well as websockets notifications and also communicates with the Coordinator-link via REST APIs and MQTT messaging

Device: This is any "Thing" deployed as part of an IOT installation, Any Device can have one or more of the following roles and all communication is via MQTT. 

  • Sensor - this is a local sensor (e.g. DHT 22 for temperature and humidity), or a remote device which is not HIP compatible. Invidivual handlers (e.g. JS file or Kura Bundle) can be deployed from the Platform to enable  the Device to integrate with the Sensor and forward readings on a poll or event-driven basis.
  • Controller (actuator) - Similar to Sensors, this can be a local or remote actuator and handlers can be deployed from the platform to enable integration. A collection of commands and their parameters are maintained on the Platform and can be pushed to local Commanders to enable local control/integration
  • Coordinator - this sits on the edge of a deployment/installation and acts as a single point of contact bwtween the deployment (the Things) and the Platform
  • Delegator - Commands from the platform or a local Commander can be routed through one or more Delegators. Different paths/rules etc. can be managed by the Platform and custom handlers deployed on the relevant device
  • Aggregator - Multiple Sensors can have their readings forwarded to one or more Aggregators and aggregator handler s can process that data locally before forwarding the output to the Coordinator and/or one or more additional Aggregators. For example, an open plan space in a large office may have a number of lighting/temperature sensors, in addition to uploading the individual readings, these can also be collated by an Aggregator to give a summarised view of the data - e.g. the temperature on the first floor or the ambient light levels on th easterly aspect of the building.

Coordinator-Link: This is an MQTT based solotion which is deployed between the Platform and the deployment (accessed via the Coordinator role on a specified device)

UI: this is a responsive frontend for the solution built in Angular and includes functionality for both administrators and end-users. The UI (and derrived Cordova apps) communicate directly with the Platform

Commander: this is (or will be) a standalone UI which communicates with the local Coordinator rather than the Platofrm in order to monitor associated Sensors and control associated Controllers

To date,  a significant portion of the functionality has been developed  - sensors can push data, via Aggregators and the Coordinator to the Platform and the Coordinator can accept MQTT messages and route them to the relevent controller/actuator. A number of additional components are under development (e.g. "health and status" messages from devices which will simplify the optimisation and role allocation across a deployment. The development of other elements, e.g., particular UI controls for viewing device and sensor status has not begun yet

Why Here?

I believe that Eclipse HIP could complement and even underpin Eclipse IOT. To continue outside of Eclipse would lead to significant duplication and could adversely impact the quality of HIP as a number of synergies may be overlooked. HIP is at a critical point where it needs to move from a conceptual to a functional project. I believe that certain aspects of the solution are close enough to completion to allow them to be reused across other IOT projects with minimal additional effort, while others need further evaluation and validation to determine how or if they should continue.


Project Scheduling

Ideally, I would like to draft a complete specification in Q2 2018 and release v1.0 later in the year

Future Work

As part of the specification to date, I have been working on a number of use cases. I would hope to expand on this list and extend the protocol based on feedback and discussions with the Eclipse community.

I've also been reviewing some of the main Eclipse IOT projects and would like to engage with their communities to ensure HIP is aligned with and supports them


Project Leads
Initial Contribution

All existing code is maintained at, with all core repositories (over 10K lines of code) maintaining "A" ratings at Codacy.

All code is developed and owned by the project lead.

Repositories are as per the components outlined in the description above

Source Repository Type