New Jeelink Openhab2 Binding

After recreating the usb device with deployed jar, it works well. That’s it!

Now I have to find out, why my jeelink stick don’t receive my IT+ WS-1600. Toggling the bit rates seems to work with “5m 30t v”, but there is no data. My stick is on:

LaCrosseITPlusReader.10.1q (RFM12 f:868300 t:30~5)]

I just created a pull request that stops the cyclic value propagation when the sensors go offline so no stale values are reported any more.

I still have to look into why you do not longer get readings. From looking at the code, I did not find any plausible explanation of the behavior. Whenever there are errors in communication with the stick, the thing for the stick should go offline. Since it did not do that, it looks like the stick simply does not get any readings. I have no idea if this might be due to a hardware problem with your stick or maybe a problem in openHABs serial library…

Can you check on the command line if the stick still works when you have the problem the next time? Do you see something when you tail the serial device in the console? Is the device still in use by openHAB (check with lsof)?
If it is still in use, what happens when you unplug the stick while openHAB is running? Does the state then change to OFFLINE?

Hi Volker, I was able to test the values via console today (with 1d debug-mode).

End receiving, HEX raw data: 6 FF 7C 6D FE 8C 3C E 7E 53 96 5F FA E8 E8 0 
## CRC FAIL ##
No valid start
No valid Temperature: 87.30
No valid Level: 828.50
No valid Voltage: 16.40

End receiving, HEX raw data: 5 AF 4E 88 30 EE 36 E4 C3 8A 31 6F B C6 7F C1 
## CRC FAIL ##
No valid start
No valid Temperature: 108.80
No valid Level: 577.00

End receiving, HEX raw data: 58 1F 25 2B 44 47 A9 3F 70 7B 83 2E 1F 54 F2 26 
## CRC FAIL ##
No valid start

But there are also some real values:

End receiving, HEX raw data: 9E 86 14 37 13 AA AA 0 0 F0 8A A0 B1 5B 44 FD 
OK 9 58 1 4 190 55

In order to find out what readings are received from your weather station, make it as simple as possible. Do not use toggle mode, but set frequency with 2r as init command.
Enable TRACE level in the openHAB console, and post what the binding reads from the stick.

I changed the command to 2r and got no data at the log but the following at the console output of the device:

End receiving, HEX raw data: A4 75 6 61 10 48 20 0 30 FE 20 FF 7D 80 13 7 
## CRC FAIL ##
No valid start
No valid Level: 375.00
No valid Voltage: 1.00

End receiving, HEX raw data: 1B D2 1F 70 73 9B C6 EE BD F0 3D A0 3E EF 47 91 
## CRC FAIL ##
No valid start
No valid Temperature: 117.00
No valid Level: 660.50

End receiving, HEX raw data: 11 13 F FF 4D 89 42 96 5 B2 D5 FD FF BD FC 9B 
## CRC FAIL ##
No valid start
No valid Temperature: 126.50

End receiving, HEX raw data: A4 75 6 61 10 48 20 0 30 FE 41 FE FB 0 1F F9 
## CRC FAIL ##
No valid start
No valid Level: 375.00
No valid Voltage: 1.00

I just reallized, that there are also no values at the WS-1600 IT+ Receiver Display - just temperature and humdity.

In the FHEM thread that you also posted to, somebody mentioned that you need to have rain and wind sensors connected to the TX22. Have you done that? From reading the FHEM thread, It sounds like you will not get any values from the jeelink as long as the rain and wind sensors are not correctly connected. And i would assume that your weather station will show rain and wind values once the hardware is setup correctly (if it is not broken). So once the weather station shows all values, you can try to get a log again and I will look at it.

Hi Volker, like described @fhem I realized, that also the base station receives no more values, so the sender could be broken. Tests with connected and unconnected sensors at the tx22, makes no difference. The only values receivd are that one posted before.

I will perform an exchange of the device and try again.

