Eltako "Baureihe 14 – RS485" (Enocean) Debugging

@philipp14 , appologies for bugging again, but I have a few more questions:

  • Does the base_id of the gateway matter? I think I read somewhere in your documentation it’s not really that important but if not, then what’s the point of it? I’m asking because of my next point:
  • I have added my lights as ‘lights’ in the eltako configuration.yml. After restarting ha core, I see them show up. I put my FSR4x into learning mode, and when I click the buttons in HA, I see traffic on the bus, but my FSR is still blinking and doesn’t exit the learning mode like it would for a physical wall switch.
  • In an attempt to blindly try something else I renamed light into switch and the integration broke stating that the mandatory light was missing. Can you clarify when one would use light and when one would use switch? Afterall, you can attach anything to an FSR, though the most probable one being a light (especially the FSR14-4x).
  • Finally, I’m not sure how to go about the “invented” ids in the configuration.yml. How would HA know whether or not a light is turned on after a wall switch was pressed? It needs to know the id of the real FSR14 channel to be able and tell whether a certain circuit is active or not?

Can someone share an up-to-date configuration.yml with some documentation?
My current setup I’m trying to get to work in HA is very simple:

  • F4T55E wireless wall switch (4 button switch)
  • 1 FSR14-4x
    => 1 button for each channel of the FSR.

Should be up and running in no time… :slight_smile:

Hello @cvvvlb,

sorry only have little time for a short answer. I try to put the longer one into a docs section.

  1. Base_id was first part of the identifier of entities now it is only the gateway id and the device id in combination. base_id is only used to check missconfiguration. In this case I’ll get a warning printed in the logs.
  2. Light sender does not use same EEps like wall-mounted switches (F6-02-01/02). It used the software commands. I use PCT14 for programming all the actuators. You can also use Device Discovery is can also program the HA switch ids into them.
  3. switch is a generalization of lights representing any arbitrary actuator. It sends F6-02-01 commands like wall-mounted switches to the actuator.
  4. When a entity is created in HA e.g. like a switch or sensor it listens to telegrams belonging to the defined gateway id, device id, and eep in the HA configuration. If that matches it updates a state. Eltako actuators and sensors either send frequently e.g. each 5min or in case of status change a telegram about their status. The same happens when you push a wall-mounted switch button then the light in HA actually reacts on the status update telegram of the actuator, does not know anything about the switch itself.
  5. This configuration example is check by unit tests and should always be up to date.

Can you send us the error logs you are receiving?

1 Like

Thanks @philipp14 . I’ve been reading and re-reading posts in this thread, the docs, and it still is very confusing to me.

I’m 100% sure the bus connection through the FGW14-USB is working well, because I can see messages in the logs when I press my wall switches:

2024-01-03 00:53:22.024 DEBUG (MainThread) [eltako] [Gateway] [Id: 1] Received message: <ESP2Message '0b 07 00 00 00 0f 00 00 19 01 00'>
2024-01-03 00:53:22.343 DEBUG (MainThread) [eltako] [Gateway] [Id: 1] Received message: <ESP2Message '8b 05 50 00 00 00 00 00 00 08 30'>
2024-01-03 00:53:23.956 DEBUG (MainThread) [eltako] [Gateway] [Id: 1] Received message: <ESP2Message '0b 05 30 00 00 00 fe df f5 a8 30'>
2024-01-03 00:53:23.965 DEBUG (SyncWorker_3) [eltako] [Binary Sensor] Send event: eltako.gw_1.btn_pressed.sid_FE-DF-F5-A8, pressed_buttons: '["LT"]'
2024-01-03 00:53:23.971 DEBUG (SyncWorker_3) [eltako] [Binary Sensor] Send event: eltako.gw_1.btn_pressed.sid_FE-DF-F5-A8.d_LT, pressed_buttons: '["LT"]'

This is also confirmed if I use ID detection in PCT14:
Screenshot 2024-01-03 002649

And you can see in PCT14 that the channels of my FSR14s are taught-in for that one 4-button wall switch:

The above log message mentions I pressed the top left button, which is the one to turn on or off the lanterns on my second FSR, channel 1.

But now I’m really not clear what to do with the ID of the wall switch in HA. I read this which seems to be a “workaround” (?) to listen for events from the wall switch, to then trigger an action to “turn on the light”. But that would not work if HA is down during the time the wall switch was pushed.

I understood originally that in the config, we define our lights (or FSR14 channels here) in our configuration.yml file, using just dummy ids:

