Eltako "Baureihe 14 – RS485" (Enocean) Debugging

I have a Eltako setup running for al lot of years (using FHEM) but are switching to HA.
The FUD dimmers work fine when I use the Enocean-intergration but the FSR relays don’t.
I do use FSR12 but what I have found these should work with the same telegrams only there is no status feedback. So what I would like to test is to switch the left and right relay in one FSR12-12VDC.
The baseID for the USB300 is FF-8C-E8-80 and the relay is FF-8C-E8-82.
I tried various config’s but cannot get the USB300 to send an on or off signal to the relay.
Can somebody help me to setup the config?

Hallo @heubie,

I’m currently working on the hearing and cooling parts of the eltako integration.
I can try to make it compatible to 12-series but don’t have any device to test with.
By quickly looking at it, it should be already compatible to fsr14. For sending I use EEP a5-38-08 (gateway command) Could you please find out what EEP command are used by fsr14 and you could also send me the log lines from actor responses.
Have you entered a sensor into the eltako device which is also registered in the config like here: https://github.com/grimmpp/home-assistant-eltako/blob/d5d95b2738d275d69d62fb4c81627755160cde82/ha.yaml#L6
And you should use eep a5-38-08 for the light actor instead of m5-38-08. Both are supported in parallel.

Hope this helps.

@philipp14,

I would love to do the testing but as for now I don’t get the gateway to send anything. When I use FHEM and send a switch command both leds on the receiver and the connected FSR12 blink. The same counts for switching a light when using Enocean in HA. But I cannot get the USB300 to send anything.I need a basic config file with my baseID for the USB300 being FF-8C-E8-80 and a receiving relay on adress FF-8C-E8-82 so that I can test when I flip the switch in HA at least the led’s blink. From there I will use my rs485-converter and and a laptop to see what is send and if it works. But I need it to send “something” in the first place.
I hope this makes sens.

Regs

Hello dear friends of Eltako!
I just found this implementation and made it work (at least up to the detection of my binary sensors).

Now I have 2 things I need help with.

  1. F4HK14 (4x Floor-Heating Module)
    At the moment it is not implemented. To feed it with data, I expect you would need to simulate a temperature sensor which is also not yet implemented.
    Luckily I have everything set up for testing (I got a FTR65, which provides Real-Temp, Set-Temp and a Night-Switch) and is accepted by th F4HK14. Unfortunately I have no idea where to start to get that running and implemented, but I can test & debug as needed.
FTR65
EEP: A5-10-06
Byte 2 SET POINT (Linear 0...255)	- 0x76  = 18,5°C, Stepping: 0,16°C
Byte 3 TEMP 255...0  (0 bis +40°C)		- 0x85 = 19,15°C
  1. I have FSA12 and FSB12 behind a FGW14 (low priority). How do I address those? I know how addressing on BR14 works, but the BR12 do not fit in that scheme (do they have any address at all?).
    If they don’t have their address… how do I simulate just a press of a binary sensor?

Hello @heubie,

just to get it right. You have the Eltako integration installed in HA and you use USB300 as radio transmitter. Did you successfully install the Eltako integration and did the integration accept USB300? Can it receive and send signals/commands?

If you want to teach-in new virtual switches from HA I think this is next level. You need to take free addresses. Some people use “00 00 B0 00” as start and just count them up. Those addresses must be entered in the actors so that they will react on it. In 14-series you can do that with the software PCT14 quite easily. I know almost nothing about 12-series so I’m just guessing from now on. For me it looks like, in 12-series you need to trigger the sender to send a tech-in message. I think the easiest way is to use a library like eltako12bus to send raw data telegram having the teach-in bit set. This should also work for all the decentralized actors. There you should be able to find the commands.

I you want to use the mentioned lib checkout the command
./eltakotool.py --eltakobus /dev/ttyUSB0 send_raw -data b'...'

With ./eltakotool.py --eltakobus /dev/ttyUSB0 listen you can simple check what telegrams are sent. By the way what tool are you using right now?

Hello @jottt,

good timing!

I’m working on the integration of heating and cooling. Right now everything is in branch ‘heating-and-cooling’. If you are interested checkout the climate entity, I’ve started to develop: https://github.com/grimmpp/home-assistant-eltako/blob/9bf3f678971b19b991f1b075410e2dd59661c691/custom_components/eltako/climate.py
I’m at the end of the exploring phase of how the things work and I’m exploring on the device FAE14SSR but I assume the control logic of the actor is the same.

