New Jeelink Openhab2 Binding

Hi Volker,

thanks for the hint. I have now deleted the jar file from /usr/share/openhab2/addons/ but it seems that I’m somehow stuck in the shallow waters between PaperUI and manual installation. PaperUI still shows the Jeelink Binding as installed (version 2.2). For some reason it won’t uninstall when I try to do so im PaperUI. I have also tried to deinstall it with “bundle:uninstall” from the OpenHab console. That seemed to work, but after a restart of OpenHab, bundle:list" gives me that:

...
253 │ Active   │  80 │ 2.2.0                  │ JeeLink Binding

And still my Jeelink Things remain in state “UNINITIALIZED”.

EDIT:
I was able to revert to a working state by stopping OpenHab, then moving the old 2.1 binding file back to /usr/share/openhab2/addons/ again and starting OpenHab. Now my Jeelink USB Thing shows as “ONLINE” and I’m able to receive data from the sensors.

From there I tried to switch to the new version of the binding following the steps in the Frequently Asked Questions (FAQs) “How can I reactivate the release version of an add-on?” but without success.
Even when I stop Openhab, remove the old jar file, start OpenHab again, PaperUI still shows the binding als “Installed”. When I try to use the deinstall button, nothing happens. The process-circle just keeps spinning.

EDIT2:
I was able to solve the issue: After removing the manually installed 2.1.0 binding as descibed in the FAQ, I had to remove the Thing for the USB Receiver too and create a new one for the new 2.2.0 binding. It seems that the new version does not pick up the Things from the older version automatically. After creating a new Thing for the USB Receiver with the new binding, I was able to reactivate the sensors by switching the Things to the new Bridge.

Many thanks,
Roland

You must have had a very old version of the binding that still used jeelink as thing type for the bridge. That has changed back in August, when a dedicated thing type has been introduced for tcp connected sticks. From then on the old configuration was no longer working and the sticks had to be removed and created again to get the new thing type, which is either jeelinkUsb or jeelinkTcp.

If you have already updated after this change (and adapted the config), then upgrading to the release version should be as simple as deleting the jar and installing with paper ui.

I got a Problem with my Jeelink, hopefully you can support me :slight_smile:

Jeelink works fine on OH2 (device online). But it is not able to find a weather station.

I switched from FHEM to OH2 without a new Jeelink Flash. I opened allready a thread in the beginner Forum… Forum Jeelink

Many Thanks
Markus

That worked very well.
Thank you for your support and again for that wonderful binding! :slight_smile:

as the pull request has been merged, I have now created a new branch for making the consumption unit configurable: https://github.com/vbier/openhab2-addons/tree/ec3kUnit8
As I have no ec3k sensors, can you please test if this works as expected?

Hi @vbier, thanks again for this change. I just want to let you know that I don’t need this anymore. Sorry for that.
I decided to go a different route for my jeelink hardware/openhab integration.

Hello all
could somebody explain me how to perform a battery change on that sensors?
I just changed the battery, did a search in paperUI, deleted the new found thing and inserted the ID of that found thing in my already existing one.

Unfortunately, it seems that the internal ID stays the same, see this log entries:

'jeelink:lacrosse:236' changed from ONLINE to OFFLINE
2018-01-13 14:56:50.446 [home.event.InboxAddedEvent] - Discovery Result with UID 'jeelink:lacrosse:64' has been added.
==> /var/log/openhab2/openhab.log <==
2018-01-13 14:56:50.448 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'jeelink:lacrosse:64' to inbox.
==> /var/log/openhab2/events.log <==
2018-01-13 14:57:24.939 [me.event.InboxRemovedEvent] - Discovery Result with UID 'jeelink:lacrosse:64' has been removed.
2018-01-13 14:57:36.304 [me.event.ThingUpdatedEvent] - Thing 'jeelink:lacrosse:236' has been updated.
2018-01-13 14:57:36.313 [hingStatusInfoChangedEvent] - 'jeelink:lacrosse:236' changed from OFFLINE to UNKNOWN
2018-01-13 14:57:38.542 [hingStatusInfoChangedEvent] - 'jeelink:lacrosse:236' changed from UNKNOWN to ONLINE

The thing is still called jeelink:lacrosse:236
This is very confusing…

Furthermore it seems that the configured Update intervale does not work any more after the battery change.

The update intervale is set tu 60 seconds, but see the following log entries regarding this thing:

