EnOcean MQTT Bridge for Home Assistant – Raspberry Pi + TCM310, supports VAES encryption, F6 dimmers, switch passthrough

EnOcean MQTT Bridge for Home Assistant – Raspberry Pi + TCM310, supports VAES encryption, F6 dimmers, switch passthrough

Hey everyone,

I wanted to share a project I’ve been working on over the past weeks: a Python-based EnOcean to MQTT bridge that integrates EnOcean devices natively into Home Assistant.

Background

I was running FHEM as my EnOcean gateway for years, but wanted to move everything to Home Assistant. The existing solutions either didn’t support the devices I have, or required too many compromises. So I built my own. And finally made a lot of trouble. Also HA discovery was not possible.

What it does

The bridge runs as a docker container on a dedicated Raspberry Pi Zero 2W with an Enocean TCM310 module and connects EnOcean devices to HA via MQTT. It publishes Home Assistant MQTT Discovery payloads automatically, so all devices appear in HA without any manual configuration.

Supported device types:

  • D2-01-0F – NodOn light actuators (on/off, unicast VLD, D2 status feedback)
  • D2-05-00 – Cover/blind actuators (open, close, stop, position)
  • D2-03-00 – Eltako secure switches with VAES encryption (AES-128, rolling code, auto teachin)
  • F6-02-01 – F6 RPS dimmers (on/off + brightness control via timed button hold)
  • A5-14-0A – VAES encrypted window/door contact sensors (contact + voltage + illumination)
  • switch_passthrough – Physical EnOcean switches directly linked to dimmers, including 2-channel switches controlling two independent dimmers

What makes it interesting

VAES crypto – The Eltako D2-03-00 devices use a proprietary VAES encryption scheme that’s not documented in the EnOcean spec. I reverse-engineered the implementation from FHEM’s 10_EnOcean.pm and verified it against real frames. The rolling code counter is persisted across restarts.

F6 RPS dimmer control – The Synergie21 EOS 09 LED drivers use F6 RPS (rocker switch simulation). Since there’s no direct brightness command, the bridge calculates hold duration from the target brightness level and sends timed press/release sequences. Brightness state is tracked across on/off cycles.

Physical switch passthrough with toggle – EnOcean switches are taught to the bridge (not the actuator directly). The bridge receives F6 events, determines press duration, and either toggles on/off (short press) or forwards a dim command (long press ≥ 1s). The known state is used to always toggle in the right direction. 2-channel switches can control two independent dimmers.

Auto TeachIn – For secure D2-03-00 devices, if the bridge sends a command and gets no F6 confirmation within 3 seconds, it automatically sends a TeachIn and retries. Useful after a factory reset or RLC desync.

Architecture

EnOcean radio → TCM310 → python-enocean → Bridge → MQTT → Home Assistant
                                           ↑
                                     state persistence
                                     VAES crypto
                                     switch passthrough logic

Fully Dockerized, MQTT credentials via environment variables (.env), state persisted on a mounted volume.

GitHub

:backhand_index_pointing_right: GitHub - andreasbloch/enocean-mqtt-bridge: EnOcean to MQTT bridge for Home Assistant. Supports lights (D2-01-0F), covers (D2-05-00), VAES-encrypted switches (D2-03-00), F6 RPS dimmers with brightness control, window sensors (A5-14-0A) and physical switch passthrough. Runs on Raspberry Pi with TCM310. Docker-based. · GitHub

The repo includes a config.yaml.example with all supported device types and a README with TeachIn procedures for each device type.


Happy to answer questions or take feedback. If you have EnOcean devices that aren’t covered yet, open an issue — the architecture is designed to make adding new EEPs straightforward.

1 Like