I have written an openhab2 binding for JeeLink USB Receivers and connected LaCrosse temperature sensors/EC3000 power monitors.
It is not thoroughly tested (but running fine here with 3 connected sensors on linux) and I would like to make it available to a wider audience for testing before I create a pull request on github.
Features are:
manual bridge configuration
sensor discovery (after bridge has been configured): it should discover things connected to the bridge for every sensor that provides values (and adds them to the inbox when there is no other sensor on this bridge with the same sensor id)
the lacrosse temperature sensor things allow to change the sensor id via a string command âSetSensorId newIdâ on the sensor id channel (this can be used to adapt the sensor id after battery replacement)
sensor values are only reported at the end of every update interval (averages will be calculated over all readings that have been made in the this time)
the length of the update interval is configurable (live mode is also possible)
it is designed to allow easy addition of other sensors that can be connected to a JeeLink.
Since the binding reads from the serial port, I am not so sure about how this works on windows, but I am open for advice and suggested improvements.
If anybody is interested in testing the binding I would upload it somewhere (or can the jar be attached to the post somehow?).
Regards,
Volker
Edit: the binding has been merged is now part of the official distribution.
I believe it should work about the same, only the path to the port is pretty different (COM1 instead of /dev/ttyUSB0). You can see how the zwave or one of the other USB based bindings does it)
Similar bindings do provide an ability to change the update interval. I donât know this technology so canât comment if it is needed here.
Typically Iâve seen people post the jar somewhere and provide a link here, or create a github repo and post a link to that. I donât think the forum allows directly posting files.
This binding would have saved me quite a bit of time a few months ago when I was wiring up a bunch of Arduino sensors with RFM69HW transceivers. I still might consider it moving over at some point if I can make the RFM69HWs work with RFM69C. Right now I have a separate Pi acting as a gateway but it would be nice to consolidate the gateway on the OH server.
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?
