Eltako F4SR14-LED working, but without feedback if I use the physical wall switch

[benediktarnold]

Hi!
I'm currently migrating my home automation from openhab to home assistant. The USB300 is already paired with most of my devices so I'd like to migrate them first.
I followed the suggestions about FAM14 devices as in #16 (comment)

My configuration looks like this: (virtual is currently commented out, but I tried every possible combination)
The only difference to the guide is that I'm using EEP A5-38-08 (Central Command Switch) to control the light through FAM14.

[light/og_arbeiten]
address 		= 0xFFE3582B
rorg    		= 0xA5
func    		= 0x38
type    		= 0x08
sender  		= 0xFFD9DF98
#virtual 		= 1

[light_state/og_arbeiten]
rorg            = 0xF6
func            = 0x02
type            = 0x01
address         = 0xFFE3582B
#virtual         = 1

Turning the light on and off from homeassistant works using EEP A5-38-08

The problem is the feedback from the device to homeassistant if I use a physical wall switch to control the light.

The RPS (F6) telegram is received, but it's not emitted to mqtt. The log message learn request not emitted to mqtt is a bit weird, since RPS telegrams don't even have a learn bit. EEP Guide Page 14

2023-10-12 21:10:34,596 INFO: received: FF:E3:58:2B->FF:FF:FF:FF (-94 dBm): 0x01 ['0xf6', '0x70', '0xff', '0xe3', '0x58', '0x2b', '0x30'] ['0x0', '0xff', '0xff', '0xff', '0xff', '0x5e', '0x0'] OrderedDict()
2023-10-12 21:10:34,597 INFO: learn request not emitted to mqtt

Does anyone have an idea what's wrong with my configuration or is it even a bug?

Thanks and regards,

Ben

[mak-gitdev]

Hi @benediktarnold,

As said in other discussions, Eltako devices are not well supported at the moment.
With the current version, you are not able to define multiple EEP per device address as you need to do for your FSR14.
The good news is that I am currently working on it, see this for more details.

I know RPS telegrams don't have learn bit and this is correctly handled by enoceanmqtt.
Without going deep into details, as the current version doesn't support multiple EEP per address, that's why you ended up with messages regarding the learn request not emitted to mqtt.

While figuring out why you got such message, I may have found a hacky way to get the feedback from your FSR14 with the current version.
In your device file, simply declare your F6 EEP before the A5 EEP like this:

[light_state/og_arbeiten]
address         = 0xFFE3582B
rorg            = 0xF6
func            = 0x02
type            = 0x01

[light/og_arbeiten]
address 		= 0xFFE3582B
rorg    		= 0xA5
func    		= 0x38
type    		= 0x08
sender  		= 0xFFD9DF98

Note that you don't need virtual at all as you are not creating virtual devices.

Your device name might change.
Could you please share a screenshot of your device page before and after the modification I suggest ?

If everything is okay, you will then have to write a template switch to bind the feedback and the state of the switch.

A better support for Eltako devices is coming as aforementioned and I may need your help for some tests if you like.

[benediktarnold]

Thanks!
Switching the order of entries in the file helped! Now I get the feedback from the physical wall switch.

I missed to take a screenshot before I made the change, but here it is afterwards:

Before the change, all entities had light_state as part of the name, now they all have just light as part of the name. So it looks like that the second entry in the devices file defines the name of all entities for the same address.

I have lots of eltako devices at home and am happy to help testing the new feature!

[fabi9163]

Hi together,
also got a FAM14 with multiple F4SR14 with and without "-LED" for shutter+lights and trying to connect them to HA.
Warning: I'm new to HA...

I thought I have to manually "lern" the virtual address from my usb300 + offset to the F4SR14 in eltako software so that it switches the channel configured for this ID.
This method shown in your examples in combination with the provided template seems to work.

Question: Where is the difference in your last example here? Or why is it better?

I could also test something if necessary,
thanks and go on!

[mak-gitdev]

Hi @fabi9163,

The difference is that in the example, we emulate a rocker switch to control the Eltako device.
Here, we control directly the Eltako device.

[fabi9163]

Hi @fabi9163,

The difference is that in the example, we emulate a rocker switch to control the Eltako device. Here, we control directly the Eltako device.

Ok, I thought the example here seems to avoid manual "learning" every virtual-address from usb300 via Software cause it looks like we can directly call the target-actor by its address instead of manually learning in the virtual-address on eltako-side.

But my attempt without feedback (only try to switch to avoid duplicated EEPs which you told are not supported) already failed. The example translated to above would be:

[light/og_arbeiten]
address = 0xFFE3582B (<-address of eltako-aktor "relay-address" of other example)
rorg = 0xA5
func = 0x38
type = 0x08
sender = 0xFFD9DF98 (<-my usb300 virtual address.)

How does the actor know which channel it should switch? I think there is also a pairing necessary, right?

@mak-gitdev Looking forward to see your new edition and also the fsr14 for shutters. Great that there are people like you!

[mak-gitdev]

@fabi9163

I thought the example here seems to avoid manual "learning" every virtual-address from usb300 via Software cause it looks like we can directly call the target-actor by its address instead of manually learning in the virtual-address on eltako-side.

No, pairing is always mandatory.
@benediktarnold had already is USB300 paired to his Eltako devices (First message, first line).

How does the actor know which channel it should switch?

It seems that for FSR14-Nx, each channel has its own address.

I would recommend not to try the method explained but to keep using virtual switches for the moment until I release support for Eltako devices.
I will let you know once I need your help for testing 👍 😉