I have about 7 lacrosse sensors in my house providing temp and humidity readings into openhab. I have instead implemented this logic within a docker container, written in python to post the readings to mqtt topics.
In implementing my solution, I think I can let you know of a couple more concerns which you may consider while implementing the binding.
the optimum location for the jeelink (rf receiver for those unfamiliar) is not necessarily where your openhab is installed. I use raspberry pi’s throughout my house to provide so called ‘edge’ computing. What I have found very useful is a linux program like ser2net to make the serial ports available over the network. This would allow you to put the jeelink in a central location within the house/office which gets better reception of the rf signals. The insteonplm binding supports this via the tcp config option as an example.
for my house I am adding a second jeelink because the rf range isn’t adequate for all the sensors. My house isn’t huge so this may be a fairly typical use case. I will implement the logic within my python to make sure i can handle duplicate detections of the same reading. You could still implement this within a binding but utilizing more than one serial port (virtual or physical).
I have found it necessary to configure min/max for sensors so you can just ignore some of the crazy readings. e.g. in my wine cellar, i would have a sensor defined with min 5 degrees and max 25 degrees. This helps remove most outlier readings from the sensor. The algorithm also rejects readings when differ by more than 6 degrees from the current rolling average.
I’ll watch for progress to see if it’s something I could use. I haven’t moved to oh2 yet because of some still missing functionality in oh2.
I also added a current snapshot jar so people do not have to build themselves.
I have added configuration of the update interval when sensors are added manually through the paper ui yesterday.
I had problems with understanding the difference between properties and configuration, but I have read eclipse smarthome documentation today and will add code to handle configuration updates next. This will then allow to change the sensor ID through the paper ui.
This is a good idea. I today saw one of those crazy values from one of my sensors, too. Discarding values that differ too much from the previous value seems to make sense, so I added this to my todo list.
I am not so sure about the ser2net stuff, as I have no experience with this and I am lacking the use case as all of my sensors directly communicate with the jeelink without problems.
So my current todo list looks like this:
react to configuration updates
discard readings that differ to much from last reading
Just for reference, the ser2net would be outside the scope of the binding. From the binding’s perspective it is just a change to the path to the serial device.
not sure it is totally out of the scope of the binding, but it can be. The ser2net side of it is for sure. That effectively exposes the serial port to a tcp port.
Then you have a couple choices. Within the binding you can support tcp connectivity, for example insteonplm does this. This can be done with a prefix within the config.
eg.
jeelink.port=/dev/ttySS0 ( or com x) for windows - this could be default direct to serial port
or
jeelink.port=tcp://192.168.x.x:7000 - this would be decoded to use tcp instead of the serial libs to get the input/output streams.
There is another option which would totally eliminate this type of coding within the binding, something like socat within the linux world, which actually does that connection to the tcp port on the server with the jeelink, and then the client side of socat which creates a virtual port on the server which has openhab. I have found this more difficult for things such as retry, etc.
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?
