You are the first one to report such a problem. And modifying the error handling would only hide a problem, as these exceptions should not occur on a normal installation.
I have updated the binding. It have added some bug fixes for pca301 and reworked the mechanism that detects which sensors are connected. So If you have pca301 sockets, test the new version:
https://github.com/vbier/openhab2-addons/blob/pca301/addons/binding/org.openhab.binding.jeelink/org.openhab.binding.jeelink-2.2.0-SNAPSHOT.jar
Hello Volker
I just updated to openhab 2.2.
Now I see the JeeLink binding at bindings in the paperUI, but it is not marked as installed.
I am afraid what happens if I install it via paperUI now. Will I loos all configuration and items of that binding?
On the other hand, if I do not install it via paperUI I will miss all further updates of that binding.
How to proceed now with openhab 2.2 and manual installation of the binding?
Thank you in advance.
BR
Matthias
Dear fellow OpenHABers,
I seem to have the same (or similar) issue as Matze:
I’m running OpenHabian on a Raspi Model 3. After updating to OpenHAB2.2 the Jeelink Binding was not installed. So I re-installed it using PaperUI. Now my Jeelink Devices show up in the PaperUI as “UNINITIALIZED”. I took a look in the logs an found the following error:
[ERROR] [org.openhab.binding.jeelink ] - FrameworkEvent ERROR - org.openhab.binding.jeelink
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.jeelink [239]
Another singleton bundle selected: osgi.identity; type="osgi.bundle"; version:Version="2.2.0"; osgi.identity="org.openhab.binding.jeelink"; si
ngleton:="true"
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:1600) [?:?]
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) [?:?]
Since another deinstall and reinstall via PaperUI did not help, I tried a “locate jeelink” to find out, where the related components are installed. I got:
# locate jeelink
/srv/openhab2-addons/org.openhab.binding.jeelink-2.1.0-SNAPSHOT.jar
/srv/openhab2-sys/addons/org.openhab.binding.jeelink-2.1.0-SNAPSHOT.jar
/srv/openhab2-userdata/tmp/mvn/org/openhab/binding/org.openhab.binding.jeelink
/srv/openhab2-userdata/tmp/mvn/org/openhab/binding/org.openhab.binding.jeelink/2.2.0
/srv/openhab2-userdata/tmp/mvn/org/openhab/binding/org.openhab.binding.jeelink/2.2.0/org.openhab.binding.jeelink-2.2.0.jar
/srv/openhab2-userdata/tmp/mvn/org/openhab/binding/org.openhab.binding.jeelink/2.2.0/org.openhab.binding.jeelink-2.2.0.jar.sha1
/usr/share/openhab2/addons/org.openhab.binding.jeelink-2.1.0-SNAPSHOT.jar
/var/lib/openhab2/tmp/mvn/org/openhab/binding/org.openhab.binding.jeelink
/var/lib/openhab2/tmp/mvn/org/openhab/binding/org.openhab.binding.jeelink/2.2.0
/var/lib/openhab2/tmp/mvn/org/openhab/binding/org.openhab.binding.jeelink/2.2.0/org.openhab.binding.jeelink-2.2.0.jar
/var/lib/openhab2/tmp/mvn/org/openhab/binding/org.openhab.binding.jeelink/2.2.0/org.openhab.binding.jeelink-2.2.0.jar.sha1
So it seems that there are some leftovers from OpenHAB 2.1 in /usr/share/openhab2/addons/ and /srv/openhab2-sys/addons/
Can I simply remove the jars and replace them with the 2.2 versions to resolve the issue or is there another canonical way to deal with such issues?
Thanks in advance and Merry Christmas,
Roland
If you do not have pca301 sockets, remove the jar that you have manually installed, and after that install using the paper ui.
Use the jar that i linked a few posts back If you have pca301 sockets.
Hi Volker,
thanks for the hint. I have now deleted the jar file from /usr/share/openhab2/addons/ but it seems that I’m somehow stuck in the shallow waters between PaperUI and manual installation. PaperUI still shows the Jeelink Binding as installed (version 2.2). For some reason it won’t uninstall when I try to do so im PaperUI. I have also tried to deinstall it with “bundle:uninstall” from the OpenHab console. That seemed to work, but after a restart of OpenHab, bundle:list" gives me that:
...
253 │ Active │ 80 │ 2.2.0 │ JeeLink Binding
And still my Jeelink Things remain in state “UNINITIALIZED”.
EDIT:
I was able to revert to a working state by stopping OpenHab, then moving the old 2.1 binding file back to /usr/share/openhab2/addons/ again and starting OpenHab. Now my Jeelink USB Thing shows as “ONLINE” and I’m able to receive data from the sensors.
From there I tried to switch to the new version of the binding following the steps in the Frequently Asked Questions (FAQs) “How can I reactivate the release version of an add-on?” but without success.
Even when I stop Openhab, remove the old jar file, start OpenHab again, PaperUI still shows the binding als “Installed”. When I try to use the deinstall button, nothing happens. The process-circle just keeps spinning.
EDIT2:
I was able to solve the issue: After removing the manually installed 2.1.0 binding as descibed in the FAQ, I had to remove the Thing for the USB Receiver too and create a new one for the new 2.2.0 binding. It seems that the new version does not pick up the Things from the older version automatically. After creating a new Thing for the USB Receiver with the new binding, I was able to reactivate the sensors by switching the Things to the new Bridge.
Many thanks,
Roland
You must have had a very old version of the binding that still used jeelink as thing type for the bridge. That has changed back in August, when a dedicated thing type has been introduced for tcp connected sticks. From then on the old configuration was no longer working and the sticks had to be removed and created again to get the new thing type, which is either jeelinkUsb or jeelinkTcp.
If you have already updated after this change (and adapted the config), then upgrading to the release version should be as simple as deleting the jar and installing with paper ui.
I got a Problem with my Jeelink, hopefully you can support me 
Jeelink works fine on OH2 (device online). But it is not able to find a weather station.
I switched from FHEM to OH2 without a new Jeelink Flash. I opened allready a thread in the beginner Forum… Forum Jeelink
Many Thanks
Markus
That worked very well.
Thank you for your support and again for that wonderful binding! 
as the pull request has been merged, I have now created a new branch for making the consumption unit configurable: https://github.com/vbier/openhab2-addons/tree/ec3kUnit8
As I have no ec3k sensors, can you please test if this works as expected?
Hi @vbier, thanks again for this change. I just want to let you know that I don’t need this anymore. Sorry for that.
I decided to go a different route for my jeelink hardware/openhab integration.
Hello all
could somebody explain me how to perform a battery change on that sensors?
I just changed the battery, did a search in paperUI, deleted the new found thing and inserted the ID of that found thing in my already existing one.
Unfortunately, it seems that the internal ID stays the same, see this log entries:
'jeelink:lacrosse:236' changed from ONLINE to OFFLINE
2018-01-13 14:56:50.446 [home.event.InboxAddedEvent] - Discovery Result with UID 'jeelink:lacrosse:64' has been added.
==> /var/log/openhab2/openhab.log <==
2018-01-13 14:56:50.448 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'jeelink:lacrosse:64' to inbox.
==> /var/log/openhab2/events.log <==
2018-01-13 14:57:24.939 [me.event.InboxRemovedEvent] - Discovery Result with UID 'jeelink:lacrosse:64' has been removed.
2018-01-13 14:57:36.304 [me.event.ThingUpdatedEvent] - Thing 'jeelink:lacrosse:236' has been updated.
2018-01-13 14:57:36.313 [hingStatusInfoChangedEvent] - 'jeelink:lacrosse:236' changed from OFFLINE to UNKNOWN
2018-01-13 14:57:38.542 [hingStatusInfoChangedEvent] - 'jeelink:lacrosse:236' changed from UNKNOWN to ONLINE
The thing is still called jeelink:lacrosse:236
This is very confusing…
Furthermore it seems that the configured Update intervale does not work any more after the battery change.
The update intervale is set tu 60 seconds, but see the following log entries regarding this thing:
2018-01-13 15:03:10.486 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 49 to 41
2018-01-13 15:03:10.490 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from ON to OFF
2018-01-13 15:03:15.638 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 41 to 45
2018-01-13 15:03:36.423 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.4 to 21.5
2018-01-13 15:03:36.436 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 45 to 47
2018-01-13 15:03:36.447 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from OFF to ON
2018-01-13 15:04:02.116 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.5 to 21.6
2018-01-13 15:04:02.119 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 47 to 49
2018-01-13 15:04:10.482 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.6 to 21.4
2018-01-13 15:04:10.492 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from ON to OFF
2018-01-13 15:04:10.499 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 49 to 41
2018-01-13 15:04:15.603 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorBadezimmer_Luftfeuchtigkeit changed from 42 to 41
2018-01-13 15:04:15.671 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 41 to 45
2018-01-13 15:04:36.449 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 45 to 47
2018-01-13 15:04:36.454 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.4 to 21.5
2018-01-13 15:04:36.459 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from OFF to ON
2018-01-13 15:05:02.123 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.5 to 21.6
2018-01-13 15:05:02.125 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 47 to 49
2018-01-13 15:05:10.479 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.6 to 21.4
2018-01-13 15:05:10.488 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 49 to 41
2018-01-13 15:05:10.501 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from ON to OFF
2018-01-13 15:05:15.703 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 41 to 45
2018-01-13 15:05:36.471 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 45 to 47
2018-01-13 15:05:36.477 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from OFF to ON
2018-01-13 15:06:02.127 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.4 to 21.6
2018-01-13 15:06:02.132 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 47 to 49
2018-01-13 15:06:10.494 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.6 to 21.4
2018-01-13 15:06:10.499 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 49 to 41
2018-01-13 15:06:10.502 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from ON to OFF
2018-01-13 15:06:15.736 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 41 to 45
2018-01-13 15:06:36.489 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 45 to 47
2018-01-13 15:06:36.494 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from OFF to ON
2018-01-13 15:07:02.130 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.4 to 21.6
2018-01-13 15:07:02.133 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 47 to 49
2018-01-13 15:07:10.487 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.6 to 21.4
2018-01-13 15:07:10.500 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 49 to 41
2018-01-13 15:07:10.512 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from ON to OFF
It looks like every status change is recognized by openhub.
I have some of these sensors but only this one is doing like this, since the first battery change.
Any hints are highly welcome.
Thank you in advance.
Matthias
The thing id does never change for an existing sensor, otherwise you would have to update all your item definitions every time you replace batteries, as these are linked to the thing ids.
Regarding the update interval, did you make any other configuration changes, e.g. buffer size?
Or you might be affected by a bug in the binding where values are published several times after configuration change. Does the problem persist if you restart openhab?
Otherwise enable trace logging and paste a part of your openhab.log showing a few updates.
Thank you for your fast reply, Volker.
In deed, a restart of openhab stopped it.
Thanks,
Matthias
You are welcome. The bug is already fixed in 2.3.0-snapshot. So if you want to avoid this problem in the future, you can upgrade the binding.
Hello!
Thanks for developing this awesome Binding! I am using the version (binding-jeelink - 2.2.0) of the jeelink binding since it has been released and i am experiencing a confusing behaviour.
I have 4 temperature sensors bound and everything works until i reboot the system.
After the reboot (or openhab service restart) the temperature, humidity, and battery new channel loose their channel links. But this happens only with one of those four sensors… the other remaining three seem to be unaffected by the channel link losses.
As a matter of fact that means for me that my temperature control is not working until i rellink the channels again through the paper ui (pretty easy to do - but you have to be aware about that problem - so its really annoying).
Release = Raspbian GNU/Linux 8 (jessie)
Kernel = Linux 4.9.35-v7+
Platform = Raspberry Pi 3 Model B Rev 1.2
openHAB 2.2.0-1 (Release Build)
binding-jeelink - 2.2.0
I use the simple Item Linking Mode
The openhab.log only mentions rule and sitemap errors. But those are subsequent faults of the lost channel links of this sensor.
Is it possible that this problem could be related to this? https://community.openhab.org/t/mysensors-binding-channel-names-disappearing-in-paperui-control-page-after-reboot/35706
There is a mention for a fix for binding developers --> I tried the workarounds, they are not working for me.
As you can see in the attached screenshot i have to relink the other channels. After that my rules and sitemaps work as they should again. This error is completely reproducible. It happens after each reboot!
Do you have an idea why this is happening? Is there a solution, a simple fix? Is it possible to make a rule to relink the channels after reboot?
With best regards and thanks in advance
Walter
Whether channels are linked or not is not part of the binding’s responsibility. This seems to be a bug in the openHAB code. I have used paper UI to link items only for a few days and then setup items files. Have you tried that?
The PCA301 code got merged into the 2.3 branch yesterday. 
I have another change in the pipeline that should make sure that the init commands are sent correctly.
Previously, the init commands have been sent when the first reading was received. This did obvioulsy not work if you needed an init command to change the datarate in order to receive readings.
Therefore I have now changed the code to send the init commands after the first reading has been received or a configurable timeout has occurred. The timeout is 15s by default and can be changed in the stick configuration.
Together with the changes that have been merged, this should now make LGWs work. I have destroyed some parts with my soldering iron in the process of building a LGW. But now that I got it working I have tested the binding code and everything looks good so far.
I have connected LaCrosse and PCA301 sensors and both are working fine.
It would be nice if some of you could test the updated binding before I create a pull request:
https://github.com/vbier/openhab2-addons/raw/jars/addons/binding/org.openhab.binding.jeelink/org.openhab.binding.jeelink-2.3.0-SNAPSHOT.jar
Hallo Volker,
nach meinem Umzug und gecrashtem NUC samt FHEM wollt ich das optisch viel ansprechende Openhab testen.
Einfache Sachen wie Hue, AVR, TV… laufen top.
Im FHEM hatte ich zwei Jeelinks, einer für meine PCA301 der andere für TFA Dostmann.
Beide liefen unter FHEM, muss da nun ein neuer Sketch drauf?
Hab eben deiner News bzgl. der PCA301 gelesen aber bekomm die einfach nicht zum laufen.
Gibt es etwas ähnliches wie das Wiki im FHEM für alle Aktoren für Openhab?
Sowas ist echt einfacher für Noobs.
Gruß Stefan
Step by step:
- you download the jar, put it into the openHAB addons folder
- you wait for the add-on to be shown in the paper UI
- you make sure the serial device can be seen by openHAB (only if connected directly via usb)
- you create a Jeelink thing manually in the paper UI inbox
- you scan for sensors using the paper UI inbox
- you create items file(s) linking the channels to items (if paper UI simple mode is disabled)
- you see updates and can control things in the paper UI
- you use a UI of your choice and use the items
- you write a blog or wiki article on how you have set everything up and link it here for other noobs
Google the steps to get detailed information.
If this fails, write detailed information on what you have tried and what did not work as expected