Hi Volker,
im switching my big home-automation environment from FHEM (Tablet-UI) to OpenHAB2 and what should I say, im pretty happy with this decision; OpenHAB2 is great. Now im struggling with my 10 PCA301 devices and i hope you can help me/us. These devices are cheap and really good (power-measurement and switching power on/off). I have 2 Jeelinks (ttyUSB0/ttyUSB1) connected to my OpenHAB2 System (with the LaCrosse and PCA301 sketches). As I read in this topic, PCA301 is not supported right now. I don't know how much time you have to spend to support this devices too (Im not a programmer). But I would send you one of my devices (as a present :slight_smile: ), perhaps you can figure it out how to support them with your binding, that would be really great.

Sorry to disappoint you, but I am mostly busy with other stuff (aka HABPanelViewer) at the moment. You can send me the device, and I will look into it when I have time, but I can not make any promises on how long it will take to add support.

No problem, as a HABPanel-User I`m happy to see you are working on this (that’s great too !).
Just send me your address, i will ship a PCA301 to you (doesn’t matter how long it will take :slight_smile: )

The PCA301 has arrived. I will try to add support as soon as I have the time. I will keep you updated with the progress.

Unfortunately, the PCA301 sketch does not seem to work with Jeelink v3c, which is the one I have. I have now ordered some parts to build a Jeelink clone.

Hi Volker,

first of all thank you very much for providing your JeeLink binding! :slight_smile:
Unfortunately I have problems to get it running.
I am completely new to openHab2 and are migrating from fhem.
I am running a Synology DS211 with DSM 6.1.3 and I have installed openHab 2.2.0 Build 1082. After installing the JeeLink binding and creating a JeeLink usb receiver thing, the openHab service is crashing everytime it gets started.
My JeeLink usb receiver is connected to /dev/ttyUSB0 and was running under fhem without any problems (using the LaCrosse sketch).
I have read about putting this line somewhere, but I don’t know where to put this on my Synology:

Do you have an idea what is going wrong?


Here are some log file details:
2017-11-19 19:16:19.931 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at
2017-11-19 19:16:20.125 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at
2017-11-19 19:17:40.923 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
2017-11-19 19:17:43.000 [INFO ] [assic.internal.servlet.WebAppServlet] - Started Classic UI at /classicui/app
2017-11-19 19:17:43.324 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2017-11-19 19:17:44.248 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
2017-11-19 19:17:45.323 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2017-11-19 19:17:45.645 [DEBUG] [org.openhab.binding.jeelink ] - BundleEvent STARTING - org.openhab.binding.jeel
2017-11-19 19:17:45.651 [DEBUG] [org.openhab.binding.jeelink ] - BundleEvent STARTED - org.openhab.binding.jeeli
2017-11-19 19:17:45.782 [DEBUG] [org.openhab.binding.jeelink ] - ServiceEvent REGISTERED - {org.eclipse.smarthom
e.core.thing.binding.ThingHandlerFactory}={,,, service.bun
dleid=208, service.scope=bundle} - org.openhab.binding.jeelink
2017-11-19 19:17:46.644 [DEBUG] [elink.internal.JeeLinkHandlerFactory] - creating JeeLinkHandler for thing 59271af4…
2017-11-19 19:17:46.695 [DEBUG] [elink.internal.JeeLinkHandlerFactory] - registering sensor discovery service…
2017-11-19 19:17:46.771 [DEBUG] [org.openhab.binding.jeelink ] - ServiceEvent REGISTERED - {org.eclipse.smarthom
e.config.discovery.DiscoveryService}={, service.bundleid=208, service.scope=singleton} - org.openhab.bindi
2017-11-19 19:17:47.534 [DEBUG] [l.connection.JeeLinkSerialConnection] - Creating serial connection for port /dev/ttyUSB
0 with baud rate 57600…
2017-11-19 19:17:47.542 [DEBUG] [l.connection.JeeLinkSerialConnection] - Opening serial connection to port /dev/ttyUSB0
with baud rate 57600…

I have found another JRE crash log file:

A fatal error has been detected by the Java Runtime Environment:

SIGILL (0x4) at pc=0x4a0c9c1c, pid=2736, tid=0x4e23f470

JRE version: Java™ SE Embedded Runtime Environment (8.0_151-b12) (build 1.8 .0_151-b12)

Java VM: Java HotSpot™ Embedded Client VM (25.151-b12 mixed mode linux-arm )

Problematic frame:

C [] JNI_OnLoad+0x28

Core dump written. Default location: /volume1/homes/openhab2/userdata/core or core.2736

If you would like to submit a bug report, please visit:


The crash happened outside the Java Virtual Machine in native code.

See problematic frame for where to report the bug.

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j java.lang.ClassLoader$NativeLibrary.load(Ljava/lang/String;Z)V+0
j java.lang.ClassLoader.loadLibrary0(Ljava/lang/Class;Ljava/io/File;)Z+328
j java.lang.ClassLoader.loadLibrary(Ljava/lang/Class;Ljava/lang/String;Z)V+48
j java.lang.Runtime.load0(Ljava/lang/Class;Ljava/lang/String;)V+57
j java.lang.System.load(Ljava/lang/String;)V+7
v ~StubRoutines::call_stub
j java.lang.Class.forName0(Ljava/lang/String;ZLjava/lang/ClassLoader;Ljava/lang /Class;)Ljava/lang/Class;+0
j java.lang.Class.forName(Ljava/lang/String;)Ljava/lang/Class;+11
v ~StubRoutines::call_stub
j org.openhab.binding.jeelink.internal.connection.JeeLinkSerialConnection.openC onnection()V+33
j org.openhab.binding.jeelink.internal.JeeLinkHandler.initialize()V+77
j org.eclipse.smarthome.core.thing.internal.ThingManager$ d;+4
j org.eclipse.smarthome.core.thing.internal.ThingManager$ ect;+1
j org.eclipse.smarthome.core.common.SafeMethodCaller$ a/lang/Object;+11
J 1857 C1 (126 bytes) @ 0x40b31c80 [0x40b 31be0+0xa0]
J 2019 C1 java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurren t/ThreadPoolExecutor$Worker;)V (225 bytes) @ 0x40b5d4c4 [0x40b5d2f0+0x1d4]
j java.util.concurrent.ThreadPoolExecutor$
v ~StubRoutines::call_stub

It looks like there is a problem with the native code of the NRJavaSerial library that openhab uses to access the serial ports. Try to find and check if it has missing dependencies with ldd.

See, which might be your problem (or at least related).

Thanks for your response.
I have tried the ldd, but I get only this result:

/volume1/@appstore/openHAB2/userdata/tmp/libNRJavaSerial_openhab2_0$ ldd
ldd: warning: you do not have execution permission for `./’
statically linked

