Hi @fruggy83,
it is a switch with a single pushbutton. And the PEHA 455 FU-S2 which sends the same signal is also a single channel switch. From my point of view it makes sense that they don’t send any right/left and up/down information.
Best regards,
Thorsten
Hi @fruggy83,
may I bother you again. I am a bit confused. If I see it correctly the virtualRockSwitch sends 0x30 for ON and 0x10 for OFF. Shouldn’t it be the other way around ON=AI=0x10, OFF=A0=0x30?
Would this also explain the other problem I have with the normal rocker switch?
Best regards,
Thorsten
@fruggy83
Hi Daniel,
works perfectly with my NodOn 2 channel module.
would there be any way to include a possibility to set the parameters like: Switch Type, repeater mode (on/off), … ?
regards
Matt
Daniel,
Which openhab version do you use 2.2 or the nightly build 2.3?<
V 2.2
How do you install the binding? Through IoT market or manually from github?<
From Github
If you used the github way, from which branch did you downloaded the binding?<
The support for your NodOn 2-2-01 i really fresh and not yet tested, as I do not own these in wall switches. So you are the first one who owns such a device I know.<
Same procedure with a NodOn 2-2-00!
If you want, you can send me a PM to solve this problem (I speak german).<
I know it Daniel, do you have a Bad and not a Bathroom 
Lets try it in english!
Best regards
Oliver
Hi Oliver (@ohart),
as I wanted to use some new (not backward compatible) features of the upcoming openhab 2.3 version, I had to create a new branch OH2.3_Mods. The EEP D2-01-0F used by your NodOn in wall switch is implemented in this new branch. This is also the case for the two channel in wall swicth NodOn 2-2-00.
As I am to lazy to merge these changes back to the openhab 2.2 branch, you have to options now:
If you choose the first option you could ask @Matt77 for help, as he successfully runs a NodOn 2-2-00 with this binding (the procedure for NodOn 2-2-01 should be the same).
Best regards
Daniel
Hi Matt (@Matt77),
glad to hear that you in wall switch works now with this binding. Time to order one for me 
.
Is it really so small that it fits into an outlet socket (Schalterdose)?
would there be any way to include a possibility to set the parameters like: Switch Type, repeater mode (on/off), … ?
I am working on this. However I have to contact the NodOn support as the repeater options are not officially part of the EEP D2-01. So I think NodOn uses a special EEP for this case. The documentation for the switch type, auto off and delayed radio off is also not clear to me.
Just wait a few days.
Best regards
Daniel
Hi Thorsten (@ThAO)
I just updated the binding. The new version supports switch/push buttons (EEP F6-01-01). This is exactly the the thing type of your FFT55Q. I have not implemented a profile yet. So you have to implement the link to a switch item with a rule by yourself. The things emits PRESSED and RELEASED events.
Shouldn’t it be the other way around ON=AI=0x10, OFF=A0=0x30
My virtual rocker switches use EEP F6-02-01. So this way should be correct. @Casshern also requested the EEP F6-02-02 for the virtual rocker switches. With the new version you can define which EEP your virtual rocker switch should use (sendingEEPId can be set to F6_02_01_Virtual or F6_02_02_Virtual).
Best regards
Daniel
Hi Daniel (@fruggy83),
glad to hear that you in wall switch works now with this binding. Time to order one for me
Is it really so small that it fits into an outlet socket (Schalterdose)?
its small, i would say similar to the Fibaro Z-Wave modules. if its fitting into the outlet/wall socked depends quite a bit which was used, if i remember right in Germany you have 60 or 90mm depth sockets (i’m already to long out of Germany to remember exactly) but it should work.
I am working on this. However I have to contact the NodOn support as the repeater options are not officially part of the EEP D2-01. So I think NodOn uses a special EEP for this case. The documentation for the switch type, auto off and delayed radio off is also not clear to me.
Just wait a few days.
your right, the docs are not the best if its coming to those settings.
the only thing i found in regards to enable the repeater function was that the Dolphin View software needs to be used to send a certain telegram to the module.
thanks again for looking into this.
regards
Matt
Hi Daniel (@fruggy83),
I really highly appreciate your work and support. Thanks again. I will try the EEP F6-01-01 as soon as possibel.
But I am still puzzled about the F6-02-01. In the EEP documentation it says
AI (F6-02-01: switch on / dim down / close, F6-02-02: switch on / dim up / open) = Enum 0 (DB_07..DB_05) + pressed 1 (DB_04) = 0x10
A0 (F6-02-01: switch off / dim up / open, F6-02-02: switch on / dim down / close) = Enum 1 (DB_07..DB_05) + pressed 1 (DB_04) = 0x30
BI (as for AI) = Enum 2 (DB_07..DB_05) + pressed 1 (DB_04) = 0x50
B0 (as for A0) = Enum 3 (DB_07..DB_05) + pressed 1 (DB_04) = 0x70
However, when I send an “ON” I see 0x30 and when I send an “OFF” I get 0x10 for F6-02-01. I have also looked in your code and as far as I can see you assigne ON to A0 for F6-02-01, isn’t it. As far as I can see the difference between F6-02-01 and F6-02-02 is the interpretation for dimming and shutter but not for switching on/off light. An the interpretation for ON/OFF should be in both cases as now implemented for F6-02-02. Does this make sense?
One other question: When I use a Dimmer (FUD14) the light does not switch completely off when pushing the slider to zero. Do you have any idea why this could be?
Best regards,
Thorsten
Hi Thorsten (@ThAO),
sorry for my late answer. Your findings are absolutely right. In my first implementation I did not differentiate between these two EEPs as I could not image how to support dimming up/down back in these days. With the intoduction of openhab profiles dimming could be implemented very easily too. So I seperated these two EEPs to support the different behaviours for dim up/down. However my implementation was not consistent to the EEP documentation as I wanted to support the case where on/off is switched.
I also think that was a bad idea now. The interpretation should be fully done (and configured) in the profile.
Regarding FUD14
I setup my FUD14 to switch off when I dim to a value lower than 5% (or maybe 10%). My LEDs got flickering in this case. Could you please post the command which is send when you set the slider to 0%?
Best regards
Daniel
Hi Daniel (@fruggy83 ),
the problem with the FUD14 is that using Classic UI it sends A502000008 for 0% which is fine. However using the Basic UI it sends A502000009 (the “ON” bit is set).
One other question. Setting the slider to 100% generates A502640009. I would expect to see A502FF0009.
Best regards,
Thorsten
Hi Thorsten (@ThAO)
thanks a lot for your hint regarding the GUIs. I think I should always react to a value of 0% with an OFF command (4th byte set to 0x08).
I implemented the dimming profile according to the eltako docs. They use a relative value. Therefore you have to send a value of 0x64 for 100%. However as the enocean doc states that you can send an absolute OR a relative value but do not need to specify which one is send, I should implement another config parameter to specify how the value should be transformed (or introduce a manufacturer specific dimming profile).
@All: Does anybody use this dimming profile without an eltako device (FUD14)?
Best regards
Daniel
Hi @fruggy83 ,
first of all thanks for your work on this binding, I read this post with large interest because I currently set up my house with some Eltako series 14 components. Now I start planning how to connect my Raspberry to the Eltako components.
I saw your post on the 2nd of May that you successfully used the FAM14 to send and receive messages. Now I’m wondering if you already had time to release those changes and if it is now possible to use the FAM14 directly for interaction with Openhab without an USB300.
Did you also observe issues regarding message loss, like mentioned by the guys from the FHEM forum? So do you also suggest using an USB300 instead of the FAM14?
Best Regards,
Jochen
@fruggy83 @Matt77
Sorry for my late answer.
Regarding this topic: It is an issue that I also face.
BUT it has nothing to do with the timings that I set in the Dimmer Profile.
The issue here is not that dimming only starts after half a second. If i reduced this setting then at some point you would get accidental dimming instead of switching. The issue is that the time from pressing the button to actually receiving the signal is slow.
The 200ms interval for sending messages is a decent value. 5 times per second the timming occurs, any higher frequency would just spam messages and not really help with the felt repsonsiveness.
Sometimes it takes several seconds for a normal switching operation to reach the items. Sometimes like 10 seconds or more and then all the clicks I had made are executed quickly after another.
The big problem is that releasing the switch when dimming does not immediatly get picked up by openHAB and stop the dimming. I don’t know where this delay comes from, or if it is even an issue with the binding.
@fruggy83 was talking about something else. He meant that you can circumvent the timings that the DImmer Profile uses by reacting to the trigger events, not the item events. The item events that you have used (INCREASE, DECREASE) have already been generated by the Dimmer Profile and have therefore already used the timings that I set. But as I said before: these timings are not the problem.
Hi all,
I just want to inform you, that I merged the OH2_3Mods branch back into master and closed it yesterday as OH2.3 was released on Monday.
As told before the new version of this binding is not compatible with OH2.2, so you have to upgrade OH before using the current version. Main features of this new versions are:
To upgrade to new version you have to delete the old version from your addon folder, clean OH cache and add the new version to your addon folder.
Best regards
Daniel
Hi Matt (@Matt77)
I have got an answer from NodOn. Indeed you have to send a manufacturer specific command to the in wall switches to activate the repeater. I added two new NodOn specific profiles which are able to activate the repeater. If you do an auto discovery the correct profiles should be choosen for you. If not you have to select them manually 
.
You can set the repeater level 1/2 or deactivate the repeater. However it is not possible to request the current repeater setup of your in wall switch or get any feedback (“You have to know that you won’t get any confirmation from the module when the activation is done.” cit NodOn). So it is somehow tricky to test this feature. Maybe you can use the receiving state channel which also tells you the repeater count of the last received message. I would be glad if you could test this.
I hope I can implement the other functions (autoOff Timer etc.) in the next days.
Best regards
Daniel
Hi Thorsten (@ThAO),
in the current version I always send an OFF (A502FF0009) when the dim value is set to 0%.
Best regards
Daniel
Hi Jochen (@Jochen86)
I am really sorry but I did not found time to clean up the FAM14 prototype yet. I just setup a prototype for research, I do not use this wired config in my productive setup. So I cannot tell you if this connection is reliable. However during my tests I did not observe any message loss. If you do not want to use such a big dongle you could also use an enocean pi module. I put one of these modules on my pi and placed it in an official pi case. This case has some small holes for the LEDs which I use to put the antenna outside of the case. It is a really small, decent and reliable setup.
However I also understand if you want to put the pi into your cable distribution cabinet (Verteilerschrank). So just be patient, I hope I can finish the work in the next days.
Best regards
Daniel
Hi Oliver (@ohart)
jfyi: I just merged the OH2_3Mods branch back into master. You should be able to use your in wall switches now with the stable OH 2.3 version.
Best regards
Daniel
Hi Daniel (@fruggy83 ),
I have istalled the version 2.4, rebooted the raspberry, checked that version 2.4 is active
211 │ Active │ 80 │ 2.4.0.201805292036 │ OpenOcean Binding
But I don’t see any change. Using the Classic UI (up down arrows) it sends A502000008 which switches the light off but using the Basic UI (with slider) it sends A502000009 - light is on at a low level.
Do you have any idea why this could be?
Best regards,
Thorsten