Created bridge in OPENHAB for the FAM14 through a Enocean USB dongle using the given FAM14 “BASEID”
Created in OPENHAB all the things for my actuators, using a unique “SenderID” for each and reference to an “EnoceanID” equal to the “BASEID” created in the previous step. I did this for rollershutters FSB14 and light actuators FSR14. A “sendingenoceanID” is generated and shown under the “Thing properties”.
Programmed in PTC14 all actuators (FSR14-LED & FSR-4x & FSB14) using the appropriate GFVS function option and completed the with the “sendingENoceanID” created in the previous step.
Added it all in my Model, using only the rollershutter point for the FSB14 and the swicth point for the FSR14. I did not add the contact.
All works fine, I can control everything now. Up, down, on, off,…
I did not use any teach-in function, as done for your real switches? I do this in an attempt to understand how it works myself.
Problem that remains:
I can not have the status of the OPENHAB switch changing when I push the real button in my house. Or in other words, there is no feed-back to the OPENHAB system coming from the ELTAKO system.
Extra info:
EEP for Receiving States for FSR14 is set to PTM200
EEP for Receiving States for FSB14 is set to FSB14 and PTM200
I configured them on several positions. Now it is on position 4, but I tried all positions by now.
I think you are right about the EnoceanID, but I can not figure out which is the one to use:
I tried 3 different ID’s, for which I added each time the Hex value of the address of output channel in the FSR14 or FSB14. Which is shown in the PCT14 tool.
I used the BASE-ID that OPENHAB gives me through the Enocean bridge thing. And disabled the RS485 bus option. (see red in the attachment, I blanked out the actual HEX value)
I created an ID myself by enabling the RS485 bus option, following the thread you mentioned. (see blue in the attachment, I blanked out the actual HEX value)
I used the one that the PCT14 tool give me under the FAM14 configuration page. And disabled the RS485 bus option.
extra info: I also enabled the debugging, checked the log files and enabled the streaming for SSE connection (not sure what that is). In neither one of them I can see ELTAKO messages coming through when I push any physical button.
I do can see under logs/openhab.txt the following lines:
The Enocean ID I entered in the Switch Thing is actually the same as the one calculated by the OPENHAB system and as indicated in PCT14 in the ID mapping page. See colored in red in the screenshot from OPENHAB and also in red in the screenshot from PCT14.
I did put the FAM14 switch on 2, as suggested by Markus in another post. And did reboot the Eltako system.
Remark and next steps
It is not perfect, it seems to miss sometimes the signal.
Next baby step is to get the roller shutters to give feed-back
Solution above only worked for a few lights, and was not stable at all. I think I found a solution, but will test a few days with all lights and shutters prior to posting. Sorry for claiming the victory too early.
pfff… I tried it for a week now, and it looks to be working.
I did the following:
I installed DolphinView on my Windows system. DolphinView is an app from Enocean to logs telegrams that are sent into the wireless PCT14 system. Because the app can not access a port, while the same port is accessed by OPENHAB, you might have disconnect the USB300 in the ENocean Bridge Thing from that port. I did that by simply entering temporarily a wrong COM port there. And then using the correct port in DolphinView. Or if OPENHAB doesn’t runs on a Windows system, you just unplug it from the system and plug it into your Windows system.
I linked the Enocean USB300 to the app and started logging. I did put the FAM14 BA switch in position 2 to ensure minimal messages to be sent out.
Then pushed a physical button to send out a message from the FAM14 into the PCT14 wireless system.
Then I checked the DolphinView app. You can see the ID in the logging pan (indicated in red), that is the one to remember, FYI - the blue is the switch status for a light switch, indicated by 50 or 70.
I might be wrong but I think you are recording the ID’s of your wall switches and not the actuators. This might work in your case but if someone has more than one wall switch controlling an actuator then you will have multiple ID’s and therefore issues. I tested this at my end and it appears to be the case where I have multiple switches (I’ve got a similar issue in synching and need to stop being lazy and track it down this week to enable better automations).
Hi there,
i didn´t have the time to read through all above, but i really think you are a little bamboozled with the IDs.
You want a feedback from your actuators like FSR14 → OpenHab, right? When you open your PCT14, look at the most left side where you see your adresses. Your first actuator does have the adress 3-4 as i see in the pic above. I am pretty sure here: This Actuator has the EnOcean Adress 00000003 and 00000004. One Adress per channel.
What you see in your chart where you marked with a red arrow are NOT the EnOcean IDs of your actuators! These are the IDs of the switches (and virtual switches from OH) you THEACHED INTO your actuators.
So, in order to get propper feedback, your first Thing in OH should have the following config (for an FSB):
Oh and by the way:
Don´t get caught while setting the correct IDs! These are calculated in HEX.
So you must use 00000003, 00000004… 00000009 and then 0000000A (which is 10 in HEX). Next up is 0000000B for adress 11.
Just to be sure If you get this wrong, you are receiving updates from wrong channels fo your actuators. Guess how i know…
I did not think along that path. Could well be, yes.
To sketch a bit my eltako installation. All my switches are wired to the ELTAKO FTS14EM input module. I have no wireless switches. And all “multiple” switch points share the same fysical input. That might well be the reason it works for me in a bita twisted way. I will give your suggestions a try.
Any news? I’m planning of installing FTS14EM in combination with FSR14. I wonder whether it’s possible to ‘read’ the wired switches (via FTS14EM) in openHAB…
I tried with the “easy” IDs. But I got confused as it did seem to work for some minutes and then it stopped working. Then it came back for some time and back to not working after a while.
After few days of issues, I reloaded the complex IDs, which I got from DolphinView. And it started working more stable again. Except for one light. It was one I did not need for any automation, so I did not dig any deeper into that one.
I do plan an expansion in few months, I would like to try to better figure this one out then.
So in summary:
Maybe I am over-killing it with this complex solution. And am I making a mistake on the easier and maybe better solution. But it works, so: “me for now = ”
Good luck… Let me know if you figured anything out.
I did read some of your other posts on using the FAM14. Your installation might be bit different.
My system has the buttons connected by wire to a few FTS14EM input modules which are connected through a bus with a few FSB14 and FSR14 actuators. The bus is done by a FAM14, which has besides the USB also wireless communication capabilities. I added an extra antenna for better reception. My system, that has openhab installed, is only wireless connected with the FAM14 through a USB300 dongle.
Works very good, only had to buy an antenna extension on the FAM14 to bring it outside the steel electro cabinet.
Both the dongle and the antenna are not so expensive. I bought also a remote IR receiver from eltako, so I can use aTV remote to switch things. That connects wireless to the FAM also.
If you run it on a NAS, within a container, you need to configure your ports correctly before deploying it. I lost few weeks there.
On windows it works out of the box. On Rpi, I do not know, but should be easy too.
”