at this stage you may not want to add the extra layer of having it connect to remote jee links…but if you did…you could expose the serial port on you openhab server via tcp, and then connect to it within your binding. Silly for you i know, but it would allow you to build in the remote capabilities I mentioned.
I wouldn’t really worry about it too much. If you abstract out the input/output streams it is really just a matter of dropping in a tcp connection class in the place of the serial port code and it should all really just work.
I have found just keeping the most recent reading insufficient in the sense that you end up with too many outlier readings.
What I do is when I have 10 readings built up, I spit out a reading which is the average of those 10 readings. Then I dump the oldest 5, and wait until I get 5 more before I emit another reading. You end up with readings about every 2 minutes or so, with a lot less crazy variance.
Just something else to think about. the outliers can play havoc with rules you may create in the future for notifications/alarms, etc.
Thanks for the input, craigh. It is very valuable.
My current approach is to have a configurable update interval. During this interval all readings are collected and averages are computed at the end of the interval. This average is then sent as update.
So whether outlier readings cause havoc currently depends very much on the interval that is configured. I am not so sure that the current approach is good, it is the just the first thing I came up with and it works fairly well with my configured update interval of 60 seconds.
But it would certainly be improved by discarding values that differ too much from the last value.
The thing is that you currently do not have to define any ports at all. The discovery iterates all serial ports and finds the jeelinks. I have no idea how this would work with tcp ports. But leaving discovery aside, I could have a look on how to make this work when the connection is specified manually via paper ui.
I’ll gonna test your binding. I have 5 LaCrosse sensors running with OH1.8.3.
I was about to start a binding myself, many thanks in advance for your work.
One more thing you may be interested in once you get your temp/humidity readings into openhab.
I use influxdb(openhab persistence) to store the temperature/humidity readings, and then grafana to visualize.
One nuance there, you can see the Shower Fan checkbox. If that is checked, it draws a vertical line when that device (dimmer switch via insteon) is on or off. You can then see say how humidity can change when the fan turns on within the bathroom with the shower. Could could have any number of options which can displayed on graphs like that.
What did you do to install the jar? I simply copy it to my runtime addons folder (which is /usr/share/openhab2/addons/ when you are running a deb install on linux).
@craigh, I have just pushed an update that allows to connect to JeeLinks over TCP. But this only works when you set up the USB Receiver thing manually.
Have you installed openhab-transport-serial as described in the readme?
feature:install openhab-transport-serial
The binding is listed in my console, so it does not seem to be loaded in your instance. Can you tail the openhab log file and touch the binding jar so it gets reloaded? Maybe this will give us a clue.
Yes, the openhab-transport-serial is installed and listet in the console. I tailed the log, touched the binding file, but nothing. Only a repeating error message regarding the org.eclipse.smarthome.binding.hue binding complaining about my hue bridge.
What’s the name of your binding in the bundle list?
No problem. Glad to hear that you got it working. It would have been even nicer if you were on windows, but maybe somebody else will try the binding on a pc with the OS from the dark side soon.
Hi Volker,
Thanks for sharing this binding. I might have missed this but I can’t find information on what sketch should be running on JeeLink to read LaCrosse sensors. Also what model of JeeLink (868 or 433 MHz band) and LeCrosse sensors are compatible?
I am no expert on JeeLinks, but AFAIK, there exists only one sketch allowing to read lacrosse temperature sensors and it seems to support only 868 MHz devices.
