New Jeelink Openhab2 Binding

Hi,

I am back with an update from my Mobile Alerts adventure with a conclusion and 3 new issues.

First the conclusion: It does not work with the MA sensors. The previous rare readings where most likely stray data from my neighbors. (Which was actually nice at it gave me 3 sensors I could test and successfully integrate in Openhab using the Jeelink binding.)

Meanhwile, I am pretty sure the MA sensors use a different protocol. I think they use a global unique ID otherwise adding sensors in the app with a QR code and changing battery without re-registering (even when separated for multiple days from the gateway) would not work.

So being able to use the MA sensors would be pretty nice, as we would not have the ID problem.


One of the issues I found has nothing to do with the binding but with my PINE64 (Ubuntu 16.04) which I used initially for my tests. It simply gets no sensor data from the Jeelink. To simplify the setting I used picocom and also echo / tail -f to communicate with the Jeelink. I could read teh version, set frequency and data rate and turn off the LED but no data. Also to note: cat never gave me anything and immediately returned when called.

Using my Microsoft Surface Book (Windows 10), I got readings every few seconds from my neighbor’s sensors.

I also used a 2m USB 3 extension to eliminate disturbance from the PINE64 being the cause and also left the PINE64 running with everything positioned the same while successfully reading data within Windows.

Next to the cat closing immediately I also have some other different behavior. Looks like on the PINE64, the first command after opening a connection is lost. You can see it in the log I posted previously, where I had to scan twice to get a response from the Jeelink. Also when I connect directly via tail -f, and issue a echo “v”, I get nothing, but all following “v” give me the version.

Feels like I have to wake up the Jeelink every time first. I guess it is some faulty USB driver implementation or maybe just a wrong driver or config. Worst case it is a hardware issue. Had no time to research it yet.


The second issue had no impact in any functionality for me, but I noticed that scanning for a Jeelink device under Windows causes a Java exception when the device is already online.

I used the Openhab 2.0.0 release version with the latest JAR for the binding downloaded last night (2.0.0.201701211052)

