Support for Eltako FUD14 dim actuator

[LutzDi]

Hi @mak-gitdev,

First of all, thank you for your add-on and your support for all of us who are using Enocean. I really appreciate your work!

I started my SmartHome career with Enocean equipment from Eltako and I have everything running with the FAM14 and the wibutler. But I'm pretty new in using HA and I have room for improvement concerning my knowledge in using and configuring HA. With your add-on and the support of the community, I got my FSR14 actuators running with virtual switches as well as with physical switches and the status in HA is as well correct. So far so good.

But I'm struggling with the integration of the FUD14 dim actuator. Please refer to the technical data from here > https://www.eltako.com/fileadmin/downloads/de/Gesamtkatalog/Eltako_Gesamtkatalog_KapT_low_res.pdf. Sorry, but this doc in German language I didn't find an English version. If I should translate some parts for you, let me know. You can find some details for the FUD14 on page T-14 where Eltako tells us that the FUD14 is similar to EEP A5-38-08. I tried some stuff in HA and your add-on but without success. What I actually have:

• The USB300 can talk to the bus, and switching of standard FSR14 actuators is running like a charm
• I've configured a virtual switch (on/off) in HA and told the FUD14 with PCT14 that its ID shall be accepted
• If the FUD14 is set to on with the physical switch and I set the virtual switch in HA e.g. to off the light is dimmed down
• So far it seems the HA can talk to the FUD14, but I can't steer the FUD14 as it should be, which means I can't switch it on or off completely as well as I can't set the dim level to a concrete percentage

I really would appreciate it if you please could support me with integration for the FUD14 because this is the last part of my puzzle to throw the wibutler out :). I would be happy to support you with whatever you need but please be kind to me and my low-level knowledge. I'm learning new things every day.

I'm looking forward to your positive answer, let me know whatever you need...

Cheers, have a great weekend...
Lutz

[mak-gitdev]

Hi @LutzDi,

As FUD14 is close to EEP A5-38-08 command 2, I think you can use that EEP instead of using a virtual switch.
Hence, what you should do is:

• Remove the virtual switch
• Declare your FUD14 like:

[my_FUD14]
address = 0x........
rorg = 0xA5
func = 0x38
type = 0x08

• Use the entity named light_com2.

At this point, for that to work, you will have to pair your USB300 to the FAM14.
At the moment, it is not possible to do it from the addon but you can use DolphinView for that.

I am working to add full support for Eltako devices, so pairing of Eltako devices will be available directly from the addon.
If you are not comfortable with the procedure above, may be you can just wait for the release with support for Eltako devices.

[LutzDi]

Hi @mak-gitdev,

many thx for your answer. I will give it a try of course. At the moment it's important to know that I can steer my Eltako stuff with HA to decide to stay with HA. At the moment it looks good.

For my better understanding and not to push you: Do you have a rough time estimate for the Eltako support of the add-on? If it's shortly I can decide only to test it now and wait for the new release... Thx for an eta...

cheers
Lutz

[LutzDi]

Ah, forgotten: Can you help me with some more details about the pairing process of the USB300 with FAM14? I am asking because what I didn't get is:

• The FUD14 has to accept a sender, which means that an ID has to be configured correctly with e.g. PCT14 > Question here: Which ID von HA should I use if I don't have a virtual switch? The ID of the USB300 couldn't be in my understanding because every FUD14 I have would react to a request and not only one.

Yes, I can pair the USB300 as a sensor but which ID has to be configured for a single FUD14? Sorry for my stupid question but I think I didn't get it completely at the moment...

Thx and have a great day...
L.

[mak-gitdev]

Hi @LutzDi ,

No need to use a specific sender id in this case. You can use the USB300 base id.

For virtual switches, you have to use a specific sender id for each virtual switch because the message emitted is broadcasted (destination address = 0xFFFFFFFF) so any devices can listen and react to it.