2018-01-13 15:03:10.486 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 49 to 41
2018-01-13 15:03:10.490 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from ON to OFF
2018-01-13 15:03:15.638 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 41 to 45
2018-01-13 15:03:36.423 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.4 to 21.5
2018-01-13 15:03:36.436 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 45 to 47
2018-01-13 15:03:36.447 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from OFF to ON
2018-01-13 15:04:02.116 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.5 to 21.6
2018-01-13 15:04:02.119 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 47 to 49
2018-01-13 15:04:10.482 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.6 to 21.4
2018-01-13 15:04:10.492 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from ON to OFF
2018-01-13 15:04:10.499 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 49 to 41
2018-01-13 15:04:15.603 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorBadezimmer_Luftfeuchtigkeit changed from 42 to 41
2018-01-13 15:04:15.671 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 41 to 45
2018-01-13 15:04:36.449 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 45 to 47
2018-01-13 15:04:36.454 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.4 to 21.5
2018-01-13 15:04:36.459 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from OFF to ON
2018-01-13 15:05:02.123 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.5 to 21.6
2018-01-13 15:05:02.125 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 47 to 49
2018-01-13 15:05:10.479 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.6 to 21.4
2018-01-13 15:05:10.488 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 49 to 41
2018-01-13 15:05:10.501 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from ON to OFF
2018-01-13 15:05:15.703 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 41 to 45
2018-01-13 15:05:36.471 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 45 to 47
2018-01-13 15:05:36.477 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from OFF to ON
2018-01-13 15:06:02.127 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.4 to 21.6
2018-01-13 15:06:02.132 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 47 to 49
2018-01-13 15:06:10.494 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.6 to 21.4
2018-01-13 15:06:10.499 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 49 to 41
2018-01-13 15:06:10.502 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from ON to OFF
2018-01-13 15:06:15.736 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 41 to 45
2018-01-13 15:06:36.489 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 45 to 47
2018-01-13 15:06:36.494 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from OFF to ON
2018-01-13 15:07:02.130 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.4 to 21.6
2018-01-13 15:07:02.133 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 47 to 49
2018-01-13 15:07:10.487 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Temperatur changed from 21.6 to 21.4
2018-01-13 15:07:10.500 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_Luftfeuchtigkeit changed from 49 to 41
2018-01-13 15:07:10.512 [vent.ItemStateChangedEvent] - LaCrosseTemperatureSensorWohnzimmer_BatteryNeu changed from ON to OFF

It looks like every status change is recognized by openhub.
I have some of these sensors but only this one is doing like this, since the first battery change.
Any hints are highly welcome.
Thank you in advance.

Matthias

The thing id does never change for an existing sensor, otherwise you would have to update all your item definitions every time you replace batteries, as these are linked to the thing ids.

Regarding the update interval, did you make any other configuration changes, e.g. buffer size?

Or you might be affected by a bug in the binding where values are published several times after configuration change. Does the problem persist if you restart openhab?

Otherwise enable trace logging and paste a part of your openhab.log showing a few updates.

Thank you for your fast reply, Volker.
In deed, a restart of openhab stopped it.
:slight_smile:

Thanks,
Matthias

You are welcome. The bug is already fixed in 2.3.0-snapshot. So if you want to avoid this problem in the future, you can upgrade the binding.

Hi @vbier,
thank your for the work on the Jeelink-Binding.
I bought two PCA301 sockets and wanted to try out your updated version with the pca support. But unfortunately it seems, that the jar file isn’t online anymore. Can you reupload the file again?

Thanks,
Thomas

Use this one:
https://github.com/vbier/openhab2-addons/raw/jars/addons/binding/org.openhab.binding.jeelink/org.openhab.binding.jeelink-2.3.0-SNAPSHOT.jar

Hello!

Thanks for developing this awesome Binding! I am using the version (binding-jeelink - 2.2.0) of the jeelink binding since it has been released and i am experiencing a confusing behaviour.

I have 4 temperature sensors bound and everything works until i reboot the system.
After the reboot (or openhab service restart) the temperature, humidity, and battery new channel loose their channel links. But this happens only with one of those four sensors… the other remaining three seem to be unaffected by the channel link losses.

As a matter of fact that means for me that my temperature control is not working until i rellink the channels again through the paper ui (pretty easy to do - but you have to be aware about that problem - so its really annoying).

Release = Raspbian GNU/Linux 8 (jessie)
Kernel = Linux 4.9.35-v7+
Platform = Raspberry Pi 3 Model B Rev 1.2
openHAB 2.2.0-1 (Release Build)
binding-jeelink - 2.2.0
I use the simple Item Linking Mode
The openhab.log only mentions rule and sitemap errors. But those are subsequent faults of the lost channel links of this sensor.

Is it possible that this problem could be related to this? https://community.openhab.org/t/mysensors-binding-channel-names-disappearing-in-paperui-control-page-after-reboot/35706
There is a mention for a fix for binding developers --> I tried the workarounds, they are not working for me.

