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.
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 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.
Did you paste the wrong part of the log? A discovery should look like this:
2018-03-06 19:55:49.601 [DEBUG] [nal.discovery.SensorDiscoveryService] - discovery started for bridge jeelink:jeelinkUsb:4c6d16fd
2018-03-06 19:55:50.410 [DEBUG] [nal.discovery.SensorDiscoveryService] - discovery for bridge jeelink:jeelinkUsb:4c6d16fd found already known sensor id 30
2018-03-06 19:55:54.151 [DEBUG] [nal.discovery.SensorDiscoveryService] - discovery for bridge jeelink:jeelinkUsb:4c6d16fd found already known sensor id 58
2018-03-06 19:55:54.642 [DEBUG] [nal.discovery.SensorDiscoveryService] - discovery for bridge jeelink:jeelinkUsb:4c6d16fd found already known sensor id 30
2018-03-06 19:55:57.894 [DEBUG] [nal.discovery.SensorDiscoveryService] - discovery for bridge jeelink:jeelinkUsb:4c6d16fd found already known sensor id 38
2018-03-06 19:56:02.411 [DEBUG] [nal.discovery.SensorDiscoveryService] - discovery for bridge jeelink:jeelinkUsb:4c6d16fd found unknown sensor of type jeelink:pca301 with id 1-160-236
2018-03-06 19:56:02.445 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘jeelink:pca301:1-160-236’ to inbox.
2018-03-06 19:56:03.059 [DEBUG] [nal.discovery.SensorDiscoveryService] - discovery for bridge jeelink:jeelinkUsb:4c6d16fd found already known sensor id 58
2018-03-06 19:56:06.487 [DEBUG] [nal.discovery.SensorDiscoveryService] - discovery for bridge jeelink:jeelinkUsb:4c6d16fd found already known sensor id 38
2018-03-06 19:56:11.582 [DEBUG] [nal.discovery.SensorDiscoveryService] - discovery for bridge jeelink:jeelinkUsb:4c6d16fd found already known sensor id 30
2018-03-06 19:56:11.963 [DEBUG] [nal.discovery.SensorDiscoveryService] - discovery for bridge jeelink:jeelinkUsb:4c6d16fd found already known sensor id 58
2018-03-06 19:56:15.082 [DEBUG] [nal.discovery.SensorDiscoveryService] - discovery for bridge jeelink:jeelinkUsb:4c6d16fd found already known sensor id 38
2018-03-06 19:56:19.600 [DEBUG] [nal.discovery.SensorDiscoveryService] - discovery stopped for bridge jeelink:jeelinkUsb:4c6d16fd
It should at least contain the discovery started and stopped messages.