Using the proposed solution, you will end up with a point-to-point communication as the destination address in this case is the address of your FUD14.
Only your FUD14 will be able to react to the sent telegram, if paired with your USB300 of course.

[LutzDi]

@mak-gitdev, you made my day... Thx a lot, now it's much clearer for me... I will give it try...

Sorry for asking again a question: Do you have an idea how to pair the USB300 with my FAM14 to reach what you proposed? I searched many sources but I didn't find an idea how to achieve this. I can of course set the FAM14 in LRN mode, but how do I send an appropriate LRN telegram from the USB300 to FAM14?

Thx again for your help.

[mak-gitdev]

Hi @LutzDi,

You need to use DolphinView.

1. In DolphinView, select the COM port of your USB300
2. Click on the connect button

3. Go to the Telegram Transmit tab

4. Click on Add Operation
5. In the Send radio section, double-click on 4BS Telegram

6. Enter the pairing data into the Data entry. From the Eltako documentation, it is E0400D80 for FUD14.
7. Set the Base ID of your USB300 into the ID entry.
   ⚠️ Make sure to use the Base ID, not the chip ID (EURID), as the Base ID is portable from one USB300 to another. ⚠️
   To find the Base ID of your USB300, see Finding your EnOcean transceiver Base ID.
   For more details about EURID and Base ID, see the EURID specification.
8. Enter the address of your FUD14 in the DestinationID entry.
9. After setting your device in learning mode, click on Execute Selected

Pairing is now done.

[LutzDi]

Hi @mak-gitdev,

thx again for your effort. Some experiences want to mention in addition to your perfect description:

• The mentioned link about "Finding your EnOcean transceiver Base ID" is wrong, the correct one is https://github.com/mak-gitdev/HA_enoceanmqtt/wiki/Finding-your-EnOcean-transceiver-Base-ID
• It seems, that I wasn't successful with our description. The FUD14 didn't react to the learn request from the stick, the light kept blinking. I see the learn request in PCT14 and the BaseID of the stick is also submitted correctly
• What I have to do is that I need to preconfigure the BaseID of the USB300 with PCT14 for the FUD14 and then start the learn-process again as you mentioned. Then the lights on the FUD14 stopped blinking. I know this behavior also from the wibulter's learn process

So it seems that everything went right, but: No light is switched on. I see in the logs that the telegram is sent out by the stick, from the BaseID directly to the FUD14. But nothing happens. Here is the log entry from e2m for such a trial to switch the light on:

jfyI the IDs:

• USB300 > FF:xx:yy:00
• FUD14 > FF:xx:yy:97

