Introducing the EnOcean ecosystemii© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

Abstract
EnOcean’s award-winning patented and battery-less, self-powered
wireless sensor radio technology provides a robust, low cost and low
power energy efficient solution for home, commercial building andindustry environments.
‘Introducing the EnOcean ecosystem’ offers the reader a reflective
and historical narrative covering the technology’s relatively shortand successful history, as well as introducing the benefits of
EnOcean Alliance membership whilst sharing some of the attributes
that succinctly characterises EnOcean’s energy harvesting technology. What’s more, we’ll explore EnOcean’s current product portfolio
and discuss the technology’s market scope. Likewise, we’ll better
understand how EnOcean fares with its competitors and examine
several differentiators that uniquely distinguish EnOcean from its
competition. Finally, we’ll explore in some detail, the Dolphin
hardware and software architectures, as well as the equipment profiles that provide EnOcean with its application-base.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

iii

Introducing the EnOcean ecosystem

iv© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

Contents

1

2
3

4

5

6

About this bookviii

Publisherviii

Acknowledgements

viiiYour feedbackix

INTRODUCTION

3

1.1

What is renewable energy?

3

1.2

Siemens Research spin-off

4

1.3
Membership with the EnOcean Alliance
1.3.1
Membership structure

5
5

1.4
Charting EnOcean’s history
1.4.1
A new wireless standard

6
7

1.5

8

EnOcean certification programme

A GREENER PHILOSOPHY

10

2.1

10

EnOcean’s competition

ARCHITECTING SUSTAINABILITY

11

3.1

12

Small or low data rates

3.2
A typical EnOcean ecosystem
3.2.1
An EnOcean ecosystem at work

13
14

ENABLING THE INTERNET OF THINGS

15

4.1
The Internet versus the IoT
4.1.1
Install and forget

16
16

NETWORKING TOPOLOGIES

18

5.1

Line-powered controllers

19

5.2

Gateway device

19

THE DOLPHIN PLATFORM

21

6.1
Introducing the EnOcean Radio Protocol 1
6.1.1
Sub-telegrams
6.1.2
Sub-telegram timings
6.1.3
Listen Before Talk
6.1.4
Repeater behaviour

23
23
25
27
27

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

v

Introducing the EnOcean ecosystem

6.1.5
6.1.6

7

8

9

vi

The ISO/IEC 14543-3-10 standard
The ISO/IEC 14543-3-11 standard

28
29

6.2
Introducing the EnOcean Radio Protocol 2
6.2.1
Physical layer
6.2.1.1
902.875MHz
6.2.1.2
928.35MHz
6.2.1.3
Other frequencies
6.2.1.4
Frame structure
6.2.2
Data link layer
6.2.2.1
Frame structure
6.2.3
Network layer
6.2.3.1
Redundancy
6.2.3.2
Repeating
6.2.3.3
Local requirements dependent specifications
6.3
Introducing the EnOcean Serial Protocol
6.3.1
Synchronization

30
30
31
32
32
32
33
34
34
35
35
35
35
38

THE DOLPHIN ARCHITECTURE

39

7.1
Introducing the DolphinAPI
7.1.1
Line-powered vs. Self-powered ULP

40
40

7.2
Introducing the EnOcean System Software Layer
7.2.1
Scheduler

40
42

7.3
Smart Acknowledge
7.3.1
Mailboxes
7.3.2
Reclaiming
7.3.3
Normal operation and learning behavior
7.3.3.1
Learn in and learn out
7.4
Introducing the Hardware Abstraction Layer

42
43
44
45
48
48

ENOCEAN EQUIPMENT PROFILES

49

8.1

The RBS and 1BS telegram types

50

8.2

The 4BS telegram type

52

8.3

The VLD telegram

55

GENERIC PROFILES

56

9.1
The communication layers
9.1.1
Message types
9.1.2
Radio communication

56
57
58

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

9.1.2.1
9.1.3

10

11

Telegram chaining
Other communication

58
59

REMOTE COMMISSIONING

60

10.1

Common rules

60

10.2

Consistent device description

61

10.3

One specification for several tasks

61

10.4

Different use case scenarios

62

10.5

Adjustments of an existing network

63

10.6

Service and maintenance

63

SECURITY OPTIONS

65

11.1

65

Introducing four new RORGsAGLOSSARY67

B

REFERENCES & BIBLIOGRAPHY

71© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

vii

Introducing the EnOcean ecosystem

About this book
This document introduces the EnOcean ecosystem and its associatedapplication scope and market landscape; its technical make-up, toinclude an overview of the EnOcean software protocol stack, itsarchitecture and equipment profiles.

Publisher
EnOcean Alliance
Suite 375
2400 Camina Ramon
San Ramon
CA 94583
United States of America
web: enocean-alliance.org
email help@enocean-alliance.org

Acknowledgements© Copyright 2013 Cambridge University Press, adaptation of ‘original work’ authored by Dean Anthony Gratton based on Chapter
9, “Green, Smart and Wireless: EnOcean,” with permission from
Cambridge University Press (The Handbook of Personal Area
Networking Technologies and Protocols, 2013).
© Copyright 2013 Cambridge University Press, artwork adaptationof ‘original work’ illustrated by Dean Anthony Gratton based on
Chapter 9, “Green, Smart and Wireless: EnOcean,” with permission from Cambridge University Press (The Handbook of Personal Area Networking Technologies and Protocols, 2013).

viii© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

Your feedback
The EnOcean Alliance encourages feedback on the content provided
in this document, as well as suggestions and/or improvements. As
such, please email help@enocean-alliance.org. Furthermore, whenoffering feedback, please provide the following information:
 the title of the document; the reference and version numberof the document; the page number and paragraphsection where your feedback,suggestion and/or improvement
applies; and finally, an explanation describing your feedback, suggestion and/or improvement© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

ix

Introducing the EnOcean ecosystemx© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

xi

Introducing the EnOcean ecosystem

2© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

1

Introduction
EnOcean is an energy harvesting wireless technology that is usedprimarily for building automation. However, the technology can also
be applied across other industries to include transportation and smart
homes (or domotics). EnOcean technology uses an energy harvesting technique, that is, the ability for a wireless sensor to derive energy from natural environmental surroundings using minor variationsin the environment; for example, ambient light; the action of turning
on or off a switch, or with the smallest change in temperature – aresome of the harvesting techniques used to generate a sufficientamount of energy to not only power a device, but to store energy forsustained use. The technique is akin to renewable energy – something consumers and industries alike have become increasing awareof due to increased cost of energy and its supply. In Section 1.1,
“What is renewable energy?”, we discuss how renewable energy isused to garner natural resources from nature to energise our increased consumption. With EnOcean utilising energy harvesting
technology, it does not need to rely on batteries or other fixed powersources, in turn, reducing cost and the need for ancillary maintenance.

1.1

What is renewable energy?
Inescapably we are increasingly aware of the rise in cost of energy
whether that’s electricity, gas or oil over the last few decades. With
the demand on such resources with increased need and population
growth, consumption on limited resources continues to rise and,alas, we’re abundantly aware that there isn’t an infinite supply. With
this in mind, many, if not all, industries have been prompted to seek
alternative energy solutions. Renewable energy is the ability tocapture natural resources such as the wind, rain, sunlight and so on,
and ultimately convert this natural energy into a sustainable andinexhaustible supply. The numerous low power wireless technologies that share the Wireless Personal Area Networking (WPAN)
domain are, likewise, mindful of consumption and provide the© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

3

Introducing the EnOcean ecosystem

consumer with the ability to use their products for longer and without the need to frequently recharge the batteries! Furthermore, innovators are equally responsible for offering consumers and the industry alternative energy source or provide more efficient transmission
techniques which, in turn, extend battery life or reduce overall energy consumption. In essence, EnOcean’s energy harvesting technology delivers an effective alternative, in turn, reducing its energy footprint with innovative techniques.

Figure 1-1: The EnOcean trademark and logo.

1.2

Siemens Research spin-off
EnOcean GmbH (enocean.com) has been venture funded and has its
head office located in Oberhaching (near Munich), Germany. In
Figure 1-1, we illustrate the company’s trademark and logo.
EnOcean also has offices in the United States and was established in
2001, as a spin-off from Siemens Research. EnOcean GmbH is theoriginator of its self-powered, patented energy harvesting wirelesstechnology, which utilises numerous small energy convertors togather variances in its surrounding environment to provide a device
with sufficient energy to power itself. The company provides its
technology and licenses for numerous patented features through the
EnOcean Alliance, which we discuss shortly in the following section. EnOcean technology has been installed and integrated into over
350,000 buildings; has more than 1,500 interoperable products andhas been chosen by a diverse and varied number of manufacturers
across the world.

4© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

1.3

Membership with the EnOcean Alliance
The EnOcean Alliance (enocean-alliance.org), a global consortiumof companies, was established in 2008 and is responsible for thecollective effort of the development and promotion of EnOcean
technology across the world; in Figure 1-2 we illustrate the Alliance’s trademark and logo. The Alliance, a non-profit consortium,
undertakes standardisation effort of the technology itself, as well as
promoting a set of interoperable wireless products for residential,commercial and industrial buildings. What’s more, the Alliancelikewise, encourages third-party developers to evangelise EnOcean
technology within the wireless sensor market across the world.

Figure 1-2: The EnOcean Alliance trademark and logo.

The EnOcean Alliance currently has almost 400 companies that are
wholly committed to advance the technology whilst boasting thelargest and proven installed-base of wireless buildings automation
networks in the world.

1.3.1

Membership structure
The EnOcean Alliance provides three levels of membership to prospective participants. The level of membership allows a participant
to decide as to how they wish to participate within the Alliance. We
summarise in Table 1-1 the three membership levels.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

5

Introducing the EnOcean ecosystem

Table 1-1: The EnOcean Alliance offers potential participants three levels ofmembership.

1.4

MEMBERSHIPBENEFITS

Promoter