10:06:39.455 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Stopping discovery of JeeLink USB Receivers...
10:06:39.456 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Stopped discovery of JeeLink USB Receivers.
10:06:39.456 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Starting discovery of JeeLink USB receivers...
10:06:39.456 [DEBUG] [nk.discovery.JeeLinkDiscoveryService] - Iterating ports...
10:06:39.764 [DEBUG] [nk.discovery.JeeLinkDiscoveryService] - Scanning port COM3...
10:06:39.765 [INFO ] [link.handler.JeeLinkSerialConnection] - Creating serial connection for port COM3 with baud rate 57600...
10:06:39.765 [INFO ] [link.handler.JeeLinkSerialConnection] - Opening serial connection to port COM3 with baud rate 57600...
10:06:39.779 [ERROR] [nk.discovery.JeeLinkDiscoveryService] - Port could not be opened: COM3
org.openhab.binding.jeelink.handler.ConnectException: gnu.io.PortInUseException: Unknown Application
        at org.openhab.binding.jeelink.handler.JeeLinkSerialConnection.openConnection(JeeLinkSerialConnection.java:101)
        at org.openhab.binding.jeelink.discovery.JeeLinkDiscoveryService.startScan(JeeLinkDiscoveryService.java:56)
        at org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.startScan(AbstractDiscoveryService.java:199)
        at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:382)
        at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScans(DiscoveryServiceRegistryImpl.java:358)
        at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:216)
        at org.eclipse.smarthome.io.rest.core.discovery.DiscoveryResource.scan(DiscoveryResource.java:84)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.8.0_121]
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)[:1.8.0_121]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)[:1.8.0_121]
        at java.lang.reflect.Method.invoke(Unknown Source)[:1.8.0_121]
        at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)[159:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)[159:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)[159:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)[159:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)[159:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)[159:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)[159:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)[159:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)[159:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)[157:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)[157:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.internal.Errors.process(Errors.java:315)[157:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.internal.Errors.process(Errors.java:297)[157:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.internal.Errors.process(Errors.java:267)[157:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)[157:org.glassfish.jersey.core.jersey-common:2.22.2]
        at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)[159:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)[159:org.glassfish.jersey.core.jersey-server:2.22.2]
        at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473)[155:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
        at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427)[155:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388)[155:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341)[155:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228)[155:org.glassfish.jersey.containers.jersey-container-servlet-core:2.22.2]
        at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76)[10:com.eclipsesource.jaxrs.publisher:5.3.1.201602281253]
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)[81:org.eclipse.jetty.servlet:9.2.19.v20160908]
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)[81:org.eclipse.jetty.servlet:9.2.19.v20160908]
        at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)[173:org.ops4j.pax.web.pax-web-jetty:4.3.0]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)[80:org.eclipse.jetty.server:9.2.19.v20160908]
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)[79:org.eclipse.jetty.security:9.2.19.v20160908]
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)[80:org.eclipse.jetty.server:9.2.19.v20160908]
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)[80:org.eclipse.jetty.server:9.2.19.v20160908]
        at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:287)[173:org.ops4j.pax.web.pax-web-jetty:4.3.0]
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)[81:org.eclipse.jetty.servlet:9.2.19.v20160908]
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)[80:org.eclipse.jetty.server:9.2.19.v20160908]
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)[80:org.eclipse.jetty.server:9.2.19.v20160908]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)[80:org.eclipse.jetty.server:9.2.19.v20160908]
        at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80)[173:org.ops4j.pax.web.pax-web-jetty:4.3.0]
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)[80:org.eclipse.jetty.server:9.2.19.v20160908]
        at org.eclipse.jetty.server.Server.handle(Server.java:499)[80:org.eclipse.jetty.server:9.2.19.v20160908]
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)[80:org.eclipse.jetty.server:9.2.19.v20160908]
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)[80:org.eclipse.jetty.server:9.2.19.v20160908]
        at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)[72:org.eclipse.jetty.io:9.2.19.v20160908]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)[83:org.eclipse.jetty.util:9.2.19.v20160908]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)[83:org.eclipse.jetty.util:9.2.19.v20160908]
        at java.lang.Thread.run(Unknown Source)[:1.8.0_121]
Caused by: gnu.io.PortInUseException: Unknown Application
        at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:475)
        at org.openhab.binding.jeelink.handler.JeeLinkSerialConnection.openConnection(JeeLinkSerialConnection.java:70)
        ... 54 more
10:06:39.795 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Closing all open ports...
10:07:09.457 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Stopping discovery of JeeLink USB Receivers...
10:07:09.458 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Stopped discovery of JeeLink USB Receivers.

I guess the COM port does not close properly.


Last issue is bit more annoying but can be worked around and is maybe rather a bug in the Openhab Paper UI and not in the binding.

Whenever I update the init commands and save it, it does not show the changes whenever I go back to editing. Only when I save them again, it also updates in the GUI.
Example:

  1. Enter edit mode: current setting: “a0;v” - shown setting: “a0;v” - change to “a0” and save --> is applied to the device
  2. Enter edit mode: current setting: “a0” - shown setting: “a0;v” - exit without saving --> nothing happens with device
  3. Enter edit mode: current setting: “a0” - shown setting: “a0;v” - exit with saving --> nothing happens with device
  4. Enter edit mode: current setting: “a0” - shown setting: “a0” - exit with saving --> nothing happens with device

Sorry to hear your MA sensors will not work.

Regarding your 3 issues:

  • waking up the USB receiver: if you find some other people with the same problem, i can add some kind of workaround to the binding, but as long as you are the only one with the problem I would leave the binding as is
  • serial port in use: this should only happen when discovery for a jeelink is running (not for sensors). In this case
    a) it is in use by the binding itself (then the stick has already been discovered)
    b) it is in use by another binding (then most likely no jeelink is to be found)
    => this should have no impact on functionality (I could reduce this to a warning without a stack trace)
  • problem with paper ui: I just tried, but could not reproduce the behaviour

