Have you tried to restart openhab?
The console lists the binding as follows when issuing bundle:list
229 | Active | 80 | 2.0.0.201610111616 | JeeLink Binding
Is the bundle shown in the paper UI when you press + in the Inbox?
After the fourth download of the snapshot it works now! I think the previous downloads were corrupt.
Sorry for the trouble! 
No problem. Glad to hear that you got it working. It would have been even nicer if you were on windows, but maybe somebody else will try the binding on a pc with the OS from the dark side soon.
Hi Volker,
Thanks for sharing this binding. I might have missed this but I canât find information on what sketch should be running on JeeLink to read LaCrosse sensors. Also what model of JeeLink (868 or 433 MHz band) and LeCrosse sensors are compatible?
I am no expert on JeeLinks, but AFAIK, there exists only one sketch allowing to read lacrosse temperature sensors and it seems to support only 868 MHz devices.
This is the one mentioned in the README in my github repo named LaCrosseITPlusReader. It can be found here:
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/
Others correct me if I am wrong.
Correct 
I have added experimental support for ec3000 sensors. Since I personally do not own one, I had to simulate the sensors with netcat. So it is possible that they will not work.
Thatâs fantastic! I will test it, but first i need to buy a second JeeLink to flash the ec 3000 sketch on it. Does your binding support two JeeLinks?
It should. But it is untested, of course. Looks like you are my man for testing 
I will do my best ;).
Itâs a goog timing. Today i was searching for some cheap sockets, switchable with Openhab, and found some Energy Control 3000 compatible ones. Missing was a binding for them. One hour later i read your post
I think i can start my first attempts next week when the JeeLink arrives.
I donât thing you can actually switch them with openhab. IMHO, you can only visualize the readings, as the JeeLink seems to be only a RF receiver. I had a look at the old ec3k binding, and this did not support any command sending. Or do I miss something here?
Yes, you are right. The ec3k is only for receiving the power consumption at the sockets.
The Jeelink uses the RFM69CW (v3c) which is also able to . I think the protocol i need is pca301. Maybe itâs possible to build a sketch which understand received lacrosse packets and can send pca301 encoded data to switch some sockets. My MC programming knowledge is a little bit rusty but i will look into it.
Since there still was jitter in the values (even with a one minute update interval), I added computation of a rolling average. We will see in a few days whether this helps.
I have also added a configuration parameter allowing to specify a sensor timeout. After this timeout the sensor is now set to OFFLINE when no values have been received. This was formerly hard coded to 60 seconds.
Is there a way to configure the minTemp attribute within the binding config?
I fail with the follow warning which leads to a - in the web-interface:
[WARN ] [sse.LaCrosseTemperatureSensorHandler] - thing LaCrosse Temperature Sensor (ID = 24) (1478417406233) has invalid temperature reading: temp=16.8
The limits are configurable in the thing configuration of the sensors. This is also described in the readme:
Lower Temperature Limit: The lowest allowed valid temperature. Lower temperature readings will be ignored
Upper Temperature Limit: The highest allowed valid temperature. Higher temperature readings will be ignored
Thanks, solved via the REST API (web-interface) and now the values are visible.
Today I managed to get the jeelink binding running under openHAB2. The worst part was to fix the debian package after the big directory movement of Kai Kreuzer, see my other article about this.
I use the udev rule /etc/udev/rules.d/98-jeelink.rules
SUBSYSTEMS=="usb", ATTRS{serial}=="AH02EWYA", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyUSB_jeelink", ACTION=="add", GROUP="dialout", MODE="0666", RUN+="stty -F /dev/ttyUSB_jeelink 57600 sane cs8 -echo"```
and the extra Java parameters in /etc/defaults/openhab2:
EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB_jeelink:/dev/ttyUSB_cul868:/dev/ttyUSB_arduino"
because I have some more ardiuno variants on the USB interface and must differentiate between them (ttyUSB0 und ttyUSB1 could be exchanged after booting).
I like the new discovery procedure. I only get 3 of 6 sensors but, 2 of them report low temperatures (~0 °Celsius) and or thrown out. I guess I have to adjust the limits.
HABDroid showed the sensor data in the beginning, but now the data is missing (but the things are there). I'll investigate this further.
What happens if I change the batteries? Any A.I. which replaces the old thing even when the id changes?
Many thanks for the binding.
greenoidI could have implemented some logic that recognizes that one sensor does not report values any more and another one is new, but that seemed to be to error prone.
The current way to replace a sensor is to replace the battery, start the discovery and look up the new sensor ID while the sensor is still in the inbox. Then delete the item from the inbox, and configure your old sensor item with the new sensor ID.
I am not sure how long the discovery waits for sensor readings in order to create sensor items. If my memory serves me right, it should be 5 seconds, which was enough for all of my sensors. Have you tried to invoke the discovery multiple times in order to find the missing sensors?
The discovery waits way longer than 5 sec, I guess 20-25 sec, and thatâs enough. I repoositioned my antenna and now I have all my 5 sensors.
Thanks for your receipt for the battery change, I will follow it.
When will the Jeelink binding be merged with the main line?
Some time ago, I have added experimental support for ec3000 devices. I am currently waiting for marb to get his hardware and set it up. We will then hopefully get the ec3000 sensors running within a few days. I will then have to check openhab code style rules and adapt my code (and perhaps add some tests, I am not sure what the policy is). When this is done, I will have to find out how to create a pull request and wait for approval.
So all in all, this looks like it might take some time.