WTH is the enocean support that basic

The support for enocean devices is pretty bad. In europe (germany and france) there are a lot home automation systems use enocean.
I use the hora smartdriveMX as TRV, and they are sadly not supported.
There are pull reauests, but they stagnate… there is hardly any effort to support the authors to integrate the PR, thats sad.
I vote for better enocean support. Connunity is willing to help

yeah, wth!

So what’s needed? Support for the USB gateway (USB300/500U/400J), and does that then know all the devices, or do they need to be supported seperately as well? Big task I think, but worth it, as it’s quite widespred (self powered door sensors, ie. NO BATTERY or 240V).

Anybody tried one of the two mqtt bridges?:


1 Like


I am the developer of HA_enoceanmqtt.
Like you I was frustrated by the EnOcean integration and I saw that many pull requests where blocked by the Home Assistant developers.
So I decided to make something based on MQTT.

Up to date, the following devices are available:

- [x] `D2-01-0B` 
- [x] `D2-01-0C`
- [ ] `D2-01-0F` (not tested)
- [x] `D2-01-12`
- [x] `D2-05-00`
- [x] `F6-02-01`
- [x] `F6-02-02`
- [x] `F6-05-02`
- [x] `D5-00-01`
- [ ] `A5-12-00` (not tested)
- [x] `A5-12-01`

Adding new devices should not be difficult.

So feel free to try it and I am available to provide support.


Hi mak-dev,

Thanks for visiting us here! I will try it ASAP (hopefully this year ;-)) .