2023-11-08 19:21:07,600 DEBUG: Received PUBLISH (d0, q0, r0, m0), 'enoceanmqtt/status/eg_esszimmer_decke/req', ...  (80 bytes)
2023-11-08 19:21:07,600 DEBUG: Got MQTT message: enoceanmqtt/status/eg_esszimmer_decke/req
2023-11-08 19:21:07,601 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: req={'COM': 2, 'EDIM': 100, 'RMP': 1, 'EDIMR': 0, 'STR': 0, 'SW': 1}
2023-11-08 19:21:07,601 DEBUG: Trigger message to: enoceanmqtt/status/eg_esszimmer_decke
2023-11-08 19:21:07,601 DEBUG: Retrieved command id from MQTT message: 0x2
2023-11-08 19:21:07,601 WARNING: Cannot find data description for shortcut CMD
2023-11-08 19:21:07,604 DEBUG: sensor data: {'COM': 2, 'EDIM': 100, 'RMP': 1, 'EDIMR': 0, 'STR': 0, 'SW': 1}
2023-11-08 19:21:07,607 INFO: sending: FF:xx:yy:00->FF:xx:yy:97 (-255 dBm):
0x01 ['0xa5', '0x2', '0x64', '0x1', '0x9', '0xff', '0xe2', '0x5c', '0x0', '0x0'] ['0x3', '0xff', '0xa1', '0x43', '0x97', '0xff', '0x0'] OrderedDict([('COM', {'description': 'Command ID', 'unit': '', 'value': 'Command ID 2', 'raw_value': 2}), ('EDIM', {'description': 'Dimming value (absolute [0...255] or relative [0...100])', 'unit': '%', 'value': 100.0, 'raw_value': 100}), ('RMP', {'description': 'Ramping time in seconds, 0 = no ramping, 1...255 = seconds to 100%', 'unit': 's', 'value': 1.0, 'raw_value': 1}), ('EDIMR', {'description': 'Dimming Range', 'unit': '', 'value': 'Absolute value', 'raw_value': 0}), ('STR', {'description': 'Store final value', 'unit': '', 'value': 'No', 'raw_value': 0}), ('SW', {'description': 'Switching command', 'unit': '', 'value': 'On', 'raw_value': 1})])
2023-11-08 19:21:07,607 DEBUG: Clearing data buffer.
2023-11-08 19:21:07,607 INFO: Sending packet
2023-11-08 19:21:07,608 DEBUG: FF:xx:yy:00->FF:xx:yy:97 (-255 dBm): 0x01 ['0xa5', '0x2', '0x64', '0x1', '0x9', '0xff', '0xe2', '0x5c', '0x0', '0x0'] ['0x3', '0xff', '0xa1', '0x43', '0x97', '0xff', '0x0'] OrderedDict([('COM', {'description': 'Command ID', 'unit': '', 'value': 'Command ID 2', 'raw_value': 2}), ('EDIM', {'description': 'Dimming value (absolute [0...255] or relative [0...100])', 'unit': '%', 'value': 100.0, 'raw_value': 100}), ('RMP', {'description': 'Ramping time in seconds, 0 = no ramping, 1...255 = seconds to 100%', 'unit': 's', 'value': 1.0, 'raw_value': 1}), ('EDIMR', {'description': 'Dimming Range', 'unit': '', 'value': 'Absolute value', 'raw_value': 0}), ('STR', {'description': 'Store final value', 'unit': '', 'value': 'No', 'raw_value': 0}), ('SW', {'description': 'Switching command', 'unit': '', 'value': 'On', 'raw_value': 1})])
2023-11-08 19:21:07,709 DEBUG: 0x02 ['0x0'] [] OrderedDict()
2023-11-08 19:21:07,709 INFO: got response packet: OK
2023-11-08 19:21:13,615 DEBUG: Sending PINGREQ
2023-11-08 19:21:13,616 DEBUG: Received PINGRESP

And this is the log for switching off with via HA:

