A cloud link for energy harvesting wireless networks

By Marian Hönsch, Software Architect, Product Marketing, EnOcean GmbH.

In today’s deeply connected world, there is an increasing demand to incorporate batteryless devices into networks based on several different communication standards such as WiFi, GSM, Ethernet/IP, BACnet, LON, KNX or DALI. With EnOcean Link, product manufacturers (OEMs) can easily transfer energy harvesting wireless signals into the requested communication protocol.

Interpretation of data

The ready-made middleware EnOcean Link provides a universal interface between energy harvesting wireless solutions and any automation application that further processes the wireless information. Therefore, the software converts the bits and bytes of an EnOcean telegram directly into data values. As a result, sensor data such as humidity or temperature is prepared so that different devices, servers and even cloud services can process it immediately. OEMs can now integrate energy harvesting wireless technology easier and faster into a wide range of applications and systems, such as those found in building automation.

A middleware is a separate piece of software which functions as a connective link between different systems or applications. It does not contribute to the application itself but enables the application to understand the messages from all components and systems in a network, even when they are based on different standards. This seamless communication is enabled because the different protocols address similar use cases (e.g. building automation). This eases the combination of several functionalities and applications to a more beneficial technical framework. EnOcean Link resembles a library, which offers services for other layers. By using the software, developers gain control of the execution order, of inbound and outbound communication interfaces and the data storage.

Main functionalities

However, the main functionalities of the middleware are to automatically take into account all specifications of the EnOcean protocol stack, the application profiles (EnOcean Equipment Profiles, EEPs) and Generic Profiles of the EnOcean Alliance as well as data encryption mechanisms. Generally speaking, the software has the following three key tasks:

1. Receiving and decoding incoming data communication according to the profile standard;
2. Executing device connection including the teach-in and store device information;
3. Encoding outgoing data communication according to the profile standard and sending them out to the further processing system.

Values for further processing

The protocol (EnOcean Serial Protocol 3.0; ESP3) describes the serial communication between a host and energy harvesting wireless receivers, such as an EnOcean USB dongle. Hosts are external microcontrollers or PCs that include application-specific software tools. ESP3 is a point-to-point protocol with a packet data structure. This protocol encapsulates actual user data (payload), command, event or response messages.

Every ESP3 packet consists of telegram header, data and optional data. Each of these groups consists of fields with 1 or x bytes. The packet header, for example, is composed of the fields: data length (number of bytes of the data group), optional length (number of bytes of the group optional data) and the packet type (e.g. radio, response, event, command).

EnOcean Link middleware provides several service layers to operate an energy harvesting wireless sensor network. These service layers are connected together to provide a clear user interface. On the physical layer, EnOcean Link receives the UART data stream (Universal Asynchronous Receiver/Transmitter) from the gateway. The ESP3 encoder is located over the physical layer. This layer handles all necessary operations to prepare the telegram data fields into a suitable form for further processing.

The profile interpreter, based on the stored application profiles, interprets the telegram payload into human readable values such as temperature or humidity. These values are presented as the so called device channels. These are made available to the application through the API interface, which can be called directly from the application’s source code or through a tunnelling protocol that encapsulates EnOcean Link. The device profiles, being how the device transmits and codes its values, are described in the EEPs or Generic Profiles.

Graph 1: Functionality EnOcean Link middleware – layers, actions and interface overview. Bottom-up: The middleware receives sensor information as a UART data stream and recognises the messages. In the next step it handles all security relevant tasks, e.g. data encryption, and extracts the raw sensor data after that. Out of this information the software decodes the raw data into actual values and provides the according application with them as decoded output data for further processing.

EnOcean Link in the Cloud

OEMs can use the middleware for any gateway application to integrate energy harvesting wireless devices and systems into a broader network. The signal of the UART data stream can come directly from a gateway or can be provided by a backbone which was optionally tunnelled before to forward the encapsulated payload protocol. So, for a scenario with simple and cost-effective gateway solutions, EnOcean Link can be run as a web service in the cloud. Here, an EnOcean gateway and the according application are combined onto a separate hardware. Smart nodes such as batteryless sensors and actuators provide their information to the gateway that forwards a request to the EnOcean Link web service via the Internet to interpret the received telegrams. The middleware extracts the value and data and sends them back to the gateway/application hardware for further processing. That way, the major part of the EnOcean-specific data processing is executed by the middleware in the cloud. Therefore, the gateways itself don’t need to cover a high computing power and can simply focus on the application.

The actual data interpretation service runs on an external server outside the building and can be offered as service on demand. In a scenario of a wider building automation system, several gateways and applications can access the same EnOcean Link web service. This enables system planers to easy and flexible build up complex networks on the basis of simple and cost-effective gateways.

Graph 2: Role of EnOcean Link middleware as a cloud service on demand in a building automation system integrating several gateways.

Test web service

Particularly for OEMs who intend to set up their own cloud service based on EnOcean Link middleware, EnOcean offers a test web service that can be used through a website or from an application. The service acts like EnOcean Link via HTTP requests and demonstrates the functionality of the middleware in the cloud. It is useful for smaller demonstrators or as a starting point for an own web service development. Its main purpose is to demonstrate the potential of EnOcean Link and its use in the cloud.

The web service can analyse, for example, ESP3 telegrams supplied by a sensor and return the complete parsed telegram structure (e.g. RORG, DATA, Source ID etc). If the forwarded telegram is a teach-in telegram, the web service stores the ID and EEP for further processing. If this data is not used in a specific period of time, the information in the database is deleted. If a telegram is being forwarded using a known ID and EEP, the web service interprets the given telegram according to the chosen profile and provides the included channels as described before. The interpreted data are returned afterwards. Further details on the usage of the test service and steps how to build up an own cloud service based on EnOcean Link middleware can be found in the application note “Combining EnOcean Link with a web service”.

One middleware – multiple use cases

Using EnOcean Link as a cloud service is just one example that shows the possibilities of the middleware for flexible automation scenarios. As the middleware works independently of a specific frequency, it can be integrated into any gateway, regardless of the communication standard it uses. Due to its embedded architecture, EnOcean Link can even be run on a mobile device, bringing the intelligence to the smartphone, for example. Thus, OEMs can develop apps based on the licensed software.

As the middleware transforms energy harvesting wireless communication to any other standard protocol, it consequently opens up various fields of application even outside buildings. In such scenarios, self-powered sensors can monitor the structural health of bridges or send an alarm signal when they measure the heat of a forest fire as part of an early warning system. Finally, EnOcean Link lays the foundation for an Internet of Things where billions of batteryless devices are connected to each other and the Internet. Having said that, the middleware offers OEMs a future-proof approach as it is updated continuously to cover even next generation energy harvesting wireless solutions.

Author Bio: Marian Hönsch is Product Manager and Software Architect at EnOcean. In this position, he is responsible for EnOcean software products and security concept, including the development of EnOcean Link middleware. Marian holds a bachelor in Informatics and a Master of Science magna cum laude in Software Engineering.