Eltako "Baureihe 14 – RS485" (Enocean) Debugging

Third party integrations
244

Hi @all

first of all, thank you guys for this amazing effort on this topic. I’m new in the world of HA and was struggling how can i integrate my Eltako Baureihe 14 into HA. You have really made great developments here. Respect!

As i mentioned: i’m realy new and try to configure my HA as you described it in your documentation. I think i fail at the point where i should teach-in my HA setup into PCT14.

My Setup: FAM14, FUD14, FSB14

PCT14
PCT141183×465 23.4 KB

Here my YAML config:


# Loads default set of integrations. Do not remove.
default_config:

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

eltako:
  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
logger:
  default: info
  logs:
    eltako: debug     # to change log level and to see messages on the bus switch from info to debug

My first question is, in the documentation from cvanlabe (Eltako-home-automation it is mentioned that we have to set in PCT14 for the FSR under function group2 the function 51 - switching state from controller. Can anyone tell me what function we have to choose in which group for FUD14 and FSB14?

Is in my configuration something wrong so far?

Thanks in advance for any help!

Regards,
sneijder55

245

Hey Tom,
my assumption is that there is a buffer overflow in the serial communication because it tries to first send all messages and then waits for answers. Either the buffer overflow is on the PC-side or on FGW14-USB. I assume the baudrate on RS485 bus is 9600 and we use to FGW14-USB 57600. So my guess the overflow happens in FGW14-USB.
I can try two things increasing the internal buffer size of the serial communication for the PC. Standard is 4096bytes what should be more than enough in our case AND to delay the communication to prevent buffer overflow in FGW14-USB. You mentioned as well the speed in FHEM seems to be slower. This is maybe the system speed. :slight_smile:

Could you do the tests again and switch on the debug for the serial communication:

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

Actually the message send logs we see here only means HA passed the message to the library which has an internal message queue. When you see this line then the message was really be put on the serial bus: https://github.com/grimmpp/eltako14bus/blob/8a65376e32f56f7cfc17125b670782e91750e3cb/eltakobus/serial.py#L118C9-L118C51

246

Hello @sneijder55,

welcome in this round. This is a good idea to prepare this information better.
In short:
FUD14 = 32
FSB14 = 31

Those numbers let the device know what telegram format is to be expected. When supported you can adjust the EEP in the config and choose different numbers as well. As example you could use real switch telegrams.

Update:
I’m about to write a new tool which allows you to manage your devices and which can also generate the Home Assistant Configuration. The key functions, you’ve asked for, I put now as comment into the auto-generated configuration.

1 Like
247

hey philipp!

thank you for pointing me in this directions.

first, this is swichting 13 lights with eltakobus.serial on debug:

2024-01-27 08:36:31.901 DEBUG (SyncWorker_5) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 0b, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010000b0097
2024-01-27 08:36:31.902 DEBUG (SyncWorker_0) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 1a, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010001a00a6
2024-01-27 08:36:31.902 DEBUG (SyncWorker_0) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 10, data 01 00 00 09, status = 0x00> - Serialized: a55a6b070100000900100010009c
2024-01-27 08:36:31.902 DEBUG (SyncWorker_0) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 19, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010001900a5
2024-01-27 08:36:31.902 DEBUG (SyncWorker_0) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 07, data 02 64 00 09, status = 0x00> - Serialized: a55a6b07026400090010000700f8
2024-01-27 08:36:31.902 DEBUG (SyncWorker_0) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 11, data 01 00 00 09, status = 0x00> - Serialized: a55a6b070100000900100011009d
2024-01-27 08:36:31.902 DEBUG (SyncWorker_0) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 12, data 01 00 00 09, status = 0x00> - Serialized: a55a6b070100000900100012009e
2024-01-27 08:36:31.903 DEBUG (SyncWorker_0) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 17, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010001700a3
2024-01-27 08:36:31.903 DEBUG (SyncWorker_0) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 08, data 02 64 00 09, status = 0x00> - Serialized: a55a6b07026400090010000800f9
2024-01-27 08:36:31.903 DEBUG (SyncWorker_0) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 0f, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010000f009b
2024-01-27 08:36:31.903 DEBUG (SyncWorker_0) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 0c, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010000c0098
2024-01-27 08:36:31.903 DEBUG (SyncWorker_0) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 18, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010001800a4
2024-01-27 08:36:31.906 DEBUG (SyncWorker_21) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 06, data 02 64 00 09, status = 0x00> - Serialized: a55a6b07026400090010000600f7
2024-01-27 08:36:31.907 DEBUG (Thread-3) [eltakobus.serial] Sent message: <Regular4BSMessage from 00 10 00 0b, data 01 00 00 09, status = 0x00>
2024-01-27 08:36:31.909 DEBUG (Thread-3) [eltakobus.serial] Sent message: <Regular4BSMessage from 00 10 00 1a, data 01 00 00 09, status = 0x00>
2024-01-27 08:36:31.910 DEBUG (Thread-3) [eltakobus.serial] Sent message: <Regular4BSMessage from 00 10 00 10, data 01 00 00 09, status = 0x00>
2024-01-27 08:36:31.912 DEBUG (Thread-3) [eltakobus.serial] Sent message: <Regular4BSMessage from 00 10 00 19, data 01 00 00 09, status = 0x00>
2024-01-27 08:36:31.913 DEBUG (Thread-3) [eltakobus.serial] Sent message: <Regular4BSMessage from 00 10 00 07, data 02 64 00 09, status = 0x00>
2024-01-27 08:36:31.915 DEBUG (Thread-3) [eltakobus.serial] Sent message: <Regular4BSMessage from 00 10 00 11, data 01 00 00 09, status = 0x00>
2024-01-27 08:36:31.916 DEBUG (Thread-3) [eltakobus.serial] Sent message: <Regular4BSMessage from 00 10 00 12, data 01 00 00 09, status = 0x00>
2024-01-27 08:36:31.918 DEBUG (Thread-3) [eltakobus.serial] Sent message: <Regular4BSMessage from 00 10 00 17, data 01 00 00 09, status = 0x00>
2024-01-27 08:36:31.920 DEBUG (Thread-3) [eltakobus.serial] Sent message: <Regular4BSMessage from 00 10 00 08, data 02 64 00 09, status = 0x00>
2024-01-27 08:36:31.921 DEBUG (Thread-3) [eltakobus.serial] Sent message: <Regular4BSMessage from 00 10 00 0f, data 01 00 00 09, status = 0x00>
2024-01-27 08:36:31.923 DEBUG (Thread-3) [eltakobus.serial] Sent message: <Regular4BSMessage from 00 10 00 0c, data 01 00 00 09, status = 0x00>
2024-01-27 08:36:31.924 DEBUG (Thread-3) [eltakobus.serial] Sent message: <Regular4BSMessage from 00 10 00 18, data 01 00 00 09, status = 0x00>
2024-01-27 08:36:31.927 DEBUG (Thread-3) [eltakobus.serial] Sent message: <Regular4BSMessage from 00 10 00 06, data 02 64 00 09, status = 0x00>
2024-01-27 08:36:32.244 DEBUG (Thread-3) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrappedRPS from 00 00 00 18, status 30, data 70>
2024-01-27 08:36:35.104 DEBUG (Thread-3) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrapped4BS from 00 00 00 06, status 00, data 02 64 00 09>

So now what i found…you pointed me towards line 118 in this file: https://github.com/grimmpp/eltako14bus/blob/8a65376e32f56f7cfc17125b670782e91750e3cb/eltakobus/serial.py#L118C9-L118C51

So i thought that line 119 might be the one to tweak in order to make it a bit slower. So i tried…i changed line 119 from

   time.sleep(.001)

to

   time.sleep(.01)

and the problem is gone. i can now switch a group of 13 lights just fine.

1 Like
248

Hello Tom,
grate work! I can adjust this.
I had actually also another idea for easier testing but now you found it out. You can chose FAM-USB and gateway device_type and switch FGW14-USB to BA=5. In this case you can use baudrate 9600. The rest should behave the same.

I use actually the same code for reading the memory of FAM14 which is quite big and here the baudrate 57600 is no problem. This I definitely need to distinguish when doing the fix.

Update:
Created release v1.3.5 (Release Version 1.3.5 Prevent Message overflow for FGW14-USB · grimmpp/home-assistant-eltako · GitHub) containing the fix. Can you please test it?

1 Like
249

wonderful. so, i’ll just wait for the fix and try again.

thank you very much philipp!

Edit: oh you already did. awesome. thank u so much.

250

It’s already fixed in V1.3.5

1 Like
251

yeah, i saw only after i posted. hence, the edit.
looks very good to me. problem is fixed imho.

thanks a lot mate

1 Like
252

Hi @philipp14,

thanks for your help. I’ve tried it with function 32 for FUD14. But somehow it doesnt work.

image
image1341×460 25 KB

My steps till now are:

  1. Create config.yaml for test one device (please find my yaml code in my post before).
  2. Install Eltako integration
  3. Choose EnOcean ESP2 Gateway - fam14 (Id: 1, BaseId: FF-AA-80-00) and /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AQ01GDDJ-if00-port0
    image
  4. Two devices found. (FAM14 and FUD14)
    image

So, HA found my devices but i can’t switch them on and off. I don’t know what the problem is.
Did i forget something?

253

Hello @sneijder55,

you need to enter the sender id 00-00-B0-09 from your config as hex. Don’t use Dec.

image
image1307×214 6.09 KB

You also can try out my new tool to managed all the devices. You can use it to write all those entries for HA and you can export the HA config. To do so just connect your FAM14 via USB click detect, connect, and then scan. It will automatically detect all devices and read their memory to know which sensor is configured. After that it will propose the Home Assistant setting which you can of course adapt. If you are happy with it just push ‘write HA senders to devies’ and export the Home Assistant config.

Pls, let me know how it works for you.

image
image1920×1051 132 KB

1 Like
254

Hi @philipp14 ,
thanks for your feedback! That was the solution! I will now integrate my other FUD14 and FSB14 components.

Regarding your tool: I used it but i get this error at step5 while starting the app:

.\.venv\Scripts\python.exe main.py
Traceback (most recent call last):
  File "...\enocean-device-manager-main\main.py", line 4, in <module>
    from view.main_panel import *
  File "...\enocean-device-manager-main\view\main_panel.py", line 8, in <module>
    from PIL import Image, ImageTk
ModuleNotFoundError: No module named 'PIL'

I have to say that I have as good as no programming skills. It was really hard for me to find out how and where to handle with the commands :smiley:

Regards,
sneijder55

255

I don’t know why this happens. Sometimes you need to run the install command twice. Or just pip install pillow

I’ve planned to create a executable soon. Are you on Windows?

256

i’ve tried it twice and with pip install pillow but same error again.
I’m using Windows and Python 3.12

I have another question. How can i get the status of the lamps? For example: if i switch the lamps with wall switch then i don’t see in HA that the lamp is on. Is there a way to fix it?

257

When the status of a device changes it will send a status update telegram containing the state e.g. on/off for lights. This telegram contains the address of the light actuator as well. The same address/id needs to be entered in the HA config. That’s how it knows what is in which state. The address are the ones in the PCT14 tree on the left but you need to take the hex code of it. E.g. in your case Adr 11, V4.2 Wohnzimmer Licht => 00-00-00-0B

Here is an example: https://github.com/grimmpp/home-assistant-eltako/blob/4fdfdea0398ff83c5cbeb014256b8c24d16e20a2/docs/update_home_assistant_configuration.md

1 Like
258

hey philipp.

did something change with the library?
i have exactly the same problem as before with lightgroups (>11 lights) not switching.

sidenote: i update HA to the latest version yesterday. don’t know if that is the reason but serial.py looks like it was changed.

serial.py has this on my system:

       time.sleep(.001)

Edit: OK, i might be totally wrong here…but is there a chance that if the integration is already installed and i just update it via HACS the modules in requirements.txt are not redownloaded if no version of the module is specified in requirements.txt?

i have the suspicion that i actually never tested your new module version (eltakobus) because on my system it just always stays the old version.

BR
Tom

259

Hey Tom,
The code you’be linked is in v0.0.33 available. Maybe 0.0.34. you should use at least 40. That is defined in the manifest of the integration. HACS takes that automatically.
Do you install the packages manually? I can you update the eltako14bus versions in requirements.txt as well if you need that.

260

yeah! you are right. its not a matter of your code.

i am pretty sure it is a matter of updating (or not updating in this case) the library.

Do you install the packages manually? I can you update the eltako14bus versions in requirements.txt as well if you need that.

i do install via HACS. just as usual…add repo to HACS → install → add integration.
i also do the updates via HACS as usual.
I dont want to produce extra work for you but i think this is not a problem that hits only me. i think everybody updating your integration will face this problem. but i am far from an expert, this is just my 2cents. :wink:

to me it looks like the requirements are not redownloaded during an update via HACS. This is IRC normal for pip. i think i remember that pip thinks the dependency is already satisfied if there is any version the of module installed and there is no version information provided in requirements.txt.

My homeassistant container holds this

homeassistant:/usr/local/lib/python3.11/site-packages# ls -ld eltako*
drwxr-xr-x    2 root     root          4096 Feb  1 14:50 eltako14bus-0.0.39.dist-info
drwxr-xr-x    3 root     root          4096 Feb  1 14:50 eltakobus
homeassistant:/usr/local/lib/python3.11/site-packages#

no matter how many times i redownload/update the eltako integration.

I would really like to try to avoid removing the integration completely.

EDIT: oh, there is a manifest…ok, did not know about that (i am new to HA). ok, in this case i have to learn about this a bit more.

BR
Tom

261

ok. so the manifest.json is the place HA takes this information from. ty for explaining…this makes me at least look at the right places.

on my installation the manifest is this:

{
  "domain": "eltako",
  "name": "Eltako",
  "codeowners": ["@bdurrer", "@grimmpp"],
  "config_flow": true,
  "dependencies": [],
  "documentation": "https://github.com/grimmpp/home-assistant-eltako",
  "integration_type": "hub",
  "iot_class": "local_push",
  "issue_tracker": "https://github.com/grimmpp/home-assistant-eltako/issues",
  "loggers": ["eltako"],
  "requirements": ["eltako14bus==0.0.39","enocean==0.60.1", "StrEnum"],
  "version": "1.2.3"
}

which on hand explains a lot, on the other hand though makes me wonder why it is not stating 0.0.40.

hmmmm, i will dig deeper.

EDIT:
i think i found the issue. looks like the new manifest.json did not make it in your home-assistant-eltako-1.3.5-prevent-message-overflow-for-fgw14usb release.

i downloaded the tar.gz of your latest release. this is the manifest.json from that release (https://github.com/grimmpp/home-assistant-eltako/archive/refs/tags/v1.3.5-prevent-message-overflow-for-fgw14usb.tar.gz):

{
  "domain": "eltako",
  "name": "Eltako",
  "codeowners": ["@bdurrer", "@grimmpp"],
  "config_flow": true,
  "dependencies": [],
  "documentation": "https://github.com/grimmpp/home-assistant-eltako",
  "integration_type": "hub",
  "iot_class": "local_push",
  "issue_tracker": "https://github.com/grimmpp/home-assistant-eltako/issues",
  "loggers": ["eltako"],
  "requirements": ["eltako14bus==0.0.39","enocean==0.60.1", "StrEnum"],
  "version": "1.2.3"
}
262

Oh, no. My bad. I’m very sorry. Í can fix that in my lunch break.

1 Like
263

No worries. And don’t rush. Please use your lunchbreak for what it is meant for…1. Lunch 2. Break! :wink: