Hi Gerald @wartel,
glad to hear that it works now. The binding in openhab 2.4 has some issues (/bugs 
). Marketplace version is newer.
Best regards
Daniel
Hi Daniel,
thank you very much for your fast feedaback. Subsequent the log-data when teaching-in the nodon PIR-2-1-00(on the device label)/01(on the box). By the way this is what is something suspect and I have asked the nodon support to exlain the difference.
2019-05-05 15:37:41.711 [INFO ] [covery.EnOceanDeviceDiscoveryService] - Stopping EnOcean discovery scan
2019-05-05 15:37:41.716 [INFO ] [covery.EnOceanDeviceDiscoveryService] - Starting EnOcean discovery and accepting teach in requests
2019-05-05 15:37:49.559 [INFO ] [ernal.transceiver.EnOceanTransceiver] - Received teach in message from 0588041F
2019-05-05 15:37:49.563 [INFO ] [covery.EnOceanDeviceDiscoveryService] - EnOcean Package discovered, RORG _4BS, payload A51C1846800588041F00, additional 00FFFFFFFF3600
2019-05-05 15:37:49.567 [INFO ] [ding.enocean.internal.eep.EEPFactory] - Received 4BS Teach In with EEP A5-07-03 and manufacturerID 46
==> /var/log/openhab2/events.log <==
2019-05-05 15:37:49.596 [home.event.InboxAddedEvent] - Discovery Result with UID âenocean:genericThing:bdf9f894:0588041Fâ has been added.
==> /var/log/openhab2/openhab.log <==
2019-05-05 15:37:49.596 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing âenocean:genericThing:bdf9f894:0588041Fâ to inbox.
==> /var/log/openhab2/events.log <==
2019-05-05 15:37:58.886 [vent.ItemStateChangedEvent] - Stat_Plug_01 changed from Rssi 55, repeated 0 to Rssi 57, repeated 0
2019-05-05 15:37:59.148 [vent.ItemStateChangedEvent] - Stat_Plug_01 changed from Rssi 57, repeated 0 to Rssi 55, repeated 0
2019-05-05 15:38:12.704 [me.event.InboxRemovedEvent] - Discovery Result with UID âenocean:genericThing:bdf9f894:0588041Fâ has been removed.
2019-05-05 15:38:12.744 [hingStatusInfoChangedEvent] - âenocean:genericThing:bdf9f894:0588041Fâ changed from UNINITIALIZED to UNINITIALIZED (HANDLER_CONFIGURATION_PENDING)
==> /var/log/openhab2/openhab.log <==
2019-05-05 15:38:41.716 [INFO ] [covery.EnOceanDeviceDiscoveryService] - Stopping EnOcean discovery scan
The result in the PaperUI is as follows which seems to be a different device and also EEP cannot set to A5-07-03 although it is sent from the device according to log-file, isnât it?
Best regards
Klaus
Hi Daniel @fruggy83,
can you tell me when the next release is planned with this feature included?
Best Regards,
Rainer
Hi Rainer @jahnra,
the version in my repo should already have included the feature. I am currently syncing my work with the official binding and create PR. I cannot tell you when this process will be finished, as this depends on the reviewers 
Best regards
Daniel
Hi Klaus @kdmsch,
thanks a lot for the log. I found the bug (transposed digits / Zahlendreher). I will fix it, when my current PR is finished. In the meantime you could create the thing manually in openHAB. Just use an Occupancy Sensor, set the EnOceanId to 0588041F and select the A5-07-03 EEP.
Best regards
Daniel
1 Like
Hi everyone 
first of all, thanks to everyone for the big efforts implementing/integrating EnOcean devices in openHab, this is awesome!
I got several new Opus Bridges for jalousie control that were not yet mentioned here. When I set them into teach-in mode, openHab finds and recognises them automatically with the correct Id as a RockerSwtich EEP F6-02-01. When I manually press the switch, I can already correctly see the state (angle, % closed etc.) changing in openHab. But I was not able to correctly teach-in the bridge, so that I can control it from openHab. In the manual it says that EEP D2-05-02 has to be used for the teach-in process and that itâs only possible via the proprietary Config-App.
Anyone has an idea of how to correctly teach-in this specific jalousie actuator resp. if it should be possible to control it from openHab at all?
Thank you very much and have a nice weekend!
Best regards
Sebastian
Thank you Daniel, this is no working partly. It is not possible to use the A5-07-03 EEP althougth it is offered in the drop-down menue. Only A5-07-01 is working but this is without âlux rangeâ. Donât know what could went wrong in my installation?
Best regards
Klaus
Hi Sebastian @Bastyd,
When I set them into teach-in mode, openHab finds and recognises them automatically with the correct Id as a RockerSwtich EEP F6-02-01
It is just a guess, but I think that openHAB just finds the Rocker Switch part of your Opus Bridge. Your Opus Bridge consists of a âBedienteilâ (a RockerSwitch) and a âLeistungsteilsâ which controlls the jalousie. So you just connected the Bedienteil with openHAB. In this way you can only receive the telegrams whenever you press a button on your Bedienteil but cannot control the Leitungsteil with openHAB.
Do you own the Config-App? What information do you need to config the bridge for EEP D2-05-02? As I have not implemented this EEP yet, it could be also possible that the teach in is just not accepted by openHAB (however I would expect a generic thing in this case). Could you please post the log when you do the teach-in?
Best regards
Daniel
Hi Klaus,
what do you mean with it is âworking partlyâ. Do you see log messages when your PIR detects motion? Or do you think that the telegrams of your PIR are not interpreted correctly by openHAB? I could not test this EEP by myself, as my order of this PIR got lost and I switched to another one from Eltako. So maybe you are the first one who uses this PIR.
Best regards
Daniel
Hi Daniel,
I have seen only two times a log from the PIR indicating detection of movement while dolphinview recognizes all events correctly. So I would say it reacts very seldom. But all Funktions are working well when recognizing by dolphinview Software. That is why I assume the is working propperly.
It is interesting that I had also trouble with some Nodon smart Plugs. They are also switched only sometimes although EEP and implementation seemed to be correct. I had used three different onces but with same effect.
Maybe Nodon does something special which causes those unstable conditions?
Best regards
Klaus
Hi Daniel (@fruggy83),
just to make sure that I got it right: the RSSI value is given as dBm unit, right? If yes, could you also please provide me a link or information about level ranges for very good, good, not so good, bad, etc. ?
In addition, maybe there is somewhere a calculation rule for translating dBm to % (percent), that would be great (e.g. for using icons in basic ui, etc.).
Thank you and best regards,
Ralf
Hi all,
meanwhile I figured out that RSSI is a relative value which, in theory, can have values between 0âŠ255. Most manufacturer define a RSSI_Max value of 100 (e.g. Cisco), but some do use other values (e.g. 0âŠ60: Atheros).
Iâm using a USB300 stick which hopefully uses the range 0âŠ100. I have no other values identified yet, but I cannot find any documentation about that topic.
Based on my assumption, I use the RSSI value also as percent indication and calculate via rule the related dBm value (just for fun and making sure, I figured the right things out). The formula is quite easy, because I assume a linear interpolation:
dBm = (RSSI / 2) -100Hope that helps someone here.
Kind regards,
Ralf
Hi Daniel,
using OH2.5.0M1-1. Sensors: 2x Easyfit ETHSA (Temp. Humi. - EEP A5-04-03) and 2xEasyfit EMCSA (Magnet Contact - EEP D5-00-01). While the two ETHSA sensors working well including displaying all values in PaperUI correct and also status recovery after restart is no issue, the EMCSA do not display contact status in paperUI (empty field) and after restart no contact status is indicated but the Rssi is still received and updated. The contact status receiving is only to reanimate after repeating teach-in of the sensors. This is not what I will do always after a restart of the system. This phenomena is not occurring during each restart, but sometimes, unfortunately I have no indication what is the resaon for or the differences between the restarts.
Do you have any hints what could be wrong in my implementation?
Hi Ralf,
according to the ESP3 docs the RSSI is given in dBm unit. Since 2.5 we already multiply the value with -1
Best regards
Daniel
Hi Klaus,
we had a really stupid bug in contact EEP D5 
. Can you switch to snapshot? Maybe your bug is already fixed by PR4581.
Best regards
Daniel
Hi,
maybe someone can help me with a challenge - I canât solve.
I am using OH 2.5.0 Build #1603 (RPi 3, with Dongle) with Eltako 12-series components.
1x FAM12-12VDC (receives signals)
2x FMS12-12VDC
3x FSR12-4x-12VDC
1x FUD12NPN-12VDC
1x FUD12/800W-12VDC
Teaching-in the FSR12 actuators works good. However, there is an issue with the teaching-in the FMS12 actuators. Pressing the âTeach-Inâ- Switch in OH makes the FAM12-Receiver receive a signal (blinks), but the FMS12 isnât reacting to the signal and stays in LRN-mode (blinking). When pressing a hardware rocker-switch for example it works at the same time. And here is the dog buried 
As I wrote before: The FSR12 actuators just take the teach-in command and react to it with no further problems.
Actually, I do not know how to update the binding to the latest snapshot version. Do you think this could be the reason? Can someone clarify that for me, please?
Just one notice - before using OH Iâve used FHEM which works fine with all the components. Iâve switched to OH because I thought it would be a little bit easier for me to set it up.
Thank you and Iâm looking forward to hearing from you.
Best regards
Jack
Hi Daniel,
thank you for your information. In case of RSSI is given in dBm (and 2.5 version as negative dBm value) the calculation to percent (%) is also very easy (if dBm value is already negative):
percent = 2 * (dBm + 100)Just for those who are interested in, e.g. for using <wifi> icons in OH.
Best regards,
Ralf
1 Like
Hi Jack,
which teach in message did you use? Could you enable the debug log level and post the message send by openhab when you switch the teach in switch? Maybe the message is wrong 
I still have not found time to fix a bug with the teach in channel. Maybe it has something to do with thisâŠ
Best regards
Daniel
Hi Daniel @fruggy83,
actuelly i dont know, how to enable DEBUG log in Karaf console, but this is what I got while pressing the Teach-In button:
20:50:24.745 [INFO ] [smarthome.event.ItemCommandEvent ] - Item âopenocean_centralCommand_1a5c564b_teachInCMDâ received command ON
20:50:24.862 [INFO ] [arthome.event.ItemStatePredictedEvent] - openocean_centralCommand_1a5c564b_teachInCMD predicted to become ON
20:50:24.939 [INFO ] [smarthome.event.ItemStateChangedEvent] - openocean_centralCommand_1a5c564b_teachInCMD changed from OFF to ON
Maybe this could help you?
Hi Jack @FuMan,
sorry that does not help me. I need the content (bytes) of the message which is send during teach in. You first have to log into the karaf console (ssh -p 8101 openhab@localhost) and set the debug level with the following command log:set DEBUG org.openhab.binding.enocean Afterwards you should see more details in you log when you press the teach in switch.