2023-11-08 19:21:54,737 DEBUG: Received PUBLISH (d0, q0, r0, m0), 'enoceanmqtt/status/eg_esszimmer_decke/req', ...  (78 bytes)
2023-11-08 19:21:54,737 DEBUG: Got MQTT message: enoceanmqtt/status/eg_esszimmer_decke/req
2023-11-08 19:21:54,737 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: req={'COM': 2, 'EDIM': 0, 'RMP': 1, 'EDIMR': 0, 'STR': 0, 'SW': 0}
2023-11-08 19:21:54,737 DEBUG: Trigger message to: enoceanmqtt/status/eg_esszimmer_decke
2023-11-08 19:21:54,738 DEBUG: Retrieved command id from MQTT message: 0x2
2023-11-08 19:21:54,740 WARNING: Cannot find data description for shortcut CMD
2023-11-08 19:21:54,741 DEBUG: sensor data: {'COM': 2, 'EDIM': 0, 'RMP': 1, 'EDIMR': 0, 'STR': 0, 'SW': 0}
2023-11-08 19:21:54,744 INFO: sending: FF:xx:yy:00->FF:xx:yy:97 (-255 dBm): 0x01 ['0xa5', '0x2', '0x0', '0x1', '0x8', '0xff', '0xe2', '0x5c', '0x0', '0x0'] ['0x3', '0xff', '0xa1', '0x43', '0x97', '0xff', '0x0'] OrderedDict([('COM', {'description': 'Command ID', 'unit': '', 'value': 'Command ID 2', 'raw_value': 2}), ('EDIM', {'description': 'Dimming value (absolute [0...255] or relative [0...100])', 'unit': '%', 'value': 0.0, 'raw_value': 0}), ('RMP', {'description': 'Ramping time in seconds, 0 = no ramping, 1...255 = seconds to 100%', 'unit': 's', 'value': 1.0, 'raw_value': 1}), ('EDIMR', {'description': 'Dimming Range', 'unit': '', 'value': 'Absolute value', 'raw_value': 0}), ('STR', {'description': 'Store final value', 'unit': '', 'value': 'No', 'raw_value': 0}), ('SW', {'description': 'Switching command', 'unit': '', 'value': 'Off', 'raw_value': 0})])
2023-11-08 19:21:54,745 DEBUG: Clearing data buffer.
2023-11-08 19:21:54,798 INFO: Sending packet
2023-11-08 19:21:54,798 DEBUG: FF:xx:yy:00->FF:xx:yy:97 (-255 dBm): 0x01 ['0xa5', '0x2', '0x0', '0x1', '0x8', '0xff', '0xe2', '0x5c', '0x0', '0x0'] ['0x3', '0xff', '0xa1', '0x43', '0x97', '0xff', '0x0'] OrderedDict([('COM', {'description': 'Command ID', 'unit': '', 'value': 'Command ID 2', 'raw_value': 2}), ('EDIM', {'description': 'Dimming value (absolute [0...255] or relative [0...100])', 'unit': '%', 'value': 0.0, 'raw_value': 0}), ('RMP', {'description': 'Ramping time in seconds, 0 = no ramping, 1...255 = seconds to 100%', 'unit': 's', 'value': 1.0, 'raw_value': 1}), ('EDIMR', {'description': 'Dimming Range', 'unit': '', 'value': 'Absolute value', 'raw_value': 0}), ('STR', {'description': 'Store final value', 'unit': '', 'value': 'No', 'raw_value': 0}), ('SW', {'description': 'Switching command', 'unit': '', 'value': 'Off', 'raw_value': 0})])
2023-11-08 19:21:54,899 DEBUG: 0x02 ['0x0'] [] OrderedDict()
2023-11-08 19:21:54,900 INFO: got response packet: OK

And in addition the log entries from e2m if I use a physical switch:

ON:

2023-11-08 19:18:10,989 DEBUG: FE:FE:6B:55->FF:FF:FF:FF (-89 dBm): 0x01 ['0xf6', '0x30', '0xfe', '0xfe', '0x6b', '0x55', '0x30'] ['0x0', '0xff', '0xff', '0xff', '0xff', '0x59', '0x0'] OrderedDict()
2023-11-08 19:18:10,989 INFO: unknown sensor: FE:FE:6B:55
2023-11-08 19:18:11,340 DEBUG: FE:FE:6B:55->FF:FF:FF:FF (-89 dBm): 0x01 ['0xf6', '0x0', '0xfe', '0xfe', '0x6b', '0x55', '0x20'] ['0x0', '0xff', '0xff', '0xff', '0xff', '0x59', '0x0'] OrderedDict()
2023-11-08 19:18:11,341 INFO: unknown sensor: FE:FE:6B:55
2023-11-08 19:18:11,751 DEBUG: Sending PINGREQ
2023-11-08 19:18:11,752 DEBUG: Received PINGRESP
2023-11-08 19:18:19,750 DEBUG: FF:xx:yy:97->FF:FF:FF:FF (-85 dBm): 0x01 ['0xa5', '0x2', '0x5c', '0x0', '0x9', '0xff', '0xa1', '0x43', '0x97', '0x0'] ['0x0', '0xff', '0xff', '0xff', '0xff', '0x55', '0x0'] OrderedDict()
2023-11-08 19:18:19,750 DEBUG: Retrieved command id from packet: 0x2
2023-11-08 19:18:19,752 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: COM (Command ID)=Command ID 2 
2023-11-08 19:18:19,752 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: EDIM (Dimming value (absolute [0...255] or relative [0...100]))=92.0 %
2023-11-08 19:18:19,753 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: RMP (Ramping time in seconds, 0 = no ramping, 1...255 = seconds to 100%)=0.0 s
2023-11-08 19:18:19,753 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: EDIMR (Dimming Range)=Absolute value 
2023-11-08 19:18:19,753 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: STR (Store final value)=No 
2023-11-08 19:18:19,753 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: SW (Switching command)=On 
2023-11-08 19:18:19,753 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: Sent MQTT: {"_RSSI_": -85, "_DATE_": "2023-11-08T19:18:19.749866", "COM": 2, "EDIM": 92.0, "RMP": 0.0, "EDIMR": 0, "STR": 0, "SW": 1}
2023-11-08 19:18:19,753 DEBUG: Sending PUBLISH (d0, q0, r1, m119), 'b'enoceanmqtt/status/eg_esszimmer_decke'', ... (122 bytes)

