Hi Thorsten (@ThAO),
PushButton bug is fixed in branch issue48. Would be fine if you could test the fix. Many thanks in advance.
Best regards
Daniel
Hi @fruggy83 ,
thanks for that. I also made an adjustement at my actuator for the RV-Time. It was set way to high, after i set it to a better matching value, i saw different kind of payloads in the responses. When i should test or provide something, just let me know.
Hi Frank @fnu
sorry I missed your message in all these other messages (I was wondering about your github Pehe EBI question 
). What EEPs do you use for your NodOn and Pehe actuators and which channels do you use?
1E means swicth all channels On/Off maybe the Peha does not accept this and also need 01 (channel 1). We should wait for the answer from the Peha support.
Best regards
Daniel
Hi Daniel (@fruggy83 ).
I have another question when I combine my FMS61NP with my physical FT55. Because I realized the FMS61NP as a classic device with toggle switch. Physically the two upper switches of the FT55 toggle UT1 and UT2 of the FMS61NP. It is working so far.
But sometimes (e.g. after reboot) it gets confused because I cannot get the right state of the FMS61NP. I always get NULL even when the light is On. As the result the switch in HABPanel is sometimes off even when the physical light is on or vice versa.
So is there a way to get the right status of FMS61NP, e.g. check is current is flowing?
I hope I explained it right. But is confusing.
Thanks, Tino
Hi Daniel (@fruggy83 ),
thanks for fixing the PushButton issue. I don’t have a test environment and the official version installed. Do you know if I can update with the jar file?
There is another thing: it might be helpful to be noted in the documentation that teach-in of virtual switches might require repeating mode to be on. This it at least the case for my Eltako devices.
With respect to the repeating option, it seems to be that the default is “no-repeating”. I would have expected “repeating on” as default.
Best regards,
Thorsten
Dont know if im right in this thread as I am a total openhab beginner.
Im running Openhab 2.4 with the Enocean 2.5 Binding on a Raspberry 3B+ with the USB300. Everything works fine except one contact from Nodon. After every Openhab restart its state is not shown any more until I delete the thing and re add it through discovery. It is still shown as online in the Paper UI but no state changes are received. It works perfectly before after beeing added as long as I dont have to restart the openhab service. Maybe somebody already knows a fix for this.
Best regards Johannes
Thanks that seems to be the same issue, just with a contact item. Not sure if any additional fixes would have to be made for the same issue with a contact not a dimmer. As I’m in way over my head with how to implement those changes from github myself I’ll guess I’ll just have to wait till the fix appears in a release. But thanks for the help 
Best regards Johannes
Hmm let me guess, you are using EEP D5_00_01? Here the channel comparison is still made by reference. I opened an issue.
1 Like
Yes you guessed right it’s EEP D5-00-01 single input. Thank you 
Hi @fruggy83
I‘m using your binding with 3 NodOn temperature/humidity sensors and one NodOn door/window sensor. Unfortunatelly the door/window sensor stopped working after update to OH 2.4.
I deleted all things and readded them… the door/windows sensor does not work:
When the sensor gets closed I see the following log entry for receivingState:
2019-01-11 13:30:32.162 [vent.ItemStateChangedEvent] - str_enocean_contact_rcvstate changed from Rssi 49, repeated 0 to Rssi 48, repeated 0
There’s no log entry when the contact gets opened. The contact state gets not changed at all.
Thanks for any help!
Hi @tailor,
just see the posts above yours. Contact EEP has currently a bug 
. Furthermore I would advice you to use the snapshot version of this binding. I will merge the issue branch in the evening.
Best regards
Daniel
Hi @flynux,
how did you defined the listeners? If you listen directly to the FMS61NP I would use the “rockerSwitch” SwitchMode. If you are listening to your FT55 you have to use the switchMode of the FT55.
The toggleMode is somehow problematical as it generates status updates relative to the current status. When you press your FT55, I just get the info to toggle the state of the item. So I have to retrieve the current status and inverse it. After a reboot the item states get set to UnDef. How should I handle the inversion of an UnDef state? In this case I just guess, that the the state should switch to ON. However if your light already was ON and you switch it after a reboot, the physical and the openHAB state get out of sync (physical: OFF, openHAB: ON). Therefore it is neccessary to persist all the state of your items which receive “relative” status updates. However even with persistance the system is not 100% perfect, as you always could switch your lights when openhab is down. I am currently working on some improvements to be able to use the persistance layer.
Best regards
Daniel
Hi Thorsten (@ThAO),
yes, you can update the jar. However deinstall the official version before you do the update to the snapshot.
With respect to the repeating option, it seems to be that the default is “no-repeating”. I would have expected “repeating on” as default.
The default value for the suppressRepeating parameter is set to false. Therefore repeating of your teach-in message should be possible. So do you set this parameter to ON when you do the teach-in? In this case you are suppressing the repeating.
Best regards
Daniel
Hi Christian (@tailor),
I just merged the fix of @dominikkv. Sorry for the troubles, I have a c# background where this comparison is legal.
Best regards
Daniel
I’m struggeling with getting dimmers to work. I have Eltako FUD61NPN dimmers, and are currently using FT55 Eltako switches to control them, and a Eltako Safe II server with GFVS.
I think I have set it up correctly in openhab (using 2.5-SNAPSHOT) and there is a blink on my USB300 so it seems that it is transmitting, but neither my actuator nor GFVS receives anything.
Thing configuration:
Thing centralCommand 00000050 “Dimmer” @ “TEST” [
senderIdOffset=50,
enoceanId=“aabbcc01”,
sendingEEPId=“A5_38_08_02”,
broadcastMessages=true,
receivingEEPId=“A5_38_08_02”,
suppressRepeating=false
]
Item:
Dimmer Dimmer_Dimmer “Dimmer” {
channel=“enocean:centralCommand:c7460c9e:00000050:dimmer”
}
Hello Helge,
did you define a listener channel in your thing? Based on my understanding it helps to define these as Type in the thing file.
e.g.:
Thing classicDevice cd01 "Enocean Licht Leseecke" @ "Esszimmer" [
senderIdOffset=100, //ID des Gerätes in der Regel wenn unbekant:, Bridge ID-EnoceanID
sendingEEPId="F6_02_02", //Typ wie gesendet wird, hintere Zahl steht für Schaltrichtung oben/unten
broadcastMessages=true,
receivingEEPId="F6_02_02", //Typ, wie empfangen wird, vordere Zahl für den Typ
suppressRepeating=false]
{
Type virtualSwitchA : virtualSwitchA [duration=300, switchMode="rockerSwitch"]
Type rockerswitchListenerSwitch : Listener1 "Schalter Leseecke links" [enoceanId="00XXXXB7", channel="channelB", switchMode="rockerSwitch"]
}
Afterwards you define the items as well with the before defined listener channel and you should see an update of your dimmer item. items file e.g.:
//Lampe Leseecke:
Switch Leseecke "Leseecke" <lightbulb> (Alle_Lichter_WZ) ["Lighting"] {
channel="enocean:classicDevice:FT1M2J09:cd01:virtualSwitchA",
channel="enocean:classicDevice:FT1M2J09:cd01:Listener1"
}
Hope this helps a bit.
Kindly,
Woogi
but a listener is used to receive the signal from other swithces. I’m having problems with sending signals from openhab to my dimmers.
Switches for on/off works, but not dimming.
Hello Helge,
What are you doing exactly? Pressing physical FT55 long to dim up e.g.? Or do you just wann to send signal to actuator? Did you already connect (I did that by teach in) your device (channel Dimmer) with the actuator?
Kindly
I’m trying to control/dim a FUD61NPN from OpenHab.
I attempted to activate teach in on the acutator (central on/off) with the signals sent from openhab, but no response.