eltako:
  general_settings:
    fast_status_change: False # True: Changes status in HA immediately without waiting for actuator response. Default: False
    show_dev_id_in_dev_name: True
  gateway:
    - id: 1
      device_type: fgw14usb 
      base_id: FF-AA-80-00
      devices:
        light:
          - id: 00-00-00-03
            eep: M5-38-08
            name: Lanterns Garden
            sender:
              id: 00-00-B0-03
              eep: A5-38-08

But here it’s not clear to me how exactly these self-invented ids would get linked with the FSR14 channels to READ the current status. I assumed that when I teach-in my FSR14 for channel 1, and I then press my “Lanterns Garden” switch in HA, it would be taught-in, but as I mentioned before, the FSR14 isn’t learning from my button switch in HA. So, I added it manually through PCT14 like this:

As you can see, this matches the sender id of the configuration.yml file. When I press the switch on the HA overview page, it switches on for a second, then off again. Nothing is happening to the lights at all, and the following is visible in the logs:

2024-01-03 01:46:56.896 DEBUG (SyncWorker_3) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 00 b0 03, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090000b003002f
2024-01-03 01:47:14.010 DEBUG (MainThread) [eltako] [Gateway] [Id: 1] Received message: <ESP2Message '0b 07 00 00 00 0d 00 00 19 01 00'>

So the message is sent somewhere on the bus, but not received. If I use ID detection in PCT14 again, and try the button in HA, I also do not see any messages arriving. It’s like no message is being sent through the FGW14-USB from HA. Only read out from it. The FGW14-USB BA is set to 6.

So long story short, I don’t get it at all… . I don’t see how with my config, HA can know what light is turned on or off when it was triggered from the wall switch. And I don’t know why the messages triggered from HA - that are visible in the logs - are not reaching the FAM14.

Thanks!

Cedric

Really great description. What I see spontaneously is that you are using id 3 in configuration and 5 in PCT14. Id 3 in PCT14 would be in the first FSR14 channel 3.
I would expect that if you push the button in HA that a response of FSR14 channel 1 (id 5) will be sent!?

Communication via gateway looks good. As far as I know you do not see the commands from HA in PCT14. My impression was it only listens to wireless telegrams but I’m unsure about that.

1 Like

No, the first one would map to another channel that also doesn’t get triggered… . Is it coded that way?

Additionally, help me understand: is HA supposed to be able and send commands? Or only listening?

I know with OpenHAB I had managed to make it work. So electrically speaking, it should work… :slight_smile:

Yes, it actually should work. The log lines you’ve posted with send message show that HA put the switch telegram onto the bus.
Do you have a resistor btw rsa2 and rsb2 and is hold cable installed?

You can actually also switch on the serial lib logs:

logger:
  default: info
  logs:
    eltako: debug
    eltakobus.serial: debug

Yes. Default resistor in place and hold everywhere connected. It worked with openhab hence I’m pretty sure it’s all wired ok. Will enable the serial debugs and see if I can find something interesting.

If the order matters… as you can see maybe from my PCT screenshot. I have an interesting setup with my first FSR. Ie: one button switches on 2 channels together. How would I go and configure that then if the order matters? Or are you saying I should just add 8 dummy ids for each channel I have?

What do you mean by order?

In your case I would create for each channel an own light entry in the configuration starting from 00-00-00-01 to 00-00-00-08. Every entry has then sender ids from 00-00-B0-01 to 00-00-B0-08 which needs to be entered in PCT14 …

And now I see in our config you’ve entered 00-00-B0-03 as sender id and in PCT14 00-00-0B-03

1 Like

You wrote:
“you are using id 3 in configuration and 5 in PCT14. Id 3 in PCT14 would be in the first FSR14 channel 3.”

Hence my question: does the order matter? Is the first id with an eep M5-38-08 mapped to the first FSR channel it finds?

You have eagle eyes :slight_smile: It worked after I changed it! At least, when I clicked the button on the overview page, the light outside turned on, but in HA it turned back off. I guess that can be related to what we’re discussing about the “order” of lights?

Yes! It works perfect now… I added them like you said in the order of the FSR channels, and they perfectly turn on and stay on.

Now a final question I have before I start documenting this back to my original git repo :slight_smile: Why would I now also want to add a binary_sensor which controls these lights?

Actually you don’t need it. You could make an evaluation of which switch was pushed when. Or you could create automations in HA which can react on switches. E.g. turn all lights off. Beauty about automations in HA is that you can combine them with none-Eltako or none-enocean sensors and actuators.

1 Like

I’ve updated my original git repo with all I learned in the last few days. Anyone wants to proof read and let me know if I forgot something or need to better explain certain things?

Eltako-home-automation/README.md at main · cvanlabe/Eltako-home-automation (github.com)

I managed to fix my weird crashing-error in HA, that kept me from testing anything and started to play with Eltako (finally!).

