Hey!
I’m by far no Python nor Home Assistant pro, so please be kind with me.
You may want to have a look at
I did a bit of development to get this thing running with my bus system here and for now it’s doing just fine. 
Let me know if it’s working for you or if you have some trouble…
Thanks a lot, @Johannes_B , for your contribution.
I will gladly test on my system, and if successful, I’d be happy to merge your changes into my repository.
Looks like quite a big code refactoring.
Hello @Johannes_B,
I’m also interested to use your eltako Baureihe 14 integration. Sorry for asking very low level questions - I’m completely new to eltako Baureihe 14 and Home Assistant.
I have got a very basic setup with FAM14, FGW14-USB, FSR13-4x and FUD14 and connected two light bulbs to the relay and dimmer. The system itself is configured and working with a regular eltako switch F4T55E.
I’ve downloaded your branch fgw14-communication and configured HA. So far everything looks quite nice.
eltako:
light:
- id: "00-00-00-01"
name: "Relay Test"
eep: "M5-38-08"
sender:
id: "00-00-B0-01"
eep: "F6-02-01"
When I want to switch on the configured light I’m getting the following error message:
2023-04-17 22:42:44.971 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.10/site-packages/eltakobus/serial.py", line 226, in send
self.transport.write(serialized)
AttributeError: '_asyncio.Future' object has no attribute 'write'
For me this looks more like a incompatibility to the eltakobus lib. Do you have any hits for me how to troubleshoot this problem?
Is there an easy way to see it the FGW14-USB is properly connected? What BA position/baud do you use for FGW14-USB?
Is there also an easy way to monitor the actual bus activity?
Sorry for asking stupid questions. After changing config to:
eltako:
light:
- id: "00-00-00-01"
name: "Relay Test"
eep: "M5-38-08"
sender:
id: "00-00-B1-01"
eep: "A5-38-08"
- id: "00-00-00-05"
name: "Dimmer Test"
eep: "A5-38-08"
sender:
id: "00-00-B1-02"
eep: "A5-38-08"
logger:
default: info
logs:
eltako: debug
both light bulbs are working as regular switch and dimmer. Furthermore logging is also properly working.
There was a wrong sender eep entered and a proper restart was missing.
Hello people in this thread,
first of all I need to say I’m really stunned what you’ve developed. When I’ve decided to use Eltako Baureihe 14 and at that time I thought I gonna go a real hard way of reengineering the whole bus protocol.
Thanks for the work and sharing all your effort!!!
@Johannes_B: I’ve found a little issue in your code. When you want to trigger events cased by wall-switches the event cannot be serialized because of a hex value instead of str. Checkout line 132 from binary_sensor.py.
I’ve adapted the code a bit, also in a way that I can detect combinations of pressed buttons on the same wall-switch. See here. Because I’m quite new to everything and good in forgetting things I’ve made a small tutorial for me and followers.
Furthermore, I would be interested in a discovery service which can detect all the devices mounted in the Eltako Bus so that I can automatically extend the Home Automation configuration for the initial setup. Setting the sender id for Home Automation on the Eltako devices in the bus would be nice as well. To do that I’ve checked out the development docs of HA but unfortunately I found only descriptions in which they use existing IP-based discovery services. Did someone already look into this topic - How to extend the HA config programmatically?
Hi all,
great to see that this integration is starting to get some traction. I love it!
@philipp14 , @Johannes_B , as you have forked the repo I opened on Github, and in order to keep things together, could you push your changes into the originating repo through pull requests?
FYI: I also created issues for further features I’d love to see in this HA Eltako14 integration:
Amongst others: automatic discovery of devices, having a HA UI config flow, etc.
I’d love to see this integration evolve towards a HACS integration.
Thanks!
regarding device discovery - I’ve already started a test to read the memory of the devices by using the eltakotool from @chrysn. So far I suck because I don’t know how to transfer it into HA. Here are my current results: output config and code
Thanks, @philipp14 .
I wanted to test it on my system, but I’m struggling to get it set up…
I have:
Any idea how I can capture the FTS14EM wall switch input signals in HA to trigger automations?
In the PCT14 software I was able to capture the IDs:
The 3 input contacts on my FTS14EM are also learned into the FSR14 and FUD14, so my wall switches can control the FSR14 light switches/relays and FUD14 dimmer.
Hello @michaelpiron,
that is almost what I’ve tried as well and found a little bug which is already solved by now. I’ve created a little documentation about how to use it here.
In this example I just tried it with my rocker switches but it may work with FTS14EM too. Just check out what is recognized as command here and if the following code gets called.
I do have an unopened FTS14EM at home and haven’t tried it out yet. If it’s not working for you I’m happy to help. Please let me know your result.
Small hint: If I want to know what is going on on my eltako bus I simple plugin a USB cable in FAM14 . In parallel I have a USB cable in FGW14-USB which I use for HA. Then I use eltako14bus lib to read the messages on the bus via FAM14 and by using the listen command: eltakotool --eltakobus /dev/ttyUSB0 listen.
I’m still thinking about if I shall invest more into the automatic device detection. By now I’m able to read all signal from the bus (devices + their memory/configuration + sensor messages incl. switches). To get all devices statuses you should enable permanent status updates of the devices which you can do by putting FAM14 BA switch to 4. (Downside: the bus will become very very very chatty)
By exploring this I found out FGW14 is filtering out some messages. FAM14 instead provides at least more. You also cannot send status pull messages (EltakoPollForced) via FGW14 to read the status of devices those will be filtered out as well. It works by using FAM14 and after reading the FAM14 instructions I’ve learned you can simple put BA switch of FAM14 to 4. 
Let me know if you would be interested in an automatically generated list of all your devices and sensors? I’ve did a start in eltakodevice_discovery to read the device types and address on the bus. It already creates the device config part. I could simple extend that for sensors. In this case you would need to trigger the sensors so that the code can read the sensor signals on the bus. What I haven’t found out yet is how to update the configuration of HA programmatically like homematic does it.
One more think: Putting FAM14 BA switch to 4 is good when loosing the connection between HA and eltako bus via FWG14. Because then HA will be out of sync and the statues of the devices could be wrong. When HA is reconnected to the eltako bus it will automatically get all device status updates.
I haven’t properly tested it but I’ve had the feeling that eltako HA integration is not able of automatically reconnecting the bus. Did you experience something similar? For me the system is not yet running productively therefore I cannot say how stable it is and if it would eventually reconnect. My HA is just running in dev mode.
Hello people in this thread,
thank you very much for this custom integration!
In my set-up there is a FAM-14 along with several FSB14 and FSR14-4x modules. There is no FGW14-USB module in my set-up.
Up to now I am controlling my Eltako actuators via an USB300 adapter and with an inelegantly self-modified version of the EnOcean Integration, which sort of works but is far from being actually usabe.
Would it be possible to use this integration with my present hardware, or what would have to be added/changed? Did I miss something and it should just work?
(I am not sure whether this is actually a vaild question, please be merciful, I am just meandering through code.)
Thank you very much!
Hello @Nurwodah,
I do not know USB300 from what I have seen it could theoretically work. It uses an serial interfaces and UART as well for communication like FAM14 und FGW14-USB does it. Eltako uses RS485 as bus protocol. I assume this is abstracted at this point. Actually on only need the EnOcean Messages and maybe you can put BA switch of FAM14 into a mode so that it will send frequently the status messages. What I haven’t seen in the spec is if baud rate is compatible. This is currently not configurable in the eltako integration. (See here in the code.)
Specs of USB300 says EnOcean standard 3 is supported. Eltako14bus uses version 2. I’m not sure if that is downwards compatible or if USB300 just supports both. Actually I’m asking my self what kind of functionality is anyway specific to that. A simple message transmitter should definitely work.
When I was browsing through the OpenHub community, which has a quite well established eltako integration, the people there always recommended to use a cable based connection with FGW14-USB. Wireless seems to be unstable although I personally do not have any wireless transmitter experiences in combination with eltako14bus.
What you can test is: Just plugin in what every you use for hosting Home Assistant via USB cable into FAM14. Both FAM14 and FGW14 do work with the eltako HA integration. FAM14 supports much more commands than FGW14. You can also use it to read the memory of all devices and write into it which is not possible via FGW14-USB. … In general I would recommend to use FGW14-USB for productive usage. Here are my experiences:
Hope it helps a bit!
Hi Philipp,
Thank you for your promt reply!
I cannot yet test a cable connection since my cable is just too short, miniUSB is rare these days.
Nevertheless, I tried the following:
The USB300 is working at 57600, verified with dolphinView when I connected the stick to a windows machine.
Also, I cannot find an error in HA logs, when I trigger an appropriate switch in HA it says that a message which looks about right was sent (debug mode).
Before I tested it with the eltako integration I deactivated the enOcean Integration. Do I have to actually delete the enOcean integration to avoid a possible serial port conflict? How do I determine which serial port the integration is using anyway, maybe I just chose the wrong one by accident?
Tried the following code:
eltako:
switch:
- id: "00-00-00-01"
name: "Eltako Licht Test"
eep: "M5-38-08"
sender:
id: "FF-DF-83-11 left"
eep: "F6-02-01"
where the sender id (base id of the USB300+offset) is the one tought in to the FSR14. Is that correct?
On the FSR14 side I tried functions 2 with “linke Wippe” and “rechte Wippe” as well as 51, but nothing worked.
Hello @Nurwodah,
Regarding usb-ports and serial ports I do not know much about it. Would be definitely cool if HA had an abstraction layer of it so that many integration could use the same serial port. For testing I definitely would at least deactivate everything using potentially the same USB-device/port.
What I can say is that the eltako integration is not limited to a special USB device like FAM14 or FGW14-USB because that you could theoretically do in HA which is not.
VERY IMPORTANT: HW changes need restart of HA. When you plugin the usb stick you need to restart so that HA recognizes the change.
When testing I recommend to restart often 
When adding the integration HA is prompting a dialog where you can choose the port. Here you should also see the device name.
Regarding yaml the sender config won’t work most probably. I’ve improved the docs a bit in my home-assistant-eltako fork. Check out the config docs. Feel free to contribute and add things. I’ve also planned to eventually push it back to the original repo.
Regarding device config: You need to enter the sender id as sensor address and choose always the function for GFVS (Eltako SW) which is in case of relays 51 but differs from device to device.
You can also check out the device detection script which I started. It generates an almost usable configuration, just some eep ids cannot be clearly mapped. Here is also an example of a generated config.
Hi @philipp14 ,
I found a mini-USB cable which is long enough and communication seems to work in principle.
However, there is still no success. I the configuration, I put the following code:
eltako:
switch:
- id: "00-00-00-23"
name: "Eltako Licht Test"
eep: "M5-38-08"
sender:
id: "FF-DF-83-11"
eep: "F6-02-01"
(For the id (not the sender id) I also tried FFF124A3 which is the base ID of the FAM14 + Adreess Nr. 35. Both seems to adress the correct FSR14, as it blinks once, if I trigger the switch in HA)
But, the FSR14 does not switch.
Also, the switch in HA jumps back to “off” after ~1 sec.
This is the configuration as it is shown in PTC14:
In the logs, it says something was sent:
and afterwards there are messages concering a cyclic actuator request, I guess.
What am I doing wrong? Thank you for you patience in advance!
Markus
Hello @Nurwodah,
you should define a new ‘virtual’ switch/sender for HA. Just define a new sender id. I personally use 00-00-B0-00 as base address and add the number of the device address on top to not get confused. In your case that would be “00-00-B0-23”. Then exchange in line 21 in your device memory “FF-DF-83-11” through 00-00-B0-23. Function 51 is correct and channel 1 fits as well.
Then try the following config in HA.
eltako:
light:
- id: "00-00-00-23"
name: "Eltako Licht Test"
eep: "M5-38-08"
sender:
id: "00-00-B0-23"
eep: "A5-38-08"
Switches and lights react on sender eep “A5-38-08” which is a gateway command. (see in spec.)
Light sends the ‘virtual’ command you’ve defined and a switch sends real rocker button commands to the eltako bus.
Hello @philipp14,
Success! (finally). The problem was the wrong eep, changing it to A5-38-08 helped, thank you!
But, it only works with USB-connection to the FAM14, there are as far as I can see significant differences in esp2 and esp3 as shown in the manual:
Hello @Nurwodah,
I just had a quick look but it seems that USB300 only supports ESP3.0 which has in this case a hardware dependency. Looks like there is a chip in the usb stick which decodes and encodes ESP3.0. That means you cannot translate it by using the usb stick as transceiver.
Personally, I would rather buy a compatible transceiver or look for a cable solution. Developing a translation, I would rate to be quite a big effort.
