I just checked, its the same with my stick. I will look into it as soon as I have the time.
I have create a pull request containing the fix for the not working init commands:
The updated jar can be downloaded here:
https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.jeelink/2.2.0-SNAPSHOT/org.openhab.binding.jeelink-2.2.0-SNAPSHOT.jar
@tailor, @oliver, this fixes the problem for me. Can somebody please confirm?
Confirmed! Works like a charm now. Thanks for fixing the bug!
Will do. But will need some time.
From time to time (after aout 10 days) the binding item’s values do not change anymore. I have two temperature/humidity sensors. for both of them them temperature and humidity doesn’t change anymore. There are item updatesevery minute, but always the same value is set.
Obviously the values sent by the sensors are not propagated correctly.
This is the trace-log:
21:02:29.484 [DEBUG] [sse.LaCrosseTemperatureSensorHandler] - updating states for thing Außenbereich (4): temp=13.9 (13.899861), humidity=89, batteryNew=false, batteryLow=false
These are the old values. The display of the sensor shows different values.
Restarting the binding resolves the problem… but it occurs again and again after a couple of days.
Is this trace or debug level output? In trace level, there should be some lines like
Read line from port x: xx xx xx xx
as long as the binding is getting data from the serial connection. If you do not see these anymore, then most likely the connection to the stick has failed. Are there any exceptions in the log? Are the stick and sensors still shown as ONLINE? Do you have any status changes for the stick in your event log? These should show an error message when there was an exception reading from the serial port.
From looking at the code I could see that the refactoring I did for the pull request review introduced a bug that leads to cyclic propagation of the last value. I will fix this as soon as I have the time.
Yes, trace has been enabled and that was the only log entry.It looks like the JeeLink was offline, but I could not find any log entry.
The only error I could find was:
2017-09-25 00:00:01.219 [ERROR] [thome.binding.astro.internal.job.Job] - Queue full
java.lang.IllegalStateException: Queue full
at java.util.AbstractQueue.add(AbstractQueue.java:98)[:1.8.0_131]
at org.eclipse.smarthome.binding.astro.handler.AstroThingHandler.addJobToQueue(AstroThingHandler.java:314)[177:org.eclipse.smarthome.binding.astro:0.9.0.b5]
at org.eclipse.smarthome.binding.astro.internal.job.Job.schedule(Job.java:58)[177:org.eclipse.smarthome.binding.astro:0.9.0.b5]
at org.eclipse.smarthome.binding.astro.internal.job.Job.scheduleSunPhase(Job.java:156)[177:org.eclipse.smarthome.binding.astro:0.9.0.b5]
at org.eclipse.smarthome.binding.astro.internal.job.DailyJobSun.run(DailyJobSun.java:90)[177:org.eclipse.smarthome.binding.astro:0.9.0.b5]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_131]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_131]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_131]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_131]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_131]
What about my other questions? Can you grep the event log please:
grep jeelink:jeel /var/log/openhab2/events.log
Sorry for answering that late. The problem occurred again and it looks like the senosers went offline while the Jeelink remains online. This is the corresponding entry in the events.log file:
2017-09-30 15:17:03.819 [hingStatusInfoChangedEvent] - 'jeelink:lacrosse:13' changed from ONLINE to OFFLINE
2017-09-30 15:17:07.818 [hingStatusInfoChangedEvent] - 'jeelink:lacrosse:4' changed from ONLINE to OFFLINE
No problem. I have no access to my PC for a while. I will look into this next week.
Hi Volker, I deployed your snapshot 2.2.0 jar to my openhab2 and confirmed, it was installed and active via bundle:list.
232 | Active | 80 | 2.2.0.201710102019 | JeeLink Binding
But I’m unable to configure the thing for usb device, only name and location is available. Your older version 2.1 works well, but seems not to be your last 2.1 version. Same problem with version 2.2.
beba8a7286234621ecb1be6c9596b8c /tmp/org.openhab.binding.jeelink-2.1.0-SNAPSHOT.jar - is working
72fefe629da3a005bf8c374c0321b600 org.openhab.binding.jeelink-2.1.0-SNAPSHOT.jar - is NOT working
Debug log for jeelink binding:
2017-10-12 09:22:16.642 [DEBUG] [org.openhab.binding.jeelink ] - BundleEvent UNINSTALLED - org.openhab.binding.jeelink
2017-10-12 09:22:28.685 [DEBUG] [org.openhab.binding.jeelink ] - BundleEvent INSTALLED - org.openhab.binding.jeelink
2017-10-12 09:22:28.701 [DEBUG] [org.openhab.binding.jeelink ] - BundleEvent RESOLVED - org.openhab.binding.jeelink
2017-10-12 09:22:28.703 [DEBUG] [org.openhab.binding.jeelink ] - BundleEvent STARTING - org.openhab.binding.jeelink
2017-10-12 09:22:28.731 [DEBUG] [org.openhab.binding.jeelink ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={component.name=binding.jeelink, component.id=233, service.id=369, service.bundleid=234, service.scope=bundle} - org.openhab.binding.jeelink
2017-10-12 09:22:28.750 [DEBUG] [org.openhab.binding.jeelink ] - BundleEvent STARTED - org.openhab.binding.jeelink
There is no need to install jars any more, the jeelink binding can now be installed via paper ui or addons.cfg in the same way as other official bindings. For the official version some things have changed and the thing for the usb stick has to be removed and newly created. Your screenshot shows jeelink:jeelink as thing type which no longer exists. It is now jeelink:jeelinkUsb for sticks directly connected to an usb port.
Hi Volker, I am on apt-repo2 stable release and that way up2date. But there is no jeelink binding. Is it not available on stable tree?
If you don’t find it, then maybe it is only available in the unstable repo (that is the one I am using). Then use the jar.
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 55In 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.