It works! At least the basics. Thanks @cvvvlb for the nice short tutorial! That helped a lot to get a basic understanding and “something” working quickly :slight_smile:

Nooow the first questions: I have a rather “strange” setup: I use old BR12 actors (light and blinds) within my BR14 Setup (via Gateway).
They are not accessible by address or PCT and programming them to new virtual HA sensors would be a pain. Also, they don’t give feedback. The easy way would be if HA just pretends to be the existing sensor in the house faking the corresponding packet that is already programmed within the actor. But…could I do that? And how? I tested a little but had no success.

Can you clarify your devices and setup a bit? I also have a large amount of series 12 actuators in use and if there’s a way to get these connected I’d love to think with you too.

Hello @cvvvlb,

I don’t have series 12 devices in you. You from @heubie I know it can work somehow. Check out the old comments and maybe @heubie can you tell some more details about your setup?

Let me know if you need any extensions.

For all Home Assistant, FHEM and ELTAKO newcomers.

ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ

I would like to thank @cvvvlb for the tip on the ELTAKO documentation. I am currently trying to switch from FHEM and iobrocker to Home Assistant. I have already read through most of this documentation. Especially the first document below is helpful for all ELTAKO enOcean users. It could have been written by me :wink: because it contains everything I had to learn many years ago.

With the first link, all ELTAKO users should be able to connect to Homeassistant. Likewise, all FHEM users should have their system prepared for FHEM.

ELTAKO enocean general:
(Also interesting for FHEM)

Home Assistent specific:

For German Search :slight_smile:

Für alle Home Assistant, FHEM und Co. Neueinsteiger.
ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ ⓘ

Ich möchte mich bei @cvvvlb für den Hinweis auf die ELTAKO-Dokumentation bedanken. Ich bin gerade dabei, von FHEM und iobrocker auf Home Assistant umzusteigen. Den größten Teil dieser Dokumentation habe ich bereits durchgelesen. Besonders das erste Dokument unten ist hilfreich für alle ELTAKO enocean Benutzer. Es hätte von mir geschrieben worden sein ;), denn es enthält alles, was ich vor vielen Jahren lernen musste.

Mit dem ersten Link sollten alle ELTAKO-Anwender in der Lage sein, sich mit Homeassistant zu verbinden. Ebenso sollten alle FHEM-Anwender ihr System für FHEM vorbereiten können.

My setup is:
FAM14
several F4HK14,
FUD14
FGW14-USB (connected to HA on RPI3)
FGW14 connected to BR12
BR12 consists of
several FSA12
several FSB12

Sensors in the setup are FT55 pushbuttons (love them) and several different thermostates for the heating (they all suck).

Unfortunately my weird crashes of HA are back after setting up Eltako again and I have no idea what cause them. HA dies slowly, first some of the features stop working and after 10 minutes to 2 hours the whole system is gone. I have to investigate again.

Hello @jottt,

Can you tell me your issue with the thermostats? I have planned to equip my house with FUTH and FLGTF. I wanted to use mainly FLGTF to get temp, humidity and air quality. Control of heating should go over home Assistent except 2 rooms shall have each FUTH and control over hearing dir them can love love Home Assistent or FUTH.

What do you think about that plan? Please let me know your experiences.

So far I’ve tested with both sensors and prepared the HA integration for it

Ok, have to admit, that was a bit “short” for an answer.

I have:

Eltako FTFB

Works fine as a sensor but as setting a temperature in F4HK14 is not easily possible, not good for every room.

Eltako FTR55EHB

I was pretty happy besides the expensive batteries, but it started sending wrong Set-Temperature after 1,5 years. Took me long to find the error as Eltako does not show the temperature it’s using anywhere. (Without a debugger and a tap somewhere). Repair/Replacement not possible by Eltako.

Eltako FTR65HS

I have 4 of those. None work with their solar cell…that only works directly at the window and a temperature sensor on the window sill is a bit pointless.
2 of the four send wrong set-temperatures after only 4 years (like above…it took me a while to find out why my heating did not work as it should.

As those sensors are pretty expensive I am very disappointed by their life expectance.

I cannot comment on the FUTH or FLGTF as both need a powerconnection. I don’t have a wire where my sensors are.
Your plan sounds close to mine: Getting temp from every room, setting temp via HA. I don’t need the option to set it directly in the room (nice bonus of course). As the Eltako sensors are pretty expensive, I started toying with cheap ones from Aquara (via Zigbee). They work fine for a lot less money, but need a working HA > Eltako F4HK14 interface.

Hello @jottt,

thanks for your shared experience. What I like about FUTH is that you can control the heating from both FUTH and Home Assistant and the FUTH actually also takes over the value from HA and shows it on its display when you change it in HA.

That’s what I’ve tested and planned to build: