New Jeelink Openhab2 Binding

Dear all
Sorry if this question was already answered, I was not following this topic for a while.

After the latest openhab update I get the following error during startup.

2018-12-01 14:06:04.951 [ERROR] [org.openhab.binding.jeelink         ] - FrameworkEvent ERROR - org.openhab.binding.jeelink
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.jeelink
Another singleton bundle selected: osgi.identity; type="osgi.bundle"; version:Version="2.3.0.201803081647"; osgi.identity="org.openhab.binding.jeelink"; singleton:="true"

Could somebody help me to fix this.

Thank you in advance.

BR
Matze

Sounds like you have two versions of the plugin installed.

Yes, I know, it looks like this.
But I do not know where this comes from?
I have no jar file any more and just installed the binding via PaperUI.
Any hint what could be wrong?
Should I uninstall the binding? How to do that?

Thank you in advance.

I got it.
I found that there are two JeeLink Bindings installed, via the karaf console.
I unistalled one and everything is ok now.

BR
Matthias

Unfortunately it is not solved.
When I try to install a new binding I get this error.

2018-12-07 16:27:09.652 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-binding-astro': Error restarting bundles:

	Could not resolve module: org.openhab.binding.jeelink [219]

  Another singleton bundle selected: osgi.identity; type="osgi.bundle"; version:Version="2.3.0.201803081647"; osgi.identity="org.openhab.binding.jeelink"; singleton:="true"

Any hint how to resolve this?

Thank you in advance.

you should try to clean tmp & cache
if you have 2 versions of the same binding and remove one from the console it doesn’t clean all the stuff and it may reload it.

See: Clear the Cache

Thank you very much!
That did it!

@vbier Are you still using your JeeLink stick with ser2net?
I also tried to get it running but something is not working as it should. My JeeLink thing of openHAB has the state online but it doesn’t receive any information from any of my sensors. It doesn’t finds any sensors (auto discovery & manual thing config). I tried switching the baud rate (56700 as used by jeelinkUsb and 115200) in the ser2net config file but this doesn’t help either and the information on the internet about JeeLinks via ser2net are quite thin.

I also use ser2net to share my zwave stick via tcp and that works fine.

Can you tell me which settings are working for your case on the side of openHAB and ser2net?

I think the important part is to simulate the version string the Jeelink sends on connect. This is from my ser2net.conf:

BANNER:jeelink:\r\n[LaCrosseITPlusReader whatever]\r\n
6666:raw:600:/dev/ttyUSB0:57600 8DATABITS NONE 1STOPBIT

This allows me to connect to the PC that has the ser2net running on port 6666.

1 Like

I had a strange behavior when i inserted these lines in my ser2net.conf. At first it looked like it would work. My sensor things were online but after about ten seconds they were unknown/offline again. I also tried without a timeout.

BANNER:jeelink:\r\n[LaCrosseITPlusReader whatever]\r\n
3333:raw:0:/dev/zwave:115200 8DATABITS NONE 1STOPBIT
3334:raw:0:/dev/jeelink:57600 8DATABITS NONE 1STOPBIT
3335:raw:0:/dev/zigbee:115200 8DATABITS NONE 1STOPBIT

/dev/jeelink is my static udev link of the port from the jeelink which leads to /dev/ttyUSB0
I also tried mentioning the banner after the jeelink line like in the examples of the config file.

BANNER:jeelink:\r\n[LaCrosseITPlusReader whatever]\r\n
3333:raw:0:/dev/zwave:115200 8DATABITS NONE 1STOPBIT
3334:raw:0:/dev/jeelink:57600 8DATABITS NONE 1STOPBIT jeelink
3335:raw:0:/dev/zigbee:115200 8DATABITS NONE 1STOPBIT

Do I have to modify the banner e.g. so the whatever meets some id or something else?

Did you find any good instructions on how to create those banners or is there a special way to find out what banners might work?

I shutdown the server over night and now in the morning the jeelink stick seems to work alongside the zwave stick. Strange behavior. :smile:

Hello Volker,

thank you for this great JeeLink Binding. Works flawless for here with a few of LaCrosse Sensors.
may i ask you about the BatterNEW and LOWBattery logics ?

Yesterday around 21 o´clock i put new Batterys (Eneloop) in my Sensors.
And the switch Battery NEW goes to "ON"State. Works great.
But this morning 6 o´clock the Switch Battery NEW was in “OFF” State.
How come ?
Br Peter

Because it was no longer new? I have no idea as I did neither invent the protocol nor manufacture the HW. I have only written the binding that displays the values.

Ok, let’s see. Because i setup another additional Lacrosse.
I fired it up around 20:30. Now I will keep an eye at witch time the BatteryNew went off.

Hello Volker,

as i mentioned in my previous post, i put in new Battery in the Sensor at around 20:30.
This morning at 06:00 the BatteryNEW Switch is OFF.
Where can i find in the log, when the ON to OFF occours ?
EDIT:
If find it in the log:

