*Experimental* [eBUS 2.0] ebusd connector

Add-ons Bindings
,
1

I’m starting an experimental version of the eBUS binding here. With this binding you can now use the great ebusd deamon directly over a network. So you can benefit from the good hardware support and let the ebusd deamon do the low level access to the bus.

If this experiment goes well, I will integrate it into the public eBUS binding. Until then I want to collect feedback from ebusd users.

This information is a preliminary information and I hope I can publish a complete release tomorrow.

Step 1 - Install latest ebusd version

The latest ebusd version 3.3.v3.3-18-g82ae848 (Commit 82ae848) is required. It is from March 24th 2019.

Step 2 - Start ebusd with the following parameters

./ebusd -d /dev/ttyUSB1 --enablehex --scanconfig= -f -p 8888

We need no configuration files from ebusd, we still use the eBUS binding configurations!
This is just an example, feel free to modify the parameters and run it as service etc.

Step 3 - Install the following eBUS binding in openHAB

Download latest version from here

Step 4 - Configurate an eBUS bridge thing and select the ebusd connector

Step 5 - Configurate the eBUS binding like the normal eBUS binding

3 Likes
2

So, the first release is out.

3

Got it to run with the ebusd.

Thank you! Its working great to read values from the UI.

But CPU Usage is 100% now (EbusSenderThread). How do I cope with that!
Can you publish the sources?

4

It seems to be a busy while-loop without a wait-statement. Always polling the send-queue i guess.

5

Yes, the send routine is a quick and dirty solution. I’ll check that next days. An idea is to switch it to an thread pool.

The source is in my github repository in an extra branch.

6

Forked it and got it to compile with maven. But there is no Karaf file. How do I do that?

7

Sorry, but I’m currently busy with other things. But I’ve uploaded the distribution project. I use it to build the kar file.

8

I just updated ebusd and installed the RC5 you linked in the first post. First of all it seems to work better than going the ser2net route! After a few minutes there still are 0 failed telegrams. But the CPU of my little raspi is constantly over 100%. It looks like the problem is still not fixed, or the fix is not contained in RC5?

Aside from that, I still have these exceptions in the log:

