What I have to do to use ebus binding i OH2.?
I copy ebus binding to addons directory and I create ebus.cfg in services directory but it does not work
Because it is not in /runtime/karaf/system/org/openhab/binding
you need to perform this steps:
Thx I will try
I have just tried ebus binding with my openhab2 and there are small problems. First of all there is no logback by default (not sure how to get it with v2 runtime), so I had to modify manifest and skip logback import. Ebus binding will also require
openhab-transport-serial feature to be installed.
I’ve placed configurations in
conf/services/org.openhab.ebus.cfg and it seems to be working. I have plenty of unknown telegrams, but this might be caused by
ser2net usage between rasp having ebus kopler and computer running OH2.
That’s in anycase an important fix. There should be no direct dependency on logback, only on slf4j.
Can you create a PR and directly create a Karaf feature with it, which includes the transport-serial?
I’m not yet sure if ebus binding is working properly. I just moved openhab to raspberry wired to ebus kopler and I still see some unknown telegrams (VRC470). Custom thread refreshing configuration in
activate method called from SCR was also causing troubles, cause under karaf
updated method is called by configuration admin, so I ended up removing this part of code too, to avoid doubled connections (one from
activate call another from
updated). I also observed working ebus connection thread after binding has been stopped.
I will keep working on that over coming days just to confirm that binding behaves in the same way under 1.8 and 2.0. I will post PR for review once I will be sure it is working configuration.
Mh, not good. I hoped that the last update is enought to get the binding run well on OH2. I checked it quickly with Equinox.
I checked the code and the import of logback is really not needed! Only slf4j is referenced.
The package “gnu.io” is marked as optional, is it really required? Or is that a side effect of another issue with maybe Karaf.
But at the moment I have no running develop environment for OH2, so I can’t check this immediately. I tried to install the new IDE, but it failed. I must check this first.
Can you send me a log of your setup? Is it possible that your RPi is not fast enough to start the binding. The
update call via Thread in
acitvate is only for restarted bundles. It only waits 15 seconds after activating!
Normally this should not being called if you not restart the binding. And I think this could have changed with Karaf.
That might be a case, cause I was calling restarts/refresh commands from command line cause I was getting null pointer exceptions in activation thread in line 303 (below). It’s really strange cause ConfigurationAdmin cardinality is set to mandatory (1…1).
Configuration configuration = configurationAdminService.getConfiguration("org.openhab.ebus", null);
So, I was able to modify the binding to fix both issues.
You could try this version
I check this version with OH 1.8.1 and 2.0 beta 2, both work well so far.
Here is the changes in github https://github.com/openhab/openhab/compare/master...csowada:eBus_OH2_Fix
Hey @csowada, your fixes helped and now I do not get any errors during startup. This time I have found thread leak. When I stop bundle and then remove it from addons directory I get errors in log such this:
2016-02-23 12:42:16.645 [ERROR] [nternal.parser.EBusTelegramCSVWriter] - error java.io.IOException: Stream closed at java.io.BufferedWriter.ensureOpen(BufferedWriter.java:116)[:1.8.0] at java.io.BufferedWriter.write(BufferedWriter.java:221)[:1.8.0] at java.io.Writer.write(Writer.java:157)[:1.8.0] at org.openhab.binding.ebus.internal.parser.EBusTelegramCSVWriter.writeTelegram(EBusTelegramCSVWriter.java:129)[167:org.openhab.binding.ebus:184.108.40.206602222212] at org.openhab.binding.ebus.internal.parser.EBusTelegramParser.parse(EBusTelegramParser.java:283)[167:org.openhab.binding.ebus:220.127.116.11602222212] at org.openhab.binding.ebus.internal.EBusBinding.onTelegramReceived(EBusBinding.java:383)[167:org.openhab.binding.ebus:18.104.22.168602222212] at org.openhab.binding.ebus.internal.connection.AbstractEBusConnector$1.run(AbstractEBusConnector.java:276)[167:org.openhab.binding.ebus:22.214.171.124602222212] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0] at java.lang.Thread.run(Thread.java:744)[:1.8.0]
To stop these I have to stop OH2 and start it back to flush all leftovers.
When I update configuration while bundle is active I get second eBUS Connection Thread:
2016-02-23 13:17:22.694 [ERROR | eBUS Connection Thread | org.openhab.binding.ebus.internal.connection.EBusSerialConnector] - Serial port /dev/ttyUSB0 is already in use
I made small change to identify threads created by ebus binding which allowed me to identify this bug:
openhab> threads|grep -i ebus "eBUS Connection Thread" Id=240 in TIMED_WAITING on lock=gnu.io.RXTXPort$SerialInputStream@566d47 at org.openhab.binding.ebus.internal.connection.EBusSerialConnector.readByte(EBusSerialConnector.java:177) at org.openhab.binding.ebus.internal.connection.AbstractEBusConnector.run(AbstractEBusConnector.java:153) "eBUS Connection Thread" Id=245 in TIMED_WAITING on lock=gnu.io.CommPortIdentifier@7c4c09 at org.openhab.binding.ebus.internal.connection.EBusSerialConnector.connect(EBusSerialConnector.java:72) at org.openhab.binding.ebus.internal.connection.AbstractEBusConnector.reconnect(AbstractEBusConnector.java:109) at org.openhab.binding.ebus.internal.connection.AbstractEBusConnector.run(AbstractEBusConnector.java:148)
You have the property
record in ebus.cfg set? Can you comment this out and try it again?
Without recording property in ebus config it’s fine - there is no first stack trace in log any longer.
Ah, good to know. I will check the issue with
record property, but now with lower proprity
After two nightruns I got extra issue showing periodically:
Exception in thread "ebus-send-receive-172" java.lang.NullPointerException at org.openhab.binding.ebus.internal.parser.EBusTelegramParser.parse(EBusTelegramParser.java:362) at org.openhab.binding.ebus.internal.EBusBinding.onTelegramReceived(EBusBinding.java:347) at org.openhab.binding.ebus.internal.connection.AbstractEBusConnector$1.run(AbstractEBusConnector.java:276) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744)
It’s easy to add a check on this position, but I would be better to find the main reason.
Can you identify a single telegram that causes this issue? Maybe a temperature below configurated min value !?
This NPE can happen if the decoded value is out of the min/max range or equal to to the replace value.
I already created a small patch https://github.com/openhab/openhab/compare/master...csowada:patch-2
The last changes are now in offical repository