I set up the group/user correctly, but a cat /dev/ttyUSB0 prints out nothing - either as root or openhab user.

Okay, cat returns immediately on my machine, too. I was so confident that this behaved differently yesterday.

tail -f /dev/ttyUSB0

does work now. This prints lines coming from the sensors like

OK 9 30 1 4 198 34

If I unplug the stick and plug it back in I get

[LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:17241)]
OK 9 58 1 4 198 34
OK 9 38 1 4 209 42
OK 9 30 1 4 198 34

This is what I would expect. But all this only works only as long as I disable the jeelink in openHAB.

My Jeelink is configured like this:

openhab@homeautomation:~$ stty -F /dev/ttyUSB0
speed 57600 baud; line = 0;
min = 0; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

This is my config;

stty -F /dev/ttyUSB0
speed 57600 baud; line = 0;
min = 0; time = 0;
ignbrk -brkint -icrnl -imaxbel
-opost
-isig -icanon -iexten -echo -echoe -echok -echoctl

But
tail -f /dev/ttyUSB0
returns nothing, even with fhem stopped and jeelink freshly plugged in. Could it somehow be a wrong firmware? I used the default Lacrosse firmware for reading the cheap temperature sensors.

There are some differences between your device config and mine, but I am not sure if this is the reason. In my understanding, my binding should do exactly the same that the FHEM binding does. So if FHEM works, then my binding should work, too. They both open the device and read text from it, which essentially is the same as invoking tail on the device from the command line.
Even the firmware should be identical, I downloaded it from the FHEM repository, so most likely it is the same that you are using. As you could see in my post, it is named LaCrosseITPlusReader.

I am running out of ideas. Can you check if some other process is accessing the stick by issuing

sudo lsof /dev/ttyUSB0

I also did not manage to get my connection to work with stty although everything was setup right in my opinion. I then used picocom and this worked fine. Also once picocom initialized the connection, tail -f will work afterwards as well (after you closed picocom).

Thanks for considering a workaround but it would not help. The Jeelink would need to do the same, otherwise I never receive any readings. I have to fix this issue on the driver/hardware level.

I also could not reproduce the Paper UI issue today although it was there before all the time. But I could not do the exact same test at the moment, so I will try to reproduce it again later.

is there a calculation problem with ec3k?
openhab says:

2017-01-27 22:15:05.930 [TRACE] [link.handler.JeeLinkSerialConnection] - Read line from port COM8: OK 22 88 40 0 0 24 178 0 0 24 177 0 0 1 114 8 107 8 255 1 2
2017-01-27 22:15:05.930 [DEBUG] [elink.handler.ec3k.Ec3kSensorHandler] - updating states for thing 5828: currWatt=217 (217.38506), maxWatt=230, consumption=0, secondsOn=6321, secondsTotal=6322

and my display for the sockets: 215,5 W

in openhab i also missing the value behind the comma, its always 0, but only if the value comes over 100
under 100 it shows the value behind the comma

when i shutdown the device on the socket, the value decreases very slowly. whats the problem?

edit:
found the solution
i’ve set the buffer to 0 and then the value is updating realtime and show true value
only the problem with 0 after comma persists

I have pushed an updated version. Please check if the rounding problem is fixed.

2.0.0.201701272210 and still zero after comma

edit:
my fault, now the problem is only sometimes in paper ui
in openhab app on my smartphone its all perfect. thanks!

I’m new to OpenHAB and just installed the Jeelink Binding. Thank’s for this great binding - I would not have changed from FHEM if I had not found this. :slight_smile:

Unfortunately I got a little bit stuck right now. PaperUI recognised several LaCrosse Seonsors and I can see temperture and humidity as desired. So far so good. But if I define the items as below, they are not displayed in the BasicUI.

