Reference · built on requestConnectorIndustrial & building protocols

EnOcean

Batteryless sensor and switch data from an EnOcean radio network, read through an EnOcean Alliance IP Gateway.

Request accessPricing ↗

About

EnOcean is an energy-harvesting radio standard run by the EnOcean Alliance, a coalition of building and IT companies formed in 2008. Devices draw power from motion, light, or temperature differences and send short telegrams at 125 kbit/s in the 868 MHz, 902 MHz, and 928 MHz bands. The sub-1 GHz radio is standardized as ISO/IEC 14543-3-1X. EnOcean Equipment Profiles, or EEPs, define how each telegram's bytes are coded so a sensor from one maker works with a receiver from another.

Through Fibric, a connector talks to an EnOcean Alliance IP Gateway, which decodes telegrams into key and value pairs over REST or MQTT. An operator watches those values and proposes a state change on an actuator for your approval.

This is a reference listing. It documents what Fibric would read from EnOcean and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Learned-in devices with deviceId, friendlyId, and EEP, read from GET /devices on an EnOcean Alliance IP Gateway
  • The current state of every device as key and value pairs, such as temperature, humidity, or contact, from GET /devices/states
  • Telegram updates as they arrive, over the keep-alive stream at GET /devices/stream or the MQTT topic EnOcean/{EAG-Identifier}/stream/telegram/{Device-Identifier}/from
  • A log of received telegrams with UTC timestamps from GET /devices/telegrams
  • Supported profiles and their direction, from or to the device, from GET /profiles and GET /profiles/{eepId}
  • Gateway identity, base ID, EURID, and radio frequency from GET /system/info

Proposed actions

  • Target capability: propose a state change on an actuator through PUT /devices/{deviceId}/state, for a profile whose direction is to the device
  • Target capability: propose the same write over MQTT at EnOcean/{EAG-Identifier}/put/devices/{Device-Identifier}/state where the gateway uses that transport

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Trust the sensors before trusting the readings

    A device that stops sending telegrams disappears without an alarm. The operator compares each device's last timestamp against its usual interval and lists the ones gone quiet, with friendlyId and last dbm.

    With Sensor Health

  • Ventilate on CO2, not on the clock

    Room CO2 and humidity keys arrive from self-powered sensors. When a room crosses the threshold you set, the operator proposes a fan or damper state on an actuator taught in to the gateway.

    With CO2 Ventilation, Indoor Air

  • Close the valve before the pipes freeze

    Window contacts report open or closed. On a cold night, an open contact beside a radiator valve gets a proposal: set the valve, then notify the person on duty.

    With Freeze Protection

Requirements

  • An EnOcean Alliance IP Gateway (EAG) that implements the EnOcean over IP specification, reachable over the network
  • Devices taught in to the gateway, since only learned-in devices appear under /devices
  • The EEP of each device, which fixes the keys the gateway reports and whether the device accepts writes
  • Gateway credentials with permission to read states and, for proposals, to put device state
Authentication
Gateway credentials: the EnOcean over IP REST specification leaves authentication to the gateway maker, recommends TLS, and defines a 401 response for an invalid application name or password.

Limits

  • Sensors transmit on their own schedule and cannot be polled; a value is as fresh as the last telegram
  • The IP representation covers EEPs only, not Generic Profiles or Remote Commissioning, and has no representation for teach-in telegrams
  • REST API security is gateway specific; the specification sets no common authentication scheme
  • Radio range is about 30 m indoors, and the sub-1 GHz bands carry a 1% duty cycle

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request EnOcean ↗

Questions and answers

How do EnOcean devices reach an IP network?
Through an EnOcean Alliance IP Gateway. The EnOcean over IP specification defines how the gateway decodes an EEP telegram into key and value pairs and offers them over REST, MQTT, or AMQP. Separate REST and MQTT implementation examples define the resources and topics.
Can the connector send commands to devices?
Yes, to devices whose profile lists the direction to. The Alliance's REST implementation example defines PUT /devices/{deviceId}/state with a functions array of key and value pairs. Keys you omit take the default values defined in the profile.
What is an EEP?
An EnOcean Equipment Profile. It is written RORG-FUNC-TYPE, for example A5-02-01 for a temperature sensor. RORG names the telegram type: F6 for RPS, D5 for 1BS, A5 for 4BS, D2 for VLD. Version 3.1 is the release on the Alliance site.
Ask about EnOcean

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with EnOcean through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy