I added the bridge. 
Så first obstacle is gone.
Now I am stuck with the next configuration_pending
I am using Ocean Pi on port /dev/ttyAMA0 and I am trying to connect a rocker switch. Thanks you for your effort.
During this “trying to connet to gateway” initialisation phase the binding tries to open the specified serial port. If another binding or process already opened the port, you get stuck in this phase. Could you do me a favor and use the latest version of this binding, remove the brigde and add it again? The current version produces more log and status messages during this critical initialisation phase.
Hi all
first of all @fruggy83: great work! I actually started my OpenHAB journey 3 years back with integrating an enocean switch.
These days, I have a lot of devices (and bindings) integrated, except for enocean. Now that I stumbled over this post, however, I am actually thinking of setting up a separate dev environment just to test your binding,
However, I have one question (which was the reason until now not to use enocean anymore): I read that the EnoceanPI does not play well with Raspberry 3 - is that still true or would I be able to install a new Openhabian (for example) on a Pi3 with EnoceanPI and everything is up and running, or do I need to modify more things? Same question actually for the Raspberry Pi2 - I also have a spare one of those lying around, though I’d prefer the 3
Thanks
Patrick
Hi @Pezzi42,
as I am currently the only one who is using this binding in a productive environment, I would also recommand to set up a seperate testing environment to not mix up your current setup. However I must tell you that this binding works quite well in my environment 
I would be very glad if you (as an expert) could set up a dev environment and share your experiences with me. Some improvements could already be implemted from the current feedback and more testers hopefully result in a more stable binding.
I developed this binding on an USB300 stick and I am running it on a Raspberry PI 3 with an Ocean Pi. So quite the same setup that you prefere. I do not have any experiences with Ocean Pi and a Pi2, however the combo Pi2 and USB300 worked well.
Thanks to the new openhabian image, this binding should nearly work out of the box. You just have to set up the serial port and permissions with openhabian-config
and activate the serial bundle with the karaff console. Thats it
Hello @fruggy83
I downloaded the latest viersion.
My next bump on the road is this error:
I tried deactivating the serial port like you wrote in the last port.
and the event log:
2018-02-22 18:31:21.133 [hingStatusInfoChangedEvent] - 'openocean:bridge:4ce5ad74' changed from UNINITIALIZED to INITIALIZING
2018-02-22 18:31:21.142 [hingStatusInfoChangedEvent] - 'openocean:bridge:4ce5ad74' changed from INITIALIZING to OFFLINE (CONFIGURATION_PENDING): trying to connect to gateway...
2018-02-22 18:31:22.149 [hingStatusInfoChangedEvent] - 'openocean:bridge:4ce5ad74' changed from OFFLINE (CONFIGURATION_PENDING): trying to connect to gateway... to OFFLINE (CONFIGURATION_PENDING): starting receiving and sending threads...
2018-02-22 18:31:22.158 [hingStatusInfoChangedEvent] - 'openocean:bridge:4ce5ad74' changed from OFFLINE (CONFIGURATION_PENDING): starting receiving and sending threads... to OFFLINE (CONFIGURATION_PENDING): trying to get bridge base id...Hi @Bayees
this is really strange. As you can see on the event log the connection to the serial port could be successfully established (trying to connect to gateway). Afterwards the threads for sending and receiving could also be started.
During the next step the binding sends a message to the Ocean Pi to determine the base id of the gateway. However something happens here. If you still want to walk road, it would be fine if you could rise the log level for the binding. Just log into the karaf console and type in
log:set TRACE org.openhab.binding.openocean
Afterwards delete and recreate the bridge. Hopefully we can find out what happens with the help of the log. If you own an enocean rocker switch it would be good if you could trigger it, so we can see if receiving enocean messages really works.
Adding the bridge with log trace on:
22:26:02.076 [DEBUG] [org.openhab.binding.openocean ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=304, service.bundleid=203, service.scope=singleton} - org.openhab.binding.openocean
22:26:02.093 [DEBUG] [org.openhab.binding.openocean ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.status.ConfigStatusProvider}={service.id=305, service.bundleid=203, service.scope=singleton} - org.openhab.binding.openocean
22:26:02.120 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'openocean:bridge:0d5cfd90' changed from UNINITIALIZED to INITIALIZING
22:26:02.130 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'openocean:bridge:0d5cfd90' changed from INITIALIZING to OFFLINE (CONFIGURATION_PENDING): trying to connect to gateway...
22:26:05.120 [INFO ] [ransceiver.OpenOceanSerialTransceiver] - Could not connect to serial port /dev/ttyAMA0
22:26:05.129 [DEBUG] [rnal.transceiver.OpenOceanTransceiver] - Listening on port: /dev/ttyAMA0
22:26:05.134 [DEBUG] [nocean.handler.OpenOceanBridgeHandler] - request base id
22:26:05.133 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'openocean:bridge:0d5cfd90' changed from OFFLINE (CONFIGURATION_PENDING): trying to connect to gateway... to OFFLINE (CONFIGURATION_PENDING): starting receiving and sending threads...
22:26:05.129 [DEBUG] [rnal.transceiver.OpenOceanTransceiver] - start sending packets
22:26:05.146 [DEBUG] [rnal.transceiver.OpenOceanTransceiver] - new request arrived
22:26:05.160 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'openocean:bridge:0d5cfd90' changed from OFFLINE (CONFIGURATION_PENDING): starting receiving and sending threads... to OFFLINE (CONFIGURATION_PENDING): trying to get bridge base id...
22:26:05.166 [DEBUG] [rnal.transceiver.OpenOceanTransceiver] - new request arrived
22:26:05.167 [TRACE] [rnal.transceiver.OpenOceanTransceiver] - sending request
22:26:05.179 [TRACE] [rnal.transceiver.OpenOceanTransceiver] - 5500010005700838
22:26:05.187 [ERROR] [rnal.transceiver.OpenOceanTransceiver] - exception while sending data null
22:26:05.193 [TRACE] [rnal.transceiver.OpenOceanTransceiver] - sending request
22:26:05.200 [TRACE] [rnal.transceiver.OpenOceanTransceiver] - 5500010005700309
22:26:05.208 [ERROR] [rnal.transceiver.OpenOceanTransceiver] - exception while sending data null
22:26:05.215 [DEBUG] [rnal.transceiver.OpenOceanTransceiver] - awaiting packets to send
After pushing the switch
22:27:58.897 [TRACE] [rnal.transceiver.OpenOceanTransceiver] - Received Sync Byte
22:27:58.905 [TRACE] [rnal.transceiver.OpenOceanTransceiver] - Received header, data length 7 optional length 7 packet type 1
22:27:58.913 [TRACE] [rnal.transceiver.OpenOceanTransceiver] - publish event for: 002f2730
22:27:58.920 [TRACE] [rnal.transceiver.OpenOceanTransceiver] - f650002f27303002ffffffff3c00
22:27:59.089 [TRACE] [rnal.transceiver.OpenOceanTransceiver] - Received Sync Byte
22:27:59.097 [TRACE] [rnal.transceiver.OpenOceanTransceiver] - Received header, data length 7 optional length 7 packet type 1
22:27:59.104 [TRACE] [rnal.transceiver.OpenOceanTransceiver] - publish event for: 002f2730
22:27:59.111 [TRACE] [rnal.transceiver.OpenOceanTransceiver] - f600002f27302002ffffffff3c00Thanks a lot, I think i know what is happening.
First of all my way to recognize if a serial port is already in use, is not working 
The entry “could not connect to serial port …” is in most cases triggered by an already used serial port. In this case I actually do not abort the initialisation so the binding goes on and tries to request the base id. However this is not possible without an open serial port, so you get exceptions while sending data.
However you can see log entries when you trigger your rocker switch with enocean id 002f2730. So I think you have already created a working bridge, which blocks the serial port and listens to enocean messages. Could you please verify that you have created just one bridge. This bridge has to be selected when you create other openocean things.
Hi Daniel,
Got it. I bound the channels to a switch item. Now I am using the channel states in rules according to your example. Works very well! Thank you.
Are you planning to add additional eep’s? For example the A5-02-05?
And I tried your last binding and maybe found a bug. It seems to me that your new version blocks other serial ports, so only the one used by binding is available for other bindings… If I delete the enocean bindig and restart openhab all other serial ports are available again. I guess this is related to your previous post?
1 Like
Hi @peter.boehm,
I am glad to hear that it is working now (somehow 
). What other bindings do you use which are not working now after using my binding? Do they use the same port as my binding or another port? What OS do you use? I will have a look tomorrow, if I can fix this problem.
Are you planning to add additional eep’s? For example the A5-02-05?
I plan to implement all EEPs. However as I only own the mentioned devices, I am not really able to test other EEPs. So it would be great if you could do the testing. Do you even own more enocean devices?
Hi Daniel,
Here is my setup:
Plattform = Latte Panda x64
OS = Debian 9 with Kernel 4.14
Java = Oracle Java 1.8.0_161
OH = 2.3.0 Build #1219
I use 4 devices (masked by udev):
/dev/zwave with Chris development version of the zwave binding
/dev/zigbee with Chris development version of the zigbee binding
/devserial11 with the serial binding
/dev/enocean with your binding
If your binding is not loaded the first 3 working as expected. If your binding is loaded only the zwave binding is working. /dev/serial11 and /dev/zigbee are not available to openhab. I get a “Unable to open serial port”
I only have a couple of switches and a temperature sensor right now. But I would like to buy some more devices 
Hello @fruggy83
So, I have now set up my dev environment with the enoceanpi.
Installing everything was fine, my rocket switch was discovered immediately when I pressed it.
However, I now hat the issue that I cannot link the channels to an item.
More precisely, the channels „Rockerswitch channel A“ and Channel B cannot be linked. They have the channel type „generalswitch“
The channel receiving state I could link to an item, and that item also receives something when I press the switch.
The switch itself is a bit older, FT55.
Am I missing something?
Cheers
Hi @peter.boehm
very nice setup I made some investigations about your problems and found some issues with the lib I use for rxtx communication. So I think I have to switch lib to the one used by the other bindings. Give me some time to fix it.
The implementation of A5-02 EEP group is nearly finished.
Hi @Pezzi42
Rocker switches are somehow special. In general I distinguish two kind of devices. Sensors, which can only receive messages, and actuators, which are furthermore able to send messages. However I implemented the rocker switches as a mixture of both.
You can use the rocker switch thing as an actuator to send switching messages. In this case you use the generalSwitch channels. There are two channels as a rocker switch can have two rockers, one channel for each rocker. To properly send messages you have to manually set a senderId.
However if you want to receive messages of your physical rocker switch FT55, the rocker switch is used as a sensor. In this case you do not need a senderId and have to use the rockerSwitch channels. These channels are implemented as trigger channels, which emit an event (“DOWN_PRESSED” or “UP_PRESSED”) whenever you trigger your FT55. So you cannot link them to an item. Instead you have to define a rule to react to the them. For example I use the following rules to trigger my Sonos in my bath, whenever I trigger my FT55:
rule "Bad Sonos ON"
when
Channel 'openocean:rockerSwitch:4326d3ef:fefdaf7c:rockerswitchB' triggered DOWN_PRESSED
then
if(Sonos_Bad_Control.state != "PLAYING"){
Sonos_Bad_Volume.sendCommand(20)
sonos_PLAY1_RINCON_949F3E1409DE01400_standalone.sendCommand(ON)
Sonos_Bad_Radio.sendCommand("WDR2 Rheinland")
}
end
rule "Bad Sonos OFF"
when
Channel 'openocean:rockerSwitch:4326d3ef:fefdaf7c:rockerswitchB' triggered UP_PRESSED
then
Sonos_Bad_Control.sendCommand("PAUSE")
end
If your FT55 switches a light on or off with a FSR and you want to visualize the light state in openhab, I would recommend you to directly add the FSR as a thing (Central command). In this case your light can be switched by your FT55 or any other switch (motion sensor or so on) and the FSR tells openhab if he switched the light on or off.
I hope I could explain it in some degree. If not, feel free to ask me any questions.
Cheers
ps I already have the new openhab feature “profiles” on my todo, so you will later be able to map the rocker switch events to light, dimmer or any other kind of items.
Hi @peter.boehm
I just changed the rxtx lib to the one used by your other bindings. Furthermore I also implemented the A5-02 EEP group. I would be glad if you could test these changes.
I have tested the new version of this binding with USB300 and enocean pi on my PI3. Everything seems to work usually.
Hi Daniel,
It seem s to work! I have to test the temperature in the eveneing sensor but the serial problems are gone.
Great work, thanks!
Hi Daniel,
Strange, now I get this error:
2018-02-26 22:18:00.913 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception
java.lang.NullPointerException: null
at org.openhab.binding.openocean.internal.transceiver.OpenOceanTransceiver.receivePackets(OpenOceanTransceiver.java:131) [200:org.openhab.binding.openocean:2.3.0.201802250921]
at org.openhab.binding.openocean.internal.transceiver.OpenOceanTransceiver.access$0(OpenOceanTransceiver.java:116) [200:org.openhab.binding.openocean:2.3.0.201802250921]
at org.openhab.binding.openocean.internal.transceiver.OpenOceanTransceiver$1.run(OpenOceanTransceiver.java:88) [200:org.openhab.binding.openocean:2.3.0.201802250921]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
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) [?:?]
Hi Peter,
really strange. I am just checking if I have to receive enocean messages any longer on this line. Do you still know, what you have done just before this error happend? Thanks a lot for this error log, I will see what I can do to make this binding more stable.
Hi Daniel,
Yes, I restarted openhab 
Today I deleted tmp and cache but it happened again. After a second restart it works again, without a problem. I’will observe it within the next day.
Hi Peter,
I am sorry for these problems. I improved the startup and shutdown of the binding in its last version. So you should not get these problems any longer during a restart. I even implemented a reconnection to the serial port after one minute, if something goes wrong.
Furthermore sending a large amount of messages (close all rollershutters during sunset) is also more reliable now.
Please empty your cache folder before you use the new version of the binding.