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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
