Beginners guide for implementing Eltako FSR14, FSB14, FUD14 via FGW14

[Beasty (Sebastian)]

Hi guys,

after finally implementing the mentioned devices above, i feel the need to write a little guide to help others with their Eltako-Devices. For me personally this was a little painful journey, but after all i can now say, that i am very satisfied with the results. Big thanks to @dirkdirk and @Udo_Hartmann , who helped me out a lot! TY, mates. This guide is VERY basic. There might be better or faster ways to achieve this. However, this is for noobs like myself In the end, you need to do this process once and are good to go.

This is my first guide ever, so this is very much WIP and somebody might share their insights or correct wrong information. For this guide to work, you must have a working Eltako-Bus-Setup with a FAM14 at the beginning of the bus and an FGW14 USB. Also you must have a working Pi with OH and the Enocean-Plugin installed. This might work with other setups, but i never tested anything else. So, here we go:

1. Setting up your gateway (FGW14 USB):
   I strongly recommend a FGW14 USB as the bridge between the Eltako-System and OH. This device polls the status of all other devices periodically and sends them into OH with a very stable wired connection. This way all your switches stay in sync, even if you change the status from outsinde OH (i.e. wallswitch) and the switching in OH is very responsove. I know, there are other possibilities like the USB300-Stick or connecting your Pi directly to the FAM14. However, i never tested them. Maybe @dirkdirk can help here. Eltako recommends to place the FGW14 USB directly to the FAM14, however, it might work, even if you put the FGW at the end of the bus. You should read the manual of the FGW14 to connect it correctly.

In OH the first thing you need to do is to add the FGW14 as a bridge. Click Things → ±symbol → EnOcean Binding → Enocean Gateway. Activate the advanced settings. Here are the settings, that worked for me:
Path: /dev/ttyUSB0
ESP: ESP2
SMACK: ON
Gateway directly connected to RS485Bus: ON
BaseID: 0000B000 → This is very important later on! YOU choose the BaseID yourself. The FGW14 does not have something like a factory BaseID. This ID must be in a certain range. 0000B000 works good for me.

Click save and connect your PI to the FGW14 via USB. OH should show „online“ in the things overview. If not, try to restart you OH or even the Eltako BUS. Make sure you set your FAM14 to BA 4 and Auto 1. Your FGW14 must be in BA 6. Both devices now blink periodically which means, that the FGW polls the status of each Bus-Device.

2. Preparation for pairing
   Before you can start to pair your Eltakos to OH you need to do some research. You must know the Enocean-IDs of all of your devices. One way to find these is via the Eltako-Software PCT 14. You can download it from the website. You need a Windows PC to run this software. Open it and connect your PC to your FAM14 with a mini-USB cable. Click „connect“ in PCT14, it should turn green. On the right side click right on „Geräteliste“ and then „Geräteliste aktualisieren“. This takes some time, wait for it to complete! After this you should see a list of all your devices and their EnOcean adresses. I.e. my first device is an FSR14 4x with adress 1-4. You will need these adresses in the next step. If you want to see, whats written in the devices, you need to perform a scan. Its called „Gerätespeicher auslesen“ which takes some tome, too. Depends on how many devices you own.

3. Pairing FSR14s (4x and 2x are the same)
   In the things overview you click on „+“ again → EnOcean Device → Switching/Dimming actuator. Choose a meaningful name (i.e. Licht Haustür). These are the settings, that worked for me:
   Bridge: FGW14-Gateway
   EnOcean ID: 00000001 → VERY important: This value must be calculated in HEX-Values! Use an online Hex-Calculator to transform your EnOcean IDs (from PCT14) into HEX values. These values must have 8 digits. In short: If your EnOcean ID in PCT14 is i.e. „4“, you need to use 00000004 in OH. But when adress in PCT is „10“, you need to use 0000000A. 11 is 0000000B and so on. This step is VERY important, dont skip this
   Sender ID: 1 → Write these down, or you gonna mess up. I manually set these IDs. The next device gets the „2“ and so on. These Values are NOT calculated in HEX. So, your 10th device gets the EnOcean ID 0000000A but the Sender ID 10. Then 0000000B and Sender ID 11….
   EEP for sending commands: „switching“
   Send broadcast messanges: ON
   EEP for recieving states: PTM200
   Click on „save“ ofc.