Right now, i am using iobroker with mqtt to controll some enocean devices (TF61-L , https://www.eltako.com/fileadmin/downloads/de/_bedienung/TF61L-230V_30100032-2_dt.pdf and TRF61-j, Jalousie actor (blinds?!) https://www.eltako.com/fileadmin/downloads/de/_bedienung/TF61J-230V_30200032-1_dt.pdf)

It works ok-ish, but i am eager to try something lighter .

Are these two devices supported with your approach?


EDIT: Just read the discription again on github and this is even an Home Assistant Addon !!!Great!

Yes, the addon is in experimental phase.

Do you have the EEP of your modules ?
I need that to know whether they are already supported or not.
And if not, to know how I could add support for these modules.

H5-3F-7F or A5-3F-7F
(source: EnOcean-TF61J-Eltako-TippFunk-Jalousieaktor – FHEMWiki)
for the TRF61-j, Jalousie actors

which is after: EEPs - EnOcean Alliance
137 A5-3F-7F Universal

But i m still googeling…

A5-3F-7F is a universal EEP. It means that it is manufacturer-dependent.
So it is not supported as it stands.
I will need to find more information about this module to integrate it.
I will let you know once I have something ok.

1 Like

I came across your Enocean integration yesterday and installed it on my system. So far everything seems to work and I see the devices and entities.
However, I still have a very basic question.
Could you describe the underlying function in more detail? I’m having a bit of a hard time understanding the exact process.
Example: I had an electrician install an Enocean system here in my house. Based on the 14 series from Eltako.
Exactly I have in use Eltako FAM14, Eltako F4SR14-LED, Eltako FSB14 and EnOcean PTM210.
The PTM210 are the buttons and switch lights and shutters. FAM14 is the radio antenna module and if I understand it correctly the center of the whole thing. The FSB14 are for the shutter control and the F4SR14 LED then for the lighting.

I think so far so clear. Currently, therefore, rather a closed system without connection to a smart home solution.

How does Home Assistant and the USB300 fit into the picture. Sends and receives the USB300 commands via Home Assistant and works so to speak as a gateway to the Enocean system, or will the USB300 with Home Assistant to a new center with which I can control all individual sensors and actuators. However, then I have to teach them again on the USB300. Similar to a Zigbee device and ZHA.

What I then also do not understand is how I switch on, for example, a light via Home Assistant.

I realize I really lack the basics here. Could someone help me here?

Thank you very much,



My explanation would be:
Homeassistant and the USB300 represent a (new) “center”.

So you would need to teach in every device you want to control with homeassistant.
In the moment you can just see what happens in the enocean network, like if you use the enocean dolphin softwear for windows.

After teach in, i would expect that the enocen device will be integrated into homeassistant as a device :wink: → so look for it in the settings → devices&services and add it to lovelace , for example to control it.

Hi @JAD,

I may be wrong as I really don’t know Eltako devices but it is my understanding that your installation looks like this:

Your only EnOcean devices are the FAM14 and the PTM210.
All other devices are RS485 devices wired to and control by the FAM14.

From what I read on the FAM14, it is able to control RS485 devices depending on data received from EnOcean devices.
Your electrician must have configured your FAM14 to control this shutter or that light depending on the PTM210 button you press.
This configuration is done on the FAM14 directly.
Whether the FAM14 can learn new EnOcean control devices is still unclear to me.
Should this be possible, then HA thanks to the USB300, would be able to control your RS485 devices through your FAM14, just like it is done with the PTM210.

At the moment, in HA, you should only see actions from PTM210. I am not sure whether you could see actions from the FAM14.

Once again I may be wrong as I am not at all familiar with Eltako and this kind of EnOcean use.

Hi mak-dev,
thank you very much for your answer.
I think you have recognized the principle quite correctly.
If I understand you correctly, you mean I would have to teach the USB300 to the FAM14 first, correct?
Each of the RS485 devices seems to have an Enocean address even if it does not speak Enocean. The FAM14 is then the mediator. Hope this is correct…?
How would I have to program the whole thing in Home Assistant? Simply as in your example each device with its ID and the EEP in the Config file. How would I then switch on a lamp, for example???
Thanks for the help.


Yes, this is what I understood from my FAM14 readings.


For that, I think I would need to have a better view of your EnOcean network.
Could you run the app with the debug option enabled and share your log file (privately if you prefer).
This way, I could see the EnOcean traffic and better understand what should be done.
EDIT: I may have misread your last question. The answer is yes. As simple as that !
Once you have the addresses and EEPs of your EnOcean devices, you just have to set them in the device config file like in the example and that’s it.
You will have in Home Assistant, under the MQTT integration, new devices and entities that you can then use to control and monitor your EnOcean devices.
By the way, you can also try to run the app with the devices in the example to see how it looks like in Home Assistant.
My previous answer was related to the FAM14 and how we could find the EEP of your devices to set the config file accordingly.

Hi mak-dev

These would be really great: The best would be my hora… they are pretty good and I don’t want to remove them…

  • A5-20-04 (Hora SmartDRIVE Mx valve)
  • 10 bit EEP for enocean temp/humidity sensors (EEP A5-04-03) not supported
  • Binary window sensors (EEP D5-00-01)

I would like to have a docker container for that, and how to integrate. As I am running a plain rasbianOS Pi, the addon does not work for me.

Hi @wallenium,

D5-00-01 is already supported.
I will have a look at your A5 devices.

Yes the docker image is in the to-do list.
But I didn’t get why the addon installation doesn’t work for you.
You also have the standalone installation.

Initial support for A5-04-03 is now available.
A5-20-04 require just a little more time which I am missing these days. I will do it as soon as I have a little time.

Please have a look at this discussion on Github.

I found the telegrams to transmit for your TF61J and TF61L.
No particular problem for TF61L. Just missing a little more time at the moment.
But for TF61J, as it is a universal profile, it means that another device can define a completely different telegram and should that other device require to be supported, then problems may arise.
I have to figure out how to handle this case to avoid problems.

1 Like


thank you very much for your message. Please excuse my late response, I was quite involved familywise.

I have read through the individual posts and also the discussion on Github several times and my head is still buzzing.
Actually, I thought I had some understanding about such things. But there I am out.

What I have understood so far.

  1. I have to teach my USB300 stick with the Eltako FAM14 with a “Base ID”.
  2. I simulate via the “Devices File” various buttons which can then be addressed in Home Assistant via MQTT. For this I use variations of the “Base ID” of the USB300, in total I have 128 addresses. Each “virtual” button switches the light on or off, or raises or lowers the blinds.

I hope this is correct.

What I do not understand now is:

  1. how does for example the actuator for the light (F4SR14-LED) know that the pressed virtual switch addresses it and not another actuator?
  2. via this method I can switch the light and the blinds, but not the current status. Is this generally not possible or have I misunderstood something?

I think first up to here. Over the weekend I will have another look at the Enocean integration of FHEM, OpenHAB, ioBrocker and NodeRed. These are supposed to be very well documented in some cases. Maybe that will help me a little in understanding.

Thanks again.




Exactly! :+1:

  1. You have to pair your virtual switch with your desired actuator. Normally you should have a LEARN button or LEARN position on your F4SR14-LED. You should put the desired F4SR14-LED (And only this one) into LEARN mode then press and release your virtual switch.

  2. To have the status, the FAM14 must generate radio telegrams which indicate the status of the actuators. As I don’t have and don’t know Eltako devices, I don’t know if this is the case. If this is the case, then it should be easy to retrieve the status of the actuator.
    Thus my previous comment:

I wonder whether I should create a new topic to not “hijack” this one with my proposed MQTT-based solution :thinking:

Thank you for your quick reply.

I also think we should possibly open a separate topic. Makes the whole thing a little clearer.

Can you please tell me again briefly what I should prepare when I create the log. Currently I am not sure if I have even one device correctly entered in the Config…

Thanks a lot