Eltako "Baureihe 14 – RS485" (Enocean) Debugging

Hello @vinnovic,

With the new release1.3.7 I messed up the states of the covers. I tried to revert that which is now available on main. (Don’t want to publish to many broken versions and it would be nice if you could test main.)

Regarding the icons of lights. My guess is: By introducing the recovery state (HA remembers the latest state of an actor and shows it after e.g. a restart.) some things start in unknown state and my interpretation of those two symbols in the same row is on and off (=unknown) at the same time. Before unknown was displayed as off.

When you once got a slidebar does it disappear again?

Hi Philip,

You were right with the icons of the lights. the slidebar does not disappear anymore even after a hard reset.

I will try to install the main version as soon as I can and report back.

1 Like

Ok strange. I’m using the HACS Version V1.3.7

Hey, let me check - sorry for the late reply.

I will let you know soon.

I’ve already put my changes on main branch of both eo_man and integration.
Sending seems to work but my e.g. FSR14 is not reacting on A5-38-08 gateway command. F6-02-01 is e.g. working.

Okay, i just enabled my debug output to show you what i am sending as gateway 4BS command:

<Regular4BSMessage> - Serialized: 55 00 0a 06 01 fe a5 01 00 00 08 ff 82 3e 26 00 03 ff ff ff ff ff 41
<Regular4BSMessage> - Serialized: 55 00 0a 06 01 fe a5 01 00 00 09 ff 82 3e 26 00 03 ff ff ff ff ff 1c
<Regular4BSMessage> - Serialized: 55 00 0a 06 01 fe a5 01 00 00 08 ff 82 3e 26 00 03 ff ff ff ff ff 41

The example shows turning a light off, on, off

In your image the end contains 0x01 after the CRC8 hash which might be the problem?

I’ve tested everything else, your CRC8 and the rest seems fine, the only thing is the 0x01 after the CRC8 which is not the same compared to my generated 4BS message.

Sorry, I don’t see what you mean. Ok, I found it now in the old pic. I think that already changed. For me it looks right now like this:

Converted esp2 (<Regular4BSMessage from ff d6 30 01, data 01 00 00 09, status = 0x00> - 
A5-5A-6B-07-01-00-00-09-FF-D6-30-01-00-82) message to 
esp3 (0x01 ['0xa5', '0x1', '0x0', '0x0', '0x9', '0xff', '0xd6', '0x30', '0x1', '0x0'] ['0x3', '0xff', '0xff', '0xff', '0xff', '0xff'] OrderedDict() - 
55-00-0A-06-01-FE-A5-01-00-00-09-FF-D6-30-01-00-03-FF-FF-FF-FF-FF-A8)

The ESP2 is working and ESP3 not.

Okay, weird.

For reference my PCT14 configuration:

YAML Configuration:

    - id: "00-00-3E-26"
      eep: "M5-38-08"
      sender:
        id: "FF-82-3E-26"
        eep: "A5-38-08"
      name: "Abstellkammer"

Do not mind the yaml difference, as i am using the old plugin.

However i do use different id’s for each controller channel and i had issues with to high id’s - that caused the 4BS message not to work.

e.g. would not work:

    - id: "00-00-3E-90"
      eep: "G5-3F-7F"
      sender:
        id: "FF-82-3E-90"
        eep: "H5-3F-7F"
      time_closes: 25
      time_opens: 26
      device_class: shutter
      name: "Wohnzimmer-Fenster (R)"

while is working:

- id: "00-00-3E-66"
      eep: "G5-3F-7F"
      sender:
        id: "FF-82-3E-66"
        eep: "H5-3F-7F"
      time_closes: 25
      time_opens: 26
      device_class: shutter
      name: "Wohnzimmer-Fenster (R)"