OFF:

2023-11-08 19:19:11,821 DEBUG: Sending PINGREQ
2023-11-08 19:19:11,823 DEBUG: Received PINGRESP
2023-11-08 19:19:18,544 DEBUG: FF:xx:yy:97->FF:FF:FF:FF (-85 dBm): 0x01 ['0xa5', '0x2', '0x0', '0x0', '0x8', '0xff', '0xa1', '0x43', '0x97', '0x0'] ['0x0', '0xff', '0xff', '0xff', '0xff', '0x55', '0x0'] OrderedDict()
2023-11-08 19:19:18,545 DEBUG: Retrieved command id from packet: 0x2
2023-11-08 19:19:18,546 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: COM (Command ID)=Command ID 2 
2023-11-08 19:19:18,546 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: EDIM (Dimming value (absolute [0...255] or relative [0...100]))=0.0 %
2023-11-08 19:19:18,546 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: RMP (Ramping time in seconds, 0 = no ramping, 1...255 = seconds to 100%)=0.0 s
2023-11-08 19:19:18,547 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: EDIMR (Dimming Range)=Absolute value 
2023-11-08 19:19:18,547 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: STR (Store final value)=No 
2023-11-08 19:19:18,547 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: SW (Switching command)=Off 
2023-11-08 19:19:18,547 DEBUG: enoceanmqtt/status/eg_esszimmer_decke: Sent MQTT: {"_RSSI_": -85, "_DATE_": "2023-11-08T19:19:18.544240", "COM": 2, "EDIM": 0.0, "RMP": 0.0, "EDIMR": 0, "STR": 0, "SW": 0}
2023-11-08 19:19:18,548 DEBUG: Sending PUBLISH (d0, q0, r1, m120), 'b'enoceanmqtt/status/eg_esszimmer_decke'', ... (121 bytes)

The questions I have:

• Does this make sense for you?
• What is the best setup for testing the FUD14 with my setup in HA? Which switch etc.? I took a normal on/off switch. Is this the appropriate setup
• What is the best way to test the connection between USB300 and the FUD14 to eliminate as many sources of error as possible?

I don't want to steal your time but I'm not experienced enough to solve this on my own. I can support you with everything I have an can, let me just know...

Cheers Lutz

[mak-gitdev]

Hi @LutzDi

Anything new on this topic ?

[LutzDi]

Hi @mak-gitdev ,

thx for reaching out to me - and I am sorry for my late reply. No, I'm not ready with the tests but this is not because of technical issues. The daily work got me and I hadn't the time to play around with that. But I'm still willing to get it running... Just give me some more time, I truly will come back :).