Items like:
Number Temperature_WZ "Wohnzimmer" <temperature> (gLaCrosse, gLaCrosseHumChart) { channel="jeelink:lacrosse:40:temperature" }

Sitemap entry like:
Text item=Temperature_WZ label="Temperatur"

Du you have any idea, why the item does not get displayed?

Btw: For some of my seonsors the string “NaN” is displayed instead of the actual values (PaperUI). Why is that?

Thanks in advance for support.

I just answered the “NaN”-Question by myself. These Seonsors had never gotten values above the minimum valid temperature. After changing this value, they worked as wanted.

Is “Temperatur” shown in the UI and only the values are missing? I am no expert on this, but would try something like:
Text item=Temperature_WZ label="Temperatur [%s]"

That worked, tkanks! :slight_smile: Obviously I’m also no expert on this…

Thanks for the binding. I tried to add several Technoline TX 29 DTH-IT sensors with an original Jeelink v3 stick. The stick shows up in PaperUI (online). Unfortunately I was not able to connect any of the sensors. The sensors just don’t show up.

Was anyone able to add Technoline TX 29 DTH-IT sensors? Any hints?

Thanks!

1 Like

That are the exact sensors i used to write the binding. So what exactly did you do? Run discovery, add the stick, run discovery again and no sensors show up? Enable debug logging, run the discovery and paste the relevant part of the log,

Hi Volker

Thanks for your support. I just retried to setup the sensors with a blank Openhabian environment. Unfortunately the result is the same. Here are the steps:

Download latest snapshot
https://github.com/vbier/openhab2-addons/blob/complete/addons/binding/org.openhab.binding.jeelink/org.openhab.binding.jeelink-2.0.0-SNAPSHOT.jar

Install openhab-transport-serial

ssh openhab@localhost -p 8101
feature:install openhab-transport-serial

Add user to group

ls -al /dev/ttyUSB0

–> ls: cannot access /dev/ttyUSB0: No such file or directory
Ok, USB stick was not connected --> Connect Jeelink and retry

ls -al /dev/ttyUSB0

crw-rw---- 1 root dialout 188, 0 Mar 5 20:33 /dev/ttyUSB0

sudo usermod -a -G dialout openhab

Add Biding to OH2
Copy jar to addons folder “openHAB-sys\addons”
Unfortunately write access is missing. Adding write access:

sudo chmod g+w /usr/share/openhab2/addons

Startup OH2
Check bindings → ok

Search for things
Jeelink USB stick does not appear automatically.

Add Jeelink USB stick manually
Sketch: LaCrosseITPlusReader
→ ok. JeeLink USB stick is online

Search for Jeelink Things
→ no result!

Enable Debug Logging:

log:set DEBUG org.openhab.binding.jeelink

Extract of log file:

