I initially made the installation and the update via your repo.
I have now decided to use the official binding. Unfortunately I do not know exactly where I can install this. In Openhab itself, I only see the following choices: (EnOcean Binding binding-enocean1 - 1.12.0) that is not correct, right? The instructions from the old Readme had helped me a lot, but is now outdated. So how can I install the official version?
I’m still new to the Openhab and Enocean users. Please have the understanding that I ask such fundamental questions.
Best regards,
Dennis
I only see the following choices: (EnOcean Binding binding-enocean1 - 1.12.0) that is not correct, right?
Yes your are right. I forgot to say, that you need a snapshot build version of openHAB to be able to directly install the official version of this binding. I am running this snapshot/test builds for months now even on my productive system, so I just forget to mention it
So you have two options now:
If you are using openhabian, you can easily switch to a snapshot build. Just use option 40 => 41 in openhabian-config.
Wait until Dezember 17th. The release of openHAB 2.4 is planned for this day.
I’m still new to the Openhab and Enocean users. Please have the understanding that I ask such fundamental questions.
No problem. I guess without your questions other users would have the same problems.
I just bought some ELTAKO TF-FGB window handle sensors which are currently not directly supported by your binding, cause the EEP is A5-14-09. I have the following information from the documentation:
Teach-In telegram: 0x50480D80
Data_byte0 = 0x08 --> window closed
0x0E --> window open
0x0A --> window tilted
Data_byte3 = battery power 0…250, 0…5V
Is it possible that you implement this quite in time? I was not able to get them working based on your instructions. Sorry.
Additionally I cannot activate your currently precompiled *.jar in my openhab 2.3 installation, which was possible a few weeks ago (I downloaded it November 26th). Are there meanwhile any changes made which corrupt functionality in openhab 2.3?
it should not be a big problem to implement this EEP A5-14-09. Fortunately Eltako describes the content of their enocean messages very good in detail. I wish this would do other manufacturers too.
As I synced my openocean repo with my work for the official binding, you have to use oh2.4 now. I am using the ESH serial port API now, which got implemented in one of the 2.4 snapshots. So I gues it has something to do with this change. However the release of OH 2.4 is coming (December, 17th).
thank you for your quick response. I just updates to the current 2.4 snapshot but now I’m missing the OpenOcean TCP gateway, cause I’m using it in combination with ser2net which runs on my raspi. Is there any chance to get it back or are there alternatives to it?
now I have another issue: I got the bridge from 2.4 snapshot version working (for a few minutes) using ser2net and socat based on thins article [Forwarding of serial and USB ports over the network to openHAB].
But just after editing the newly added thing (renaming the element), it turned into “offline - configuration pending”. On the server side I can see messages coming up the the related serial port after editing the thing but no more turning into “green/onlne”.
The log announces the following:
2018-12-13 02:52:51.436 [INFO ] [transceiver.EnOceanSerialTransceiver] - Transceiver shutdown
2018-12-13 02:52:51.439 [hingStatusInfoChangedEvent] - 'enocean:bridge:40ef060c' changed from OFFLINE (CONFIGURATION_PENDING): trying to get bridge base id... to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2018-12-13 02:52:51.444 [INFO ] [transceiver.EnOceanSerialTransceiver] - EnOceanSerialTransceiver initialized
2018-12-13 02:52:51.447 [hingStatusInfoChangedEvent] - 'enocean:bridge:40ef060c' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_PENDING): starting rx thread...
2018-12-13 02:52:51.448 [hingStatusInfoChangedEvent] - 'enocean:bridge:40ef060c' changed from OFFLINE (CONFIGURATION_PENDING): starting rx thread... to OFFLINE (CONFIGURATION_PENDING): trying to get bridge base id...
The related HEX dump of the serial port after or while this message comes each minute up:
I tried a lot: restarting openhab, clearing cache, restarting binding only, deleted and reinstalled thing… no chance. Now I’m at my end of all my knowledge and it’s late. Hope to hear quite quick from you with additional hints what to do.
the big advantage of using the ESH serial port API is that a serial connection over tcp is directly integrated. So I dropped the tcpbridge. You just have to ensure that the feature esh-io-transport-serial-rfc2217 is installed. In my setup this feature was already running. Next you have to specify the path in your bridge in the following way: rfc2217://a.b.c.d:e where a.b.c.d is the ip of ser2net server and d is the port. I had no problems in my tests doing it in this way.
I gave it a try but now get the error “port could not be initialized”. Must there also something be added to /etc/default/openhab2 like for activating serial ports?
i have recently migrated from an older version to the m8 build of the plugin.
So i needed to re-create everything to switch from openocean: to enocean:
Which is fine the only problem is my FMS61NP which you originally helped me
to set up using virtual rocker switches here https://github.com/fruggy83/openocean/issues/7
For example i Have:
For the State:
openocean:rockerSwitch:36336014:018614c7:rockerswitchB
And for the switching:
openocean:virtualRockerSwitch:9268057a:virtualRockerswitchB
And the Actual Item looks like:
Switch baDecke “Badezimmer” (Bathroom) [ “Lighting” ] {channel=“openocean:virtualRockerSwitch:9268057a:virtualRockerswitchB” [profile=“openocean:rockerswitch-to-on-off”,switchMode=“rockerSwitch”, duration=250], channel=“openocean:rockerSwitch:36336014:018614c7:rockerswitchB” [profile=“openocean:rockerswitch-to-on-off”]}
So my question for this type of switch (sending rocker switch telegrams on state change), in the new binding
what should i use for those devices classicDevice or genericThing and more importantly how would a
config for the Classic device look like since it should not change state based on switch telegrams but
does actually send them itself ?
now I got an exception. Maybe this is the reason for my problems?!?
2018-12-13 22:47:54.681 [DEBUG] [transceiver.EnOceanSerialTransceiver] - shutting down transceiver
2018-12-13 22:47:54.681 [DEBUG] [ernal.transceiver.EnOceanTransceiver] - Interrupt rx Thread
2018-12-13 22:47:54.682 [DEBUG] [transceiver.EnOceanSerialTransceiver] - Closing serial port
2018-12-13 22:47:54.687 [INFO ] [transceiver.EnOceanSerialTransceiver] - Transceiver shutdown
2018-12-13 22:47:54.691 [hingStatusInfoChangedEvent] - 'enocean:bridge:40ef060c' changed from OFFLINE (CONFIGURATION_ERROR): Port could not be initialized to OFFLINE (CONFIGURATION_PENDING): opening serial port...
2018-12-13 22:47:54.693 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - error during bridge init occured
org.eclipse.smarthome.io.transport.serial.UnsupportedCommOperationException: gnu.io.UnsupportedCommOperationException
at org.eclipse.smarthome.io.transport.serial.rxtx.RxTxSerialPort.enableReceiveThreshold(RxTxSerialPort.java:157) ~[?:?]
at org.openhab.binding.enocean.internal.transceiver.EnOceanSerialTransceiver.Initialize(EnOceanSerialTransceiver.java:61) ~[237:org.openhab.binding.enocean:2.4.0.201812121631]
at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.initTransceiver(EnOceanBridgeHandler.java:197) [237:org.openhab.binding.enocean:2.4.0.201812121631]
at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.access$2(EnOceanBridgeHandler.java:184) [237:org.openhab.binding.enocean:2.4.0.201812121631]
at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler$4.run(EnOceanBridgeHandler.java:176) [237:org.openhab.binding.enocean:2.4.0.201812121631]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: gnu.io.UnsupportedCommOperationException
at gnu.io.rfc2217.TelnetSerialPort.enableReceiveThreshold(TelnetSerialPort.java:948) ~[?:?]
at org.eclipse.smarthome.io.transport.serial.rxtx.RxTxSerialPort.enableReceiveThreshold(RxTxSerialPort.java:155) ~[?:?]
... 11 more
2018-12-13 22:47:54.701 [hingStatusInfoChangedEvent] - 'enocean:bridge:40ef060c' changed from OFFLINE (CONFIGURATION_PENDING): opening serial port... to OFFLINE (CONFIGURATION_ERROR): Port could not be initialized
I implemented the ClassicDevice with your use case in mind. To ease things up, I combinded the old virtualRockerSwitch and the rockerSwitch into one device and dropped the profiles. In this way I can avoid the unnecessary double switch messages now too.
As you want to control your light through channelB of your “virtualRocker” you have to use the virtualRockerswitchB channel and a rule which converts the OnOff commands into Dir1Dir2 press commands. If you would use just channelA, you could avoid this stuff, use the virtualSwitchA channel and bind it together with the listener channel to the same item.
This is your rule
rule "Bathroom light switch"
when
Item baDecke received command
then
if(receivedCommand == ON) virtualSwitcher.sendCommand("DIR1_PRESSED")
else virtualSwitcher.sendCommand("DIR2_PRESSED")
end
really strange . This seems to be a bug in the ESH serial API. The rfc2217 does not support ReceiveThresholds. However as I am just developing against an interface without knowing which type of serial port you are using (standard or rfc2217), I would suggest that the rfc2217 implementation just ignores this function call. I have tested it in an early stage of the API succesfully. I will check this tonight.
@fruggy83, thanks again for your fast help, i got it working with the rules as you suggested
above. When i tried to learn the A channel like you suggested i unfortunately was not
able to, i put my Aktor int LRN and pressed the switch button but unfortunately the
actor does not seem to process the telegram, i used config:
but exception mentioned above still remains in openHab
2018-12-14 17:08:19.267 [DEBUG] [nternal.handler.EnOceanBridgeHandler] - error during bridge init occured
org.eclipse.smarthome.io.transport.serial.UnsupportedCommOperationException: gnu.io.UnsupportedCommOperationException
at org.eclipse.smarthome.io.transport.serial.rxtx.RxTxSerialPort.enableReceiveThreshold(RxTxSerialPort.java:157) ~[?:?]
at org.openhab.binding.enocean.internal.transceiver.EnOceanSerialTransceiver.Initialize(EnOceanSerialTransceiver.java:61) ~[237:org.openhab.binding.enocean:2.4.0.201812121631]
at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.initTransceiver(EnOceanBridgeHandler.java:197) [237:org.openhab.binding.enocean:2.4.0.201812121631]
at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler.access$2(EnOceanBridgeHandler.java:184) [237:org.openhab.binding.enocean:2.4.0.201812121631]
at org.openhab.binding.enocean.internal.handler.EnOceanBridgeHandler$4.run(EnOceanBridgeHandler.java:176) [237:org.openhab.binding.enocean:2.4.0.201812121631]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: gnu.io.UnsupportedCommOperationException
at gnu.io.rfc2217.TelnetSerialPort.enableReceiveThreshold(TelnetSerialPort.java:948) ~[?:?]
at org.eclipse.smarthome.io.transport.serial.rxtx.RxTxSerialPort.enableReceiveThreshold(RxTxSerialPort.java:155) ~[?:?]
... 11 more
as you can read here there is already a discussion ongoing how to handle calls to enableReceiveThreshold for a rfc2217 connection. I would have expected that this exception is handled silently in the lib. However this is not true.
I will do a PR this weekend. Meanwhile you could use the jar from my repo, issue28 branch. The official version cannot be used in parallel with this jar. With the following ser2net config, I was finally able to connect through rfc.
you are welcome, but same issue as before. I activated your new jar and followed your suggestion regarding the ser2net settings, but no chance to get it up right working.
237 │ Active │ 80 │ 2.4.0.201812141820 │ EnOcean Binding
ser2net registers a connection but nothing more happens:
2018/12/14 21:43:27 CLOSE netcon (network read close)
2018/12/14 21:43:27 CLOSE port (All network connections free)
2018/12/14 21:43:27 OPEN (::ffff:192.168.8.10:33838)
2018/12/14 21:44:27 CLOSE netcon (network read close)
2018/12/14 21:44:27 CLOSE port (All network connections free)
2018/12/14 21:44:27 OPEN (::ffff:192.168.8.10:33862)
2018/12/14 21:45:27 CLOSE netcon (network read close)
2018/12/14 21:45:27 CLOSE port (All network connections free)
2018/12/14 21:45:27 OPEN (::ffff:192.168.8.10:33888)
Still the same exception within openHab.
Do you think it will take you some time to fix it? In that case I will try to go back to OH2.3 version with your previos jar I was able to use.
another stupid mistake I will do a PR this weeking. I will do a PR this weekend. Meanwhile you could use the jar from my repo, issue30 branch. The official version cannot be used in parallel with this jar.