I do not have a FUD61, but a TF61D. However, the approach could be similar. And my setup works. Not sure if it’s configured exactly the way it should be, but it behaves as expected.
In my understanding, the ID of an actor like the TF61D is the address where a command (e.g. by HA&USB300 or some switch) should be send to.
And the Sender ID of an actor like the TF61D is the address from where the status updates of the actor are sent from. i.e. this is the address your HA needs to know in order to display the status of your actor.
By connecting the USB300 to a PC and running DolphinView (free download after registration from https://www.enocean.com/en/support/download/) you can read all enocean telegrams. Hereby, you can see the address of some sender (e.g. some Eltako switch when pressing a button) or your USB300 (in the dropdown top left when connected).
At the same time, you can also see the Sender ID of an actor like the TF61D when the latter sends out status telegrams: you have to change the state of the actor (e.g. by clicking on an enocean switch that you had taught in with that actor before) and then wait for the actor to send a status telegram (note: you might have to enable status telegrams on your actor first! check the manual!)
In the case of my TF61D, both ID and Sender ID turned out to be the same, i.e. the one printed on the actor. I don’t know if this is the case with all the actors. But just play around with DolphinView and you’ll figure out.
Turn on status/confirmation telegrams on your TF61D (see manual)
Teach in your USB300 with the TF61D (i.e. you need to tell your TF61D to listen to the USB300 - note: to your USB300 connected to any device, does not have to be the device you’re running HA)
You need to send the teach-in telegram (from the TF61D manual I got 0xE0400D80 for rotary switches) from the USB300 to the TF61D (the latter being in teach-in mode)
I did this by connecting the USB300 to my PC and via DolphinView: in tab “Telegram Transmit” add operation “Send radio -> 4BS Telegram”, put in the above teach-in telegram as data, the USB300 address (from connection dropdown top left) as ID, and FF FF FF FF (for broadcast to any actor being in teach-in mode) or your actor address as DestinationID, then press “Execute…”
You might also be able to use the “GP Send” with “Send Teach In Telegram” to achieve the same.
I went via my PC and DolphinView because I do not know how to send specific telegrams through the USB300 when it is connected to my RPI (where I run HA).
Re-connect the USB300 with your device running HA. Done
So long story short:
configure actor as light (or whatever you want to control with that actor…) in HA
put actor in teach-mode, send teach-in telegram of actor (found in manual) from USB300, e.g. by connecting USB300 to PC and using DolphinView
Does this help?
Did anybody succeed with other actors than the TF61D?
This is great stuff! Can you explain just a tiny bit more about the teach in telegram?
I’m wondering about this part:
Is that something you put in the telegram, or is it a setting on the actuator itself?
The FUD61 has two rotary switches to put it in different teach-in modes, but I haven’t got it to work yet…
The next thing I wanted to try was indeed via Dolphin application. But then i readed your message. I’m working on a Mac and my server (Intel Nuc) is running Ubuntu, so first I had to install Parallels Desktop with Windows10.
@alexanderpett: I followed the steps from Danist. I read the FUD61 manual, but I couldn’t find anything about “Teach in” data in it. So I just tried to use the same data as he did. To my great surprise, that just worked.
Keep in mind: If you set the dimmer to LRN, you must send/execute the signal within 120 seconds (otherwise you have reactive the LRN mode).
I made a print screen with the values that I used:
As you can see i received four messages back after i send the request. In two of them i found a 4 bytes long number. I created just 2 dimmers in HA with the same device_id and with two different sender_ids. I found out that the second message (green outlined) contained the working sender_id.
I am now going to try to also configure my other FUD61 dimmers.
I’ve now added a second dimmer on the same way. It worked, but unfortunately both dimmers now respond to the same signal (when I switch on dimmer A, then dimmer B also switches on).
I guess this has somewhat to do with the Data i used for the “teach-in” telegram in DolphinView? I’ve tried it with a different value (E0400D90 instead if E0400D80) but the result is the same (both dimmers reacts on a single HA event). I gave them an unique device_id and sender_id in my config.
This is weird and I can’t tell since I only tested it with one dimmer.
As to my understanding the teach in telegrams are used to teach the dimmer to “listen” to the device they received the telegrams from, i.e. the USB300.
Thus if that USB300 sends out a signal, any dimmer previously thaught in should be “listening”. However, if you send a message from HA I would expect that message/signal to also include the target ID of the dimmer to be controlled. So even though two dimmers had been thaught in with the same USB300, they should only react when addressed via their respective ID.
On the other hand, I might be completely wrong with my “method” of teaching in. What if teaching actually requires ID of your (virtual) switch, i.e. the ID of the button in HA and not the ID of the USB300? And if this was the case, how do I know the ID of that switch? I guess it would still be possible to teach in via DolphinView, since you can set a sender ID different than the USB300. But how to find out the HA switch ID in the first place?
I believe my assumption in the last paragraph of my post above is turns out to be true and I know why my original way of teaching in results in always both dimmers reacting: When teaching in the USB300 with the dimmer, the dimmer learns to listen to specific sender. And without further configuration during the teach in process, that sender (i.e. sender ID) is always the base ID of the USB300. Therefore, we need to choose a different sender ID when teaching in. Apparently, this sender ID has to be in a certain range of the USB300 base ID.
I found a post on a symcon forum in German. The platform is different, but I believe the process is the same. I was not able to test yet, but it sounds promising.
if you were able to teach a button into IPS, then the USB300 will work But from now on it gets a bit more complicated. First you have to check if your 14 components FUD14, FSR14, FSB14 etc. have got a bus-ID, you can do this with the Eltako software PCT14, when you see your actuators then everything is OK. Next you have to create a corresponding instance (Eltako Dimmer) in IPS and assign a device ID to the instance.
The device ID can be freely assigned between 1 and 128 or 256, making the instance unique. I have thought of a small scheme and built an Excel sheet (see attachment) to keep the overview.
The Device ID is an extension for the Base ID of your USB300, because you want to be able to switch every single lamp separately and not all at once.
Next you have to teach the actuator accordingly, the ID to teach is now composed of the Base ID of the USB300 plus the Device ID of the instance. You have to add the values, e.g. Base ID is FFAB1080 and Device ID is 15 (corresponds to 0x0F) = FFAB108F, or Device ID 55 (0x37) → 0x80+0x37 = 0xB7 -->> FFAB10B7.
Teaching-in is either cumbersome using the rotary switches on the actuator or much easier with the PCT14:
start PCT14 and connect it to FAM14
in PCT14 “Recognize ID - switch on”
click on Teach in at the IPS instance, the ID then appears in PCT14 in the right block
simply drag the ID with the mouse to the corresponding position (ID assignment area) in an actuator
adapt the data (function, channel, etc.)
take over data and transfer them to the device
in PCT14 disconnect the connection to FAM14!!
test if the actuator can be controlled via IPS
Then there is the message ID, this is used to receive status telegrams from the actuators to keep the status of the instance up to date. e.g. you switch on your light with the wall switch, without message ID IPS would not notice this and in the visual display the light would still be off. With the message ID, IPS receives the status telegram from the actuator stating that the light is on and IPS can update the display.
The message ID in turn is composed of the base ID of the FAM14 and the bus address (see PCT14) of the actuator/channel.
Alternatively you can also try to search for the message ID, but I prefer to do this manually.
So, this sounds very complicated, but it is not. Once you understand this and have set up two instances, everything goes easy. And with the Excel table you can enter your complete actuator/sensor system and then simply copy/paste the IDs into IPS.
An actor only acts on telegrams coming from a switch the actor had been taught in to
if you have physical switchs, they all have different IDs, so no problem
The USB300 has a so-called Base ID. Without further config, this Base ID would be the one the actor is taught in with. And actually all actors, that’s why they would all react at the same time
However, the USB300 can also send telegrams with different Sender IDs. These “virtual” IDs are needed to distinguish the switches configured in HA
that sender ID can’t be an random number, it has to be the USB300’s Base ID plus a value between 1 and 126.
in order for only one specific actor to react to your HA switch, you need to teach in with that specific sender ID.
I do the teaching in with the USB300 connected to a PC and by using DolphinView.
Obtaining the sender ID:
connect the USB300 to your PC, start DolphinView, connect to USB300
watch out, in the dropdown it says “ID”. However, this is not the USB300 Base ID!
on the tab “Telegram Transmit” add operation “Send radio > 4BS telegram”
click on “Set ID > Base ID”. This sets the Base ID in the field ID.
Assigning an ID to your actor
Give your actor a number between 1 and 126, let’s say 1
Take the Base ID from above in hex format. convert to decimal, add 1, convert to hex (e.g. use Excel with formulas HEX2DEC and DEC2HEX)
This is the sender ID of the switch you will configure in HA
Teaching in
Continue from above (DolphinView, Tab “Telegram Transmit”)
** ID: The Sender ID from above
** Data: Teach in telegram (for my Eltako TF61D-230V this was E0400D80 according to the manual)
** Destination ID: Enocean ID of your actor
I could only verify this with one actor. But when I changed the Sender ID in the HA config, the actor would not react any longer. So obviously this should word with multiple actors. Could anybody confirm this?
And if this is all correct, this could be added to some documentation. however, I don’t know where and how to do so…
Hi,
I’m trying to teach in an Eltako TF61-L, basically just a switch-actor. I followed your guide for the TF61-D in hope it would work the same. In the end I was abled to switch the actor to on, but I am not able to switch it back off. Does anyone have any idea what causes this problem? Maybe another teach-in telegram? Anyone who has sorted it out already?
Hey Daniel, I tried that with an Eltako FSR14-4.
Teach in worked like you wrote (USB300, PC, DolphinView, E0400D80 as data) - and that was the ONLY way to teach in, I’ve tried so many ways.
But after all, I cannot control my FSR14 via HA. I can turn on the light - but I am not able to turn it off again.
Base IDs of my equipment:
FF-AA-E9-00 >> Eltako FAM14
FF-9C-D4-00 >> USB300
@ikea sorry, I can’t really help you with that part. I know that there are some people working on the enocean component.
Maybe you could create a custom component out of the current enocean component (probalby just the files for light) and manipulate it accordingly. However, I believe it’s rather tricky to translate the 4BS telegram into the raw data that has to be defined via code.
On the other hand, this sound weird anyway. Maybe it has something to do with the supported enocean profiles?
@danist Thanks for your reply.
I found out: to control ELTAKO devices, I’d need to send RPS Radio-Packets with coustumizable data.
But HA is only sending 4BS Telegrams, without any changable data (data = 0x00)
Could you help me to contact these people?
I really want to help to get ELTAKO integrated in HA.
Thx man.
Could you give me some hints ant links where to learn about creating costom components?
I really know, what I should change, but I am such a n00b in HA, I even did not make it to the code of the enocean-component…
I’m actually struggling with a custom component myself. I can’t get the custom Enocean component to work somebody implemented. So I’m not the best person to ask for support on that one…
I also try to get my EnOcean components to work.
I have not yet tested to send something to the actor but the switches are working.
I also had a Look at a Node Red Plugin MoBiUs for EnOcean there i found howe to set this up.
May be that you can find a hind there.
There is also a other Plugin for actors but Installation faild.
I guess there are some parameters missing.
I have also temprature sensors and her online one value (actual temp) and i Know Form a former FHEM installation there are More values in the telegram.
The issue is
If i teach the First message to the actuator it took this as a Main on
The second teach in also
So both messages have been teached in as a Main switch on
I used PCT14 to See this
Also via PCT 14 i changed one Message to off
And it worked