2019-02-25 20:26:00.769 [vent.ItemStateChangedEvent] - LaCrosse_Aussen_BatteryNew changed from OFF to ON
2019-02-26 01:29:06.590 [vent.ItemStateChangedEvent] - LaCrosse_Aussen_BatteryNew changed from ON to OFF

and here another one:

2019-02-27 20:44:09.165 [vent.ItemStateChangedEvent] - LaCrosse_Innen_WHZ_BatteryNew changed from NULL to ON
2019-02-28 01:46:13.751 [vent.ItemStateChangedEvent] - LaCrosse_Innen_WHZ_BatteryNew changed from ON to OFF

Looks like after around 5hrs it went to OFF.
Ok, if i now persist this i knew when put in new Batterys.
But more important is when the LOW Battery is detected. :slight_smile:

BR Peter

The logic to switch from “battery new: on” to “battery new:off” is implemented by the firmware of the Technoline / LaCrosse Sensors and we cannot change them.
But with some rules you could detect the change from new to ‘normal’ and trigger an event.

My logfile is quite filled with the following messages:

> 2019-05-26 22:54:18.668 [hingStatusInfoChangedEvent] - 'jeelink:lacrosse:2' changed from ONLINE to OFFLINE
> 2019-05-26 22:54:21.669 [hingStatusInfoChangedEvent] - 'jeelink:lacrosse:2' changed from OFFLINE to ONLINE
> 2019-05-26 22:55:47.734 [hingStatusInfoChangedEvent] - 'jeelink:lacrosse:2' changed from ONLINE to OFFLINE
> 2019-05-26 22:55:51.669 [hingStatusInfoChangedEvent] - 'jeelink:lacrosse:2' changed from OFFLINE to ONLINE

… although I’ve set sensor timeout really high:

Thing jeelink:lacrosse:tx35it "LaCrosse TX35-IT" (jeelink:jeelinkUsb:lacrosse) @ "home" [ sensorId="2", sensorTimeout=180, updateInterval=180, minTemp=-30, maxTemp=50]

Does anybody have an idea what might be going wrong? BTW I’m on OpenHAB 2.5.0-M1.
Thanks a lot!

Are you sure jeelink:lacrosse:tx35it and jeelink:lacrosse:2 are the same thing? Looks to me as if the first one is the one you defined in the things file and the second one has been added by discovery.

Got my TX29DTH-IT working now!
However, discovery didn’t work, there was no sensor thing in my inbox, although it was registered.

2019-06-12 09:27:11.450 [DEBUG] [elink.internal.JeeLinkHandlerFactory] - registering sensor discovery service…
2019-06-12 09:27:11.454 [DEBUG] [org.openhab.binding.jeelink ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=425, service.bundleid=250, service.scope=singleton} - org.openhab.binding.jeelink
2019-06-12 09:27:11.704 [DEBUG] [l.connection.JeeLinkSerialConnection] - Creating serial connection for port /dev/ttyUSB0 with baud rate 57600…
2019-06-12 09:27:11.705 [DEBUG] [l.connection.JeeLinkSerialConnection] - Opening serial connection to port /dev/ttyUSB0 with baud rate 57600…
2019-06-12 09:27:11.732 [DEBUG] [ding.jeelink.internal.JeeLinkHandler] - Connection to port /dev/ttyUSB0 opened.
2019-06-12 09:27:11.737 [DEBUG] [ding.jeelink.internal.JeeLinkHandler] - Init commands scheduled in 10 seconds.
2019-06-12 09:27:11.739 [DEBUG] [ding.jeelink.internal.JeeLinkHandler] - Monitoring job started.
2019-06-12 09:27:31.823 [DEBUG] [ding.jeelink.internal.JeeLinkHandler] - Registering converter for sensor type 9: org.openhab.binding.jeelink.internal.lacrosse.LaCrosseTemperatureReadingConverter@159f417c

After raising the loglevel to TRACE, I saw readings:

2019-06-12 09:39:20.008 [TRACE] [connection.AbstractJeeLinkConnection] - Read line from port /dev/ttyUSB0: OK 9 6 129 4 242 53

2019-06-12 09:39:20.009 [TRACE] [.LaCrosseTemperatureReadingConverter] - Creating reading from: OK 9 6 129 4 242 53

After figuring out, that the 6 in that line is my sensor id, I was able to manually create the sensor thing.

May I suggest the following changes to the documentation:

  • Add a note to raising the log level to trace
  • describe the reading format, especially the sensor id. (From what I understand, the 1st number (9 here) is the sensor type, the 2nd number is the sensor id (6), the penultimate is the encoded temperature (242) and the last number is the humidity in percent (53). The others are probably the battery or so)

Thank you Volker!

This should not be needed. A better approach would be to make the discovery work reliably. Can you remove the sensor thing, enable trace logging and then start discovery. Please post the part of the log containing the discovery.