2019-05-17 16:03:54.969 [ERROR] [e.csdev.ebus.core.EBusControllerBase] - Error while firing onTelegramReceived events!
java.lang.NullPointerException: null
	at de.csdev.ebus.command.datatypes.ext.EBusTypeDateTime.decodeInt(EBusTypeDateTime.java:77) ~[256:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
	at de.csdev.ebus.command.datatypes.ext.EBusTypeDateTime.decodeInt(EBusTypeDateTime.java:29) ~[256:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
	at de.csdev.ebus.command.datatypes.EBusAbstractType.decode(EBusAbstractType.java:106) ~[256:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
	at de.csdev.ebus.command.EBusCommandUtils.decodeValueList(EBusCommandUtils.java:374) ~[256:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
	at de.csdev.ebus.command.EBusCommandUtils.decodeTelegram(EBusCommandUtils.java:426) ~[256:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
	at de.csdev.ebus.service.parser.EBusParserService.onTelegramReceived(EBusParserService.java:94) ~[256:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
	at de.csdev.ebus.core.EBusControllerBase$2.run(EBusControllerBase.java:142) [256:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]

Additionally, when I shut down ebusd, all things stay in status ONLINE in Paper UI, even though the log states that the connection is lost and it is trying to reconnect. But CPU consumption is back to normal.

9

Thank you for you detailed post. I’m not sure if it is fixed in RC5, in RC6 it should be fixed. If checked it this evening and my small fix reduces the cpu usage massively.

Regarding you error log, could you provide the raw telegram and the configuration that causes the issue.

And the last bug, I’ll check it now.

10

I just tried to reproduce the exception, and it took a while (I had hundreds of these exceptions the last time, no idea what has changed). Unfortunately, there is no raw telegram in the log in DEBUG level. I have now set the level TRACE and am waiting for the next occurrence.

As configuration I use

2019-05-21 17:27:54.966 [INFO ] [ding.ebus.thing.EBusTypeProviderImpl] - Load custom configuration file 'https://raw.githubusercontent.com/csowada/ebus-configuration/master/src/main/resources/commands/vaillant-bai00-configuration.json' ...
2019-05-21 17:27:55.521 [INFO ] [ding.ebus.thing.EBusTypeProviderImpl] - Load custom configuration file 'https://raw.githubusercontent.com/csowada/ebus-configuration/master/src/main/resources/commands/vaillant-vrc-configuration.json' ...

Edit: there is no raw telegram even with TRACE logging. So how do I get the raw telegram?

11

So I’ve released a new version. The ebusd connector is now part of the nromal builds. Due to this you can always use the latest build from the main topic. But the ebusd connector is still experimental, so I need your feedback to make it more stable and robust.

12

I have installed RC7 and can confirm CPU consumption is down.

The status is now also shown correctly as OFFLINE when I shut down ebusd and returns to ONLINE when I restart ebusd.

I still have exceptions, but I see you added an error message:

2019-05-23 16:05:03.437 [WARN ] [mmand.datatypes.ext.EBusTypeDateTime] - DateTime Debug: data
2019-05-23 16:05:03.440 [WARN ] [mmand.datatypes.ext.EBusTypeDateTime] - DateTime Debug: variantTime
2019-05-23 16:05:03.443 [WARN ] [mmand.datatypes.ext.EBusTypeDateTime] - DateTime Debug: variantDate
de.csdev.ebus.command.datatypes.EBusTypeException: The decoded datetime part of datetime is null!
	at de.csdev.ebus.command.datatypes.ext.EBusTypeDateTime.decodeInt(EBusTypeDateTime.java:83) ~[260:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
	at de.csdev.ebus.command.datatypes.ext.EBusTypeDateTime.decodeInt(EBusTypeDateTime.java:1) ~[260:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
	at de.csdev.ebus.command.datatypes.EBusAbstractType.decode(EBusAbstractType.java:106) ~[260:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
	at de.csdev.ebus.command.EBusCommandUtils.decodeValueList(EBusCommandUtils.java:374) ~[260:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
	at de.csdev.ebus.command.EBusCommandUtils.decodeTelegram(EBusCommandUtils.java:426) ~[260:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
	at de.csdev.ebus.service.parser.EBusParserService.onTelegramReceived(EBusParserService.java:94) [260:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
	at de.csdev.ebus.core.EBusControllerBase$2.run(EBusControllerBase.java:142) [260:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]

So how do I get the raw telegram?

I do now also get additional things in the inbox. eBUS Standard (04) and eBUS Standard (06). I do not understand what all these things are good for, as I now have the bai, vrc430, and four eBUS Standard things.

13

The standard devices are added for any device to support the ebus standard communication set. But I think I’ve removed the raw telegrams by mistake from the logger in the past. I’ll add this in the next release. So the binding runs but shows errors if you receive a DateTime value?

14

Yes, it looks good now, except for the exceptions. But they do not seem to have an impact in functionality.

15

The new release “RC7b” should hopefully show the issue and print the raw telegram in the logs.

16

The new version did not really improve things:

2019-05-28 14:36:50.954 [WARN ] [.csdev.ebus.core.EBusEbusdController] - ignore:  -s FF 08B509030D5400
2019-05-28 14:36:50.978 [ERROR] [e.csdev.ebus.core.EBusControllerBase] - Error while firing onTelegramReceived events!
java.lang.ArrayIndexOutOfBoundsException: null
        at java.lang.System.arraycopy(Native Method) ~[?:?]
        at de.csdev.ebus.command.EBusCommandUtils.decodeValueList(EBusCommandUtils.java:373) ~[264:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
        at de.csdev.ebus.command.EBusCommandUtils.decodeTelegram(EBusCommandUtils.java:426) ~[264:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
        at de.csdev.ebus.service.parser.EBusParserService.onTelegramReceived(EBusParserService.java:94) ~[264:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
        at de.csdev.ebus.core.EBusControllerBase$2.run(EBusControllerBase.java:142) [264:de.cs-dev.ebus.ebus-core:0.9.20.SNAPSHOT]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]