2017-03-05 18:03:06.663 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at /start
2017-03-05 20:44:09.610 [INFO ] [arthome.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2017-03-05 20:44:09.971 [INFO ] [basic.internal.servlet.WebAppServlet] - Started Basic UI at /basicui/app
2017-03-05 20:44:10.085 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel
2017-03-05 20:45:30.916 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Stopping discovery of JeeLink USB Receivers...
2017-03-05 20:45:30.924 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Stopped discovery of JeeLink USB Receivers.
2017-03-05 20:45:30.929 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Starting discovery of JeeLink USB receivers...
2017-03-05 20:45:31.046 [INFO ] [link.handler.JeeLinkSerialConnection] - Creating serial connection for port /dev/ttyUSB0 with baud rate 57600...
2017-03-05 20:45:31.048 [INFO ] [link.handler.JeeLinkSerialConnection] - Opening serial connection to port /dev/ttyUSB0 with baud rate 57600...
2017-03-05 20:45:36.072 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Creating 0 discovered things...
2017-03-05 20:45:36.074 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Discovered things created.
2017-03-05 20:45:36.076 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Closing all open ports...
2017-03-05 20:45:36.078 [INFO ] [link.handler.JeeLinkSerialConnection] - Closing serial connection to port /dev/ttyUSB0...
2017-03-05 20:46:00.928 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Stopping discovery of JeeLink USB Receivers...
2017-03-05 20:46:00.930 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Stopped discovery of JeeLink USB Receivers.
2017-03-05 20:58:51.863 [INFO ] [elink.internal.JeeLinkHandlerFactory] - creating JeeLinkHandler with sketch LaCrosseITPlusReader for thing 368e6f94...
2017-03-05 20:58:51.874 [INFO ] [elink.internal.JeeLinkHandlerFactory] - registering discovery service LaCrosseTemperatureSensorDiscoveryService...
2017-03-05 20:58:51.917 [INFO ] [link.handler.JeeLinkSerialConnection] - Creating serial connection for port /dev/ttyUSB0 with baud rate 57600...
2017-03-05 20:58:51.918 [INFO ] [link.handler.JeeLinkSerialConnection] - Opening serial connection to port /dev/ttyUSB0 with baud rate 57600...
2017-03-05 20:58:56.908 [WARN ] [ome.core.thing.internal.ThingManager] - Initializing handler for thing 'jeelink:jeelink:368e6f94' takes more than 5000ms.
2017-03-05 20:58:57.932 [INFO ] [nding.jeelink.handler.JeeLinkHandler] - JeeLinkHandler for port /dev/ttyUSB0 is ONLINE.
2017-03-05 21:02:38.726 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Stopping discovery of JeeLink USB Receivers...
2017-03-05 21:02:38.731 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Stopped discovery of JeeLink USB Receivers.
2017-03-05 21:02:38.732 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Starting discovery of JeeLink USB receivers...
2017-03-05 21:02:38.734 [DEBUG] [nk.discovery.JeeLinkDiscoveryService] - Iterating ports...
2017-03-05 21:02:38.755 [DEBUG] [nk.discovery.JeeLinkDiscoveryService] - Scanning port /dev/ttyUSB0...
2017-03-05 21:02:38.757 [INFO ] [link.handler.JeeLinkSerialConnection] - Creating serial connection for port /dev/ttyUSB0 with baud rate 57600...
2017-03-05 21:02:38.758 [INFO ] [link.handler.JeeLinkSerialConnection] - Opening serial connection to port /dev/ttyUSB0 with baud rate 57600...
2017-03-05 21:02:38.766 [DEBUG] [nk.discovery.JeeLinkDiscoveryService] - Trying for a maximum of 5 seconds to read the sketch name from the ports...
2017-03-05 21:02:43.769 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Creating 0 discovered things...
2017-03-05 21:02:43.779 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Discovered things created.
2017-03-05 21:02:43.781 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Closing all open ports...
2017-03-05 21:02:43.782 [INFO ] [link.handler.JeeLinkSerialConnection] - Closing serial connection to port /dev/ttyUSB0...
2017-03-05 21:03:08.733 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Stopping discovery of JeeLink USB Receivers...
2017-03-05 21:03:08.740 [INFO ] [nk.discovery.JeeLinkDiscoveryService] - Stopped discovery of JeeLink USB Receivers.
3 Likes

I will have to look into this later. Generally, the stick should be found by the discovery. If it is not, then the sensors won’t work either. The binding conects to the serial port (which it can, as there is no error message in the logs), and then reads the sketch name from it (which it could not, as otherwise it would have put the stick thing in the inbox).

Did you have this stick working before? If it is new, did you flash the correct sketch? If I remember correctly, the binding does not verify the sketch name. So it would not complain if you flashed the wrong sketch but added it with the correct sketch manually.

To be honest the stick is brand new and I havn’t flashed any other firmware :frowning:

Is there any manual for this task? Which firmware should I take?