thanks for your improvement. Now my FTKE works as aspected
Unfortunatly, I have not installed the switch itself yet. As soon as I have done this, I will gladly send you some photos.
EDIT:
Now I have a similar problem with the ELTAKO FTK-rw :
The contact is recognized by the binding (D5-00 - Single input contact) but again: no action for the item.
First of all: thanks a lot for this work. I really apprechiate it. I had FHEM running and was never satified with it. So I am going to move to Openhab. I started to define my eltako FSR12 actors using the generic thing which worked fine. However I wonder if I can use files to define the things and items because I have a lot of them. Is this possible or can I somehow copy things and items?
glad to hear that your FTKE and FTK work now. However it should not be necessary to restart openhab. Maybe there is still another bug. Can you describe which steps you made to setup your FTK? Do you have âsimple item linkingâ activated?
glad to hear that you can control your FSR12 actors with this binding.
I could not find a lot of information about your FSR12 actor, but I think it should be nearly the same as my FSR14 (except for the bidirectional communication). So you should also be able to use a A5-38 central command thing for your actor (I know the wording of the thing types is not really clear). With this thing type you do not need a mapping file.
I also own a lot of eltako actors (light, dimmer and rollershutter, aprox 50 enocean things). It is definitely possible to define your things and items with files. I created an excel file for this. If you want I can share it with you.
No, âsimple item linkingâ is not enabled.
Iâve created the Things manually (as D5-00 - Single input contact) and also added an Item manually to my first contact.
My second contact, was linked to a new created Item by using the âCreate a new Itemâ function - it also worked
Now Iâm perfectly happy - everything works as it should.
Another improvement I could imagine if there will be a transceiver bridge in future for using enocean devices over a TCP / IP connection (as the rfxtcom-binding has)
Really great work - thanks a lot. I have been waiting for such a solution for a long time!
thanks for the hint. I will try the A5-38 at the weekend. And you are right, according to the eltako documentation the FSR12 and the FSR14 are using the same codes. For me it worked with 4BS 0000000F:on,4BS FFFF000F:off,4BS 18080D87:teach. I can send you the documentation where the old components are listed if you are interested. In the current documentation they are removed.
I would really appreciate to get your Excel. What is the way to exchange files?
It would be nice, if you could upload the documentation (pdf should be allowed), as I only have a newer one, which only includes the 14 series.
I started to create a wiki for this binding to document the supported devices. There you can find the excel.
As I am using a FAM14 which generates the EnoceanIds of my actuators, I can easily calculate them. For sensors or if you do not use a FAM, you have to set the thing Ids manually. If I setup all the formulas correctly, it should be no problem to copy them and create new lines for more devices. However I âoptimizedâ this sheet just for my devices.
If I find time, I try to add more devices to the wiki and sync the excel file with the table.
thanks for the link to the Excel. This definitely helps because I was not sure how the syntax looks like. Unfortunattely I cannot upload the old Eltako documentation here because I am a new member. I have done this as item under your github project.
actually I found my old mails from 2013 where I discussed the FSR12 behavior with somebody who owned and FSR14 like you. He also proposed to use the A5-38-08 which worked for him. But when I tried it, I was only able to switch the light on but not off. The same when I try it now using openhab. So A5-38 does not work for the FSR12 I think. On the other hand your codes 0100000F:on und FFFF000E:off does the job.
The reason why I send 0F instead of 0E for off is the following. I was using an TCM in repeater mode for sending the signals. However the TCM also repeats the signals it sends. This was not rejected in the fhem code and causes troubles for my rules because they are triggered twice. 0F I think indicates that the repeater should ignore the telegram.
Do you have any idea why A5-38 might not work otherwise I think I have to stick with the generic genric thing.
to be honest, I really do not have any idea why EEP A5-38 does not work with your FSR12. According to the docs the FSR12 and FSR14 use the exactly same messages/EEP.
Do you own the Eltako PCT14 software? You can read the config of your FAM12 and all your actuators and do the teach in/pairing with this tool. Maybe you should try this tool and look how your FSR12 is configured.
sorry this might be a dumb question, but why don´t you use the âF6-02 - Rocker Switchâ ? I have a pretty simular actuator from Opus -> CLICK and the F6-02 works just fine. I just had to teach in ON and OFF.
I must apologize but I have forgotten some important details on my setup. After setting it up five year ago I was so happy that everything was running that I never touched the system afterwards. But now looking at my notes I remember why I had the problems with the FSR12. I think the main reason is that I own FSR12-12V modules with one exception and not FSR12-4x12V. The FSR12-12V is not documented in the Eltako telegram definition. I have tried a lot things for the FSR12-12V. The only way to run it with a A5-38 is teaching in with a central on/off but then both channels are switched simultaneously.
Because I need a well defined on/off (not a toggle) I mimiced a FAH light sensor which eventually worked for me. In addition using a raw 4BS signal allows me to define that the signal is ignored by my two repeaters (but this is just a side note).
To be honest I donât want to change the settings, because everything is already teached in and running under FHEM. For OpenHab I bought a new Raspberry with an Enocean Pi where I set the base ID to the base ID of my running FHEM system. So for the migration from FHEM to OpenHab I donât have to teach in anything. I just have to use the same telegrams which saves a lot of time for me.
In any case I am happy to try alternative setting. So I will try the rocket switch. On the other hand I spent a lot of time to get the FSR12-12V running and it works for me with the generic 4BS command. Apart from this, I also donât like the idea to teach in all my components again. I hope you can understand this.
i not really sure that you need to teach in everything new. When you try the âRocker Switchâ just use the same enocean-ID. I also used fhem many years back and after switching to openhab almost all of my old teached in actuators worked right away.
currently I am running a TCM under FHEM in repeater mode and I have two additional repeater. The TCM is sending the commands to my FAM for which i donât need any repeater.
Sending command to the FAM also triggers some rules. If I remember correctly what happened under FHEM is that the command is send back from a reapeater to the TCM which agains repeats the signal and this triggers the rule a second time. I guess this can be solved resp. will not happen in OpenHab.
The second issue is that I donât want that the commands from the TCM/EnOceanPi are repeated at all because they can reach the FAM directly. E.g. when I switch on my outdoor lights in the evening I send 5 commands simutaneously. Repeating it (twice) results in 5x7=35 commands. Already now with 5 commands it happens from time to time that one of the commands âget lostâ. And since I donât have a bidirectional equipment and cannot check it.With the generic 4BS thing I can set a bit such that the command is ignored by the repeater. This is very convenient for me. I guess currently I cannot do this with the rocker switch.
But in any case I am happy with the generic thing. Everything works fine. What I like to do is to define the generic thing in a file which I didnât managed so far.
sorry for my late answer. Just a few points before I come to the generic thing config
FAH mimic: That was the missing information for me. Now your telegrams make sense to me (esp. the teach in telegram). So you switch you FSR by sending different lux values. Maybe this is the reason why your FSR does not react to the A5-38 profile, because it expect a different FAH telegram. If you find time, you could try to teach in a A5-38 profile into your FSR with a new id. I could imagine that it is not possible to overwrite a teached in profile for an id.
Did you changed the base id with fhem? This use case did not come to my mind, so I did not implemented it. Maybe I should support this function, too?
Repeater:
a. I filter out messages with an enocean id within the range of ids based on the base id of your TCM. So your repeated messages should not trigger any rule in openhab. This works for me, as I also have to use a repeater (FSSA-230V).
b. You can setup the repeater mode of your TCM with my binding, too.
c. There exists two repeater modes (level 1 and level 2). Level 2 mode just repeates repeated messages. Maybe you should review your current configuration to lower the repeated messages. However if everything works, I have not said anything (do not touch a running and (w) accepted system )
d. âDo not repeat messagesâ: I did not know that this is possible. Do you have some docs where this (or other hidden flags) is described? Maybe this is a function, I should support, too.
thanks a lot for the reply, especially for the generic thing example. I will try it tomorrow. Concerning the other items:
I will try to teach in a A5-38 but I not too optimistic. I can do the following with the FSR12-12V: Teach in an impulse switch per channel (this is not what I want because then I can only toggle), teach in a relay switch for each channel (also not what I want), teach in a central on/off switch which is what I want but not for both channel simultaneously.
Yes, I changed the base ID with FHEM. For this I had to install FHEM. Integrating this functionality in your code would be probably very helpful for many users.
a) great! In FHEM there was no filter. b) again very helpful !! d) Here I was wrong in my previous mail. I donât switch it off with the data bytes but with the status byte. For this I used an attribute in the switch definition. If the command should not be repeated I set the repeater count in the status byte to the highest value. The description of the status byte I found in the EEP documentation.
I also do not think that you will have success with A5-38 and your FSR. I looked over at the fhem project and they control the FSR just with a switch profile and do not use the gateway profile. So maybe the FSR12 really does not support the A5-38.
3.d) Very smart and nice solution. However if you need this functionality also in my binding, I have to extend the generic thing. Currently you are only able to set the data part but not the status of the messages.