Now go to the channel settings. Click „show advanced.“ At the bottom of the list you should find a teach in channel. Here you click on „add link to item“ → create new item → link.
After this click on the teach in channel again and you should have an I/O-Switch. You can swith this on and off with your mouse. However, this wont work just right now.
You need to teach this thing into you Eltako-System. This process cant be skipped.

You need to set you FSR (i.e. 4x) to the desired channel with the little knobs. You need a screwdriver for this. Be careful! Set the „Auto-Knob“ to channel 1, 2, 3 or 4 (i.e.), the upper knob to „0“ and the middle knob on LRN (learn). Now your FSR is ready to recieve the teach-in from OH. It should blink red slowly. Make sure, nobody in your home pushes any buttons, or you gonna mess up, as the FSR now teaches in wall-switches, too Go back to your teach-in channel in OH and set the switch from OFF to ON. It needs to be in the OFF position before you set your FSR to LRN. After switching it to ON, the little LED on your FSR should stop blinking.

Turn the knobs on your FSR to the default position. From top to bottom: 0, AUTO 1, AUTO.

If you wish you can review the result via PCT14. Do another „Gerätespeicher auslesen“. Your FSR should now have a new entry in „ID-Zuordnungsbereich“. The ID should be 0000B001. You see now: This Value is the Base-ID of the FGW14 + the EnOcean ID of your FSR14 channel 1. Maybe now you see, why you should write these values down. Its easy to mess up. PCT14 should show „Funktion 51“ Schaltzustand von GFVS. GFVS is Eltakos proprietary server which seems to work similar to the OH-Plugin

Now, in OH, you can remove the teach-in channel. You wont need it anymore.
Add another channel. A switch channel, to be precise ;). With this switch you can FINALLY controll your Eltako FSR14 on channel 1. Enjoy
You need to repeat this process for all channels of your FSRs. Make sure not to mess up the adresses and Sender IDs!!

A more advanced way is, to set all the IDs via PCT14, which should be alot faster. But you also need to know exactly, what you are doing. Which in my case is not the case

4. Pairing FSB14s for Rollershutters
   The FSB14 are a bit advanced, scince they are able to send an extended status like Rollershutter half way down i.E. However, the teachIn follows the same principle as with the FSR14s.
   First, add a new thing with “+”. Select the EnOcean-Binding ofc and then “Rollershutter Actuator” from the list. Here are the settings that worked for me:
   Bridge: FGW-14 Gateway
   EnOcean ID: like above you have to put in the Bus-ID from PCT14, calculated in HEX and with 8 digits: “000000xx”
   Sender ID: pick the next free one. Not HEX
   Polling interval: 10
   EEP: Eltako FSB14/61/71
   Send broadcast messenges: ON
   EEP for recieving: Eltako FSB14/61/71 AND PTM200 Rollershutter Status
   Press save

In the Channel-Section, activate"show advanced" and create a new teachIn channel.
Now, on the FSB14 you need to select the teachIn for the first channel (1. “Motor”) by turning the upper wheel to “180” → check the eltako manual, 180=Szenentaster und PC. PC means GFVS-Server in this case. The teachIn for the second channel/motor is 200.
Turn the middle wheel to LRN and the ASB should start to blink.
In OH, set the teachIn button from off to on and check the FSB14 stops blinking. Return all wheels to the standard position. The lower wheel you put on AUTO 1.

Now for the fun part:
In the channel section, add a new rollershutter item and link it to the channel. Press save.
Return to the channel section and click on your new channel. Now you should see the option “configure channel”. Click on it Here, under “shut time”, you have to put the time in seconds for your rollershutter moving from completely UP to completely DOWN. Use your regular wall-switches for that and measure it with a stop-watch. In my case the rollershutter needs 17 seconds.
On your FSB14 you then need to select this value with the “RV-Wheel” too. You can take the value close and above it (aufrunden ;). So in my case i set RV to 20.
Go to the “Items” menu and search for your new Rollershutter item. Select it. Under “Metadata” you add the option “auto-update false.”

