Eltako FGW14-USB

[HotteX]

EnOcean by wire

This might or might not be a bigger thing, so lets start.

What is it?

The FGW14-USB Gateway is a simple entrypoint into the hardwired RS485 bus used by Eltako for connecting their BR14 (and BR12) Enocean-stuff inside your main switchbox.
It speaks ESP2 (which should be the same like the USB300), but uses only 57600 BAUD.
It does not have or need a Base-ID

Whats the difference to using the USB Radio (or Pi-HAT)

• Wired - making communication secure and reliable.
• When it comes to receiving telegrams: The FAM14 with antenna (in my case) is a lot stronger than the tiny PiHAT)
• Direct communications to all BR14 (and in parts BR12) devices and all status telegrams (that are usually not broadcasted)
• without the limitation of the base ID. As far as I understood: On the bus you can use any address as long as its valid. Not limited to 128 devices. It won't be checked.
• In theory this should make it easy to build systems with a fallback (Like: Temperature sensor A talks directly to actor B but gets overridden by Home Assistant (to switch off heating, when the window is open for example) but IF HA crashes or dies, the system still works (without being very smart of course).
• It also makes it easy to integrate already existing setups, as you dont have to teach all devices again, just use the adresses of sensors that are already known to the actors.
• Eltako has switches that use encoded telegrams, a very nice thing for security but a hell for smart home wireless sniffers. Encryption happens between sensor and the FAM14 radio. On the bus those telegrams are decrypted and readable.

It wont work (alone) if there are wireless actors outside of the bus though. Those telegrams need to be broadcasted directly. I think you cannot use FAM14 easily to send telegrams from the gateway. Maybe it is possible if you emulate an Eltako-BR14 device. I don't know and I guess there are more pressing things to do before that.

So for a first start I would try if the currect addon can read the bus if you just lower the BAUD. Maybe make that an optional field in configuration? Also the check for the Base-ID needs to go as there is none.
If we're lucky that's all.
Secondly maybe it would be perfect to have both Gateways usable in parallel (to broadcast telegrams directly) but in my case thats not neccessary. I have no actors outside the bus.

Adding to this: Maybe it's time for a Wiki of some sort so that special configurations for devices (I am looking at you Eltako) are easy to find for future users.

[magic2910]

I have a FGW-14 and some dimmers, relais etc. So I can test a few things, if needed

[mak-gitdev]

Hi @HotteX,

Big topic this one !

If I correctly understand, you want to connect HA directly to your FAM14 usb serial port instead of USB300 or EnOceanPi HAT, right ?

Baudrate is already 57600 so no problem. You can try and report the log.
We will see what errors we get at this point.
The problem is EnOcean-MQTT "speaks/understands" ESP3 but FAM14 "speaks/understands" ESP2.
There will be mismatches...

There is already a wiki

[mak-gitdev]

Getting this Waiting for base ID message is the expected behavior as it is supposed to be interfaced with an EnOcean chip supporting ESP3.

I have to better understand our the FAM14 works to try adding support for it as an entry to an EnOcean network.
Do you have documents dealing with that ?

Once I will have a better knowledge, if adding support is very easy then it will be done ASAP.
Otherwise, I think it will come after most of the items in the TO-DO list get implemented 😊

Regarding coffee, tea, chocolate, or whatever else, I don't plan to set up such a thing. Unless of course someone want to reward me with $1,000,000 😅
I am doing this for fun, and I am having fun doing it.
But thanks for the intention.

[HotteX]

Do you have documents dealing with that ?

Not yet. I send a request to Eltako. They usually have very helpful technicians, even though the answer takes a while sometimes.

The protocol itself is described here: https://www.enocean.com/wp-content/uploads/Knowledge-Base/EnOceanRadioProtocol2.pdf Chapter 4.3 & 4.4 for the packets.

I think there may be not much more to it (for reading) than to correctly interpretate the raw data.
I captured the stream and its already "readable".

These are 3 telegrams as sent by the FGW14-USB. A press and a release of button 3 from sensor fef791fc, an encrypted FT55.
The 3rd is from an unencrypted temperature sensor.

a55a 0b05 7000 0000 **fef7 91fc** 3032 
a55a 0b05 0000 0000 **fef7 91fc** 20b2 
a55a 0b07 00a5 750f **0593 da67** 0014

The same 3 packages sniffed directly from the air. The first 2 from FE:F7:91:FC are garbage (encrypted). The 3rd from a temperature sensor is readable.

2023-01-25 16:18:07,874 DEBUG: FE:F7:91:FC->FF:FF:FF:FF (-65 dBm): 0x01 ['0x30', '0x4', '0xfd', '0x14', '0x62', '0xfe', '0xf7', '0x91', '0xfc', '0x0'] ['0x2', '0xff', '0xff', '0xff', '0xff', '0x41', '0x0'] OrderedDict()
2023-01-25 16:18:07,882 WARNING: message not interpretable: enoceanmqtt/switch/DG_Arbeitszimmer
2023-01-25 16:18:08,748 DEBUG: FE:F7:91:FC->FF:FF:FF:FF (-67 dBm): 0x01 ['0x30', '0x5', '0xa1', '0xbb', '0x73', '0xfe', '0xf7', '0x91', '0xfc', '0x0'] ['0x1', '0xff', '0xff', '0xff', '0xff', '0x43', '0x0'] OrderedDict()
2023-01-25 16:18:08,755 WARNING: message not interpretable: enoceanmqtt/switch/DG_Arbeitszimmer
2023-01-25 16:18:10,320 DEBUG: 05:93:DA:67->FF:FF:FF:FF (-79 dBm): 0x01 ['0xa5', '0x0', '0xa5', '0x75', '0xf', '0x5', '0x93', '0xda', '0x67', '0x0'] ['0x1', '0xff', '0xff', '0xff', '0xff', '0x4f', '0x0'] OrderedDict()
2023-01-25 16:18:10,334 DEBUG: enoceanmqtt/Temp/EG_Bad: HUM (Rel. Humidity (linear))=66.0 %
2023-01-25 16:18:10,335 DEBUG: enoceanmqtt/Temp/EG_Bad: TMP (Temperature (linear))=17.439999999999998 °C
2023-01-25 16:18:10,336 DEBUG: enoceanmqtt/Temp/EG_Bad: TSN (Availability of the Temperature Sensor)=available 

This adapter is working in FHEM (PERL), I think openhab and iobroker has a working integration as well. Description here: https://forum.iobroker.net/topic/55286/test-adapter-enocean-v0-7-x Source here: https://github.com/Jey-Cee/ioBroker.enocean

Regarding coffee, tea, chocolate, or whatever else, I don't plan to set up such a thing. Unless of course someone want to reward me with $1,000,000 😅
I am doing this for fun, and I am having fun doing it.
But thanks for the intention.

If I can spare the $1.000.000 in future I will ask again ;)
Then just be assured that I am very grateful and happy that you do what you do and I sincerely hope you do not loose your fun.

