Eltako "Baureihe 14 – RS485" (Enocean) Debugging

jottt · January 15, 2024, 10:44am

This looks pretty perfect. I checked when you explained your setup in October, unfortunately my stability issues came in the way. I am still not completely rid of it, something is wrong here, as soon as I run the Eltako-extension. I suspect maybe memory.

I came over a small issue while testing: HA complains that the target temp value is unknown instead of a value. My fault or faulty code? Config & error below.

The sensor is a FTR65HS and the EEP should be correct. It’s similar to your FUTH. I get a temperature value from it, so some communication works.

        sensor: 
          - id: "FF-A9-E9-00"
            name: "Temp/DG_w"
            eep: "A5-10-06"

2024-01-15 10:54:27.990 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback Entity.async_write_ha_state()
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 639, in state
    numerical_value = int(value)
                      ^^^^^^^^^^
ValueError: invalid literal for int() with base 10: 'unknown'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 642, in state
    numerical_value = float(value)
                      ^^^^^^^^^^^^
ValueError: could not convert string to float: 'unknown'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/asyncio/events.py", line 80, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 945, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1066, in _async_write_ha_state
    state, attr, capabilities, shadowed_attr = self.__async_calculate_state()
                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1003, in __async_calculate_state
    state = self._stringify_state(available)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 951, in _stringify_state
    if (state := self.state) is None:
                 ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 646, in state
    raise ValueError(
ValueError: Sensor sensor.eltako_gw1_ff_a9_e9_00_target_temperature has device class 'temperature', state class 'measurement' unit '°C' and suggested precision '1' thus indicating it has a numeric value; however, it has the non-numeric value: 'unknown' ()
    if (state := self.state) is None:
                 ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 646, in state
    raise ValueError(
ValueError: Sensor sensor.eltako_gw1_ff_a9_e9_00_target_temperature has device class 'temperature', state class 'measurement' unit '°C' and suggested precision '1' thus indicating it has a numeric value; however, it has the non-numeric value: 'unknown' ()

philipp14 · January 15, 2024, 12:39pm

Hello @jottt,
I don’t really understand what symptoms you’ve got with the instabilities. Can you explain it in more detail?

Regarding the error message you’ve posted: This is an initialization problem and lies in the code. I’m aware of it but don’t know how to fix it. For temp sensors I say for example they shall have numeric values, e.g. °C as unit, … then there is a check in HA which then know the value must be a number but I start with an empty value ‘unknow’ instead of ‘0’. Otherwise you would have 0°C at the start value what would probably be wrong. When the first telegram arrives everything is fine again. The behavior in HA is actually also correct but it prints the error message which is not nice. If you find a way to correct it please let me know.

jottt · January 15, 2024, 1:20pm

Instabilities:
My HA was running stable and after installing eltako it worked fine for a short while, then I noticed missing data from sensors, sometimes stopped addons and sooner or later the system broke down (sometimes after minutes, sometimes after days). There was never any error in the logfile.
I uninstalled eltako, but the issue persisted.
I tried a different PSU, restored a backup, nothing helped until I took out the SD, put it into my PC to check it (no errors found) and put everything back and HA was stable again. I did not touch it and it worked for at least 2 months. I have no idea why.

Some days ago I felt like “lets try eltako again!” and it was working initially but after about a day the issue was back and again…the only way to “fix” it was to take out the SD card, put it into my computer (no scan this time) and put it back. Sounds totally bonkers, but now HA works again.

Things I suspect at the moment:
I enabled debug both times before it started becomming unstable, this creates loads of logs and I only have a Pi3 with 1GB RAM. Maybe this damaged the data on the SD in some kind that gets fixed by putting the card into a PC (no FSCK used the second time, no errors reported)? Sounds a bit hokus-pokus to me, to be honest, but SD & Raspberry Pis are known for strange stuff.

Maybe the RAM is used up, but then again, why did the error persist after removing eltako? Doesn’t make too much sense.

I am a bit at a loss with this problem, as I cannot find any logentry that reports anything unusual.

As for now, the system is stable since about 12 hours (with eltako, but without debug), so I might have it circled. Lets wait some days…

EDIT: Nope, it was not the Debug-Mode. System froze again at after 10 hours at 5:34 p.m. - I bought a Pi5. Lets wait for delivery and see. I also changed the FAM14 from chattery “4” to serene “6” to see if that makes a difference.

Missing value:
I understand the underlying problem, but mine extends a bit further I think:The error should vanish as soon as a value is received, but in my case (for all my 4 sensors), this value never gets written. I get the current temperature, but no set_temperature. The above error shows up every time a telegram is received. Not an issue for me right now (don’t need the value), but probably something to look at.

Unfortunately, I am only a sophisticated tinkerer, but my programming skills are verly low.

Hersfeld · January 16, 2024, 4:18pm

I finally found the time to test a little more and added one of my FSR14. I am able to switch the light on an off and also see the status change when using the switch on the wall. But after one second the status goes from on to off again even though the light is still on.

For the sender ID I used the one from my USB300 stick so I dont had to perform a new teach in.

philipp14 · January 16, 2024, 7:36pm

Hello @Hersfeld,
Can you share your config? Are you using usb300?

Hersfeld · January 16, 2024, 7:58pm

Sorry, I did what I hate the most. Asking without providing all details.

I have FHEM > MQTT > HA with USB300 gateway running and want to migrate to this integration to get rid of the FHEM instance.

I have installed your integrations as described in the documentation and have connected HA via USB to the FAM14 (BA = 2)

My configuration looks like this:

eltako:
  gateway:
  - id: 1
    device_type: fam14
    base_id: FF-CE-97-00
    devices:
      light:
      - id: FF-CE-97-0A
        eep: M5-38-08
        name: Arbeitszimmer
        sender:
          id: FF-D6-30-01
          eep: A5-38-08

philipp14 · January 16, 2024, 8:16pm

Hello @Hersfeld,
Can you try 00-00-00-0A as id for the FSR14?

You could also try out to use USB300 directly. I’ve added the support with v1.3.3 as experimental. I thing so far nobody tested it. (I don’t own one for testing.)

Hersfeld · January 16, 2024, 8:40pm

Changed it and its working now.

The USB300 is currently connected to FHEM but once I have the whole setup in HA complete I will connect it to HA and test it. Afterwards I can send it over to you for testing/development if you want.

Hersfeld · January 17, 2024, 11:27am

I wanted to test the USB300 now but in the documentation I dont find the configuration for it.

I assume its:

gateway:
- id: 1
  device_type: usb300
  base_id: FF-D6-30-00

philipp14 · January 17, 2024, 11:31am

github.com

grimmpp/home-assistant-eltako/blob/797e07e532cbfdb4b12290974abd47c95c2776fa/custom_components/eltako/const.py#L78


      
              Platform.SWITCH,
              Platform.COVER,
              Platform.CLIMATE,
              Platform.BUTTON,
          ]
          
          class GatewayDeviceType(str, Enum):
              GatewayEltakoFAM14 = 'fam14'
              GatewayEltakoFGW14USB = 'fgw14usb'
              GatewayEltakoFAMUSB = 'fam-usb'     # ESP2 transceiver: https://www.eltako.com/en/product/professional-standard-en/three-phase-energy-meters-and-one-phase-energy-meters/fam-usb/
              EnOceanUSB300 = 'enocean-usb300'    # not yet supported
          
              @classmethod
              def find(cls, value):
                  for t in GatewayDeviceType:
                      if t.value.lower() == value.lower():
                          return t
                  return None
          
              @classmethod
              def is_transceiver(cls, dev_type) -> bool:

enocean-usb300

Hersfeld · January 17, 2024, 11:42am

Unfortunately the integration broke. I assume because in the initial installation process I chose the other gateway. Is there an way to restart the installation process other than delete the integration and install it again?

philipp14 · January 17, 2024, 11:48am

github.com

grimmpp/home-assistant-eltako/blob/797e07e532cbfdb4b12290974abd47c95c2776fa/docs/install-specific-version-or-branch.md

# How to install a specific version or branch

This documentation tells you how you can install e.g. a specific branch of this integration.

## Prerequisites
* Add-on "Terminal & SSH" is installed.

## How to change version
1. Open "Terminal & SSH".
2. Type `git clone https://github.com/grimmpp/home-assistant-eltako/`
3. Wait until downloaded and change into folder `cd home-assistant-eltako`
4. Change to your version, tag, or branch by using `git checkout VERSION_TAG_BRANCH` (If you want to use main branch (latest version) just skip this step.)
6. Update by running install script: `./install_custom_component_eltako.sh`
7. Wait until Home Assistant is restarted. DONE!

Hint: Your can past into "Terminal & SSH" by using key combination: `SHIFT + STRG + V`

You can manually install it. Just skip step 4.

You can actually keep the old gateway in the configuration and just add the USB 300 as second gateway. Both should also work on parallel.

Hersfeld · January 17, 2024, 1:17pm

Reinstalled and choose the USB300 as gateway but I get “Fehler beim Einrichten”. In the logs I see:

  File "/config/custom_components/eltako/gateway.py", line 86, in __init__
    self._bus = ESP3SerialCommunicator(port=serial_path, callback=self._callback_receive_message_from_serial_bus)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: ESP3SerialCommunicator.__init__() got an unexpected keyword argument 'port'

philipp14 · January 17, 2024, 2:20pm

can you try again? Change is applied to main branch.

LHBL2003 · January 17, 2024, 8:47pm

Hi,

I can currently control FSR14_4x via home-assistant-eltako.
Only for the FTS14EM I do not get the status displayed in HA.
I can do it in FHEM.

Upper rotary switch position: 10
Lower rotary switch position: UT 1
Port 5

Config

eltako:
  gateway:
    - id: 1
      base_id: FF-00-00-00
      device_type: fgw14usb
      devices:
        binary_sensor:
        - id: 00-00-10-15
          eep: F6-02-01
          name: FTS14EM - KG-S1 - Signal 5 (Frei)
          #device_class: presence 
          #invert_signal: False
 
logger:
  default: info
  logs:
    eltako: debug

EEP: F6-02-01 is also set up by default in FHEM when FHEM scans the Eltako bus.

Logging Message (It looks as if the signal is detected by HA.):

2024-01-15 20:25:52.653 DEBUG (Thread-2) [eltako] [Gateway] [Id: 1] Received message: <RPSMessage from 00 00 10 15, db0 = 70, status = 0x30 (T2, N, 0 repetitions)>
2024-01-15 20:25:52.656 DEBUG (SyncWorker_12) [eltako] [Binary Sensor] Send event: eltako.gw_1.btn_pressed.sid_00-00-10-15, pressed_buttons: ‘[“RT”]’
2024-01-15 20:25:52.657 DEBUG (SyncWorker_12) [eltako] [Binary Sensor] Send event: eltako.gw_1.btn_pressed.sid_00-00-10-15.d_RT, pressed_buttons: ‘[“RT”]’
2024-01-15 20:25:56.784 DEBUG (Thread-2) [eltako] [Gateway] [Id: 1] Received message: <RPSMessage from 00 00 10 15, db0 = 00, status = 0x20 (T2, U, 0 repetitions)>
2024-01-15 20:25:56.786 DEBUG (SyncWorker_23) [eltako] [Binary Sensor] Send event: eltako.gw_1.btn_pressed.sid_00-00-10-15, pressed_buttons: ‘’
2024-01-15 20:25:56.787 DEBUG (SyncWorker_23) [eltako] [Binary Sensor] Send event: eltako.gw_1.btn_pressed.sid_00-00-10-15.d_, pressed_buttons: ‘’

Visu (Status remains unknown):

Do you have any idea what I should configure?

With eep: D5-00-01 it gets even worse.

philipp14 · January 18, 2024, 9:06am

Oh man, I’ve tested yesterday night a lot and after a while I realized I’ve got two FST14EM sending different telegram types for the same rotary switch positions

So now you can use for switch telegrams F6-02-01 and F-02-02 and for contact telegrams you can use D5-00-01. If it’s wrongly configured the warning will tell you that message type and eep does not fit together.
I think in your case you can leave the configuration with F6-02-01.

Changes are pushed to main branch.

Updates in: FTS14EM - Visu (Status remains unknown): · Issue #43 · grimmpp/home-assistant-eltako · GitHub

naich11 · January 25, 2024, 11:19am

Hey!

I started using your Integration yesterday and have to say a big thank you. It rly is well documented and worked from the beginning on. I am in the process of migrating from FHEM to HA.

There is a slight problem i am not sure is expected or is my fault in some way.

I use an FGW14-USB for connection and i can switch all auf my ~13 lights (FSR14-4x and FUD14) just fine. But if i put them in group and turn them all on/off at once only one turns on/off. If i however remove just one light from the group of all my eltako lights it works just fine. it does not matter which one i remove.

Did anybody see a similar issue?

BR
Tom

naich11 · January 25, 2024, 5:25pm

I also noticed that in a scene like this:

scene:
    - name: test
      entities:
        light.eltako_gw1_00_00_00_06: "off"
        light.eltako_gw1_00_00_00_08: "off"
        light.eltako_gw1_00_00_00_0b: "off"
        light.eltako_gw1_00_00_00_0c: "off"
        light.eltako_gw1_00_00_00_0f: "off"
        light.eltako_gw1_00_00_00_10: "off"
        light.eltako_gw1_00_00_00_11: "off"
        light.eltako_gw1_00_00_00_12: "off"
        light.eltako_gw1_00_00_00_17: "off"
        light.eltako_gw1_00_00_00_18: "off"
        light.eltako_gw1_00_00_00_19: "off"
        light.eltako_gw1_00_00_00_1a: "off"

If all lights are turned on and i activate the scene only one light is turned off all the rest stays on.
If i however turn on all lights but one (no matter which one) and i activate the scene all the lights are turned off.

if i understand the debug output correctly we send a msg for all of them but only receive a reply for one:

2024-01-25 18:26:25.968 DEBUG (SyncWorker_34) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 06, data 02 00 00 08, status = 0x00> - Serialized: a55a6b0702000008001000060092
2024-01-25 18:26:25.969 DEBUG (SyncWorker_34) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 08, data 02 00 00 08, status = 0x00> - Serialized: a55a6b0702000008001000080094
2024-01-25 18:26:25.969 DEBUG (SyncWorker_34) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 0b, data 01 00 00 08, status = 0x00> - Serialized: a55a6b07010000080010000b0096
2024-01-25 18:26:25.969 DEBUG (SyncWorker_34) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 0c, data 01 00 00 08, status = 0x00> - Serialized: a55a6b07010000080010000c0097
2024-01-25 18:26:25.969 DEBUG (SyncWorker_34) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 0f, data 01 00 00 08, status = 0x00> - Serialized: a55a6b07010000080010000f009a
2024-01-25 18:26:25.969 DEBUG (SyncWorker_34) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 10, data 01 00 00 08, status = 0x00> - Serialized: a55a6b070100000800100010009b
2024-01-25 18:26:25.969 DEBUG (SyncWorker_34) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 11, data 01 00 00 08, status = 0x00> - Serialized: a55a6b070100000800100011009c
2024-01-25 18:26:25.969 DEBUG (SyncWorker_25) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 12, data 01 00 00 08, status = 0x00> - Serialized: a55a6b070100000800100012009d
2024-01-25 18:26:25.971 DEBUG (SyncWorker_56) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 17, data 01 00 00 08, status = 0x00> - Serialized: a55a6b07010000080010001700a2
2024-01-25 18:26:25.972 DEBUG (SyncWorker_56) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 18, data 01 00 00 08, status = 0x00> - Serialized: a55a6b07010000080010001800a3
2024-01-25 18:26:25.972 DEBUG (SyncWorker_24) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 19, data 01 00 00 08, status = 0x00> - Serialized: a55a6b07010000080010001900a4
2024-01-25 18:26:25.972 DEBUG (SyncWorker_56) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 1a, data 01 00 00 08, status = 0x00> - Serialized: a55a6b07010000080010001a00a5
2024-01-25 18:26:26.757 DEBUG (Thread-3) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrappedRPS from 00 00 00 1a, status 30, data 50>

philipp14 · January 25, 2024, 11:00pm

Hello @naich11,

nice to hear.

I haven’t tested scenes so far. Can you explain a bit more in detail if the light go on and off in real and is it only a display issue in HA? Is this out of sync as well? …

Actually every actuator should send status update telegrams after a change. If FAM14 is on BA=2 then you should receive every 1-2min an status telegram of each actuator as well. (Not sure but devices sometimes also behave different from version to version)

Do you have FSR14 or FSR12 mounted? Afaik FSR12 is sending no status telegrams. But there are workarounds as well.

How is your configuration looking like? I assume you are using the same sender addresses like in FTS14EM? In general this should work. When you use different addresses than you can distinguish what was push. (Nice for statistics)

I’m about to develop a new tool in which you can inventory and managed your EnOcean devices + auto generate Home Assistant configurations. If you like you can have a look and let me know what you think makes sense to add as basic features.

OK, I actually tried it out now with one FSR14x4 and used all 4 lights. Like in your case it is sending for all lights one command to switch off but it receives for each single light a status update. Is there maybe an amount/threshold of lights when it will break?

naich11 · January 26, 2024, 6:32am

Hi philipp!

Thanks for your fast and detailed answer.

Yeah , sure…right…i should go into more detail here.

Can you explain a bit more in detail if the light go on and off in real and is it only a display issue in HA?

The situation explained is the real situation and also the situation in HA. So no, they are not of sync.
For me it happens every time i try to switch all my Baureihe14 Lights on the Bus. (Does not matter if its a scene or a group e.g.)

Do you have FSR14 or FSR12 mounted? Afaik FSR12 is sending no status telegrams. But there are workarounds as well.

My Bus consists of FSR14-4x and FUD14. The FAM14 is on BA = 2. I have 12 lights in total connected:
3x FSR14-4x: 10 Lights
3x FUD14: 2 Lights (one of the FUDs is connected but there is not light/consumer attached)

How is your configuration looking like? I assume you are using the same sender addresses like in FTS14EM?

I have HA connected via an FGW14-USB and am not using the same sender addresses like in FTS14EM. The sender addresses had been thought in via FHEM a few years ago.

I am pretty sure that my HA config is correct as i can switch any light ON/OFF or DIM at any time as long as i do it to either one light or a group of lights that is not a group consisting of all lights.

Is there maybe an amount/threshold of lights when it will break?

Yeah, this is a very good question. For me right now it is exactly the amount of all my lights (12).
So if i create a group with all 12 lights in it and turn it on only one light is turned on.
Do i remove 1 light from the group (does not matter which one) so its only 11 lights in the group they all switch on and off just fine.

I know this is a bit confusing. i will test further and update my learnings.

Edit/Update:

I did a bit more in depth testing. I made 2 tests to narrow the problem down a bit further.

Test 1: Use my unused FUD14 to add another light

Before: 12 lights

10 lights on FSR14-4x, 2 lights on FUD14, 1 unused FUD14
Observation - Group of 12 lights:
behaves very strange. One light in group turns on/off by toggling the group. Toggling the lights directly (not using a group) always works.
Observation Group of 11 lights or less:
behaves exactly as expected. All lights in group turn on/off just fine all the time.

Now: 13 Lights

10 lights on FSR14-4x, 3 lights on FUD14, no unused FUD14
Observation - Group of 13 lights:
behaves exactly as strange as a group with 12 lights. but now 2 lights in the group are turned on/off. other than this there is no difference in the problem shown compared to the 12 light group.
Observation - Group of 12 lights:
now that i have 13 lights i can try and remove one light from the group and see if a group of 12 lights behaves differently now.
result: it does not. the group with 12 lights (even though my total lights on the bus is now 13) still behaves as strange as before-.
Observation Group of 11 lights or less:
behaves exactly as expected. just like before when i had a total of 12 lights. all lights in group turn on/off just fine all the time.

Conclusion Test 1:

This very simple trial and error takes me to the assumption that the threshold from where things go weird is when switching more than 11 lights at a time.

Test 2: Revert to FHEM and try to reproduce (short)

This one is short and easy. I reverted my setup back to my old (but still running) FHEM instance, created a group of all my 13 Lights. Switching the group on/off works fine all the time (~ 50 group switches done). While standing next to my Baureihe14 components though i noticed that it seems that FHEM is switching them a bit slower.

Log Switching Group of 13 Lights

2024-01-26 10:21:33.537 DEBUG (SyncWorker_9) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 10, data 01 00 00 09, status = 0x00> - Serialized: a55a6b070100000900100010009c
2024-01-26 10:21:33.537 DEBUG (SyncWorker_9) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 08, data 02 64 00 09, status = 0x00> - Serialized: a55a6b07026400090010000800f9
2024-01-26 10:21:33.538 DEBUG (SyncWorker_9) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 0b, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010000b0097
2024-01-26 10:21:33.538 DEBUG (SyncWorker_9) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 12, data 01 00 00 09, status = 0x00> - Serialized: a55a6b070100000900100012009e
2024-01-26 10:21:33.538 DEBUG (SyncWorker_9) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 18, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010001800a4
2024-01-26 10:21:33.539 DEBUG (SyncWorker_9) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 0c, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010000c0098
2024-01-26 10:21:33.541 DEBUG (SyncWorker_19) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 1a, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010001a00a6
2024-01-26 10:21:33.541 DEBUG (SyncWorker_19) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 17, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010001700a3
2024-01-26 10:21:33.541 DEBUG (SyncWorker_19) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 11, data 01 00 00 09, status = 0x00> - Serialized: a55a6b070100000900100011009d
2024-01-26 10:21:33.542 DEBUG (SyncWorker_19) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 0f, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010000f009b
2024-01-26 10:21:33.542 DEBUG (SyncWorker_19) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 19, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010001900a5
2024-01-26 10:21:33.542 DEBUG (SyncWorker_19) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 06, data 02 64 00 09, status = 0x00> - Serialized: a55a6b07026400090010000600f7
2024-01-26 10:21:33.542 DEBUG (SyncWorker_19) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 07, data 02 64 00 09, status = 0x00> - Serialized: a55a6b07026400090010000700f8
2024-01-26 10:21:36.730 DEBUG (Thread-11) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrapped4BS from 00 00 00 06, status 00, data 02 64 00 09>
2024-01-26 10:21:36.778 DEBUG (Thread-11) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrapped4BS from 00 00 00 07, status 00, data 02 64 00 09>

Log Switching Group of 11 Lights

2024-01-26 10:24:41.822 DEBUG (SyncWorker_5) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 10, data 01 00 00 09, status = 0x00> - Serialized: a55a6b070100000900100010009c
2024-01-26 10:24:41.822 DEBUG (SyncWorker_11) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 08, data 02 64 00 09, status = 0x00> - Serialized: a55a6b07026400090010000800f9
2024-01-26 10:24:41.822 DEBUG (SyncWorker_0) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 0b, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010000b0097
2024-01-26 10:24:41.823 DEBUG (SyncWorker_13) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 12, data 01 00 00 09, status = 0x00> - Serialized: a55a6b070100000900100012009e
2024-01-26 10:24:41.823 DEBUG (SyncWorker_16) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 18, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010001800a4
2024-01-26 10:24:41.826 DEBUG (SyncWorker_18) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 0c, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010000c0098
2024-01-26 10:24:41.826 DEBUG (SyncWorker_2) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 1a, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010001a00a6
2024-01-26 10:24:41.826 DEBUG (SyncWorker_18) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 17, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010001700a3
2024-01-26 10:24:41.826 DEBUG (SyncWorker_14) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 11, data 01 00 00 09, status = 0x00> - Serialized: a55a6b070100000900100011009d
2024-01-26 10:24:41.827 DEBUG (SyncWorker_2) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 19, data 01 00 00 09, status = 0x00> - Serialized: a55a6b07010000090010001900a5
2024-01-26 10:24:41.827 DEBUG (SyncWorker_18) [eltako] [Gateway] [Id: 1] Send message: <Regular4BSMessage from 00 10 00 06, data 02 64 00 09, status = 0x00> - Serialized: a55a6b07026400090010000600f7
2024-01-26 10:24:42.429 DEBUG (Thread-11) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrappedRPS from 00 00 00 0b, status 30, data 70>
2024-01-26 10:24:42.499 DEBUG (Thread-11) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrappedRPS from 00 00 00 0c, status 30, data 70>
2024-01-26 10:24:42.706 DEBUG (Thread-11) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrappedRPS from 00 00 00 10, status 30, data 70>
2024-01-26 10:24:42.768 DEBUG (Thread-11) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrappedRPS from 00 00 00 11, status 30, data 70>
2024-01-26 10:24:42.828 DEBUG (Thread-11) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrappedRPS from 00 00 00 12, status 30, data 70>
2024-01-26 10:24:42.887 DEBUG (Thread-11) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrappedRPS from 00 00 00 17, status 30, data 70>
2024-01-26 10:24:42.940 DEBUG (Thread-11) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrappedRPS from 00 00 00 18, status 30, data 70>
2024-01-26 10:24:43.004 DEBUG (Thread-11) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrappedRPS from 00 00 00 19, status 30, data 70>
2024-01-26 10:24:43.068 DEBUG (Thread-11) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrappedRPS from 00 00 00 1a, status 30, data 70>
2024-01-26 10:24:45.050 DEBUG (Thread-11) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrapped4BS from 00 00 00 08, status 00, data 02 64 00 09>
2024-01-26 10:24:45.833 DEBUG (Thread-11) [eltako] [Gateway] [Id: 1] Received message: <EltakoWrapped4BS from 00 00 00 06, status 00, data 02 64 00 09>

Note: All states (on/off) are always real states and HA states. “On” means the light is on in HA and in real life. Same for Off. They never get out of sync.

This is my configuration.yaml:

eltako:
  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
    base_id: FF-AA-80-00
    device_type: fgw14usb
    devices:
      light:
      - id: 00-00-00-12
        eep: M5-38-08
        name: vr_deckenlicht_FSR14_4x
        sender:
          id: 00-10-00-12
          eep: A5-38-08
      - id: 00-00-00-0C
        eep: M5-38-08
        name: vr_stiegenlicht_FSR14_4x
        sender:
          id: 00-10-00-0C
          eep: A5-38-08
      - id: 00-00-00-1A
        eep: M5-38-08
        name: ez_decklenlicht01_FSR14_4x
        sender:
          id: 00-10-00-1A
          eep: A5-38-08
      - id: 00-00-00-17
        eep: M5-38-08
        name: ez_decklenlicht02_FSR14_4x
        sender:
          id: 00-10-00-17
          eep: A5-38-08
      - id: 00-00-00-07  #newly added for testing
        eep: A5-38-08
        name: ez_decklenlicht03_FUD14
        sender:
          id: 00-10-00-07
          eep: A5-38-08
      - id: 00-00-00-10
        eep: M5-38-08
        name: ku_decklenlicht01_FSR14_4x
        sender:
          id: 00-10-00-10
          eep: A5-38-08
      - id: 00-00-00-11
        eep: M5-38-08
        name: ku_decklenlicht02_FSR14_4x
        sender:
          id: 00-10-00-11
          eep: A5-38-08
      - id: 00-00-00-08
        eep: A5-38-08
        name: ku_decklenlicht03_FUD14
        sender:
          id: 00-10-00-08
          eep: A5-38-08
      - id: 00-00-00-0F
        eep: M5-38-08
        name: ku_wandlicht01_FSR14_4x
        sender:
          id: 00-10-00-0F
          eep: A5-38-08
      - id: 00-00-00-19
        eep: M5-38-08
        name: wz_deckenlicht01_FSR14_4x
        sender:
          id: 00-10-00-19
          eep: A5-38-08
      - id: 00-00-00-18
        eep: M5-38-08
        name: wz_deckenlicht02_FSR14_4x
        sender:
          id: 00-10-00-18
          eep: A5-38-08
      - id: 00-00-00-06
        eep: A5-38-08
        name: wz_deckenlicht03_FUD14
        sender:
          id: 00-10-00-06
          eep: A5-38-08
      - id: 00-00-00-0B
        eep: M5-38-08
        name: ga_deckenlicht01_FSR14_4x
        sender:
          id: 00-10-00-0B
          eep: A5-38-08