Hi @fruggy83,
this would be really great if you could implement this because this is my remaining component to be included (apart from some switches which should work).
Actually I don’t know the difference between a trigger and a state channel. The only thing I need it for is to trigger a rule based on motion detection (motion=yes + some time constraints -> light on; motion=no -> light off).
Best regards,
Thorsten
Addendum: if I got it right I need a state channel to trigger for no-motion
Hi @ThAO,
if I got it right I need a state channel to trigger for no-motion
You are absolutely right. If you also want to detect no-motion you need a state channel 
I finished the implementation of the A5-08 EEP class. Your FABH63 is somehow special (as most of the Eltako devices), as it uses the A5-08-01 profile but without sending temperature and with a enlarged illumination range. Therefore I check now the provided manufacturer Id during discovery to choose the special eltako profile for your FABH63.
New Thing
Thing openocean:lightTemperatureOccupancySensor:XXXXXXXX:AABBCCDD "Label" (openocean:bridge:XXXXXXXX) [receivingEEPId="A5_08_01_FXBH"]
New Items
Switch FABH_MOTION "Label" {channel="openocean:lightTemperatureOccupancySensor:XXXXXXXX:AABBCCDD:motionDetection"}
Number FABH_LUX "Label" {channel="openocean:lightTemperatureOccupancySensor:XXXXXXXX:AABBCCDD:illumination"}
However as I am currently working on the integration of some new openhab 2.3 features (like dimensions etc), I had to push these changes to a new branch (OH2.3_Mods). This branch is not well tested by me, so use it at your own risk 
Best regards
Daniel
ps: I will use this new branch (after renaming) as my dev branch in the future and merge it back to master when it is tested
Thanks a lot!! I will try at the weekend.
Unfortunately I got the following error using the branch OH2.3_Mods:
2018-04-28 18:13:56.573 [ERROR] [org.openhab.binding.openocean ] - FrameworkEvent ERROR - org.openhab.binding.openocean
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.openocean [210]
Unresolved requirement: Import-Package: javax.measure.quantity
at org.eclipse.osgi.container.Module.start(Module.java:444) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1620) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1599) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1514) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
@fruggy83
Hi Daniel,
i wanted to say thank you for the great binding and the effort you but in it.
just setup my rocker switches without rules and it worked from the beginning.
i will see to setup my Nodon actuators next. till now i did not used them cause of the limitation of the EnOcean binding but now i can make finally use of them.
again, great work
Kind Regards
Matt
Hi @ThAO,
do you already use openhab 2.3? This quantity type is a new feature which was introduced in openhab just a few days/weeks ago. I use this feature to connect a measurement unit (Celcius Grad, Watt, Watt/h, Lux etc) to the item states. In openhab 2.3 you have to define which measurement system ( SI units (metric system), anglo american units) you use and all states a transformed into the right units automatically (celcius <-> fahrenheit for example)
I use a nightly build in my productive system for months now and do not have any problems.
Best regads
Daniel
HI @Matt77,
thanks a lot for your words. I am glad to hear that this binding works well for you.
Using my rocker switches without any rules is possible because of the openhab 2.2 feature “profiles”. You can connect my rocker switches to a any switch (or even dimmer) item through a profile. This profile translates then the rocker switch messages (UP/DOWN pressed, LONG/SHORT press) to ON/OFF (or DIM UP/DIM DOWN) commands.
For example I use some rocker switches to control hue lights (on/off, dim up/down) or play/pause my sonos without any rule 
What kind of nodon actuator do you own? The in wall actuators or the smart meter plugs? Currently my binding just supports the smart meter plugs (I even own them). However supporting the in wall actuators should not be big thing.
Best regards
Daniel
Hi @fruggy83,
this was the solution. After upgrading openhab the FABH63 works perfectly.
Thanks a lot !!!
Thorsten
Hi @fruggy83
i have actually the in wall actuators, if you could integrate them as well would be great.
Just let me know which details you need and ill check them later.
for the dimmer integration i did, most likely exactly the same you did with my hue lights.
on/off works quite good, but for dimming its a bit tricky to use.
in my setup it seems to be quite delayed, meaning if i long press the rocker it takes some time until the light gets dimmed. and if i press it a bit to long, even already released, its still dimming or even switch off.
with my previous setup, enocean binding and rules, it was more responsive, not sure if this is something related to the binding or my setup.
kind regards
Matt
Hi @Matt77,
maybe I find some time today to do the first implementation for your in wall actuator. Do you own the one or two channel actuator?
Yes you are right, dimming is a bit tricky. As enocean rocker switches do not know long/short press, the openhab dimming profile uses some time dependent mechanics to differ between short and long press. A press is recognized as a long press when you hold the button at least 500 ms. So the first dimming command is send after 550 ms, subsequent dimming commands are send after 200 ms. If you used tighter timings or used smaller increasing/decreasing steps in your rule, the system was more responsive. Maybe you should ask the developer (jaykay) of this profile to modify it a little bit for you.
Best regards
Daniel
Hi @Matt77,
I implemented the EEP profiles D2-01-0F and D2-01-12 which are used by the one and two channel in wall actuators. Currently I just support the switching functions, advanced features like auto off timers are not implemented yet. If you need them too leave a comment here.
As I am currently developing this binding against the OH 2.3 version and use some new features which are not backward compatible to version 2.2, I created a new branch “OH2.3_Mods” in github. To be able to use this new version of this binding, you have to switch to the unstable/nightly build of OH. If this is a problem for you, I can look if I can merge these changes to the OH 2.2 compatible branch.
However I would be very happy, if you could test these changes and tell me if it works for you setup. Thanks a lot in advance.
Best regards
Daniel
Hi @fruggy83,
actually i made use of the commands INCREASE and DECREASE the rocker switch was sending, which i then used to send to my dimmer items.
Therefore no need of any timings in the rules.
kind regards
Matt
I’m on 2.3 so will have a look into it and report back soon.
may need some days since i have not tested the actuators at all yet.
kind regards
Matt
Hi @fruggy83,
I am afraid that I need your help again. I tried to define a switch using the text files in the following way
Thing openocean:rockerSwitch:37182ce4:0082EB6D "Schalter" (openocean:bridge:37182ce4) [receivingEEPId="F6_02_01", broadcastMessages=true]
Switch Switch_A "Schalter A" {channel="openocean:rockerSwitch:37182ce4:0082EB6D:rockerswitchA"}
Switch Switch_B "Schalter B" {channel="openocean:rockerSwitch:37182ce4:0082EB6D:rockerswitchB"}
String Receiving "Schalter Receiving" {channel="openocean:rockerSwitch:37182ce4:0082EB6D:receivingState"}
When I press the switch the “Receiving” item shown RSSI and repeating information. But I don’t see a state change for the two other items. What have I done wrong.
Best reagrds,
Thorsten
Hi @ThAO,
i had to combine the switching and receiving part like this:
Switch Switch_A "Schalter A" {channel="openocean:rockerSwitch:37182ce4:0082EB6D:rockerswitchA", channel="openocean:rockerSwitch:37182ce4:0082EB6D:receivingState"}
Switch Switch_B "Schalter B" {channel="openocean:rockerSwitch:37182ce4:0082EB6D:rockerswitchB", channel="openocean:rockerSwitch:37182ce4:0082EB6D:receivingState"}
Best regards,
Alex
Hi @ThAO,
I do not know why but sometime the automatic item profile assignment is strange. So maybe a false profile (for example my state updating profile) is choosen for your switch item.
Could you try this item definition
Switch Switch_A "Schalter A" {channel="openocean:rockerSwitch:37182ce4:0082EB6D:rockerswitchA" [profile="system:rawrocker-to-on-off"]}
Switch Switch_B "Schalter B" {channel="openocean:rockerSwitch:37182ce4:0082EB6D:rockerswitchB" [profile="system:rawrocker-to-on-off"]}
This profile should be the default one if you really want to send a ON/OFF command to the item. May I come to know what you are planning to do? Do you also want to switch something with your item?
Best regards
Daniel
thanks for your help. Actually I think my problem is that the switch sends 0x10/0x00 for pressed/received.I have tried another switch which sends 0x70/0x00 resp. 0x50/0x00. In this case I see “triggered DIR1/2_PRESSED” and “triggered DIR1/2_RELEASED”.
The only thing I want to do with the switch is to trigger a rule.
Best regards,
Thorsten
Hi @ThAO,
Actually I think my problem is that the switch sends 0x10/0x00 for pressed/received
That could also be the reason What kind of switch do you use here? Do know which EEP it uses? If I look into the EEP docs, I just find a wind speed threshold detector (F6-05-00), which sends such messages.
The only thing I want to do with the switch is to trigger a rule.
In this case your definitions are correct.
Best regards
Daniel
Hi @fruggy83,
it is an Eltako FFT55Q. An this it what it sends:
EnOcean received via EUL: EnOcean:1:F6:10:0082EB6D:20:01FFFFFFFF4400
EnOcean received via EUL: EnOcean:1:F6:00:0082EB6D:20:01FFFFFFFF4400
Best regards,
Thorsten
… I have tested another “single” switch which also sends 0x10/0x00. It is the voltage controlled transmitter PEHA 455 FU-S2. In FHEM both switched can be simply defined as standard switch and 0x10 is interpreted as “pressed” and “0x00” as “released”. Daniel, if you could implement something similar I would be really glad. Or do you think there is another way to get the information?
Hi @ThAO,
my binding does not identify these messages as rocker switch messages because of the status byte (0x20). According to the EEP doc, the bits 5 and 6 of the status byte should be set (for example 0x30).
When I drop this check, your rocker switches should work as well. Let me see what other implications this change could have.
Best regards
Daniel
Hello Andreas (@Jako),
Is it possible to use the binding in a wired setup? Currently I am using an USB300, but I would prefere to connect the FAM14 over USB to the openhab-server (raspberry).
I could use the long weekend to test the wired setup of my binding. It is possible to send and receive messages with an USB connected FAM14 after some modifications (FAM14 does not have a base id). However the guys at the fhem forum do not recommend this kind of setup as the FAM14 is not intended to send/receive messages. Some guys mention message loss.
I hope I can clean up the prototyp implementation and release a updated version of my binding during the next week.
Best regards
Daniel