Thx for your help and patience...
Lutz

[mak-gitdev]

Hi @LutzDi,

No problem at all 😉

[LutzDi]

Hi @mak-gitdev,

sorry for my late answer. As time goes by I decided to use another integration for Eltako and didn't work on the issue here anymore... I just want to let you know about, because for me the case can be closed. Thx a lot for your offer to help, I keep my fingers crossed that you will find a solution for the FUD14...

Thx and brgds, I wish u all the very best for the new year 2024...
Lutz

[mak-gitdev]

Hi @LutzDi,

Thanks for your feedback and your wishes.
You're right, with the current version, Eltako support is not that great.
But this is going to change as I have a working solution that is currently under test.

Which you the best as well for 2024 👍

[LutzDi]

Hi @mak-gitdev,

oh, that sounds interesting, because from the baseline idea I find your approach amazing... Can I offer u my help? What I have here and want to use is:

• RS485 wired devices
• Eltako FAM14
• Eltako FGW14USB
• Eltako FSR14-2x
• Eltako FSR14-4x
• Eltako FUD14
• Eltako FRW-ws
• Eltako FHF Hoppe SecuSignal window handle

I want to connect HA over the FGW14USB with the wired installation of the Eltako system and all that stuff is already installed and is running with HA with the other integration I mentioned. I'm not really experienced in developing such things, and I'm new to HA (for a few months), but if I can support u in testing I'm willing to do so... Just let me know...

Thx and have a great day...
Lutz

[Blinchik91]

@mak-gitdev @mak-gitdev,
Is the FUD14 still not integrated ?

@LutzDi
Hast du nun eine funktionierend Integration vom FUD14 hingekriegt? Das ist mir hier in diesem Thread nicht so ganz ersichtlich.

[LutzDi]

@Blinchik91 , yep, funktioniert im genannten Setup. Ich kann an-/ausschalten und Dimmen. Ich habe es so implementiert, dass Eltako autark laufen kann, also ohne HA mit Taster aber ohne Wibutler oder andere Zentralen, und zusätzlich alles über HA gesteuert werden kann... Das funktioniert auch mit dem FUD14.

Hast Du es schon mal versucht? Was fehlt Dir an Info? Ich frage, weil ich natürlich keine Anleitung geschrieben habe :). Und denk dran, ich nutze die Integration hier nicht mehr...

[Blinchik91]

ja, ich nutze aktuell diese Integration und wollte eigentlich auch dabei bleiben, weil es mit den normalen Switches wunderbar funktioniert, hab aber halt auch Dimmer da.
Ich bin noch ganz "frisch" mit HA unterwegs und das sind grad meine aller ersten versuche wo die Switches schonmal funktionieren und wollte mich schonmal schlau machen, ob das mit den FUD14 auch so einfach funktioniert.

Deswegen verstehe ich noch nicht so ganz was du gemacht hast und was das bedeutet, dass du ohne HA-Taster und ohne Zentrale arbeitest.

Bei mir sind die ganzen Relais im Stromkasten verbaut und die physischen Schalter Kommunizieren stink normal mit denen, also da ist sonst nix dazwischen außer der FAM14 und ich will jetzt einfach über HA alle zusätzlich steuern können mit meinem Raspberry und USB300.

Bzw. welche Integration verwendest du ?

[LutzDi]

Eigentlich ist Enocean, resp. Eltako angetreten, die Steuerung selbst zu erledigen. HA ist das kein Thema, mit dem die sich beschäftigen. Dabei ist es auch egal, ob Du Reiheneinbaugeräte wie Du (und ich) hast, oder ob Du Unterputzgeräte verbaust. Die setzen entweder auf einen komplett autarken Ansatz (erkläre ich Dir gleich), oder eben eine Zentral wie den Wibutler, der dann die Steuerung sowie die Szenen, Automationen etc. übernimmt. Wir in unserem Fall ersetzen den Wibutler als Zentrale durch HA.