As you can see in the attached screenshot i have to relink the other channels. After that my rules and sitemaps work as they should again. This error is completely reproducible. It happens after each reboot!

Do you have an idea why this is happening? Is there a solution, a simple fix? Is it possible to make a rule to relink the channels after reboot?

With best regards and thanks in advance
Walter

Whether channels are linked or not is not part of the binding’s responsibility. This seems to be a bug in the openHAB code. I have used paper UI to link items only for a few days and then setup items files. Have you tried that?

The PCA301 code got merged into the 2.3 branch yesterday. :champagne:

I have another change in the pipeline that should make sure that the init commands are sent correctly.
Previously, the init commands have been sent when the first reading was received. This did obvioulsy not work if you needed an init command to change the datarate in order to receive readings.
Therefore I have now changed the code to send the init commands after the first reading has been received or a configurable timeout has occurred. The timeout is 15s by default and can be changed in the stick configuration.
Together with the changes that have been merged, this should now make LGWs work. I have destroyed some parts with my soldering iron in the process of building a LGW. But now that I got it working I have tested the binding code and everything looks good so far.
I have connected LaCrosse and PCA301 sensors and both are working fine.

It would be nice if some of you could test the updated binding before I create a pull request:
https://github.com/vbier/openhab2-addons/raw/jars/addons/binding/org.openhab.binding.jeelink/org.openhab.binding.jeelink-2.3.0-SNAPSHOT.jar

Hallo Volker,
nach meinem Umzug und gecrashtem NUC samt FHEM wollt ich das optisch viel ansprechende Openhab testen.
Einfache Sachen wie Hue, AVR, TV… laufen top.
Im FHEM hatte ich zwei Jeelinks, einer für meine PCA301 der andere für TFA Dostmann.
Beide liefen unter FHEM, muss da nun ein neuer Sketch drauf?
Hab eben deiner News bzgl. der PCA301 gelesen aber bekomm die einfach nicht zum laufen.

Gibt es etwas ähnliches wie das Wiki im FHEM für alle Aktoren für Openhab?
Sowas ist echt einfacher für Noobs.

Gruß Stefan

Step by step:

  • you download the jar, put it into the openHAB addons folder
  • you wait for the add-on to be shown in the paper UI
  • you make sure the serial device can be seen by openHAB (only if connected directly via usb)
  • you create a Jeelink thing manually in the paper UI inbox
  • you scan for sensors using the paper UI inbox
  • you create items file(s) linking the channels to items (if paper UI simple mode is disabled)
  • you see updates and can control things in the paper UI
  • you use a UI of your choice and use the items
  • you write a blog or wiki article on how you have set everything up and link it here for other noobs

Google the steps to get detailed information.
If this fails, write detailed information on what you have tried and what did not work as expected

  • I pluged in the pca301 flashed Jeelink attached to ttyUSB0
  • create the Jeelink in the paper ui inbox

2018-03-07 19:08:09.038 [hingStatusInfoChangedEvent] - ‘jeelink:jeelinkUsb:0ecb16f4’ changed from UNINITIALIZED to INITIALIZING

2018-03-07 19:08:09.048 [hingStatusInfoChangedEvent] - ‘jeelink:jeelinkUsb:0ecb16f4’ changed from INITIALIZING to ONLINE

But after scan nothing happens.
When I push the button on the pca301 device the Jeelink´s blue led flash´s, but nothin to see in the event log.

Ist the socket paired to the stick? Die you press the button while discovery was in progress?
It is essential that the stick receives a reading while discovery is running.
If that does not help, enable trace logging in the console and paste the relevant part (discovery with button press) of the openhab.log file.

Yes the socket was/is paired with the stick (from previous fhem setup).
Yes I pressed the button in discovery mode an the led flash´s

You meen this?

2018-03-07 20:18:48.050 [DEBUG] [elink.internal.JeeLinkHandlerFactory] - creating JeeLinkHandler for thing c57ae68a...
2018-03-07 20:18:48.052 [DEBUG] [elink.internal.JeeLinkHandlerFactory] - registering sensor discovery service...
2018-03-07 20:18:48.062 [DEBUG] [org.openhab.binding.jeelink         ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=321, service.bundleid=188, service.scope=singleton} - org.openhab.binding.jeelink
2018-03-07 20:18:48.070 [DEBUG] [l.connection.JeeLinkSerialConnection] - Creating serial connection for port /dev/ttyUSB0 with baud rate 57600...
2018-03-07 20:18:48.071 [DEBUG] [l.connection.JeeLinkSerialConnection] - Opening serial connection to port /dev/ttyUSB0 with baud rate 57600...

.

Yes, but with trace logging enabled. Search this thread for instructions.