You should be good to go and be able to open/close/stop your rollershutter.
If you want to send a certain value to this channel, the easy way ist via a rule. I created a new “dummy-Item” like “Rollos 90%”. When i activate it, the rollershutters recieve the command “90” via a rule and start moving down. After 90% of 17sec (math! they stop. You need to experiment a little with the values to get the result you are after. For this to work propperly, the rollershutters need to be full up or full down, when you start the rule.

ToDo:
TeachIn for FUD14, format the post ;(

So long!
Beasty

[pking (Patrick)]

Hi @Beasty,

first of all, thank you for sharing the guide and putting it together.
Have you also set up FSB14 successfully including the semantic model creation? It would be great see how it looks on your end.

Cheers

[Beasty (Sebastian)]

Yes, FSB14s are running very nicely. I have to continue the HowTo as soon, as I got the time
Hopefully tonight.

[ceddes]

Hey @Beasty, thanks so much for putting this together!
It works great!

I have my FAM14 set to BA2 and the FGW14 to 6, assuming this allows bidirectional communication. Would there be a way to get the buttons in OH in sync with what happens outside of OH?
ie: today if I press my wall switch, my FSR14 turns on that channel, but in OH, the light is still off. Do you know if there’s an easy way to get those switches in sync with what’s being sent over the bus?

Thanks for the great write-up!

[Beasty (Sebastian)]

Hi @ceddes
as written above, you must set the FAM14 to BA4 and AUTO1.
In my setup the syncing works great. However, the FGW14 polls the status periodically in circles, so sometimes the sync is not instant, but within a few secons.

Sometimes, after a restart of OH i dont get the sync function for some reason. Then i shut down the Eltakos and my Pi completely and start again. You might try this, too. But first… BA4

[ceddes]

Thanks for the suggestion @Beasty . Tried that, but no luck (including the rebooting, shutdown of the Eltako board and the entire Pi), unfortunately.

Possibly I’m having the wrong expectations? On the channel I had to change the profile to “Follow” instead of “Default” because else the switch wouldn’t just stay on. With “Follow” it stays nicely on, but whenever I make the FSR14 switch from an external sensor, OH doesn’t see it - despite now FAM14’s BA4 .

How I’m trying it is by looking at:

1. the channel itself and clicking on the linked actuator, it remains off
2. I added the switch to the overview page as an item and I can from that page nicely control the FSR14, but again it will not reflect the current state of the FSR14.

Is it possible you made some additional configuration changes elsewhere that are not documented in your write-up?

Thanks a lot!

[Beasty (Sebastian)]

@ceddes

the switch not staying „on“ makes me suspicious. Are you sure you got the numbers right? I mean the Enocean ID and sender ID numbers? Maybe you configured the thing/channel wrong and your FGW-14 sends an „i am off“ state to your channel. Does the actuator turn on the light, when you set the OH switch to on?

Here you can see a working config of my FGW-14:

UID: enocean:bridge:4632083bac
label: FGW-14 Gateway
thingTypeUID: enocean:bridge
configuration:
  rs485BaseId: 0000B000
  path: /dev/ttyUSB0
  rs485: true
  enableSmack: true
  espVersion: ESP2
  sendTeachOuts: false

And here a fully working thing with a switch channel:

UID: enocean:centralCommand:4632083bac:a8204e13e7
label: Licht Hauseingang
thingTypeUID: enocean:centralCommand
configuration:
  enoceanId: "00000001"
  senderIdOffset: 1
  suppressRepeating: false
  sendingEEPId: A5_38_08_01
  broadcastMessages: true
  receivingEEPId: F6_00_00
bridgeUID: enocean:bridge:4632083bac

Profiles are all on standard, as this has nothing to do with what you wanna achieve. Yet, i am not sure, what profiles are used for

[ceddes]

Hey @Beasty,

Yeah, I’m sure the IDs are all as expected. They properly turn on the lights, and I can see the OH “virtual switches” in PCT14. Your configs are identical to mine:

UID: enocean:centralCommand:ceaaeb7540:b98cab414b
label: Lantern Lights
thingTypeUID: enocean:centralCommand
configuration:
  enoceanId: "00000001"
  senderIdOffset: 1
  suppressRepeating: false
  sendingEEPId: A5_38_08_01
  broadcastMessages: true
  receivingEEPId: F6_00_00
bridgeUID: enocean:bridge:ceaaeb7540
location: Garden

and

UID: enocean:bridge:ceaaeb7540
label: EnOcean Gateway
thingTypeUID: enocean:bridge
configuration:
  rs485BaseId: 0000B000
  path: /dev/ttyUSB0
  rs485: true
  enableSmack: true
  espVersion: ESP2
  sendTeachOuts: false

I even took the same BaseId to make sure there’s 0 differences

I guess the question is, the external switch/sensor you are using, does it have its own ID and is it recognized by OH? Because I’m switching ‘externally’ using an FTS14-EM (which has conventional pulse switches cabled to it). FTS14-EMs don’t show up in PCT14, you just have to know the ID each port will send, or… similar to your instructions, just put the actor into learning mode, and let it catch it. Maybe it just doesn’t recognize those messages and ignores them.

FWIW, I’m running openHAB 3.4.0 on a RPI3.

[mdillman (Markus Dillmann)]

My guess is that your enoceanId is wrong and does not match the bus-id of your FSR14 as seen in PCT14.

You could also switch the binding to DEBUG and post a log-snippet here. This would show if anything is received and if the IDs are correct.

[ceddes]

Hi @mdillman !

That may be actually a good tip. My FSR14 is occupying addresses 1 to 4. I assumed channel 1 is on address 1, and 2, 3, and 4, on their respective channel in the same order.

Where in PCT14 can you actually see the individual addresses per channel? I can only see in the left pane that uses Addr 1 - 4, and on each channel I can see the ID mapping range where I see my inputs and the OpenHAB virtual switches.

Thanks!

Cedric

[Beasty (Sebastian)]

I think you got this wrong.
Letz try to get the first one working. Maybe you should remove all OH-Switches from the FSR you are trying to programm. Just to be sure…

Your first FSR has the adresses 1-4, right? So the first adress (channel if you want) has the ENOCEAN ID 00000001. Put 1 as sender ID. Choose the right EEPs (switching for sending commands and PTM200 für recieving commands). The Bridge is the FGW-14 ofc.

Under channels, click on “advanced” and add a teach in channel. You should remove this one later. Then proceed as written above in my guide (Teach-In-Process). In short: Set the big knob to channel 1, the middle knob to “learn”, watch the LED blinking. Activate the Teach -In in OH once, the LED should stop blinking. Put the knobs back into default position! Or it wont work (guess, how i know

Check if it works Just to be sure you get things right: If you have a wallswitch, which switches the SAME channel as above, OH doesn´t care for the ID of that wallswitch. OH just gets the update, that channel 1 activated. Thats why the IDs are damn important.

Speaking of IDs: Did you understand this HEX-Stuff? Basically its Enocean ID 00000001, 00000002 … for the first NINE IDs. After this (the 10th) gets the 0000000A and NOT the 00000010!! If you mess this up, this would explain your Problem. You can then switch i.E. the ID 00000010 but won´t recieve the correct status-updates. Guess how i know… i messed up really hard
Get the numbers right. I.e. 0000000A gets the sender ID 10. 0000000B gets the sender ID 11 and so on… Use a HEX calculator and teach in from the beginning.

EDIT: If you look into PCT14 after the teach-in, you should see an 0000B001 in the “ID-Zuordnungsbereich.” Thats because the Base ID and the Enocean ID gettig calculated (summed) in HEX.

[ceddes]

Hi @Beasty ,

I really didn’t get that wrong…trust me And yes, I do understand the difference between hex and decimal

You’re confirming my suspicion… My first FSR has indeed address range 1 - 4 so as you confirm, my logic is that the first channel has 00000001 and the last one 00000004. The teach-in worked fine, else I wouldn’t see the ID of my OH invented IDs (0000B00X) taught-in in PCT14, and my FSR wouldn’t respond to the switch changes in OH!

All that works fine, it’s only the opposite direction that doesn’t work. Turning on the FSR14 from outside OH, and seeing it reflected inside OH.

[Beasty (Sebastian)]

Send a screenshot of your PCT14 with the ID-Zuordnungsbreich of that first FSR14.
In case you used 0000B000 as the BaseID, for your first device you should see:
ID (Hex): 0000B001
Function: 51
Taste: 0
Kanal: 00000001
Quelle: Schaltzustand nach GFVS

Does the switch item still turn itself off after switching it ON inside OH?

[mdillman (Markus Dillmann)]

Also remember:

• to control an actuator (e.g. FSR14) from OH, only the BaseID plus the senderIdOffset (in Hex) are relevant. This resulting ID is paired into the actuator. Everyting that gets send to the bus is a broadcast, and an actuator acts if the sender matches one of the paired IDs
• to get status updates, only the enoceanID is taken into account. So the gateway forwards the telegrams from all actuators to OH, and OH matches the proper thing based on its configured enoceanID.

To get deeper I again suggest you activate logging of the enocean-binding so we can see if status messages are reaching OH at all and what IDs are sent.

[ceddes]

@Beasty , here you go:

When the switch in OH is OFF, and I turn the light on externally, and then turn the light on in OH, it doesn’t go OFF. It says ON. When it’s then on in OH, and I click it again to go OFF, it turns OFF as expected.

@mdillman I have turned on the logs to debug and it was very chatty, even though nothing was happening at all. Is that normal? That’s actually the biggest differentiator for me between FAM’s BA2 and BA4. BA2 only shows activity on the FGW14-USB when something happens. BA4 shows non-stop traffic.

Anyway, here you can see some messages when I externally turned on the light (via ID 00001006, which is +E6 on my first FTS14EM)

e[0m08:06:52.141 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - e[36mRADIO_ERP1 with RORG RPS for 00001006 payload F6000000100620 receivede[m
e[0m08:06:52.192 [DEBUG] [internal.messages.ESP2PacketConverter] - e[36mReceived ESP2 message telegram: 8B05700000000000000230e[m
e[0m08:06:52.196 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - e[36mConverted to: RADIO_ERP1 with RORG RPS for 00000002e[m
e[0m08:06:52.199 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - e[36mRADIO_ERP1 with RORG RPS for 00000002 payload F6700000000230 receivede[m
e[0m08:06:52.203 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - e[36mESP Packet payload F6700000000230 for 00000002 receivede[m
e[0m08:06:52.256 [DEBUG] [internal.messages.ESP2PacketConverter] - e[36mReceived ESP2 radio telegram: 0B05500000000000100630e[m
e[0m08:06:52.260 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - e[36mConverted to: RADIO_ERP1 with RORG RPS for 00001006e[m
e[0m08:06:52.265 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - e[36mRADIO_ERP1 with RORG RPS for 00001006 payload F6500000100630 receivede[m
e[0m08:06:52.319 [DEBUG] [internal.messages.ESP2PacketConverter] - e[36mReceived ESP2 message telegram: 8B05500000000000000330e[m
e[0m08:06:52.324 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - e[36mConverted to: RADIO_ERP1 with RORG RPS for 00000003e[m
e[0m08:06:52.329 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - e[36mRADIO_ERP1 with RORG RPS for 00000003 payload F6500000000330 receivede[m
e[0m08:06:52.368 [DEBUG] [internal.messages.ESP2PacketConverter] - e[36mReceived ESP2 radio telegram: 0B05000000000000100620e[m
e[0m08:06:52.372 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - e[36mConverted to: RADIO_ERP1 with RORG RPS for 00001006e[m
e[0m08:06:52.377 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - e[36mRADIO_ERP1 with RORG RPS for 00001006 payload F6000000100620 receivede[m
e[0m08:06:52.432 [DEBUG] [internal.messages.ESP2PacketConverter] - e[36mReceived ESP2 message telegram: 8B05500000000000000430e[m
e[0m08:06:52.437 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - e[36mConverted to: RADIO_ERP1 with RORG RPS for 00000004e[m
e[0m08:06:52.441 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - e[36mRADIO_ERP1 with RORG RPS for 00000004 payload F6500000000430 receivede[m
e[0m08:06:52.495 [DEBUG] [internal.messages.ESP2PacketConverter] - e[36mReceived ESP2 message telegram: 8B05500000000000000130e[m
e[0m08:06:52.500 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - e[36mConverted to: RADIO_ERP1 with RORG RPS for 00000001e[m
e[0m08:06:52.506 [DEBUG] [ternal.transceiver.EnOceanTransceiver] - e[36mRADIO_ERP1 with RORG RPS for 00000001 payload F6500000000130 receivede[m
e[0m08:06:52.511 [DEBUG] [ernal.handler.EnOceanBaseThingHandler] - e[36mESP Packet payload F6500000000130 for 00000001 receivede[m
e[0m08:06:52.543 [DEBUG] [internal.messages.ESP2PacketConverter] - e[36mReceived ESP2 message telegram: 8B05500000000000000230e[m

Thanks!

[dirkdirk (Dirk)]

@ceddes
Have you still set your channel profile to follow?
There is no need for that, the default profile works fine. Maybe this is your problem.

[ceddes]

If I don’t set it to follow, then in OH, when I press the channel button to be “ON” it immediately switches back to “OFF”. No idea why, but when I use follow, it behaves as a switch that stays on.

[dirkdirk (Dirk)]

This sounds like your setup is messed up at some point.
I never changed the channel profile for any enocean device item. So if it doesn’t work for you with the default setting, there must be something wrong with your ID’s and or acknowledgement telegrams.

Best would be to delete your thing and also clear the pct14 settings. Then you should write your calculated openhab enoceanbridge + fsr14 id into pct14 AND your eltako gateway + fsr id into openhab.

Dumb question, but is there a fts14fa in your bus at all?

[mdillman (Markus Dillmann)]

I’d recommend a systematic approach for a test/debug:

• remove the profile
• set the FAM to BA2 to only get confirmation messages and reduce the noise
• activate “fresh” logging
• do an on/off cycle with FTS14EM for the first channel of the FSR14
• do an on/off cycle via openHAB
• post the log

I have my FAM14 set at BA2 (only confirmations) and no profiles. Only difference is I use an USB300. I do have wired and wireless actuators and I get feedback from all devices irregardless if controlled via OH or operated with local switches.

[Beasty (Sebastian)]

I think i can solve your problem

As i expected, you messed something up in PCT14. As you can see, your Lanterns have the Enocean ID 0000B001. You are using the first Channel of the FSR14. But look into the table, there i see channel 00000010. This is corresponding to Channel 2 (!) of your FSR14. I know, its confusing…

For explanation:
00000001 is the first relais of your FSR14 (here your Lanterns are wired)
00000010 is the second (Your Poles)
00000100 is the third (Spots Front)
00001000 is the forth (Spots back)

Basically, your OH gets a state of relais #2 but thinks its item #1 (Lanterns). Thats why you are bamboozled

Change ID 0000B001 Channel 00000010 to ID 0000B001 Channel 00000001 and i BET it will work.

Edit: BA2 you only need for commands via radio signals (USB300). BA4 works better with a wired connection with FGW14 like we use. The “non stop activity” is the FGW14 polling statuses in circles. Which is exactly what we want

Edit 2: I wonder how this happened. Maybe you teached in twice on both channels by accident?
See below how it should look like for all the channels of your first FSR14.