<Regular4BSMessage> - Serialized: 55 00 0a 06 01 fe a5 01 00 00 08 ff 82 3e 26 00 03 ff ff ff ff ff 41
<Regular4BSMessage> - Serialized: 55 00 0a 06 01 fe a5 01 00 00 09 ff 82 3e 26 00 03 ff ff ff ff ff 1c
<Regular4BSMessage> - Serialized: 55 00 0a 06 01 fe a5 01 00 00 08 ff 82 3e 26 00 03 ff ff ff ff ff 41

I know why the high sender ids don’t work. Your stick has a base id probably FF-82-3E-00 and the range of allowed address is base id + (0-128). In your case from FF-82-3E-00 - FF-82-3E-7F. This is hardcoded in your tranceiver chip although you are allowed to change it a few time.

1 Like

I’ve tested with oe_man if I’m able to send and receive a message by sending with USB300 and receiving by FAM-USB. This situation is works.

1 Like

Will look into the problem this weekend, will let you know if i find something.

I’ve added support for F6-02-01 as EEP for light sender (HA). If I use ‘direct pushbutton top on’ and ‘left rocker’ in PCT14 I can switch the light on and off by using USB300.
Current state is pushed to main branch.

Hello @alq.cev,

after resetting my messy configuration of the actuators it is working now :slight_smile:.

I will prepare a proper release with USB300 support!

1 Like

Perfect :smiley:

Love it, to be honest i was not able to find any other issues. I hope i was still able to assist/help :slight_smile:

(Following now on GitHub)

@philipp14 is the library capable of setting the temperature from home assistant and updating it using an eep?

I have a tado thermostat and would like to read the temperature (which is possible using homekit) and update the temperature using an eep, currently my modified integration does not support setting values using an automation

does your library allow this? otherwise i might look into it and add such a feature for specific eeps like A5-10-06

i thought of a fake sensor as well, the current temp and the target temp can be changed from homeassistant (i read something about your experimental climate sender)

Hello @alq.cev,

I’ve implemented that for eltako thermostats.
Check this out: home-assistant-eltako/docs/heating-and-cooling at feature-branch · grimmpp/home-assistant-eltako · GitHub
Maybe it is close.

I did not exactly understand what you want to control? But that’s a good idea to bring more possibilities into what I’ve started. The climate entity can already send A5-10-06 telegrams for target temperature. If tado works with enocean this should work.

What I really like about Eltako at this point is that you can sync both HA and wall-mounted thermostat. This is often not possible with other Smart Home systems.

In general I could create an Home Assistant event for every incoming and out-going telegram then you would be able to react on everything in the automation section. Send arbitrary telegram would be also a nice thing. I’ve added that lately in eo_man. You can use it for testing.

1 Like

Tado itself does not work with enocean, it does not even use the enocean frequency, it uses wifi.

My goal is to use the tado thermostat to control my floor heating, my flat has FTR55 thermostats which can’t be controlled using an app, as the circular slider need to be set manually.

Therefore i am am looking forward to replace my current eltako thermostats with the tado ones, which can be controlled manually or through the homekit app and home assistant.

The workflow i am going for:

  1. The tado thermostat temperature has been changed either through the app or manually
  2. Tado sends the values to home assistant (works already)
  3. create an automation that sets the value of a fake thermostat with an eep of A5-10-06 using the values from the tado

The reason to not use eltako thermostats with a screen (FUTH55ED) is simply because i have no electric wiring where the thermostats are located.

ftr55esb-wg

OK, understand. Then you also need no representation of the any new device. In this case I would just add the function to send an arbitrary enocean message by using HA automation. I think that could be useful for many other use cases.

I was thinking to use events then you could specify parameters like eep, sender id, data, … At least we would need to keep data changeable / not hardcoded. Do you know if you can detect the target temperature and pass it as variable into the triggered event to be sent?

By the way USB300 support is release: Release Version 1.4.0 ESP3 Support (USB300) · grimmpp/home-assistant-eltako · GitHub

ESP3 adapter is outsoruced to: GitHub - grimmpp/esp2_gateway_adapter: enocean gateway adapter from ESP3 to ESP2 for eltako home assistant integration

1 Like