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.
thanks for your message. I think the “no repeat” option is a nice to have. At the moment I got a bit stuck with the virtualRockerSwitch which I think I need to “toggle” the FSR12. By the way the FUD12 workes in the same way as your FUD14 exaples.
I am sorry I have to bother you again. To toggle my FSR12 I have to send a RPS x30 command. I have used the generic thing for it and set in the mapping file
I get the virtual rocker Switch running and it works for me. So I don’t need the generic thing. However, I would appreciate to understand why the generic RPS sends DB_0 to DB_3.
… however, currently it does not work for all of my components. Perhaps because the virtual rocker switch sends two signals “pressed” and “released”. In my FHEM setup I only have the “pressed” signal.
The release-signal was really important to get my actuators (similar to your FSR12) to work - so i guess you need them too. But i also have one rollershutter-actuator, which has a problem with how long the press-signal gets send. I already discussed it with Daniel and he is working on the binding to get the “Rocker Switch” more configurable. This will probably help you too.
I will definitely implement this as a new thing config parameter. However I some more important things on my to do list. So just be patient with this feature.
55000A0701EBF600000030FFC75D2500
That definitely wrong. Give me some time to fix it. RPS should only send DB_0! You did nothing wrong, it is a bug.
I get the virtual rocker Switch running and it works for me
Glad to hear this.
Perhaps because the virtual rocker switch sends two signals “pressed” and “released”
Too happy too soon Which componets do not work? My virtual rocker switch exactly simulates a physical rocker switch. All of my rocker switches send a “PRESSED” and when I release them a “RELEASED” message. However as @Casshern said, we assume that some components are sensible about the timing when the second “RELEASE” message is send. So I introduced a profile parameter “duration”, through which you can define after how many ms the “RELEASED” message is send. Maybe I should use negative numbers to suppress sending the “RELEASED” message.
Using the duration for the rocker switch will probably work for me (I have to test next weekend). I need it for a PEHA actor for a roller shutter. Currently I send an A0 signal to open it. The shutter stops automatically. Sending the “release” signal probably also stops the shutter. So if I set the duration to a sufficient large number it should work (I hope). I have to check but probably the actor works as a relay. In general for a relay it might be useful to have the option to set the “release” independently in case “release” should be triggered by a rule.
actuallly for my FSR12-12V the “release” signal does not matter because I teached in an impulse switch. Under FHEM I only send one signal (A0) and it works. However the “release” does not harm for my case (it is ignored) except that I prefer not to send signals which are not needed.
I you want to go low level and make your hands dirty, you can use rules to do what ever you want. Just link an String Item to your virtual rocker switch and react on another item. Then you could do the following in a rule
rule "Low Level VRS"
when CONDITION
then
STRING_ITEM_VRS.sendCommand("DIR1_PRESSED")
STRING_ITEM_VRS.sendCommand("DIR1_RELEASED")
end
If you do not need a release you just do not send the second command. The profile does nothing more, except that you can easily configure the time between the “Pressed” and “Released” message.
)
Which componets do not work? My virtual rocker switch exactly simulates a physical rocker switch. All of my rocker switches send a “PRESSED” and when I release them a “RELEASED” message. However as