Promoter membership is the highest level available
within the Alliance. It provides participants with theability to define and drive the EnOcean Allianceitself and offers the participant company a seat on
the Board of Directors.

ParticipantParticipant membership offers potential members
the ability to create and utilise interoperable
EnOcean profiles for a range of building environments. What’s more, members may define newfeatures and profiles through the Technical Working
Group (TWG). Likewise, members can also use theuser education programmes through the Marketing
Working Group (MWG). Participant membershipallows its members to use the Alliance wording andbranding on their own documentation and products.
Original Equipment Manufacturers (OEMs) typically have access to this membership level.

Associate

Associated membership provides potential members
an entry level which, in turn, permits access tostandards, EnOcean documentation and other information once available. Building professionals,
academics and researchers/journalists typically haveaccess to this membership level.

Charting EnOcean’s history
In this section, we briefly summarise EnOcean’s relatively shorthistory from its inception to where the technology is today. In Figure 1-3 we provide an infographic charting EnOcean’s history. Earlier, in Section 1.2, “Siemens Research spin-off,” we touched upon
how EnOcean technology was originally developed at Siemens
Research, Munich, Germany. As such, during the mid-1990s, numerous patents covering energy harvesting were developed and,coinciding with the establishment of the Alliance in 2008 that the6© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

EnOcean Equipment Profiles (EEP) v2.0 specification emerged inearly 2009. You will also note from our infographic that EnOcean
products began entering the market in 2002 where subsequently
EnOcean products were installed in buildings later in 2003.

1.4.1