If you want to test it out, install the addon ssh-terminal and do the following

  1. git clone https://github.com/grimmpp/home-assistant-eltako
  2. `cd home-assistant-eltako
  3. git checkout heating-and-cooling or better git checkout 9bf3f67 which is the commit id of a good test state.
  4. ./install_custom_component_eltako.sh

The installation script will overwrite the existing custom component of eltako but the configuratio will be kept untouched. For configuring the heating see the following example. The sneder is representing a control panel.

climate:
    - id: "00-00-00-??" # device Id
      eep: "A5-10-06"
      sender:
        id: "??-??-??-??" # controller Id needs to be entered in function group 3 as target temp. controller
        eep: "A5-10-06"

In addition I’ve configured a temperature sensor in function group 1 and for cooling I send hardcoded messages via address ‘00-00-C1-09’ to set cooling mode for the actor. This ID has to be entered in function group 3 as heatpump function (137) if you want to use it.

The way how to control it in HA is not properly defined. Heating and cooling should actually be defined from outside by the heater control which is right now done by the control panel in HA for testing reasons.
So far everything works for me except that FAE14SSR is not detect the heat pump function via pyhsical switch (FTS14EM) that’s why there is the test of sending frequently a singal of a faked switch. The faked switch is working and I’m still trying out how the pyhsical one should work.

When testing the whole thing please keep in mind I’m still testing and things change often. Therefore I would recommend to use the commit id 9bf3f67 instead of the branch.
If there is any bigger progress I can let you know.

Regarding 2. (FSA12 and FSB12) for teaching things in - same what I wrote @heubie. To get the addresses my first idea would be to listen to the bus so that you get all commands listed and then trigger a switch so that you can see what is reacting to it. Hope this is not too much effort.

2 Likes

Hello all,

if you want to do me a favor could you please write docs/tutorial about your experiences and findings. I’ve started to prepare a few things in here: https://github.com/grimmpp/home-assistant-eltako/tree/main/tutorials.

This would help quite a lot because otherwise the new people need to go through all posts and collect all information and we need to repeat a lot.

Would be nice. Thanks a lot in advance!

1 Like

Yes it is installed and I use an USB300 as radio transmitter.
I have the Enocean integration working with 4 dimmers. I have a R485 to USB converter connected to the Eltako bus and can log the commands that are one the bus via a pc and serial monitor software.
My next step was to disable de Enocean int. and install the Eltako int. This works and I selected the USB300.
I added some lines to my configuration and switched on logging to test.

eltako
    light:
      - id: "FF-8C-E8-82"
        name: buitenlamp
        eep: "A5-38-08"
        sender:
            id: "FF-8C-E8-80"
            eep: "A5-38-08"
      - id: "FF-8C-E8-80"
        name: espresso
        eep: "A5-38-08"
        sender:
            id: "FF-8C-E8-82"
            eep: "A5-38-08"
2023-10-31 12:41:41.825 DEBUG (SyncWorker_0) [eltako] Send message: <Regular4BSMessage from ff 8c e8 80, data 02 64 00 09, status = 0x00> - Serialized: a55a6b0702640009ff8ce88000d4
2023-10-31 12:41:47.929 DEBUG (SyncWorker_9) [eltako] Send message: <Regular4BSMessage from ff 8c e8 80, data 02 00 00 08, status = 0x00> - Serialized: a55a6b0702000008ff8ce880006f
2023-10-31 12:42:05.146 DEBUG (SyncWorker_8) [eltako] Send message: <Regular4BSMessage from ff 8c e8 82, data 02 64 00 09, status = 0x00> - Serialized: a55a6b0702640009ff8ce88200d6
2023-10-31 12:42:12.294 DEBUG (SyncWorker_7) [eltako] Send message: <Regular4BSMessage from ff 8c e8 82, data 02 00 00 08, status = 0x00> - Serialized: a55a6b0702000008ff8ce8820071

But the thing is that this is not sent to the USB300 since I don’t see the led blink and there is nothing in the serial monitor logging on the pc.

Any idea on what I am doing wrong?

Regarding 1:
That reads extremely promising. I will start testing as soon as I can.
The FAE14SSR and the F4HK14 look pretty similar and they have the same settings and sensors, so this should work

Regarding 2:
I am not easily able to look inside the BR12 Bus as it sits behind the Gateway. My Setup is a BR14 System with a Gateway to BR12 and some older actors behind it (I got them cheap and it works flawless).
Not sure if thats neccessary anyway, as (at least for me) it would suffice to simulate a binary sensor (aka switch) on the BR14 Bus that gets replicated on the BR12-Bus just like the other physical Sensors.
BR12 is monodirectional. No answer.
The teach-in way might be the “proper” way.
The easy way would be to just imitate an already existing physical binary sensor. It does not really matter (for my use case at least), that the light reacts on a button press that actually came from HA and not the real wall switch.

For me this looks good. Just checked the data which looks correct too.

Maybe one thing if you read the messages from the serial bus with another software if could be that it never reaches the USB300 if the software behaves like a queue.

Except the missing ‘:’ after eltako and many too spaces in the configuration it looks good.

I switch on debug and I no programmer but I think something is going wrong.
Could you comment on this?

2023-11-01 12:25:52.187 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback EltakoGateway._initialize_bus_task.<locals>.bus_done(<Task cancell...serial.py:97>>) at /config/custom_components/eltako/gateway.py:73
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/asyncio/events.py", line 80, in _run
    self._context.run(self._callback, *self._args)
  File "/config/custom_components/eltako/gateway.py", line 75, in bus_done
    if bus_future.exception() != None:
       ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/eltakobus/serial.py", line 135, in run
    await self.await_bufferlevel(14)
  File "/usr/local/lib/python3.11/site-packages/eltakobus/serial.py", line 58, in await_bufferlevel
    await self._buffer_request
asyncio.exceptions.CancelledError: Final process shutdown


Hello @heubie,

yes, the serial interface crashed. In this case it takes the whole eltako integration down. There is unfortunately no auto-reconnect yet implemented.
The serial-bus is running in “parallel” and there is a handover implemented with a queue.

I wanted to check out where the problem really is but you have different code running than the latest main version. Did you install this repo: GitHub - grimmpp/home-assistant-eltako: Integration for Eltako 14 series in Home Assistant

I thought I had the code installed, but you made me doubt. I reinstalled but still no joy…

Is there anything which I can do or check to debug the problem with the serial interface?

Hello @heubie,

I don’t know very thing in detail but here is the thing: Eltako is using RS485 bus standard and therefore exists an serial library which is used in the Eltako integration.
It looks that USB300 is using a simple UART protocol and the enocean integration uses kipe/enocean library.

In branch heating-and-cooling I put some more helping things and prepared among other things that gateways could be defined in the config. So far I can distinguish between Eltako FAM14 and Eltako FGW14-USB which makes no difference for the serial lib but for the command you can send. With FAM14 you can e.g. completely program all actors or read the full-memory.
With branch heating-and-cooling you can optionally specify the gateway like this:

eltako:
  gateway:
    device: fam14   # In the code I've already prepared to define USB300 with 'enocean-usb300'

Here you can see some details:

I can add the other enocean library optionally but I don’t have an USB300 to test with. If a USB300 is falling into my lap I’ll do it. :slight_smile:

OK, because it looked so easy I just added it.

If I put the following into the config it uses the enocean lib instead of RS485.

eltako:
  gateway:
    device: enocean-usb300
...

It starts then the other serial interface:
2023-11-08 23:45:15.400 INFO (Thread-5) [enocean.communicators.SerialCommunicator] SerialCommunicator started

Obviously, it does not work for me because I only do have FAM14 and FGW14-USB and it almost directly stops.

What you need to do for testing is:

  1. Install Eltako Integration normally via HACS
  2. Add gateway section with USB300 like above into the Eltako config
  3. Checkout the heating-and-cooling branch like described in earlier post and use the branch name heating-and-cooling
  4. if you run ./install_custom_component_eltako.sh it will automatically restart HA otherwise you need to do it manually.

Let’s see what is does :rocket: :crossed_fingers:

Sorry it took me some time but I tested it. I cannot find any errors during the startupfase but when I try to switch on the light this error comes up:

2023-11-11 18:31:00.406 ERROR (SyncWorker_0) [enocean.communicators.SerialCommunicator] Object to send must be an instance of Packet

Oh :face_with_open_eyes_and_hand_over_mouth:, sitll sending the eltako command. They differ. I’ll try to fix it.

There are now two functions converting the eltako messages back and forth to enocean messages.
Hope that does the job. It’s untested!!!

This is the difference in the messages I could find.

Just tested the code but this error comes up.

2023-11-13 08:40:10.740 ERROR (SyncWorker_7) [eltako] Cannot convert eltako message <Regular4BSMessage from ff 8c e8 80, data 02 64 00 09, status = 0x00> into EnOcean message: PARSE_RESULT = '1'

But when I send first an “ON” and direct after that an “OFF” to the same FSR12 relay via my old FHEM installation these messages pop up. So the USB300 works. the problem is in the conversion.

2023-11-13 08:53:02.342 DEBUG (Thread-5) [eltako] Received radio packet: FF:8C:E8:82->FF:FF:FF:FF (-54 dBm): 0x01 ['0xf6', '0x10', '0xff', '0x8c', '0xe8', '0x82', '0x30'] ['0x0', '0xff', '0xff', '0xff', '0xff', '0x36', '0x0'] OrderedDict()
2023-11-13 08:53:02.345 ERROR (Thread-5) [eltako] Cannot convert EnOcean package to Eltako message!
Traceback (most recent call last):
  File "/config/custom_components/eltako/gateway.py", line 42, in convert_EnOceanPacket_to_EltakoMessage
    return ESP2Message.parse(eltako_data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/eltakobus/message.py", line 54, in parse
    raise ParseError("Invalid message length")
eltakobus.error.ParseError: Invalid message length
2023-11-13 08:53:09.500 DEBUG (Thread-5) [eltako] Received radio packet: FF:8C:E8:82->FF:FF:FF:FF (-52 dBm): 0x01 ['0xf6', '0x30', '0xff', '0x8c', '0xe8', '0x82', '0x30'] ['0x0', '0xff', '0xff', '0xff', '0xff', '0x34', '0x0'] OrderedDict()
2023-11-13 08:53:09.501 ERROR (Thread-5) [eltako] Cannot convert EnOcean package to Eltako message!
Traceback (most recent call last):
  File "/config/custom_components/eltako/gateway.py", line 42, in convert_EnOceanPacket_to_EltakoMessage
    return ESP2Message.parse(eltako_data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^