[magic2910]

Maybe this old Integration could be useful:
https://gitlab.com/chrysn/home-assistant-eltako

[HotteX]

This is a very interesting find. It references this project in the code, that seems to be exactly what we need. The python implementation of ESP2 for Eltako: https://gitlab.com/chrysn/eltakobus.
Even though both projects seem abandoned, the maintainer is still active, so maybe it's possible to get some help if needed. My coding is too bad to even start to try.

[HotteX]

Hi @mak-gitdev, had any chance to take a look yet into this (or alternatively the option to simulate more than one device on HA)?

For my testing here I would be fine with sending temperatures I get from my Zigbee devices into Enocean (and my heating controllers) but that would mean around 10 devices sending into Enocean.

My system is open for any tests you need, when the time arises.

[HotteX]

Here they are discussing a similar topic on the official HA-EO dev it seems to me, but unfortunately this stuff seems abandoned. But maybe it has valuable information or code to use:

kipe/enocean#123

[HotteX]

Nope, nothing new. No entry in my Logs.
I don't know anymore, what settings I used, when I dumped the packets some weeks ago for the post further up, but according to specs it should be 57600 Baud and ESP2.
Could you insert some debug-points, content of variables or something, so we see, where it fails exactly?

[mak-gitdev]

Hi @HotteX,

I think you could simply read the serial port stream using your preferred linux tool. If you get packets, then it means that the problem comes from ESP2 not being supported by the EnOcean library.

Then one solution would be to create an ESP2<->ESP3 adapter between the FGW14 and the EnOcean library.

I have to take a closer look at it.
It would be an interesting feature to add.

By the way, if you are only interested in using FGW14-USB, as it is not supported at the moment, I just found this repository which seems to do exactly that.

[HotteX]

Hello...summer is over, I lost my github (and got it back). Sorry for lacking any reply on this one... I have not seen it until now.
This is exactly what I needed...and it works. Its a rather "rough" implementation, but it actually manages to talk to the bus directly.
Thanks a lot for finding it.
Now I just need to get them to support my F4HK14, as at the moment...they don't. So the only thing I can do is fetch my switches encrypted switches (after decryption), but its a very huge step in the direction I like to go :)

The implementation works fine together with enoceanmqtt. At the moment I get temperature sensors via Enocean-HAT > enoceanmqtt and switch sensors via Eltako FGW14-USB > ha-eltako :) Now "all" I need is feeding stuff into my actors....

[mak-gitdev]

Hi @HotteX,

Nice to see your feedback and happy that you are starting to make your setup working 👍

It is still in the to do list so I won't hesitate to bother you in due course 😄

[HotteX]

Yes, bother me in due course :P Until then I will try to use & improve the Eltako-Addon. I am sure this will help a lot as they already did most of the work to implement this. Maybe it's not even a bad thing to have the projects seperated, but working together.

[mak-gitdev]

https://github.com/users/mak-gitdev/projects/1?pane=issue&itemId=35567496