New Jeelink Openhab2 Binding

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.

How do actually force starting the discovery?

Go to the inbox and press the scan button (upper right corner of the page).

I see. I was using HABmin, there’s no such scan button. Now in PaperUI I can see that button. Will resetup the thing tonight.

Hi Guys,

I can’t get the thing connected #pun
Jeelink binding installed, manual creation of the Thing:
LaCrosseGateway (connected over TCP)
But using the default port 81, my Thing says: Connection refused (Connection refused)
Running a port scan I can only see port 80 open. Knowing this is default http - browsing shows me the internal webserver info page (blue page with IP details primarily). There’s no weather data from my sensor.

I’ve got a GW 1000u, IP of 192.168.1.37 - I’ve used Advanced Port Scanner & wireshark and can only see port 80 open. And very little traffic activity to anywhere else.
I’ve got a VA0/1117 temperature sensor only, with a wetbulb connected into my pool. The devices are registered and iOS app works fine to see the data/temps etc.

I’ve tried every port listed in this thread, and waited. Including port 80.
Feel like i’m missing a installation component somewhere…
I’m running OpenHab2.4 so Jeelink is bundled. All my connectivity seems fine.
I just can’t get past the Connection failing to my GW.
If I use port 80 in the thing config I get a connection then a disconnected, EOF error:
2019-11-24 03:31:14.946 [hingStatusInfoChangedEvent] - ‘jeelink:lgwTcp:d69a4f05’ changed from OFFLINE (COMMUNICATION_ERROR): Got EOF on port 192.168.1.37:80 to ONLINE
2019-11-24 03:31:15.224 [hingStatusInfoChangedEvent] - ‘jeelink:lgwTcp:d69a4f05’ changed from ONLINE to OFFLINE
2019-11-24 03:31:15.226 [hingStatusInfoChangedEvent] - ‘jeelink:lgwTcp:d69a4f05’ changed from OFFLINE to OFFLINE (COMMUNICATION_ERROR): Got EOF on port 192.168.1.37:u6e80:

*EDIT: I should have mentioned I haven’t go anything in the INIT commands field… I couldnt find any list of what these were, so haven’t messed with them - do I need to? I just want to know what the temperature is… nothing else :slight_smile:

Any advice on how to make this work?
Hopefully I’ve covered enough info…
Johnny

This looks like the binding can not connect to the LGW. I no longer use my LGW, as it repeatedly hung up after some weeks of use. So I am not sure if there is some configuration in the LGW web UI to be done to open the port.
Or does your router block access to port 81?

As long as the binding can not connect, you don’t need to worry about init commands.