Now it is available in release v1.3.6. What I realized is that HACS will always download the latest version independent of what I’ve selected.
I only use HACS for testing purposes. Usually I install the different versions like this:
First of all, thank you very much for your quick reaction and willingness to help.
this time the update worked as expected.
the manifest now points at
"requirements": ["eltako14bus==0.0.45","enocean==0.60.1", "StrEnum"],
But looks like we introduced a new bug:
2024-02-02 13:03:10.520 ERROR (MainThread) [homeassistant.components.light] Error while setting up eltako platform for light
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 360, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/eltako/light.py", line 36, in async_setup_entry
gateway: EnOceanGateway = get_gateway_from_hass(hass, config_entry)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/eltako/eltako_integration_init.py", line 29, in get_gateway_from_hass
return hass.data[DATA_ELTAKO][config_entry.data[CONF_GATEWAY_DESCRIPTION]]
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'EnOcean ESP2 Gateway - fgw14usb (Id: 1, BaseId: FF-AA-80-00)'
2024-02-02 13:03:10.522 ERROR (MainThread) [homeassistant.components.binary_sensor] Error while setting up eltako platform for binary_sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 360, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/eltako/binary_sensor.py", line 29, in async_setup_entry
gateway: EnOceanGateway = get_gateway_from_hass(hass, config_entry)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/eltako/eltako_integration_init.py", line 29, in get_gateway_from_hass
return hass.data[DATA_ELTAKO][config_entry.data[CONF_GATEWAY_DESCRIPTION]]
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'EnOcean ESP2 Gateway - fgw14usb (Id: 1, BaseId: FF-AA-80-00)'
2024-02-02 13:03:10.524 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up eltako platform for sensor
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 360, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/eltako/sensor.py", line 279, in async_setup_entry
gateway: EnOceanGateway = get_gateway_from_hass(hass, config_entry)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/eltako/eltako_integration_init.py", line 29, in get_gateway_from_hass
return hass.data[DATA_ELTAKO][config_entry.data[CONF_GATEWAY_DESCRIPTION]]
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'EnOcean ESP2 Gateway - fgw14usb (Id: 1, BaseId: FF-AA-80-00)'
2024-02-02 13:03:10.527 ERROR (MainThread) [homeassistant.components.cover] Error while setting up eltako platform for cover
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 360, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/eltako/cover.py", line 31, in async_setup_entry
gateway: EnOceanGateway = get_gateway_from_hass(hass, config_entry)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/eltako/eltako_integration_init.py", line 29, in get_gateway_from_hass
return hass.data[DATA_ELTAKO][config_entry.data[CONF_GATEWAY_DESCRIPTION]]
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'EnOcean ESP2 Gateway - fgw14usb (Id: 1, BaseId: FF-AA-80-00)'
2024-02-02 13:03:10.530 ERROR (MainThread) [homeassistant.components.climate] Error while setting up eltako platform for climate
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 360, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/eltako/climate.py", line 38, in async_setup_entry
gateway: EnOceanGateway = get_gateway_from_hass(hass, config_entry)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/eltako/eltako_integration_init.py", line 29, in get_gateway_from_hass
return hass.data[DATA_ELTAKO][config_entry.data[CONF_GATEWAY_DESCRIPTION]]
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'EnOcean ESP2 Gateway - fgw14usb (Id: 1, BaseId: FF-AA-80-00)'
2024-02-02 13:03:10.532 ERROR (MainThread) [homeassistant.components.button] Error while setting up eltako platform for button
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 360, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/eltako/button.py", line 36, in async_setup_entry
gateway: EnOceanGateway = get_gateway_from_hass(hass, config_entry)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/eltako/eltako_integration_init.py", line 29, in get_gateway_from_hass
return hass.data[DATA_ELTAKO][config_entry.data[CONF_GATEWAY_DESCRIPTION]]
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'EnOcean ESP2 Gateway - fgw14usb (Id: 1, BaseId: FF-AA-80-00)'
this makes all my lights unavailable. 
BR
Tom
Hallo Tom,
unfortunately this is an incompatibility of your settings to the latest versions and HA doesn’t allow to fix this automatically. It has something to with the creation of the gateway in the form. It doesn’t allow to pass properly configuration data.
This should be solved by removing and adding the gateway/hubs again.
====
Update: I actually never wanted to add compensation code but I thing makes not sense without it. Now the version 1.3.6 is able to deal with both old and new gateway descriptions.
thank you very much. this fixes it. switching groups >11 lights also works now. 
I’m trying to get some kind of a automatic-migration prepared. It’s really a pity that I can only work with displayed values and no Ids in the background.
I am thrilled to see progress for FAM14 and USB300, looking forward to replace my modified onIon-energy/home-assistant-eltako that supports USB300 with yours @philipp14
Well it works to read temperature, control my lights and covers, but it is to be honest kinda “hacky” and a bit limited 
serialized = b"\×55\x00" + self.body
header_checksum = serialized 11:41
data = b"\×55\×00" + self.body return data + crc8(data[1:]).digest()
class RPSMessage(ESP2Message):
"""An incoming or outgoing RPS (1 byte, switch) telegram"""
org = 0xF6 # org = 0x05, rorg = 0xF6
package_type = 0x01 # Radio_ERP_1
telegram_count = 0x02 # Sub-Telegram Count
header_checksum = 0x7A
destination = b'\xff\xff\xff\xff\xff' # Not Specified
data_4b = b'\n\x06'
Hello @alq.cev,
mine isn’t even on this level. 
I’ve added ESP3 protocol (USB300) as experimental but haven’t managed to convert from ESP3 to ESP2 which means I’m not able to send out message to e.g. switch on light.
Receiving messages (conversion from ESP3 to ESP2) works well.
Sending message (conversion from ESP2 to ESP3) is not working:
When it works, I then would like to put it actually in the communication lib (eltakobus) so that I can use it in my other tools like enocean device manager as well.
Do you have a code snipped which can convert ESP2 telegram to ESP3 telegram?
I replaced the ESP2 code to work with ESP3 therefore i have no real conversion, but i may help to explain how i did it.
As ESP3 requires a CRC8 header checksum as well as a checksum for the header and data combined i used crc8/crc8.py at master · niccokunzmann/crc8 (github.com) to generate the CRC8 checksums.
Using this example ESP3 4BS Message:
55 00 0A 06 01 FE A5 01 00 00 08 FF 82 3E 70 00 03 FF FF FF FF FF C0
55 = Starting with the Sync Byte
00 0A = Data Length
06 = Optional Length
01 = Packet type eg. RADIO_ERP1
FE = CRC8 Header Checksum generated by using the data from data length to packet type eg. 00 0A 06 01
a5 = radio telegram RORG eg. 4BS = 0xA5
01 00 00 08 = 0x01, 0x00, 0x00, 0x08 (Switching output OFF, not blocked) EEP A5-38-08
FF 82 3E 70 = the sender
00 = status?
03 = sub telegram count, 03 for send with radio erp1 4bs?
FF FF FF FF = destination id, sending FF FF FF FF is required without a fixed destination if i remember correctly
FF = dBm i guess when sending always FF
C0 = final checksum generated from data and optional data and header eg. 00 0A 06 01 FE A5 01 00 00 08 FF 82 3E 70 00 03 FF FF FF FF FF
The ESP3Message that i am generating looks like this this:
class ESP2Message:
def serialize(self):
serialized = b"\x55\x00" + self.body
data = b"\x55\x00" + self.body
return data + crc8(data[1:]).digest()
class _4BSMessage(ESP2Message):
org = 0xA5
package_type = 0x01 # Radio_ERP_1
telegram_count = 0x03 # Sub-Telegram Count
header_checksum = 0xFE # In this case always the same as length does not vary
def __init__(self, address, status, data, outgoing=False):
self.address = address
self.status = status
self.data = data
self.outgoing = outgoing
h_seq = property(lambda self: 3 if self.outgoing else 0)
body = property(lambda self: bytes((0x0A, 0x06, self.package_type, self.header_checksum, self.org, *self.data, *self.address, self.status, self.telegram_count, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF)))
class RPSMessage(ESP2Message):
"""An incoming or outgoing RPS (1 byte, switch) telegram"""
org = 0xF6 # org = 0x05, rorg = 0xF6
package_type = 0x01 # Radio_ERP_1
telegram_count = 0x02 # Sub-Telegram Count
header_checksum = 0x7A
def __init__(self, address, status, data, outgoing=False):
self.address = address
self.status = status
self.data = data
self.outgoing = outgoing
h_seq = property(lambda self: 3 if self.outgoing else 0)
# 55 00 07 07 01 7A F6 70 FF B9 FC 8D 30 02 FF FF FF FF 44 00 F8
body = property(lambda self: bytes(0x07, 0x07, self.package_type, self.header_checksum, self.org, *self.data, *self.address, self.status, self.telegram_count, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF))
I guess most of this is already known to you, but maybe it will help - took me a while, is kinda hacky but works for me.
1 Like
@philipp14 , thanks for your feedback and explanaiton. Somehow the status of my device is not changing in HA if i use the wall switches. Have I made a bad mistake with the IDs?
Here a example of my yaml and PCT14:
# always starts with 'eltako'
eltako:
# optional section 'general_settings'
general_settings:
fast_status_change: False # True: Changes status in HA immediately without waiting for actuator response. Default: False
# section 'gateway'
# Currently only devices based on ESP2 protocol are supported. In future ESP3 protocol shall be extended.
#
gateway:
- id: 1
device_type: fam14 # Supported gateways: fam14, fgw14usb
base_id: FF-AA-80-00
devices:
light:
- id: 00-00-00-09
eep: A5-38-08
name: Schlafzimmer Licht
sender:
id: 00-00-B0-09
eep: A5-38-08
- id: 00-00-00-10
eep: A5-38-08
name: Kinderzimmer Licht
sender:
id: 00-00-B0-0A
eep: A5-38-08
- id: 00-00-00-11
eep: A5-38-08
name: Wohnzimmer Licht
sender:
id: 00-00-B0-0B
eep: A5-38-08
In PCT14 the address are in decimal and in the config we need it hexadecimal. This means 00-00-00-10 needs to be 00-00-00-0A and so on. Light with adr 9 should work.
Sorry, i‘m a tittle bit confused.
- in PCT14, in the line where I defined function 32 the address has to be in DEZ?
-in YAML: the ID is in DEZ and the sender ID is in HEX?
For example
Kinderzimmer Licht
PCT14: 00-00-00-10
YAML:
-ID: 00-00-00-10
-Sender ID: 00-00-00-0A
is this right? When do we use the additional B0? For example in address 9 I used it. But I don’t know when we need it.
Blockquote
I’ve meant the values in the right treeview.
should look then like:
light:
- id: 00-00-00-09
eep: A5-38-08
name: Schlafzimmer Licht
sender:
id: 00-00-B0-09
eep: A5-38-08
- id: 00-00-00-0A
eep: A5-38-08
name: Kinderzimmer Licht
sender:
id: 00-00-B0-0A
eep: A5-38-08
- id: 00-00-00-0B
eep: A5-38-08
name: Wohnzimmer Licht
sender:
id: 00-00-B0-0B
eep: A5-38-08
1 Like
Thank you!!! Now i got it. Will try this tomorrow.
@philipp14 i hope my explanation was any helpful? I hadn’t had the time to look into your code in detail, and just simply generated a sample send request, and as far as it seems it is a wrong order and missing the CRC checksums for ESP3
Yes, thank a lot for it. I need to pause the ESP3 topic a bit. I have beside my regular job two other bigger projects running and regarding Eltako automation I’m focusing at the moment on the enocean device manager at the moment to get it stable.
1 Like
Some times when I toggle an FSR14 or an FSB14 its not responding. In case of FSB14 the switch will go back to off and I can see it didn’t worked. But for FSR14 when I press the close button the state switches to closing but the shutter stays open. Any idea how to get this fixed?
Sorry, I didn’t get it really. Can you explain a bit more in detail which real switches and buttons you push where.
Lights in HA go almost immediately back to off when they don’t receive an status-update telegram from FSR.
Please, check your logs if those status-update telegrams are missing.
If that symptom only happening to single devices or is it the same for all?
hi philipp!
i am sorry to bother with - what i consider - a rather stupid question.
so, over here home-assistant-eltako/docs/gateways at main · grimmpp/home-assistant-eltako · GitHub you wrote that:
Use FAM-USB for operations with Home Assistant. FAM-USB is a must for decentralized actuators. If your setup only have actuators mounted on the RS485 bus FGW14-USB is a good choice.
my setup currently holds one FAM14, one FGW14-USB and one FTD14.
do i understand it correct that there is no way to use decentralized actors (e.g. FT55-RW, FSVA-230V, …) with just an FGW14-USB or FAM14?
a bit of background why i am asking a question like this:
i am one of the guys moving from FHEM to HA. In FHEM it was pretty easy to get decentralized actors working with just one connection to the FGW14-USB. now, i do understand your integration is different from the one in FHEM and i really do not want to bother you in a “why does work here and there” kind of approach. i am just plain curious if i get this right, if i have to extend my shopping list, if this is a technical/design restriction or maybe just a matter of time/progress.
BR
Tom
Hello,
today I added three FTKE window switches with the EEP F6-10-00. The registered successfully, but they are shown as always closed, even if in open state. Does anybody else have the same problem?
Hallo Tom,
I’m by far not an expert in this matter. Just started about 1 year ago where I bought my first Eltako devices. At this time I wanted to evaluate if serie 14 fits for me and if it can be made compatible to HA. I own now quite a lot of device but almost nothing is for me really in production so far.
One important use case I wanted to be covered was the heating and cooling story where I want to have wall-mounted thermostats (temp. and humidity sensors + temp. controller) and HA working in conjunction. For me it is important that the wall-mounted thermostat and HA is synchronized. I managed to implement HA in a way so that both show the latest target temperature doesn’t matter where you define it.
When I started developing it I had FAM14 + FGW14-USB + FAE14SSR + FUTH… . HA was connected via FGW14-USB and wireless telegram were sent and received via FAM14. In this scenario I realized that I was not able to send command-telegrams from HA via FGW14-USB via FAM14 into wireless network to FUTH. Later I found out for my self that FAM14 only sends status telegrams into wireless network. (Maybe, it can be configured to do so but I’m not aware of it.) In that time someone wanted to have support for FAM-USB anyway and I got one mini-safe for reengineering how the telegrams, communication process and everything works. That’s why I went on with FAM-USB. (That’s my current state of knowledge)
In the end it is important to get the commands you send with HA out into the wireless network so that the decentralized devices can receive them. I was not aware of FTD14. When I understand the docs correctly it should work with it. It sounds for me that FTD14 has its own base_id, what you might need to consider when defining the HA configuration. (The same applies when using e.g. FAM-USB, USB300, … any wireless transceiver.)
Please, let me know what is working for you then I will extend the docs and make it more clearer.
1 Like