But this part works in my setup. My openHAB switch items reflect the actual status of the lights.
What exactly do you mean by this?
When you add a new thing, it asks for an enocean Id.
This ID is (at least for my setup) the FAM14 BaseID + address in the bus.
E.g.
Fam14 base id FFDDC10
Fsr14 address is 25
16 (10 hex) + 25 = 41 (29 hex)
So the adress FFDDC29 is the enocean ID for the thing which reflects your fsr14 at address 25.
To control it I need to add the openHAB base id + sender ID in the same format via pct14 into the fsr14.
Now the bus knows which telegrams control the actuator and openHAB knows which telegrams reflect which thing.
I just used ā00000003ā (as ākelderā is the 2nd device of the FSR14 with addresses 2-5) as EnOceanId, and openHAB can read the status of that light. So that part is covered.
This is where it appears to go wrong. But I donāt understand why: I configured the bridge ting to have BaseID 0000B000 and in the ākelderā thing I configured Sender Id as 3. And I added 0000B003 with function 51 in PCT14, linked to āchannel 2ā of the FSR14.
Sounds correct to me, should work this way. Donāt know why it doesnāt.
Maybe it is the wired connection or some misconfiguration within the bus itself.
Best would be to speak or write with someone who is using the same wired setup like you.
Hey there,
I am sorry to maybe disappoint you, but I am no expert in this by any means 
so, I might be wrong.
As I wrote in my guide above, I only got this working with an fgw-14 usb. This might be an option for you, too. At least we know, it works this way and this add-on is not that expensive.
I have one other hint: As written above, YOU can set any BASE ID for your Gateway. At least with an fgw-14 it works like this. BUT I am pretty sure the Base ID must be within a certain range. I canāt even remember where I found this. 0000B000 works for me and I set this via the thing item in OH.
So maybe your Gateway (which is not a fgw-14) does require a base ID within any other range? But I am not sure about this.
I can remember one case, where I could see the status but was not able to switch the light via OH. In this case I messed up the EnOcean IDs. I used 00000010 for the 10th address in PCT 14. But 00000010 means ID 16, so I teached into a wrong channel and only saw its state. Very confusingā¦
So just double check, whether this may be your problem.
My gateway is an FGW14-USB. The FTS14EM is the module that receives signals from the physical switches (where FAM14 works with wireless switches, if I understand correctly?).
I get what you mean with the HEX confusion, but with 3 or 9 thatās not an issueā¦
@Beasty, @dirkdirk (and I say @flysl88 has a setup with an FTS14EM as well):
Iāve taken a closer look to the documentation of the FGW14-USB, and it might be possible thereās a wire missing going from Hold of the FGW14-USB to Hold of the FTS14KS (or FAM14). Is there such a wire with you?
Like I said, I donāt use a wired connection. So there canāt be wire for me.
My HOLD terminal is connected to all my FTS14EM like it should be.
But yes, it looks like you need this wire.
Ask your electrician, he should know it. If not, look for another one who knows what he is doing
Gateways FGW14 and FGW14-USB will be
connected to the terminal HOLD when they
connect a PC with a RS232 bus and/or up to
3 wireless receiver modules FEM with a subbus RS485.
FTS14EM, FTS14KEM, FTS14KS and FTS14TG
will be also connected to terminal Hold.
Yes, there is a wire and it is definitely important.
I added the wire between the two Hold sockets. Then the bridge in openHAB went offline. I rebooted the Linux machine on which openHAB runs.
And lo and behold: it works!!
Thanks for bearing with me, guys!
1 Like
Haha!! 
Very well!
Have fun
I want to make an āall offā switch (āZentral ausā), but Iām not sure how to do this. I canāt make a switch without an EnOceanId, and that doesnāt make sense for all lights.
So maybe the only solution is a group item, and then send all OFF signals via the EnOcean gateway, instead of one signal for all? (That doesnāt feel like the most logical solution thoughā¦)
Hey,
this is more of a general OH question.
How do you plan to use your OH? Via OH App, maybe Google Home or Apple Homekit?
There is no need to teach in a general switch. Ich just tell Siri to turn off all lights and she does.
You are right, within OH it would be a good idea to put all lights (and shutters ā¦) into one group and then send a command to this group.
Butā¦ If you wanna have a physical wall switch for all lights, you would need to teach one into all the actuators. Within PCT14 you can select āZentralkommandoā or something like this. Canāt remember exactly. Basically this means, this switch turns on/off all channels within an actuator.
Have fun 
Btw, I am pretty sure you can teach in different and multiple Items into the same actuator.
All you have to do is to choose another EnOcean ID and Sender ID and you are fine.
You will see this within PCT14, too. But these IDs wouldn`t match the channel IDs within PCT14, which is a good idea initially.
But as i saidā¦ Wouldnāt go this route scince itās very inflexible. OH can manage groups way better.
EDIT: My first post about EnOcean IDs was kinda wrong.
1 Like
That is indeed possible. The PCT14 software is pretty straightforward, once you get the hang of it.
Can you take me through this again? I can get the EnOceanId of the physical switch from PCT14, but which Sender Id would the thing have?
On the other hand, the thing (or linked item) wouldnāt send out any telegrams, so any random number might work, I supposeā¦?
This works a little different and has nothing to do with PCT14
Basically you teach in a physical wall switch into openhab.
Take a look at the back side of a switch. You will find an EnOcean ID there.
Add a new thing in OH ā EnOcean Binding ā Rocker Switch. Then you select your Gateway and type in the switch ID from the back side. Save it and connect a switch item to one of the channels (A or B for the double rocker switch types).
From now on, when you press up/down on your wall switch, the OH item should switch on/off, too. You can use this to trigger any rule you wish.
I just came home from 8 days of vacation, with @rlkoshakās Presence Simulation [4.0.0.0;4.9.9.9] active. But I noticed upon arrival the OH items didnāt record the input from the physical switches anymore. Also, in the CLI log, nothing appeared when I switched the physical switches. (The OH switches worked, and switched the lights as they should.)
After a reboot, all works again, but I assume something broke down along the way?
Are there any logs I can try to find? Iāve got 7 days of back-up if need beā¦
I can remember this happened to me, too. But without rlkoshaks whatever this is
I figured out, that some other faulty bindings and/or stupid rules i wrote lead to OH crashing or at least some parts of it not reacting.
Sorry, canĀ“t really help here.
Heās talking about Presence Simulation [4.0.0.0;4.9.9.9] but thatās just a rule template and wouldnāt have anything to do with the behavior. All it does is command Items to what ever state they were in seven days ago (for example) to simulate presence. I doubt it has anything to do with this.
For future reference: I managed to do this with a pushButton (āSimple Push Buttonā) item.
I linked it to a switch item, but for one case really needed it to work as relay. So I created a rule that the item switches itself off again immediately after being switched on. I donāt know whether there is a ānicerā way to do this, but it works.