Calling with sudo does not help. Do you have any ideas?

I have no idea how to check if the library has undefined symbols. Did you try to replace the library with the updated one from the linked bug report? See

You can also ask in the more general part of the forum, as I am pretty sure this is not jeelink related, but a problem with the nrjavaserial lib.

I have received the parts for the Jeelink clone, soldered and programmed it. Just did a quick test on the serial console and was able to “see” the socket you have sent me. I could as well turn it on and off with the serial console, so the hardware works.

I have added support for PCA301 sockets.

The new version should support discovery of pca301 sockets, as well as getting the values and turning the socket on and off. I have tested it with the socket you sent me, it’s your part to test with several devices.

Get the jar from here:

Please test and report back if there are problems or if it works as expected.

Hello Volker, greetings from Magdeburg! Genialer Nachname :smile:
I’ve assembled a LaCrosseGateway with 3x RFM69HCW and got it working with your bindings tcp support,
but there some problems.
If the connection to the LGW is lost, it does not reconnect, i must restart the whole openhab with “service openhab2 restart” then it works again.
And with the newest version i cant see any PCA301 entry @ Paper UI, is it for manually config only?

The LaCrosseGateway works differently than the Jeelink with pcaSerial sketch. It does not support the commands to list the known devices, or to switch or poll the socket.
Therefore discovery only works if you are lucky and the sensor actually sends a value while discovery is in progress. So make sure you can see the pca301 in the LaCrosseGateway web UI and adjust the polling rate to 5 seconds for the discovery.
If the sensors are still not found enable TRACE level and send me the relevant part of the log.

But as I already said, you will only be able to see the values, not to control the socket.

Edit: regarding the connection problem: enable DEBUG level, wait for disconnect and send me the relevant part of the log.