A new wireless standard
The EEP v2.1 and v2.5 specifications included additionalfeatures, improvements, new telegrams (something we’ll pickup on later) and other minor enhancements. In April 2012, theEnOcean wireless standard was ratified as the International
Organisation for Standardisation (ISO) / International Electrotechnical Commission (IEC) 14543-3-10.1 The standard
covers layers one to three of the Open Systems Interconnection (OSI) model. The current version of the equipment profiles, namely EEP v2.6.4, will be released in December 2015
(latest version always available under: http://www.enoceanalliance.org/eep/) and likewise provides additional featuresand other enhancements. More specifically, the ISO/IEC iscurrently expanding the EnOcean standard to accommodate
new frequencies, which now utilise the Frequency-shift Keying (FSK) modulation scheme. The new standard, currently
available in draft format, will be named, ISO/IEC 14543-3-11
and is planned for full release December 2015. In fact, both
315MHz and 868MHz frequencies use Amplitude-shift Keying(ASK) modulation, which are covered by the existing
ISO/IEC 14543-3-10 standard whereas, the 902MHz and
928MHz frequencies use the FSK modulation scheme andwill be covered in the new -11 standard. The 902MHz frequency now replaces 315MHz for North America; 928MHz is
positioned within Japan, whilst the 868MHz FSK frequency
will be used in China and not for Europe.
1 EnOcean Wireless Standard, https://www.enocean.com/en/enocean-wireless-standard/, 2015.
© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

7

Introducing the EnOcean ecosystem

Figure 1-3: Charting EnOcean’s relatively short history.

1.5

EnOcean certification programme
The EnOcean Alliance provides EnOcean device manufacturers afour-stage self-certification process to ensure interoperation of theirdevices with other like-enabled devices. In Figure 1-4, we illustrate
this four-stage process. The certification programme provides guidance to device manufacturers aiding them in their self-certification
process – this is akin to the European CE declaration. Interoperability, for EnOcean technology, requires that all layers of the software
protocol stack performs as defined and are repeatable, such that:

8© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystemthe air-interface (at the physical layer) must becompliant with the EnOcean ISO/IEC 14543-310/11 standard, along with achieving a definedminimum transmission range;
the scheduling and logical compliance at thecommunication layers must have definedcommunication flows;
and finally, the correct coding and decoding ofcommunication content at the application layer
must adhere to defined schedules and processing of transmitted data.

Figure 1-4: EnOcean Alliance’s four-stage self-certification process.

What’s more, EnOcean’s self-powered technology must assure theability to harvest energy from the ambient environment over a defined timeframe to ensure proper operation of the device over adefined period. In Table 1-2, we summarise the four-staged selfcertification process milestones.
Table 1-2: Four-stage self-certification process milestones.
PROCESS1

DESCRIPTION
Test cases;
Device documentation (public).

2

Test procedures;
Test coverage;
Test results.

3

EnOcean self-certification documentation.

4

Quality marking “EnOcean certified”.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

9

Introducing the EnOcean ecosystem

2

A Greener Philosophy
We have already touched upon a need to reduce our demand on
natural resources and, in turn, the homes, commercial and industrial
buildings that are architected today must be eco-friendly and forexisting buildings they must at least be retrospectively geared towards a greener philosophy. Naturally, this has a long-term view on
reducing our energy footprint, but it also helps with reducing cost to
the consumer and business alike.
EnOcean is not alone in its endeavour in creating a greener world.

2.1

EnOcean’s competition
EnOcean is presented with competitive technologies such as low
power Wi-Fi, Bluetooth Smart, ZigBee and Z-Wave, which all compete in a similar or the same market sector. Nonetheless, EnOcean
uniquely sets itself apart from its competition, insofar as, its energy
harvesting patented technology bestows upon its wireless sensor theability to capture the minutest changes in its environment to power
the device sufficiently to transmit and receive data – this ability
singularly sets EnOcean apart from its competitors. What’s more,
EnOcean’s energy harvesting technology has some positive consequences, namely it removes the need for sensors to house batteries
and almost eliminates the need to maintain sensors within an installation. The EnOcean Alliance continues to place EnOcean technology at the heart of and to establish the technology as the de facto low
energy standard for sustainable buildings, in turn, embracing agreener philosophy.

10© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

3

Architecting Sustainability
With consumers and industries becoming increasingly conscience of their growing energy
consumption and, in turn, its exponential growthon demand, alternative energy resources arenowadays needed to help alleviate consumptionof our limited natural resources. EnOcean is notalone in its endeavour to reduce our energy
footprint. Wireless technologies such as Bluetooth Smart, ZigBee and Z-Wave are some of the technologies thatare vying for a similar market to EnOcean. However, EnOcean
GmbH provides a unique wireless sensor technology that’s selfpowered and affords homes, commercial and industry dwellings
with an eco-friendly and environmentally responsible ecosystemthat helps architect sustainability and paves the way to a greener,
eco-conscience world.

Figure 3-1: The STM 330/430 is a solar-based wireless sensor utilizing
315MHz, 868MHz, 902MHz or 928MHz frequencies.

EnOcean’s battery-less, self-powered wirelesssensor technology provides its users with anecosystem where intelligence can be offered tosuch systems as lighting, heating and climate
control, and ancillary building diagnosis andmaintenance.
An
EnOceanecosystem© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

11

Introducing the EnOcean ecosystem

additionally negates the need to retrofit cabling, in turn, eliminatingor reducing the cost of cabling whilst providing a reduced necessity
to constantly maintain the installed equipment. What’s more,
EnOcean offers the ability to remote manage the ecosystem using asmartphone or over the Internet. Incidentally, a Feng-Shui approach
can be adhered to for most EnOcean installations.
3.1

Small or low data rates
EnOcean’s wireless sensors utilize small or low
data rates whilst its energy harvesting techniques
removes the need for batteries. The smallest
ambient changes in a sensor’s environment are
sufficient to allow the sensor to transmit data.
For example, variances such as a light switch
being turned on or off; the minutest vibrations
within a vehicle; energy derived from the motionof people or ambient luminosity or temperature changes can be usedsingularly or in combination to power a sensor. Furthermore,
EnOcean provides third-party developers the Dolphin system architecture, which we discuss later in Section 6, “The Dolphin Platform”. It empowers such third-parties the ability to create a wirelesssolution that uniquely satisfies their own residential and commercial
building requirements. As such, EnOcean additionally provides aseries of wireless sensor products that utilise the EnOcean standard,
and in Figure 3-1, we provide an example of a self-powered wirelesssensor product, which will help accelerate your development lifecycle. Alternatively, in Figure 3-2, we show a mechanical energy
harvester (motion convertor) that is used alongside other products,
which include the wireless sensor.

12© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

Figure 3-2: The ECO 200 is an energy harvester (motion convertor).

3.2

A typical EnOcean ecosystem
In this section, we provide an example of a typical EnOcean ecosystem, as shown in Figure 3-3 and, as such, we’ll explore further how
the technology is used in a real-world context to help us understandthe numerous products and applications supported in such an ecosystem.

Figure 3-3: An EnOcean ecosystem where, in this example, lighting
and HVAC systems are powered.
© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

13

Introducing the EnOcean ecosystem

EnOcean technology can be installed, mostly inhibited and undaunted by its location. As we have already mentioned, EnOcean has
been installed in over 350,000 buildings and the company vaunts tohave “the largest installed base of proven interoperable wirelessbuilding automation networks in the world. 2”

3.2.1

An EnOcean ecosystem at work
EnOcean technology can be installed in locations such as residential
homes, commercial and industry settings, hospitals, aircraft, historicbuildings and yachts! If we refer back to our example installation in
Figure 3-3, we depict an environment that manages lighting andHeating, Ventilation and Air Conditioning (HVAC) systems using a
combination of wireless sensors, which is managed through a touch
panel (8). The touch panel can be remote managed over the Internet
or using a smartphone (9), as shown in our illustration. You will also
notice a number of battery-less wireless sensors in our example
ecosystem. As such, switches and blinds (1), occupancy detectors(2), and outdoor lighting (3) sensors, room temperature (4), as wellas humidity (5) sensors; window handles (6) and contact (7) sensors.
Finally, in (10) we have a line-powered gateway device. When aroom is occupied, the occupancy sensors can detect such presence
and turn the lights on; likewise, it can also control the room temperature. Conversely, when a room is unoccupied the lights are turned
off and the ambient temperature can be reduced. Similarly, the heating and air conditioning systems are switched off where the window
handles and contact sensors alert the system when a window is
opened.

Schneider, Andreas, “EnOcean Company Presentation”, May
2010.
2

14

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

4

Enabling the Internet of Things
The Internet of Things (IoT) has largely been touted and hyped
across an industry always eager to launch the next big thing, 3 and
EnOcean technology will ultimately play a part in creating an IoT
ecosystem that will help shape the future of the technology. In Figure 4-1, we provide an image that’s representative of today’s visionof the IoT. Firstly, we need to better understand the differentiatorsthat distinguish the Internet from the IoT, and further explore theoriginal supposition used to explain the IoT. Finally, we’ll discuss
how EnOcean will help shape the future of the Internet of Things.

Figure 4-1: An image that is representative of
the Internet of Things. 4

3 Gratton, D. A., “What is this Internet of Things, thing?”, retrieved January

2015.
4 Image credit: “Internet of Things” by Wilgengebroed on Flickr – cropped

and sign removed from Internet of Things signed by the author.jpg. Licensed under Creative Commons Attribution 2.0 via Wikimedia Commons.
© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

15

Introducing the EnOcean ecosystem

4.1

The Internet versus the IoT
The Internet is a globally connected network, which is formed
across many, multiple networks using either a wired or wirelessinterconnection; whereas, the IoT supposes the ability of a device, or‘thing’ that can be tracked or identified within an IP or similar structure.5 Nowadays, the IoT supposition has essentially been misunderstood and, as such, anything remotely having Internet capability isdeemed to be integral within the IoT, and this is certainly not thecase. IoT is representative of an ability to track and identify objects
or things within an IP structure. These ‘smart’ objects, or things,
hitherto have an ability to collate data which, as a consequence, has
extended the original IoT supposition. To a greater extent, the Internet has been largely reliant on information provided by humans;
however, with the IoT, we can empower6 our smart objects withsome intelligence to collate data or information, in turn, providing
new and more accurate data since humans are constrained by timeand often have limited accuracy. Such smart/intelligent devices havea representation5 of their world and, can share data or informationthat can be readily digested and consumed by humans. These smart
objects are empowered to gather and share data with other likeminded objects and, of course, us! Hence, the notion of ‘big data,’
which is often used synonymously with the IoT.3

4.1.1

Install and forget
Typically, the notion of the IoT has been extensively overused toembrace numerous Internet-like trends which, in short, is due to the
popularity of the Internet itself. The IoT has been moulded andshaped into various guises, which aptly suit a particular industry
trend or phenomenon. Nonetheless, EnOcean’s vision of the smart
object would typically cost no more than a few dollars (or less),
5 Gratton, D. A., The Handbook of Personal Area Networking Technologies

and Protocols, 2013.
6 Ashton, K., “That ‘Internet of Things’ Thing”, RFID Journal, June 2009.
16© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystemcomprise a small foot print harnessing an 8-, 16- or 32-bit microcontroller with a modest memory of say several tens of kilobytes; would
send and receive small data packets, and ultimately, would have theability to connect to the Internet. Of course, EnOcean energy harvesting technology would negate the need for such devices to use
batteries. It is anticipated that such smart objects would be inclusive
within smart homes, industry and commercial automation, something that lends itself well to EnOcean’s existing product portfolio.
And finally, “The intelligence to make use of the data can and will
be implemented anywhere, but the systems that collect the initial
information need to be reliable and perpetual so that we can ‘installand forget’; this is where energy harvesting wireless sensors comein: the ‘things’ in the IoT.”7

7 Siskens, W., “Energy harvesting will be big in 2015”, ElectronicsWeek-

ly.com, retrieved January 2015.
© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

17

Introducing the EnOcean ecosystem

5

Networking Topologies
In this section, we discuss several networking topologies that can beused within an EnOcean ecosystem and some of the devices that
may form such an ecosystem. Firstly, EnOcean supports a point-topoint, star and mesh topologies, which we highlight in Figure 5-1. In
particular, EnOcean primarily supports both a point-to-point and star
topologies although, with the use of ‘smart’ repeaters, it is possible
to achieve range extension or build a mesh topology.

Figure 5-1: EnOcean supports three networking topologies, namely
point-to-point, star and mesh.

Earlier, in Section 3.2, “A typical EnOcean ecosystem” we provided
an example of an EnOcean ecosystem that managed lighting and
HVAC system and discussed how some of the sensors were used to
manage the installation. An EnOcean network may comprise further
devices, which may include energy harvesting switches and sensors;
actuators and controllers; a gateway and building management
system, as well as other ancillary wireless modules, sensors andrepeaters.

18© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

5.1

Line-powered controllers
In Figure 5-2, we illustrate how, in this topology, a number of battery-less wireless sensors communicate with their respective linepowered controllers, which successfully manage the lighting, shading and HVAC systems.

5.2

Gateway device
Conversely, in Figure 5-3, we illustrate how, in this topology, anumber of battery-less wireless sensors communicate with an
EnOcean gateway device. In this instance, the gateway device uses abackend bus network that permits it to manage the lighting, shadingand HVAC systems.

Figure 5-2: In this topology, a number of battery-less wireless sensors
communicate with their respective line-powered controllers

The EnOcean gateway device supports both the LonWorks8 (LON)and Konnex9 (KNX)/European Installation Bus (EIB) protocols;
however, the gateway may also support BACnet,10 TCP/IP, Digital

8 LonWork is a networking protocol that was developed and created by the

Echelon Corporation.
9 Konnex is a network communications protocol standard and is managed
by the KNX Association.
10 BACnet is a communications protocol used for intelligent buildings.
© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

19

Introducing the EnOcean ecosystem

Addressable Lighting Interface (DALI), Thread,11 AllJoyn,12ZigBee, Bluetooth Smart and other building automation protocols.
Essentially, the intelligent building or building automation concept
is realised through the use of these protocols which, in turn, offer
building automation standardisation for such systems as lighting and
HVAC.

Figure 5-3: in this topology, a number of battery-less wireless sensors communicate with an EnOcean gateway device.

11 Thread is an IPv6-based networking protocol primarily used for smart

home device.
12 AllJoyn is a system that provides devices the ability to advertise andshare its capabilities with other devices that are in proximity.
20© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

6

The Dolphin Platform
In this section, we’ll begin to lift the lid on EnOcean’s software andhardware architectures, as well as revealing components of the
hardware and the associated developer environment that is provided
by EnOcean. What’s more, we will discuss the EnOcean Radio
Protocol (ERP), later in Section 6.1, “Introducing the EnOcean
Radio Protocol” and the layers that form the software stack architecture.

Figure 6-1: The EnOcean Dolphin EO3000I hardware platform that’s usedin the development and design of numerous products.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

21

Introducing the EnOcean ecosystem

The Dolphin platform is a System-on-Chip (SoC) transceiver providing a bi-directional Ultra Low Power (ULP) solution for various
applications. It comprises a RF transceiver offering data rates of up
to 125kbit/s with an 8051 microcontroller. The SoC is further supported with a number of peripherals and numerous ULP power management sections. In Figure 6-1, we illustrate the building blocks
that comprise EnOcean’s EO3000I hardware platform and offer asummary description in Table 6-1. The powerful SoC allows thirdparty developers to both design and develop a myriad of EnOceanenabled products, such as switches, sensors, receivers and transceivers uniquely taking advantage of EnOcean’s energy harvesting wireless technology for use within the home, commercial and automation industry. Likewise, the Dolphin platform can be used in linepowered receivers with either switched output or gateways, something we touched up on earlier in Section 5, “Networking Topologies”.
Table 6-1: A snapshot of EnOcean’s EO3000I hardware building blocks.
BLOCK

NAME

DESCRIPTIONULP

Voltagelimiter

The ULP building block limits voltage
supply of the Dolphin system.

Thresholddetector

An ULP On/Off threshold detector.

TimersWatchdog

The timer building block uses an internal oscillator for ULP timing.

RF

Transceiverand state

EnOcean products use 315MHz,
868MHz, 902MHz, and 928MHz frequencies and, as such, can be configured. The integral state engine undertakes the transmission and receiving oftelegrams, which is based on the ERP.

EngineCPU and
peripherals

22

Using an 8051 processor, along with atransceiver and state engine, the CPU isalso accompanied with system timers,
memory and a serial interface.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

Mixedsignalsensorinterface

The mixed signal sensor interface can
support up to 10 configurable I/O lines.

Operatingmodes

The operating modes supported are,CPU mode”, “OFF mode”, “Deep sleepmode”, “Flywheel sleep mode”, “Shortterm sleep mode” and “Standby mode”.

The EnOcean Dolphin platform provides third-party developers abroad developer environment with a comprehensive Application
Programming Interface (API) called the DolphinAPI. Using theDolphinAPI, developers can create their own specific firmware
utilising the control, configuration and management features of theprocessor. Such features within the control of the receiving andtransmission of radio telegrams are based on the ERP in addition to
management of generic I/O and control of the power modes.
6.1

Introducing the EnOcean Radio Protocol 1
In this section, we describe ERP1, which is used across the United
Kingdom and Europe. In Section 6.2, “Introducing the EnOcean
Radio Protocol 2”, we describe ERP2, which is used across both theUnited States and Japan. In Figure 6-2, we illustrate EnOcean’s
software building blocks, which are mapped against the Open Systems Interconnection (OSI) model. You will note that the session
and transport layers are not used within the model and are not shown
here.

6.1.1

Sub-telegrams
The ERP1 is a packet-based protocol and comprises three possible
data unit types, namely a frame, a sub-telegram or a telegram, which
are all hierarchal in nature. In the hierarchy, the lowest data unit is
the frame and carries data relating to the physical layer such as thecontrol and synchronization parameters of the receiver. The frame© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

23

Introducing the EnOcean ecosystemdata unit is transmitted as a bit serial sequence. Moving up in the
protocol hierarchy, the sub-telegram forms the next data unit, which
we illustrate in Figure 6-3. The sub-telegram data unit carries data
relating to the data link layer.

Figure 6-2: EnOcean’s software building blocks mapped against the
OSI model. You will note that the session and transport layers are notused within the architecture.

The EnOcean software architecture undertakes responsibility for theencoding/decoding process, where it provides the preamble padding,that is, Start of Frame (SoF), inverse bits and End of Frame (EoF) toassure quality in transmission. Naturally, the encoding process is
initially undertaken prior to transmission at the physical layer. The
receiving device decodes the data unit and discards the preamble
padding.

Figure 6-3: The structure of the sub-telegram data unit.

Essentially, ERP1 is a unidirectional protocol, but can offer bidirectional support especially with SmartACK, although we’ll come backto this later. The protocol offers no handshaking, but reliability is
assured with a repeating mechanism where three identical subtelegrams are transmitted over a fixed period. In Table 6-2, we
24© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystemdescribe the fields that comprise the sub-telegram data unit. We
discuss later, in Section 8, “EnOcean Equipment Profiles” the highest data unit in our hierarchy, that is, the telegram. Incidentally, forfuture reference, we should not that the sub-telegrams’ timings aregrouped ORGanizationally (RORG).
Table 6-2: The fields that comprise the sub-telegram data unit.

6.1.2

FIELD

DESCRIPTION

BITS

ChoiceThe Choice field is 8-bits in length andsets the type of sub-telegram andcorresponds with the RORG value of
ERP1.

8

Data

The Data field is of variable length andcarries the actual payload to be transmitted.

~

SourceID

The SourceID field is 32-bits (Japan
48-bits) in length and identifies thesource transmitter.

32

StatusThe Status field is 8-bits in length, andcontains a value, which determines if
the sub-telegram was transmitted froma repeater, as well as identifying thetype of integrity control mechanism inuse.

8Checksum

The Checksum field is 8-bits in lengthand provides a data integrity check on
the data transmitted.

8

Sub-telegram timings
The ERP1 is aware of telegram collisions over the air-interface and,as such, the management of sub-telegram timings is paramount.
Therefore, a sub-telegram is transmitted at varying time intervals,
which is determined by the transmit (TX) and receive (RX) maturity© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

25

Introducing the EnOcean ecosystem

periods. In Table 6-3, we provide the associated timing windows forthe maturity period in which all sub-telegrams have to be transmitted and received, respectively. For example, if a telegram uses three
sub-telegrams, then each sub-telegram (from start to finish) shall not
exceed the TX maturity period.
Table 6-3: The maturity windows for TX and RX periods.
MATURITYDESCRIPTION

40ms

Maximum TX maturity period.

100ms

RX maturity period.

However, a repeater device uses an alternative timing method compared with the originating transmitting device. So, each subtelegram (from start to finish) shall not exceed the RX maturity
period. Furthermore, an effective scheduling mechanism is provided
where the TX maturity period is divided into four windows; hence, awindow now has 10, 1ms time slots, as we illustrate in Figure 6-4.
As we mentioned earlier, the TX maturity period permits up to three
sub-telegrams to be transmitted where the specific period is determined by a sequence corresponding to the current window in use.
Collision avoidance is limited when using repeaters where the timing of the original versus the repeat telegram differs and, as such, we
now demonstrate in Table 6-4 how the allocation of time slots forthe various telegrams occur.

Figure 6-4: The TX maturity period is divided into four 10ms windows.

26© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

Of course, all sub-telegrams are transmitted in sequence where asecond or third sub-telegram may only start transmitting once thefirst sub-telegram has completed. In instances where a wirelesschannel is busy, the Listen Before Talk (LBT) mechanism can delaytransmission until the end of the TX maturity period. We discuss
LBT in the following section.
Table 6-4: The appropriate allocation of time slots to the corresponding telegram.

6.1.3

STATUS

1ST SUBTELEGRAM

2ND SUBTELEGRAM

3RD SUBTELEGRAM

Original

0

1…9

20…39

Level 1
repeated

10…19

20…29

Level 2
repeated

0…9

20…29

Listen Before Talk
The LBT is an optional feature, although it is strongly recommended. It provides a collision avoidance technique, which is a common
feature used within most wireless technologies. The mechanism
simply determines if there is an ongoing transmission before a device begins transmission of its payload. More specifically, if an
EnOcean device detects an ongoing transmission, it shall defertransmission for a random period. At the end of this period, theEnOcean device will again attempt to transmit its payload and if it’s
clear to do so, then the payload is sent.

6.1.4

Repeater behaviour
In an environment where wireless sensors need to be deployed overa large area and if it’s not feasible to bring a sender and receiverdevice into proximity with each other, then a maximum of two© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

27

Introducing the EnOcean ecosystemrepeater devices can be used to ensure seamless wireless communication. Akin to a relay race, a repeater device receives a payload
from the sending device and relays it to the receiving device. In
instances where a sub-telegram has been repeated, the Status field,
as shown in Table 6-5, is modified to reflect the repetition sequenceor if the sub-telegram is not to be repeated.
Table 6-5: The possible values of the Status field.
VALUE

DESCRIPTION

0x00

Original sender.

0x01

Sub-telegram was repeated once.

0x02

Sub-telegram was repeated twice.

0x0F

Sub-telegram shall not be repeated.

You will notice in Table 6-6 that two repeater levels are used to not
only distinguish, but limit the repetition of sub-telegrams.
Table 6-6: The two repeater levels that assist with limiting repeated sub-telegrams.
LEVEL

6.1.5

DESCRIPTION

1

Repeat only received original subtelegrams.

2

Repeat only received original sub-telegramsor once repeated sub-telegrams.

The ISO/IEC 14543-3-10 standard
In Section 1.4.1, “A new wireless standard”, we touched upon how
the EnOcean standard had been ratified. In this section, we’ll explain a little further on the specifics of that standardization, namely
ISO/IEC 14543-3-10 Information technology includes Home Electronic Systems (HES), Part 3-10 “Wireless Short-packet (WSP)28© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystemprotocol optimized for Energy Harvesting – Architecture and Layer
Protocols”.

Figure 6-5: ISO/IEC 14543-3-10 now provides the physical, data link
and network layers of the EnOcean software stack.

ISO/IEC 14543-3-10 provides the physical, data link and network
layers of the EnOcean software stack, as shown in Figure 6-5. Boththe 315MHz and 868MHz frequencies use the ASK modulation
scheme, which are covered in this standard. What’s more, it is thefirst and only wireless standard that is suitable for energy harvestingwith a focus on optimized ultra-low energy consumption. This new
standard when combined with the EnOcean EEP forms a holistic
interoperable, open technology that can be used across the world.

Figure 6-6: The host (in this example, a PC) interfaces with an
EnOcean module over an RS232 serial interface.

6.1.6

The ISO/IEC 14543-3-11 standard
Likewise, in Section 1.4.1, “A new wireless standard”, we discussed
how EnOcean’s initial 14543-3-10 standard is being extended to© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

29

Introducing the EnOcean ecosystem

accommodate new frequencies, namely 902MHz and 928MHz,
along with the FSK modulation scheme. The new standard is currently available in draft format and is planned for full release end2015. Moreover, the 902MHz and 928MHz frequencies both use the
FSK modulation scheme and will be covered in this new standard.
The 902MHz frequency now replaces 315MHz for North America;
928MHz is positioned within Japan, whilst the 868MHz FSK frequency will be used as an option in China.
6.2

Introducing the EnOcean Radio Protocol 2
In this section, we describe ERP2, which is used across the UnitedStates and Japan. Earlier, in Section 6.1, “Introducing the EnOcean
Radio Protocol 1”, we described ERP1, which is used across boththe United Kingdom and Europe. ERP2 was designed to improve
performance and to extend implementation across a variety of RF
transceiver architectures.
In the following list, we highlight several significant changes whencompared with ERP1:
 the use of FSK modulation versus ASK in ERP1;
 the use of a longer preamble and longer syncword (formerly known as SoF) to increase detection reliability; and changes in the telegram structure where the
EoF field is used as a data length filed to allow
variable length telegrams with minimal overhead.
In the following sections, we now describe the physical, data link
and network layers, which are used in ERP2.

6.2.1

Physical layer
The electrical specification of the physical layer is open to any frequency, but two frequencies are currently specified. Nevertheless,

30© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

subject to national regulatory requirements and new markets additional frequencies may be implemented.
In Table 6-7, we list key parameters that are used in ERP2.
Table 6-7: Key parameters that are used in ERP2.
PARAMETERMINFrequency
error

-18

Modulation13
Frequency
deviation

MAX

UNIT

-18

kHz

±70.0

kHz

FSK
±55.0

Data rate
Data rate
tolerance14

VALUE

±62.5
125

-30

kbps
+30

ppm

PA ramp-on
time

40

µs

PA ramp-off
time

40

µs

CodingNRZ

Code for 1

+62.5

kHz

Code for 0

-62.5

kHz

6.2.1.1 902.875MHzIn Table 6-8, we show the parameter used in ERP2 at 902.875MHz,
which is targeted toward the North American market.
13 Permitted to use GFSK with various filters (BT) subject to national regu-

lation requirements.
14 This provides a 1µs time offset between RX and TX after 256 bytes. A

transmitter may feature higher tolerances since the time offset between
RX and TX does not exceed 1µs following the maximum number of bytes
actually transmitted.
© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

31

Introducing the EnOcean ecosystem

Table 6-8: ERP2 at 902.875MHz for North America.
PARAMETER

MIN

Nominalfrequency

VALUE

MAX

902.875

UNIT
MHz

6.2.1.2 928.35MHzIn Table 6-9, we show the parameter used in ERP2 at 928.35MHz,
which is targeted toward the Japanese market.
Table 6-9: ERP2 at 928.35MHz for Japan.
PARAMETER

MIN

Nominalfrequency

VALUE

MAX

928.35UNIT
MHz

6.2.1.3 Other frequencies
ERP2 was specifically designed to be frequency independent. However, other frequencies may be introduced as and when new markets
and requirements emerge.
6.2.1.4 Frame structure
At the physical layer, data is transmitted in frames, as we illustrate
Figure 6-7 – in Table 6-10, we describe the fields that make up thephysical frame structure.

Figure 6-7: The ERP2 physical frame structure.

32© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

Table 6-10: The fields that comprise the ERP2 physicalframe structure.
FIELD

DESCRIPTION

BITS

Preamble

The preamble field is 16-bits inlength and is used to provide bit
synchronisation.

16

Syncword

The Sync-word field is 16-bits inlength and is used to enable thereceiver to synchronise to thedata bytes.

16

LengthThe Length field is 8-bits inlength and indicates the numberof bytes in the Data_PL field.

8

Data_PL

The Data_PL (physical layer)field is of variable length andcarries the actual payload.

In Figure 6-7, we also show the physical layer to data link layer
conversion where the length followed by the Data_PL is transferredto the data link layer.

6.2.2

Data link layer
At the data link layer sub-telegrams are transmitted, which we discussed earlier in Section 6.1.1, “Sub-telegrams”. Sub-telegram timings aim to avoid telegram collisions from different transmitterswhilst LBT is a technique used to ascertains in its environment
whether other devices are transmitting prior to transmitting its payload. 15

15 EnOcean GmbH, “Specification: EnOcean Equipment Profiles 2”, v1.0,
September 2013.
© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

33

Introducing the EnOcean ecosystem

6.2.2.1 Frame structure
The frame structure at the data link layer differs depending on its
size. Telegrams that are six bytes or less have a fixed structure for
special payloads such as acknowledge, keep alive and errors messages, as we show in Figure 6-8. We describe these fields in Table
6-11.

Figure 6-8: The frame structure for the data link layer with six
bytes or less.

Further information can be obtained from EnOcean’s ERP2 specification.
Table 6-11: The fields that comprise the data link layer
frame structure.

6.2.3

FIELD

DESCRIPTION

LengthThe length field is 8-bits inlength and indicates the number of bytes in the Data_DL
field.

8

Originator
ID

The Originator ID field isvariable in length and indicates the originating device.

8, 16,
24,
32

Data_DLThe Data_DL (data layer)field is of variable length andcarries the actual payload.

BITS

Network layer
The network layer specifies access to the transmission media, as
well as providing guidance for redundancy in transmission such as34© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystemrepeating or acknowledge. At this layer, routing, repeating and subtelegram timing is taken from ERP1.
6.2.3.1 Redundancy
As a default, redundant transmission is used, if no other technique tosuccessfully acknowledge transmissions is available. A transmission
shall be repeated at least once and up to a maximum of two. Furthermore, there is a maximum pause of 12ms between the first andsubsequent transmission. Typically, this technique will be applied todevices that are unable to receive (that is, pure transmitters) but canalso be applied to transceivers.
6.2.3.2 Repeating
Only level 1 repeating is permitted and will remain the same as
specified in ERP1.
6.2.3.3 Local requirements dependent specifications
There are no specific requirements for the US and Canada(902.875MHz); however, redundant transmissions shall be finishedwithin 50ms for Japan (928.35MHz). In other words, following thelast transmission no further transmissions are permitted for 50ns.
6.3

Introducing the EnOcean Serial Protocol
The EnOcean Serial Protocol (ESP) allows developers with an
EnOcean module to establish serial communication with, for example, a host, that is a microcontroller or PC and, as we demonstrate in
Figure 6-6. The connection established between a host and the module is based on an RS232 serial interface; more specially, a 2-Wire
Universal Asynchronous Receiver/Transmitter (UART) connection,
comprising receive, transmit and ground, as well as software handshake and full-duplex. The ESP uses a point-to-point topology asshown in Figure 6-6 and uses the data structure illustrated in Figure
6-9; the data structure is made up of the user data, command,© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

35

Introducing the EnOcean ecosystem

response and event messages. Moreover, Figure 6-9, illustrates thepacket structure, which comprises a header, length, packet type, data
and an optional data payload, as well as a sync-byte (indicating startof frame). In Table 6-12, we explain the fields that comprise the
ESP packet structure.

Figure 6-9: The ESP packet structure.

Table 6-12: The fields that comprise the ESP frame structure.
FIELD

DESCRIPTION

Sync-byte

The Sync-byte field is 8-bits in lengthand provides the serial connection witha synchronisation mechanism and isalways set to 0x55.

8Data length

The Data length field is 16-bits inlength and indicates the number ofbytes that need to be addressed in the
Data field.

16

Optional length

The Optional length field is 8-bits inlength and the number of bytes thatneed to be addressed in the Optional
data field.

8

Packet type

The Packet type field is 8-bits in lengthand indicates the packet type contained
within the data and optional data fields.
In Table 6-13, we show the possible

8

36

BITS

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

packet types that are available.
CRC8H

The CRC8H (header) field is 8-bits inlength and contains the checksum fordata and optional data, and packet type.

8

Data

The Data field is variable in length andcontains the payload.

~

Optional data

The Optional data field is variable inlength and contains the optional payload.

~

CRC8D

The CRC9D (data) field is 8-bits inlength and contains the checksum fordata and optional data fields.

8

Table 6-13: The possible Packet types and value.
VALUE

DESCRIPTION

0x00

Reserved.

0x01

Radio telegram.

0x02

Response to any packet.

0x03

Radio sub-telegram.

0x04

Event message.

0x05

Common command.

0x06

SmartACK command.

0x07

Remote management command.

0x080x7F

Reserved (EnOcean use only).

0x800xFF

Manufacturer-specific commandand message.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

37

Introducing the EnOcean ecosystem

6.3.1

Synchronization
In Figure 6-10, we illustrate a Sync-byte value (0x55) initiates thestart of frame where the data and optional length, packet type that all
follow, are validated against the CRC8H (header) field. If there is nomatch, then the Sync-byte does not correspond with a new payload
and the process is repeated. Conversely, if there is a match, then the
payload is processed and moved along.

Figure 6-10: The Sync-byte is used to denote the start of a new payload.

38© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

7

The Dolphin Architecture
In Figure 7-1, we illustrate the high-level view of EnOcean’s software stack architecture where each layer uniquely provides a set offunctions and parameters. As such, each layer or module is wholly
independent and provides an interface, which can be directly accessed by an application. Each module further provides two types ofinterface, that is, initialisation and functional. The function interface
offers reliable access as to whether or not a function was executed
successfully. Moreover, the function interface provides the ability toshare parameters and offers a reason, if the function was not executed successfully. You should note that not all software modules areaccessible from the application layer, such as scheduling and interrupt handlers, as we illustrate in Figure 7-2.

Figure 7-1: A top-level view of the Dolphin system architecture thatmake up the EnOcean software stack.

In Figure 7-1, the block labelled (1) represent both the Media AccessControl (MAC) and Physical (PHY) layers, which we discussed
earlier in Section 6, “The Dolphin Platform”; block labelled (2)forms the center of the EnOcean architecture, which includes theDolphinAPI (see Section 7.1, “Introducing the DolphinAPI”), theEnOcean System Software Layer (ESSL) and the Hardware Abstraction Layer (HAL); and finally, block (3) permits third-party© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

39

Introducing the EnOcean ecosystemdevelopers to create their own applications using either the EEP (see8, “EnOcean Equipment Profiles”) or Generic Profiles (see Section
9 “Generic Profiles”).
7.1

Introducing the DolphinAPI
The DolphinAPI offers developers an interface to create two application types, namely Line Powered and Self-powered ULP. The
former application type is typically used for modules that require afixed power feed such as controllers, repeaters and gateways whereas the latter application type is used for modules that are poweredusing the energy harvesting technique, such as sensors and actuators. A line powered module remains on and does not enter a sleep
state (only standby), where on the other hand, the self-powered ULP
module is normally switched off or is in a deep sleep state periodically awakening.

7.1.1

Line-powered vs. Self-powered ULPNaturally, line-powered and self-powered ULP differ insofar as theirrespective APIs offer varying methods in functionality for energy
optimisation. More specifically, whilst a line-powered device istypically energy efficient, it can be a little relaxed with its energy
consumption where a telegram can be transmitted using the scheduler (see Section 7.2.1, “Scheduler”) regardless of the lapsed time.
Alternatively, a self-powered ULP device remains more moderate inits energy consumption where telegram transmissions have to be
optimised and completed quickly.

7.2

Introducing the EnOcean System Software Layer
In Figure 7-2, we show a series of blocks that are shown horizontally – these represent several software modules that comprise the
ESSL. In our illustration looking from left to right, we see the RadioULP, several timer modules, a Serial Peripheral Interface (SPI)
and a Universal Asynchronous Receiver/Transmitter (UART);40© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

Smack (see Section 7.3, “Smart Acknowledge”), generic I/O, power
management (PWR) and miscellaneous software module resources.
Some modules are not able to be accessed from the application layer, but interact with each other. The ESSL likewise houses thescheduler, power management, the serial and radio protocol stacks
and other miscellaneous compounds. Incidentally, the Dolphin architecture does not adopt a user/kernel topology and, instead, theDolphinAPI and other libraries are all linked to the application during compilation. Similarly, memory management is also allocatedduring compilation.

Figure 7-2: A number of interactive modules comprise the ESSL that’s
located within the Dolphin architecture. Security options may now also be
added here.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

41

Introducing the EnOcean ecosystem

7.2.1

Scheduler
We summarise in Table 7-1 the scheduler functionality where tasks
can be executed concurrently within the EnOcean system. The DolphinAPI supports both single application and multiple system tasks,
as well as pre-emptive priority scheduling at the system level. Most
system tasks execute to completion and cannot be interrupted byother system tasks, although the UART system task has a higher
priority and, as such, has the ability to pre-empt system tasks.
Table 7-1: Functionality offered by the scheduler.
SCHEDULER FUNCTIONALITY
Transmit and receive telegrams.
Offer levels 1 and 2 repeating.
SmartACK postmaster functionality.
LBT
Software timing.
Remote management.

The scheduler is executed using a round robin technique where theapplication task is provided a 1ms opportunity to be interrupted.
Synchronous system tasks are executed consecutively and are triggered by the timer hardware interrupt – the average duration for asynchronous task to complete is around 50 to 150µs. A synchronoustask may take longer than 1ms to complete where other active functionality, radio buffers, traffic load and the actual length of a subtelegram may be factors that extend a system task’s execution.
7.3

Smart Acknowledge
Smart Acknowledgement (SmartACK) is a bidirectional communications protocol where communication happens between two actuators, that is, an energy autarkic sensor and a line-powered controller.
Primarily, SmartACK is used to provide efficient data transmission

42© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

and its reception within an EnOcean ecosystem. When a sensor is inreceive mode, it results in unnecessary energy consumption –SmartACK uses message synchronisation to reduce receiver ontime, in turn, message flow is undertaken in a predefined interval:that is, actual reclaim period. As soon as a sensor sends its telegram, it expects an immediate reply and, as such, the receiver ontime is only available for a short period. If the sensor doesn’t receive
the response in time, then it can reclaim it from a mailbox located on
the controller device. Line powered devices are considered postmasters and can act as a controller or repeater. In some instances, a
repeater may cause some delay, which disrupts synchronisation. As
such, mailboxes are used within line powered devices, which havedirect access with the autarkic device.
The SmartACK protocol uses three actuators, namely a sensor, repeater and a controller – these are actual devices within an EnOcean
ecosystem. A repeater and a controller device may adopt the role ofa postmaster, which houses a sensor’s mailbox. In fact, the functionality within these devices is similar, yet controllers are capable oflearning. Likewise, a repeater may also provide additional functionality such as a light actuator. A SmartACK sensor is a self-sufficientdevice also capable of learning; as such, the controller and sensor
are both aware of each other’s existence.

7.3.1

Mailboxes
A mailbox can retain only one telegram whereas a postmaster may
retain one of two types of mailbox, that is, temporary or normal, as
we describe in Table 7-2. A postmaster notifies a sensor if its mailbox doesn’t exist or if it’s empty. A controller can hold multiple
mailboxes for as many connections it has with other sensors within
the ecosystem.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

43

Introducing the EnOcean ecosystem

Table 7-2: The two types of mailbox.
TYPE

SCHEDULER FUNCTIONALITY

Temporary

A temporary mailbox is used
when learning.

NormalA normal mailbox is used during
standard operation.

Figure 7-3: The radio is switched on whilst thesensor awaits a reply within the reclaim period.

7.3.2

Reclaiming
The reclaim process is the ability to reduce the need for radio on
time, hence time synchronisation established between the sensor andpostmaster is enabled for the duration of the transfer. If a reclaim
has failed, then the sensor can retry up to three times where theperiod between is set by the length of a sub-telegram (see Section
6.1.2, “Sub-telegram timings”). For additional clarity, we illustrate
in Figure 7-3, a message sequence chart showing when the sensor
transmits a reclaim telegram and switches the radio on. The radio is44© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystemswitched on once the sensor receives the reclaim request and thenthe radio is switched off following the reclaim period. The‘acknowledge’ in this sequence forms the conceptualization, smart
acknowledge.

7.3.3

Normal operation and learning behavior
A distinction should be made between normal operation and learning behaviour and, as such, in Table 7-3 we note the SmartACK
telegram differences. Normal operation is the typical data transfer
that is undertaken between two devices; Figure 7-4 illustrates themessage sequence for an operation showing a sensor and a postmaster, which are in direct contact with each other.
Table 7-3: The different types used during normal vs.
learning operations.
TELEGRAMNORMALOPERATIONLEARNING
BEHAVIOUR

InitialData

Learn request

Reply

Data reply

Learn reply

Reclaim

Data reclaim

Learn reclaim

Acknowledge

Dataacknowledge

Learn
acknowledge

In Figure 7-5 we show an alternate sequence where the sensor has
no radio contact with the other device. In this message sequence,
you can see from the illustration that a repeater is used. You should
also note that in both sequence charts, an acknowledgement is optional.
The learning ability actually refers to a sensor’s unique functionality
to understand more about neighbouring sensors. This process isachieved through the exchange of information resulting in learningout or learning in. An autarkic sensor enters learning mode by© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

45

Introducing the EnOcean ecosystem

submitting a learn request, as we illustrate in Figure 7-6 and Figure
7-7 – we depict here a complex scenario since a repeater is involved
due to the sensor not being in radio contact.

Figure 7-4: Normal operation request where thesensor is in direct contact with its peer device.

When a sensor issues a learn request telegram, a Radio Signal
Strength Index (RSSI) value is used to denote if the signal strengthis acceptable. As such, if the value offered is significant, then thedevice is considered to be within direct radio contact.
We have already touched upon how a SmartACK controller or repeater is capable of retaining a sensor’s mailbox. A sensor discovers
the nearest device where a postmaster is then chosen; the controller
or repeater will then decide if the learning is ‘in’ or ‘out’. For thenormal operation and learning behaviour process, the best scenario
is to ascertain a simple mode where the sensor, that is for either
normal or learning, is in direct radio contact.

46© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

Figure 7-5: Normal operation request where the sensor is not in
direct contact with the corresponding device.

Figure 7-6: The learning behavior where thesensor is in radio contact.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

47

Introducing the EnOcean ecosystem

Figure 7-7: The learning behavior where the sensor is not inradio contact and a repeater is used.

7.3.3.1 Learn in and learn out‘Learn in’ is a requirement for a controller to sustain a relationshipwith its sensor; ‘learn out’ is the need for a controller to cease therelationship. A ‘relationship’ can be understood, if the controller isalready aware of an existing relationship or if the controller accepts
EEP telegrams from neighbouring sensors.
7.4

Introducing the Hardware Abstraction Layer
The HAL is the lowest layer within the EnOcean software stack, asshown earlier in Figure 7-1 and Figure 7-2; it provides hardware
independence and abstraction for the underlying Dolphin platform.

48© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

8

EnOcean Equipment Profiles
The equipment profiles essentially form the application layer, as we
earlier illustrated in Section 7, “The Dolphin Architecture”. The
ERP describes the radio telegram where the transmission window istypically under 1ms and it uses little power to transmit data. Due toinfrequent transmission, the likelihood of data is reduced which suits
itself well to a more reliable transport mechanism. We discuss inthis section the EEP telegram structures that, in turn, offer interoperability across manufacturers. What’s more, the EnOcean Allianceprovides three profile elements, which we illustrate in Table 8-1 –these profile elements are common to all equipment profiles.
Table 8-1: The three common profile elements used in the payload.
DESCRIPTION
1The ERP radio telegram type, ‘RORG’.

2

Basic functionality of the data content, ‘FUNC’.

3

Type of device, ‘TYPE’.

In Section 6.1.1, “Sub-telegrams”, we discussed how the RORG
value actually corresponded to ‘CHOICE’, which is represented at
the radio telegram level. As such, in Table 8-2, we describe thetelegram types that are used at the EEP layer.

Figure 8-1: The three common elements that comprise all EnOcean devices.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

49

Introducing the EnOcean ecosystem

Table 8-2: The telegram types that are used within the EEP.

8.1

RORG

TELEGRAM

DEFINITION

0xF6

RPS

Repeated Switch Communication.

0xD5

1BS

1-byte Communication.

0xA5

4BS

4-byte Communication.

0xD2

VLD

Variable Length Data.

0xD1

MSC

Manufacturer-specificCommunication.

0xA6

ADT

Addressing Destination
Telegram.

The RBS and 1BS telegram types
Both the RBS and 1BS telegrams provide a one-byte data payload
where the frame structures are comparable to each other, as we
illustrate in Figure 8-2. However, the use of the LRN-bit in the data
field, distinguishes the two telegram types.

Figure 8-2: The RBS and 1BS telegram frames are comparable with the
exception of the LRN-bit.

50© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

Figure 8-3: An example EnOcean mechanicalenergy harvester wireless sensor based on the
PTM 210 transmitter.

In Figure 8-3, we illustrate an example EnOcean device, which isbased on the PTM 210 transmitter module – a mechanical energy
harvester wireless sensor utilising 315MHz, 868MHz, 902MHz,
928MHz (or 2.4GHz) frequencies. Our example image shows a‘State’ and a ‘Channel’ setting which, in turn, influences the functionality within the status field. Furthermore, two types of messages
are used, namely N-message and U-message, which are further denoted in the status field; see Figure 8-2. The data telegram not only
includes the data type, but the T21 and NU bits in the status field areused to distinguish the state and channel setting. The status field also
includes a Repeater Count (RC). In Table 8-3 and Table 8-4, we
describe the numerous application sets that are used for both RPS
and 1BS telegrams.
Table 8-3: An example list of application types that use the RPS telegram.
RORG

FUNC

DESCRIPTIONTYPE

DESCRIPTION

0xF6

0x02

Rocker switch, 2
rockers.

0x01

Light and blind
control, style 1.

0x02

Rocker switch, 2
rockers.

0x02

Light and blind
control, style 2.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

51

Introducing the EnOcean ecosystem

0x03

Rocker switch, 4rockers.

0x01

Light and blind
control, style 1.

0x03

Rocker switch, 4rockers.

0x02

Light and blind
control, style 2.

0x04

Position switch,home and officeapplication.

0x01

Key card activation
switch.

0x10

Mechanical handle.

0x00

Window handle.

Table 8-4: An example list of application types that use the RPS telegram.

8.2

RORG

FUNC

DESCRIPTIONTYPE

DESCRIPTION

0xD6

0x10

Contact andswitches.

0x07

Single input
contact.

The 4BS telegram typeThe 4BS telegram offers a four-byte payload and we illustrate its
structure in Figure 8-4. Our payload, in this instance, shows a 10-bit
temperature profile that showcases how a range from 0 to 1023 canbe addressed. Finally, in Table 8-5, we describe the set of applications used for the 4BS telegram type.

Figure 8-4: The 4BS frame structure.

52© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

Table 8-5: An example list of application types that use the 4BS telegram.
RORG

FUNC

DESCRIPTIONTYPE

DESCRIPTION

0xA5

0x02

Temperature
sensors.

0x01
0x1B

Variable temperature
ranges.

0x04

Temperature andhumidity sensors.

0x01

Range 0°C to 40°C
and 0 to 100%.

0x06

Light sensor.

0x01

Range 300lx to
60.000lx.

0x06

Light sensor

0x02

Range 0lx to 1.020lx.

0x07

Occupancy sensor.

0x01

Occupancy.

0x08

Light, temperatureand occupancy
sensor (ceiling).

0x01

Range 0lx to 510lx;
0°C to 51°C andoccupancy.

0x08

Light, temperatureand occupancy
sensor (wall).

0x02

Range 0lx to 1020lx;
0°C to 51°C andoccupancy.

0x08

Light, temperatureand occupancy
sensor (outdoor).

0x03

Range 0lx to 1530lx; 30°C to 50°C andoccupancy.

0x09

Gas sensor.

0x01

CO sensor.

0x09

Gas sensor.

0x04

CO2 sensor.

0x10

Room operating
panel.

0x01
0x1E

Various voltage monitor, temperature sensor, set point and fan
speed control; humidity and occupancy
control.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

53

Introducing the EnOcean ecosystem

54

0x11

Controller status.

0x01

Lighting controller.

0x11

Controller status.

0x02

Temperature controller output.

0x12

Automated meterreading (AMR).

0x00
0x03

Counter: electricity, gas and water.

0x13

Environmental
applications.

0x01
0x06

Weather station;
sun intensity,
northern hemisphere; data exchange; time andday exchange;
direction exchange
and geographic
position exchange.

0x20

HVAC components.

0x01
0x03

Battery powered,basic and line
powered actuators.

0x20

HVAC components.

0x10

Generic HVAC
interface.

0x20

HVAC components.

0x11

Generic HVAC
interface (error
control).

0x20

HVAC components.

0x12

Temperature controller input.

0x37

Energy management.

0x01

Demand response.

0x38

Central command.

0x08

PHC gateway.

0x3F

Universal.

0x00

Radio link test.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

8.3

The VLD telegram
The VLD telegram type provides a variable data payload that varies
between one to 14-bytes. In Figure 8-5, we show the VLD frame
structure and in Table 8-6, we describe the range of application setsthat is used for the VLD telegram type. You may notice, the application type shown, in this instance, uses the SmartACK protocol;
something we discussed earlier in Section 7.3, “Smart
Acknowledge”.

Figure 8-5: The VLD data structure.

Table 8-6: An example list of application types that
use the VLD telegram.
RORG

FUNC

DESCRIPTIONTYPE

DESCRIPTION

0x02

0x00

Room Control
Panel (RPC).

0x01

RCP with temperature measurement and display.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

55

Introducing the EnOcean ecosystem

9

Generic Profiles
The EnOcean Alliance TWG is responsible for ensuring interoperability across the EnOcean product portfolio, along with supporting
multiple manufacturers that deploy, integrate and develop using
EnOcean products. As such, the working group originally provided
a series of equipment profiles, something we discussed earlier in
Section 8, “EnOcean Equipment Profiles”, which not only complements the new Generic Profiles, but also offers an alternate profile
set such that new and existing manufacturers have every opportunity
to create and extend their ecosystems with a new generation of
EnOcean profiles or applications. The EnOcean Alliance continues
to support legacy products that have been successfully used over thelast twelve years or so, as well as architecting new profiles that
accommodate a new generation of consumer expectations and requirements whilst being mindful of a need to accelerate the time-tomarket.
“With Generic Profiles, the EnOcean Alliance has
further developed the standardized interoperable
communication of energy harvesting wireless solutions. It allows multi-functional products that flexibly adapt to a variety of applications.”— Marian Hönsch, Technical Working Group,
EnOcean Alliance
What’s more, the EnOcean Alliance has selected an architecture thatminimises development overhead for product designers, as well as
providing sufficient flexibility in product design to assure productlongevity.

9.1

The communication layers
In Table 9-1, we describe the abstraction layers and services that areused for the Generic Profiles (GP), which are mapped against the
OSI model. Using this approach, as depicted in Table 9-1, offers
56© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

software independence from the radio, serial or any other communication type to exchange GP messages. In other words, any radio
medium can be used to deliver content over the air-interface using
the EnOcean software protocol.
Table 9-1: The layer model for Generic Profiles.

9.1.1

LAYER

SERVICE

Application

Product-/manufacturer-specific software
application/GP message generation.

Presentation

Radio telegram processing.

SessionNot used.

Transport

Not used.

Network

Addressing telegrams/RORG/Status processing.

Message types
The GP provides four message types, as we describe in Table 9-2,
where each message is assigned to a destination Identifier (ID) that
is, Addressing Destination Telegram (ADT).
Table 9-2: The four message types for Generic Profiles.
TYPE

PROPERTIESRESTRICTION

Teach-inrequestGP teach-in request.

512 bytes in length

Teach-inresponse

GP teach-in response(bi-directional only).

512 bytes in length

Complete
data

Complete (measurement) data.

512 bytes in length

Selective
data

Selected parts (measurement) data.

512 bytes in length© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

57

Introducing the EnOcean ecosystem

9.1.2

Radio communication
In Table 9-3, we describe the layers and services that are used for
GP during radio communication. Incidentally, the application layer
at the GP API shown in our table, the RORG radio telegram shall beselected subject to the message type. However, if the message exceeds the restricted length, as shown in Table 9-2, then the telegram
shall be split across a number of telegrams.
Table 9-3: The layer model for Generic Profiles during radio
communication.
LAYER

SERVICE

Application

Generates GP messages as a bit stream andascertains message type.

GP API

Selects RORG and translates messages to
one or more radio telegrams.

Dolphin API

Transmits radio telegram(s).

Dolphin chip

The physical radio telegram transceiver.

9.1.2.1 Telegram chaining
As we mentioned, in instances where the GP telegram payload exceeds the restricted length (see TAB), chained radio telegrams areused where the payload is split into the number of messages required by the EnOcean radio stack. For instance, ERP 1, the maximum payload is 13 bytes or nine bytes, if it is an ADT message.
16171816 EnOcean Alliance, “System Specification: Generic Profiles”, v1.0, April

2014.
17 DolphinAPI User Manual,

http://www.enocean.com/fileadmin/redaktion/pdf/download/EO3000I_
API_user_manual.zip
18 EnOcean Radio Protocol (1) Specification,
http://www.enocean.com/fileadmin/redaktion/pdf/tec_docs/EnOceanRa
dioProtocol.pdf.
58© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

9.1.3

Other communication
With the EnOcean Alliance TWG creating generic messages insteadof defining specific telegrams, provides the opportunity for manufacturers and developers to use other communication types and, assuch, we describe in Table 9-4 the available layers that could perhaps be expanded for future use; for example, serial communicationand so on.
Table 9-4: The layer model for Generic Profiles during serial
communication.
LAYER

SERVICE

Application

Generates GP messages as a bit stream andascertains message type.

GP API (withserial support)

Creates serial message(s).

Dolphin API

Transmits radio telegram(s) via ESP3, forexample.

Dolphin chip

The physical serial transceiver.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

59

Introducing the EnOcean ecosystem

10

Remote Commissioning
The EnOcean Alliance has defined a standardized process to pave
the way forward for remote commissioning of EnOcean-based devices in building automation networks. As such, installers and system integrators can now remotely connect battery-less wirelessdevices using a central tool. What’s more, EnOcean’s standard permits such networks to be adaptable, such that existing installations
can easily be expanded or modified.
Remote commissioning defines an ordered and interoperable process to manage EnOcean devices when establishing a new ecosystem or installation. Furthermore, this process offers a standard interface, ensuring ease of use for commissioning and maintaining an
EnOcean network. Utilising remote commissioning with an
EnOcean device reduces installation complexity; removes the needto physically access a device to configure it and allows simpler
replacement of devices. More specifically, remote management
allows EnOcean devices to be accessed and configured remotelyusing a basic set of standardised and mandatory commands called
Remote Management Control Commands (RMCC) which, in turn,provide the abstract structure of a Remote Procedure Call (RPC).
The Technical Working Group (TWG) of the EnOcean Alliance hasdeveloped a complete process for remote commissioning that includes initial set-up, parameterization, control, maintenance anddocumentation of battery-less wireless devices. Our objective is todefine a uniform approach for all of the listed procedures as a nextlevel of interoperability.

10.1

Common rules
Remote commissioning defines the communication between thecommissioned and the target device. Our specification expands theexisting EnOcean standardized profiles and offers enhanced interoperability which, in turn, defines abstract structure of commands and60© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

basic rules for remote access, configuration and a uniform procedureof parameterizing EnOcean-based devices. The communication isbased on the Generic Profiles data description language; the grammatical rules for all options of data encoding for ultra-low powerand energy harvesting radio communication. These also specify how
a managing device – a smart phone for example, talks with the target device.
10.2

Consistent device description
In addition to the commissioning process, the TWG has introduced astandardized file for device description that describes the device andits functionalities in detail in a pre-defined electronic data sheet. It
comes along with a uniform device label, which comprises the
EnOcean ID (communication basis) and the product ID (reference tomanufacturer’s specific end-application). All this information isavailable on a central data base. Installers or system operators canuse a device ID to locate the detailed electronic data sheet. As such,
installers or system operators have immediate access to all the specifics of the product, including the application profiles in use, that is,
EEPs, operational modes and the requirements of parameterization.
This significantly simplifies set-up and maintenance of an EnOcean
network.
The specification has an open character so that manufacturers andservice providers can develop tools such as ‘apps’ and web interfaces that include all functionalities of the remote commissioning. This
will provide installers and system operators with user-friendly solutions to configure, control and maintain automation systems.

10.3

One specification for several tasks
The standardized interface and process of remote commissioning areintended to further optimize the control and configuration of building automation networks by using software that automates the support for EnOcean-based devices.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

61

Introducing the EnOcean ecosystem

In the following list, we describe several remote commissioning
tasks:
 In a network, devices can be identified by theirunique EnOcean ID, radio and device label; The connection between devices (network
structure) can be fully documented and modified (add/change/delete); The device’s operating parameters can becommissioned and documented;
 A device that replaces a previous device, forexample, due to a malfunction, can be remotely
configured using commissioning to match thefunctionality of the replaced device; A device can either be commissioned in thefield or pre-commissioned on- and off-site of
the installation;
 All functionalities of the installed device arestill configurable after the installation has been
completed; A factory reset to defaults is available;
 The radio link/range can be remotely tested using the commissioning tool; A device that supports remote commissioning
can be remotely commissioned without physical access to the device.
10.4

Different use case scenarios
The functionalities of remote commissioning provide benefits inseveral scenarios. First of all, they help to centralize and record theteach-in process. Likewise, they enable system planners to reproduce an implementation at any time, even after several years. As
such, planners can adapt a process or change it for a new device or if
62© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

the network structure needs to be modified. When a new network is
installed, all parameterization can be completed using one central
commissioning tool. The user just needs to scan the device andtransmit this information to the actuator. All necessary information
including IDs and functionalities are transformed with one single
step and stored centrally for configuration purposes.
10.5

Adjustments of an existing network
In an existing network, devices can be commissioned retrospectively. This is particularly relevant for areas where rooms have a similar
design like a hotel, for example. Here, the same commissioning
procedure can be repeated several times for different target devices.
Another scenario is the change of control parameters of intelligent
actuators, for example thresholds and timers in local HVAC equipment, or if the room structure in office buildings has been changed.
The complete process of re-configuration can be undertaken during
operation via remote control without physically touching a single
device. Nevertheless, this might affect the configuration of the application or of the entire system, which can also be completed withthe remote commissioning tool.

10.6

Service and maintenanceThe comprehensive documentation as a vital part of the remotecommissioning process can also be used to set-up a comprehensive
monitoring application to visualize and actively control a live network. More so, visualization tools provide an overview of the documented system structure (plans, drawings, descriptions, tables andso on) that, for example, allow users to identify and solve potential
problems in context. The same functionality can also help to determine malfunctions and the affected devices very quickly. Additionally, the specifics of remote commissioning simplify the replacement of the non-functioning device. For a simpler replacement process, a new device should support the same application profiles (thatis, EEP) as the previous device. Installers can find this information© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

63

Introducing the EnOcean ecosystemin the product labeling, which they can access in the central database. Moreover, the application configuration needs to be restored in
the new hardware. As such, the new device can be commissioned inaccordance with the documented and previously stored link tables
and application configuration of the old device. This guarantees aseamless product exchange without any system failure.
In summary, the EnOcean Alliance’s remote commissioning standard has defined new procedures for the set-up and operation of intelligently automated buildings. This significantly eases the work ofplanners, installers and system integrators. Similarly, it strengthens
the interoperability of EnOcean-based devices as the installer
doesn’t need to concern themselves with specifics. Today, manufacturers can integrate the standardized specification in their devices
and develop tools for central control, configuration and troubleshooting – bringing the intelligence of a smart building to the nextlevel.

64© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

11

Security Options
EnOcean’s energy harvesting wireless solution provides several
enhanced security mechanisms to prevent replay or eavesdropping
attacks. If these are included, a battery-less wireless node ‘counts’
all incoming and outgoing data packets continuously and thus ensures the authenticity of the telegrams. A 16- or 24-bit Rolling Code(RC) incremented with each telegram is added as a constantly
changing, that is, ‘rolling’ security mechanism. So, the telegram
header, telegram data and current rolling code are used to calculate a
24- or 32-bit Cypher-based Message Authentication Code (CMAC).
The CMAC counting is also protected by an Advanced Encryption
Standard (AES) 128-bit encryption algorithm. The receiver system
can then validate the data packet on the basis of the code. Morespecifically, this functionality protects networks against reply attacks – additionally, another mechanism is used to encrypt the data
packets from the transmitter. The data is encrypted using the AES
algorithm with a 128-bit key, in turn, negating eavesdropper attacks.

11.1

Introducing four new RORGs
With these new security mechanisms 19 in mind, EnOcean have introduced four new RORGs, which we describe in Table 11-1.
Table 11-1: Four new RORGs, which bolster EnOcean’s security.
RORG

DESCRIPTION

0x30

Secure telegram. This message was not created froma non-secure counterpart. A message with this RORG
was created by the secure application and the data
may be interpreted by a teach-in-process outside ofthis specification; for example, EEP or GP.

19 Further information can be found in, “Security of EnOcean’s Radio Net-

works,” https://www.enocean.com/en/security-specification/.
© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

65

Introducing the EnOcean ecosystem

0x31

A secure message that transports the original RORG
non-secure code.

0x32

A non-secure message type that results from thedecryption of a secure message with RORG 0x30.

0x35

Secure teach-in telegram transmits private key androlling to the communication partner.

66© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

AGlossary
1BS

1-byte Communication

4BS

4-byte Communication

ADC

Analog-to-Digital Converter

ADT

Addressing Destination Telegram

AES

Advanced Encryption Standard

AP

Access PointAPI

Application Programming Interface

ASK

Amplitude-shift Keying

CDM

Chained Data Message

CPU

Central Processing Unit

CMAC

Cypher-based Message Authentication Code

CRC

Cyclic Redundancy Check

DALI

Digital Addressable Lighting Interface

EEP

EnOcean Equipment Profiles

EIB

European Installation Bus

EoF

End of Frame

ERP

EnOcean Radio Protocol

ESP

EnOcean Serial Protocol

ESSL

EnOcean System Software Layer

FCC

Federal Communications Commission

FCS

Frame Check Sequence

FSK

Frequency-shift Keying

FW

Firmware© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

67

Introducing the EnOcean ecosystem

GP

Generic Profiles

HA

Home Automation

HAL

Hardware Abstraction Layer

HAN

Home Area Network

HES

Home Electronic Systems

HVAC

Heating, Ventilation and Air Conditioning

ID

Identifier

IEC

International Electrotechnical Commission

IEEE

Institute of Electrical and Electronics Engineers

IoT(the) Internet of Things

IP

Internet Protocol

ISM

Industrial, Scientific and Medical

ISOInternational Organization for Standardization

ITU

International Telecommunications Union

KNX

KonnexLAN

Local Area Network

LE(Bluetooth) Low Energy

LBT

Listen Before Talk

LON

LonWorks

LSB

Least Significant Bit

M2M

Machine-to-Machine

MAC

Media Access Control

MAN

Metropolitan Area Network

MSB

Most Significant Bit

MSC

Manufacturer-specific Communication

68© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

MWG

Marketing Working Group

OEM

Original Equipment Manufacturer

OSI

Open Systems Interconnection

PAN

Personal Area Network(ing)PC

Personal Computer

PCB

Printed Circuit Board

PDU

Protocol Data Unit

PHY

Physical (layer)

QoS

Quality of Service

RC

Repeater Count

RC

Rolling Code

RCP

Room Control Panel

RF

Radio Frequency

RMCC

Remote Management Control Command

RORG

Radio (telegrams) ORGanizationally

RPC

Remote Procedure Call

RPS

Repeated Switch Communication

RSSI

Receive Signal Strength IndicatorRX

Receive

SmartACK

Smart Acknowledgement

SoC

System-on-Chip

SoF

Start of Frame

TCPTransmission Control Protocol

TWG

Technical Working Group

TX

Transmit© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

69

Introducing the EnOcean ecosystem

UART

Universal Asynchronous Receiver/Transmitter

UDP

User Datagram Protocol

ULP

Ultra Low Power

VLD

Variable Length Data

WPAN

Wireless Personal Area Network(ing)WSP

Wireless Short-packet

70© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem

B

References & Bibliography
EnOcean GmbH, “Dolphin Core Description” v2.1, December 2014.
EnOcean GmbH, “EnOcean Certification: Quality Seal for Reliable
Interoperability”, retrieved, February 2015.
EnOcean GmbH, “Generic language for EnOcean networks”, retrieved, January 2015.
EnOcean GmbH, “Specification: EnOcean Serial Protocol 3(ESP3)”, v1.27, July 2014.
EnOcean GmbH, “Specification: EnOcean Equipment Profiles”,
v2.6.2, November 2014.
EnOcean GmbH, “Specification: EnOcean Equipment Profiles 2”,
v1.0, September 2013.
EnOcean GmbH, “Security of EnOcean’s Radio Networks,” v1.9,
July 2013.
EnOcean GmbH, “System Specification: Generic Profiles”, v1.0,
April 2014.
EnOcean GmbH, “System Specification: Remote Commissioning”,
March 2014.
EnOcean GmbH, “System Specification: Smart Acknowledge”,
v1.6, July 2014.
EnOcean GmbH, “The Dolphin API”, v2.6.1.0, September 2014.
EnOcean Wireless Standard, https://www.enocean.com/en/enoceanwireless-standard/, retrieved, January 2015.

© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

71

Introducing the EnOcean ecosystem

Gratton, D. A., The Handbook of Personal Area Networking Technologies and Protocols, First Edition, Cambridge University
Press, United Kingdom, 2013.
Gratton, D. A., “What is this Internet of Things, thing?”, Telecoms.com, July 2014.
Schneider, Andreas, “EnOcean Company Presentation”, EnOcean
Alliance, May 2010.
Siskens, W., “Energy harvesting will be big in 2015”, ElectronicsWeekly.com, retrieved, January 2015.

72© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

Introducing the EnOcean ecosystem© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.

73

Introducing the EnOcean ecosystem

74© COPYRIGHT 2016 ENOCEAN ALLIANCE INC. ALL RIGHTS RESERVED.