Das, was ich meine, spielt sich auf der Ebene Eltako/Enocean ab. Eltako bietet Dir die Möglichkeit, durch die Software PCT14 oder aber auch durch die Programmierung des Aktors selbst, Aktoren und Sensoren/Schalter zu verheiraten. Du kannst also grundlegend ganz ohne Zentrale (sei es Wibutler oder HA) einem Aktor A sagen, er möge bitte schalten, wenn Taster B gedrückt wird. Das geht wie gesagt ganz ohne HA. Das habe ich für grundlegende Funktionen gemacht. Warum? Weil ich will, dass zumindest das Licht angeht, wenn HA nicht das tut, was es soll. Auch Paniksituationen/Feuer möchte ich nicht erleben, wenn ich zum Lichtanschalten erst das Handy zücken muss. Insofern haben ich grundlegend Aktoren und vor allem Taster direkt mit einander verknüpft. Das läuft alles außerhalb von HA mit den Tools von Eltako. Mann kan zwar auch so Szenen etc. programmieren, aber das überlasse ich dann doch HA.

Danach habe ich die HA-Integration aktiviert und zusätzlich weitere Intelligenz reingebracht. Das betrifft virtuelle Taster, um zusätzlich auch über HA schalten zu können, Szenen, Automationen und der ganze schöne Schlumpf, der mit HA geht. Natürlich kann ich auch sagen, dass in der Küche bitte das Licht angehen soll, wenn die Spülmaschine fertig ist - ob das Sinn macht, ist eine andere Frage :)... Aber z.B. kann ich HA sagen, es soll bei Aktivierung eines Bewegungssensors (nicht Enocean/Eltako) sagen, dass nachts das Licht im Bad bitte auf 10% gedimmt angeht. Dann stolpert der alte Mann nicht, wenn er aufs Klo muss :).

Ich hoffe, jetzt wird meine Strategie etwas klarer. Und ein Tipp noch: Egal welche Integration Du nutzt, dokumentiere gut, wer mit wem auf Enocean/Eltako-Ebene redet. Schreib Dir genau auf, welches Geräte (Aktor, Taster, etc.) welche Adresse hat und wo sie verbaut sind. Sonst suchst Du dich im Bedarfsfall dämlich und ich habe schon mal alle Taster von der Wann abgebaut, weil ich es mir nicht aufgeschrieben habe...

Wünsche gutes Gelingen...

LG
Lutz
P.S.: ich nutze die HA-Integration von grimmpp

[Blinchik91]

Das ist bereits bei mir der Fall :-) Ich brauche keine Zentrale, es wurde schon mit dem Haus fertig Konfiguriert bzw. mit den physischen Schaltern gebunden. Das ganze Haus läuft über EnOcean/Eltako (Licht, Dimmer, Steckdosen, Rollos, Thermostate)
Mit PCT14 hab ich auch schon hantiert.

Ich will es jetzt halt für mich noch zusätzlich automatisieren und steuerbar machen und kein Geld für überteuerte Zentralen wie der Wibutler ausgeben, zumal ich noch andere Smarthome Geräte haben und ich alles über HA steuern möchte. Deswegen der USB300 und Feuer.

Mir ging es jetzt hauptsächlich und die Integration von virtuellen Dimmschaltern, scheint aber hiermit ja nicht ganz oder bedingt zu klappen wie ich gelesen habe.
Auf grimmpp bin ich auch schon gestoßen und sieht vielversprechend aus und scheint ja zu funktionieren sonst hättest du es ja auch nicht verwendet :-) Danke für die Info, dann schau ich mir das mal als Nächstes an.

[ChristopheHD]

FUD14 is supported by this integration only if you use the Eltako branch.
mak-gitdev have disappear since 1 year and I have created a fork of this addon which integrates Eltako branch : https://github.com/ChristopheHD/HA_enoceanmqtt-addon