[eBUS 2.0] New binding - Release Candidate 7b

Sending the the first byte is time critical, so I guess that this is the main issue with the ser2net setup. Is there any option for low latency or a buffer size?

So, just a quick look into the manual for ser2net and I found three interesting parameters.

disable-chardelay
dev-to-net-bufsize=<number>
net-to-dev-bufsize=<number>

But in general, is the binding not working with a tcp connection? I see no additional benefit to map a virtual serial port.

The problem is not ser2net, as it works better when I additionally use socat on the openhab host.
TCP does not work reliably, I get lots of errors with it. I also experimented with dev-to-net-bufsize=1 and net-to-dev-bufsize=1, but this did not seem to bring any benefits. Looking at my ser2net.conf, I have -chardelay in it, so that seems to have made things better.

My current ser2net.conf looks like this:
8888:raw:0:/dev/ttyebus:2400 8DATABITS NONE 1STOPBIT -chardelay chardelay-min=0 chardelay-max=0
Most likely, the min and max parameters can be left out.

But again, it is working a lot better with serial bridge config and socat in addition to ser2net, so this points to differences in what the binding does when using serial/network access.

Hey guys,

i´ve spend a lot of time for testing some different settings and so on, but with no success.
After pointing the ttyebus to port 8888 using ser2net (tried it also with -chardelay but with no noticeable differences) i was able to set my bridge via network with localhost port:8888. This worked more stable as the serial configuration.

However i get no readings except the date broadcast & temperature broadcast.

I also tried to discover my addresses and devices using ebusd… (only for testing, stopped the service after that) here are the results.

[16:48:11] openhabian@OH2:~$ ebusctl info
version: ebusd 3.3.v3.3
signal: acquired
symbol rate: 24
max symbol rate: 158
min arbitration micros: 3
max arbitration micros: 16
min symbol latency: 4
max symbol latency: 4
reconnects: 0
masters: 3
messages: 610
conditional: 2
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0204;HW=9602", loaded "vaillant/bai.0010015600.inc" ([HW=9602]), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0510;HW=6403", loaded "vaillant/15.700.csv"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503", loaded "vaillant/26.vr_71.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd

the devices in console were found correctly, i think.

openhab> smarthome:ebus list
Thing UID                                | Label                                    | Type
-----------------------------------------+------------------------------------------+-----------
ebus:vrc700_general:92e784cd:15          | Vaillant VRC 700 general (15)            | node
ebus:bridge:92e784cd                     | eBUS Bridge                              | bridge
openhab> smarthome:ebus devices
MA | SA | Identifier     | Device         | Manufacture               | ID | Firmware   | Hardware   | Last Activity
---+----+----------------+----------------+----------------------+----+------------+------------+---------------------
FF | 04 |                | <interface>    | eBUS Library              |    | null       | null       | ---
10 | 15 | 37 30 30 30 30 | vrc700_hc1     | Joh. Vaillant GmbH & Co.  | B5 | 5.1        | 64.03      | Sun Mar 03 17:03:46 CET 2019
   | 26 |                | ---            | null                      |    | null       | null       | Sun Mar 03 17:03:46 CET 2019
03 | 08 |                | ---            | null                      |    | null       | null       | Sun Mar 03 17:03:45 CET 2019
----------------------------------------------------------------------------------------------------------------------
MA = Master Address / SA = Slave Address / ID = Manufacture ID
openhab>

What i´ve noticed is, if add a thing (like “Vaillant VRC 700 general (15)”) with all the items the ebus bridge shows me a lot of failed telegrams in the metrics.

Does anyone have an idea how to solve? Or any hints for further investigation?

EDIT:
I logged some things in debug-mode with many, many errors…

2019-03-03 19:42:40.633 [DEBUG] [de.csdev.ebus.core.EBusController   ] - Send: FF 15 B5 24 06 02 00 00 00 02 00 F0 @ 0. attempt
2019-03-03 19:42:40.637 [DEBUG] [de.csdev.ebus.core.EBusController   ] - eBUS collision detected! 0x10
2019-03-03 19:42:40.642 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! 08 [ERROR: INVALID_                                    SOURCE_ADDRESS, DATA: 10 26 B5 23 04 02 00 01 34 27 00 02 01 9C 2B 00 00 00 00 00 1B 00 01 01 9A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0                                    0 00 00 00]
2019-03-03 19:42:40.728 [DEBUG] [de.csdev.ebus.core.EBusController   ] - Send: FF 15 B5 24 06 02 00 00 00 02 00 F0 @ 1. attempt
2019-03-03 19:42:41.248 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DA                                    TA: FF 15 B5 AA]
2019-03-03 19:42:41.250 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Unable to send telegram FF 15 B5 24 06 02 00 00 00 02 00 F0 after 2                                     attempts ... [ERROR: TOO_MANY_ATTEMPS, DATA: FF 15 B5 24 06 02 00 00 00 02 00 F0]
2019-03-03 19:42:45.393 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from address 10 to 08 with command boiler.control.getopdata
2019-03-03 19:42:45.397 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - No handler has accepted the command boiler.control.getopdata from 10 to 08 ...
2019-03-03 19:42:46.253 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from address 10 to 08 with command boiler.control.setopdata
2019-03-03 19:42:46.256 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - No handler has accepted the command boiler.control.setopdata from 10 to 08 ...
2019-03-03 19:42:55.437 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from address 10 to 08 with command boiler.control.getopdata
2019-03-03 19:42:55.439 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - No handler has accepted the command boiler.control.getopdata from 10 to 08 ...
2019-03-03 19:42:56.296 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from address 10 to 08 with command boiler.control.setopdata
2019-03-03 19:42:56.299 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - No handler has accepted the command boiler.control.setopdata from 10 to 08 ...
2019-03-03 19:43:05.521 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from address 10 to 08 with command boiler.control.getopdata
2019-03-03 19:43:05.523 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - No handler has accepted the command boiler.control.getopdata from 10 to 08 ...
2019-03-03 19:43:06.183 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:92e784cd:15:vrc700_general_gen_time#value" with "FF 15                                     B5 24 06 02 00 00 00 35 00 51" ...
2019-03-03 19:43:06.187 [DEBUG] [de.csdev.ebus.core.EBusQueue        ] - Size of send queue is 1 ...
2019-03-03 19:43:06.202 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:92e784cd:15:vrc700_general_gen_holiday-end#value" with                                     "FF 15 B5 24 06 02 00 00 00 72 00 6E" ...
2019-03-03 19:43:06.206 [DEBUG] [de.csdev.ebus.core.EBusQueue        ] - Size of send queue is 2 ...
2019-03-03 19:43:06.243 [DEBUG] [de.csdev.ebus.core.EBusController   ] - Send: FF 15 B5 24 06 02 00 00 00 35 00 51 @ 0. attempt
2019-03-03 19:43:06.763 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DA                                    TA: FF 15 B5 AA]
2019-03-03 19:43:06.807 [DEBUG] [de.csdev.ebus.core.EBusController   ] - Send: FF 15 B5 24 06 02 00 00 00 35 00 51 @ 1. attempt
2019-03-03 19:43:06.810 [DEBUG] [de.csdev.ebus.core.EBusController   ] - eBUS collision detected! 0x10
2019-03-03 19:43:06.818 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! 08 [ERROR: INVALID_                                    SOURCE_ADDRESS, DATA: 10 26 B5 23 01 07 D1 00 0F 05 01 00 80 00 80 00 80 03 C8 00 00 80 54 04 DE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0                                    0 00 00 00]
2019-03-03 19:43:07.157 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:92e784cd:15:vrc700_general_gen_bank-holiday-start#valu                                    e" with "FF 15 B5 24 06 02 00 00 00 83 00 60" ...
2019-03-03 19:43:07.161 [DEBUG] [de.csdev.ebus.core.EBusQueue        ] - Size of send queue is 3 ...
2019-03-03 19:43:07.210 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:92e784cd:15:vrc700_general_gen_installer-2#value" with                                     "FF 15 B5 24 06 02 00 00 00 6D 00 B2" ...
2019-03-03 19:43:07.214 [DEBUG] [de.csdev.ebus.core.EBusQueue        ] - Size of send queue is 4 ...
2019-03-03 19:43:07.343 [DEBUG] [de.csdev.ebus.core.EBusController   ] - Send: FF 15 B5 24 06 02 00 00 00 35 00 51 @ 2. attempt
2019-03-03 19:43:07.866 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Unable to send telegram FF 15 B5 24 06 02 00 00 00 35 00 51 after 2                                     attempts ... [ERROR: TOO_MANY_ATTEMPS, DATA: FF 15 B5 24 06 02 00 00 00 35 00 51]
2019-03-03 19:43:07.864 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DA                                    TA: FF 15 B5 AA]
2019-03-03 19:43:08.038 [DEBUG] [de.csdev.ebus.core.EBusController   ] - Send: FF 15 B5 24 06 02 00 00 00 72 00 6E @ 0. attempt
2019-03-03 19:43:08.559 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DA                                    TA: FF 15 B5 AA]
2019-03-03 19:43:08.603 [DEBUG] [de.csdev.ebus.core.EBusController   ] - Send: FF 15 B5 24 06 02 00 00 00 72 00 6E @ 1. attempt
2019-03-03 19:43:08.607 [DEBUG] [re.connection.AbstractEBusConnection] - InputBuffer is not empty before sending: 1 bytes waiting !
2019-03-03 19:43:08.616 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Unable to send telegram FF 15 B5 24 06 02 00 00 00 72 00 6E after 2                                     attempts ... [ERROR: TOO_MANY_ATTEMPS, DATA: FF 15 B5 24 06 02 00 00 00 72 00 6E]
2019-03-03 19:43:08.614 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! 08 [ERROR: INVALID_                                    SOURCE_ADDRESS, DATA: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0                                    0 00 00 00]
2019-03-03 19:43:08.624 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! 6A [ERROR: INVALID_                                    SOURCE_ADDRESS, DATA: 10 26 B5 23 01 07 D1 00 0F 05 01 00 80 00 80 00 80 03 C8 00 00 80 54 04 DE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0                                    0 00 00 00]
2019-03-03 19:43:08.848 [DEBUG] [de.csdev.ebus.core.EBusController   ] - Send: FF 15 B5 24 06 02 00 00 00 83 00 60 @ 0. attempt
2019-03-03 19:43:09.174 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:92e784cd:15:vrc700_general_gen_bank-holiday-end#value"                                     with "FF 15 B5 24 06 02 00 00 00 84 00 97" ...
2019-03-03 19:43:09.179 [DEBUG] [de.csdev.ebus.core.EBusQueue        ] - Size of send queue is 3 ...
2019-03-03 19:43:09.297 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:92e784cd:15:vrc700_general_gen_cylinder-ch-offset#valu                                    e" with "FF 15 B5 24 06 02 00 00 00 29 00 BB" ...
2019-03-03 19:43:09.300 [DEBUG] [de.csdev.ebus.core.EBusQueue        ] - Size of send queue is 4 ...
2019-03-03 19:43:09.369 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DA                                    TA: FF 15 B5 AA]
2019-03-03 19:43:09.413 [DEBUG] [de.csdev.ebus.core.EBusController   ] - Send: FF 15 B5 24 06 02 00 00 00 83 00 60 @ 1. attempt
2019-03-03 19:43:09.417 [DEBUG] [de.csdev.ebus.core.EBusController   ] - eBUS collision detected! 0x10
2019-03-03 19:43:09.424 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! 08 [ERROR: INVALID_                                    SOURCE_ADDRESS, DATA: 10 26 B5 23 01 07 D1 00 0F 05 01 00 80 00 80 00 80 03 C8 00 00 80 54 04 DE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0                                    0 00 00 00]
2019-03-03 19:43:09.507 [DEBUG] [de.csdev.ebus.core.EBusController   ] - Send: FF 15 B5 24 06 02 00 00 00 83 00 60 @ 2. attempt
2019-03-03 19:43:10.032 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DA                                    TA: FF 15 B5 60 AA]
2019-03-03 19:43:10.034 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Unable to send telegram FF 15 B5 24 06 02 00 00 00 83 00 60 after 2                                     attempts ... [ERROR: TOO_MANY_ATTEMPS, DATA: FF 15 B5 24 06 02 00 00 00 83 00 60]
2019-03-03 19:43:10.191 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:92e784cd:15:vrc700_general_gen_cylinder-ch-hyst#value"                                     with "FF 15 B5 24 06 02 00 00 00 27 00 CE" ...
2019-03-03 19:43:10.194 [DEBUG] [de.csdev.ebus.core.EBusQueue        ] - Size of send queue is 4 ...
2019-03-03 19:43:10.206 [DEBUG] [de.csdev.ebus.core.EBusController   ] - Send: FF 15 B5 24 06 02 00 00 00 6D 00 B2 @ 0. attempt
2019-03-03 19:43:10.210 [DEBUG] [re.connection.AbstractEBusConnection] - InputBuffer is not empty before sending: 1 bytes waiting !
2019-03-03 19:43:10.217 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! 08 [ERROR: INVALID_                                    SOURCE_ADDRESS, DATA: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0                                    0 00 00 00]
2019-03-03 19:43:10.221 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! B5 [ERROR: INVALID_                                    SOURCE_ADDRESS, DATA: 10 26 B5 23 01 07 D1 00 0F 05 01 00 80 00 80 00 80 03 C8 00 00 80 54 04 DE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0                                    0 00 00 00]

So, I’ve spend my day to resolve this issue. At the moment I can say that the the TCP connection is working in general in the eBUS core library. But I’m still adjusting the perfect serial to tcp settings. At the moment socat has less issues than net2ser on reading. My Wolf system is very chatty without polling. So all my tests are are only for passive reading the bus!

Next step is to also find the best settings for low latency writing to the bus.

Here my current settings:

socat command:

socat /dev/ttyUSB_EB,rawer,b2400,crnl,nonblock tcp-listen:8881,fork,reuseaddr,keepalive

ser2net configuration file

8881:telnet:0:/dev/ttyUSB_EB:2400 8DATABITS NONE 1STOPBIT

My quick test shows that with socat I’ve an error rate of 4% and with ser2net about 30%. But this test is only over 10 mins each. So not really reliable.

Here some results:

socat

15:10:51.820 [main] [INFO ] d.c.e.c.EBusStateMachineTest - Failure ratio: 4.9%
15:10:51.820 [main] [INFO ] d.c.e.c.EBusStateMachineTest - Failed: 36
15:10:51.820 [main] [INFO ] d.c.e.c.EBusStateMachineTest - Received: 699
15:10:51.820 [main] [INFO ] d.c.e.c.EBusStateMachineTest - ReceivedAmount: 11512

ser2net

14:59:02.073 [main] [INFO ] d.c.e.c.EBusStateMachineTest - Failure ratio: 29.7%
14:59:02.073 [main] [INFO ] d.c.e.c.EBusStateMachineTest - Failed: 220
14:59:02.073 [main] [INFO ] d.c.e.c.EBusStateMachineTest - Received: 520
14:59:02.074 [main] [INFO ] d.c.e.c.EBusStateMachineTest - ReceivedAmount: 8780

So here my best settings for serial over tcp.

Reduce the latency for FTDI serial to usb converts.

echo 1 > /sys/bus/usb-serial/devices/ttyUSBn/latency_timer

Create a low latency tcp connection

socat /dev/ttyUSBn,rawer,b2400,nonblock tcp-listen:8881,fork,reuseaddr,keepalive,nodelay

Collegues have the same issue with using of /dev/ttyebus. ebusd check passed with succsess. I’ve added /dev/ttyebus to /etc/defaultopenhab and it appeared in Paper UI. Could you please give me a liitle more things what to do to make it working.

ion.EBusSerialNRJavaSerialConnection] - Unable to connect to serial port /dev/ttyebus

Thanks for investing your time in this. How are your two devices connected, via lan or wifi? This most likely has a huge impact on the connection. I have a failure ratio of 14% after 15 minutes without polling over wifi.

I tried your socat line, but socat does not work with the ebus adapter from the FHEM forum. As soon as the client connects, the ebus driver logs an exception and the connection is directly dropped:

2019/03/05 17:06:24 socat[11827] E read(5, 0x1d86100, 8192): Bad address

I already asked about this on the fhem forum, but nobody answered. Maybe I should try to contact the driver author directly!?!

Exactly the same issue and message on my raspi. The socat command didn´t work for me, too.
With ser2net and only the ebus bridge with the metrics in control-view i have a failed telegram ratio of 3% over a day. If i add a thing like VRC 700 General the failed ratio bumped up to 75%-90%.

@Sergiy_Podnos
Hi. Directly connecting to the serial port worked for me pretty bad, so that the ebus bridge gave me connection error after a minute or so. Then i tried with ser2net and added the following line in /etc/ser2net.conf

8888:raw:0:/dev/ttyebus:2400 8DATABITS NONE 1STOPBIT

After this you can add an ebus bridge in openhab with localhost and port 8888 instead of using serial connection. But you see, there are still some showstopping issues around there. :wink:

1 Like

I have now contacted the ttyebus author and asked for help. I hope he is willing to help and this will help us using socat with ttyebus. I will keep you posted on progress, if any.

Regarding the current setup, it seems to be relatively reliable for me. I have now activated polling on my BAI device and still have a 10% failed ratio while at last getting values for my items. Without polling, I also only had time and outside temp.

But my devices are detected differently by the eBus binding:

smarthome:ebus list
Thing UID                                | Label                                    | Type      
-----------------------------------------+------------------------------------------+-----------
ebus:bai:e5920e96:08                     | Vaillant BAI00 (08)                      | node      
ebus:vrc430:e5920e96:15                  | Vaillant VRC 430(f)/470(f) (15)          | node      
ebus:bridge:e5920e96                     | eBUS Bridge                              | bridge  

I do not know what is causing the difference. Might the wiring be a problem? I use a relatively short wire from the bus to the adapter. How much impact has shielding the wire, might there be interference?

Hi vbier,

thank you very much for trying to contact the author of ttyebus… hope he will help us.

My wire is very short, too. I´ve used a pair of 1,5mm² with a lenght of about a meter (unshielded). If i´m at work after the weekend, i´ll take a special Bus-Cable (Siemens Profibus for industial machine communication) to home and try it with this shielded one. But i guess, this doesn´t make a big difference on a meter…

I´ve tried to add the BAI thing like you did. without polling i have a failed telegram ratio of nearly 10%, but if i set polling to every 60s, it bumps up to 50% after a few minutes.
Without polling i get some more readings than in VRC700-thing. With polling enabled, i only get the time & outside temperature.

Hope we will get it work someday…

@csowada
If i use telnet in my ser2net-config, i have the most errors with about 50% failed telegram ratio. With raw instead of telnet, i have less than 10% error-rate.

Hello Guys,

I have a fresh install of OH2 2.5.0.M1 Milestone Build on RPi3 Stretch. After installing Ebus 2.0 binding in PaperUI I get the below error messages. The binding does not show up in settings in Paper UI. Can you suggest a solution to this error?

21:15:58.057 [INFO ] [smarthome.event.ExtensionEvent       ] - Extension 'market:binding-3670618' has been installed.
21:15:58.052 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 
java.lang.NullPointerException: null
	at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) ~[?:?]
	at java.util.concurrent.ConcurrentHashMap.containsKey(ConcurrentHashMap.java:964) ~[?:?]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.registerReadyMarker(XmlDocumentBundleTracker.java:426) ~[?:?]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.finishBundle(XmlDocumentBundleTracker.java:374) ~[?:?]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.processBundle(XmlDocumentBundleTracker.java:397) ~[?:?]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.access$6(XmlDocumentBundleTracker.java:389) ~[?:?]
	at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker$2.run(XmlDocumentBundleTracker.java:359) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:?]
	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) [?:?]

Thanks,
Peter

I hope there is no new issue with 2.5. But do you use the latest kar file from post 1? The error message sounds like you use the market place version.

I did use the market binding. Now with KAR file everything is ok. Thank you.

Hello,

I have a Vaillant VRC 430(f)/470(f) and would like to see both HC1 and HC2 data. HC1 data is displayed Ok. Do you guys have an idea how can I get HC2 data from my thermostat?

Thanks,
Peter

Hey guys,

now i´ve connected the VRC700 & my ebus-platine with a shielded bus-cable. Unfortunatelly with the same results. No other values where displayed with this one… also no better failed telegram ratio at all, so it´s not about the cable.

This week i tried to manage some readings with FHEM & ebusd via telnet-protocol. No problems with this setup. All configured readings are working pretty well.

I´ve no idea what to do with the ebus binding to get it work.

I’asked the author of ebusd to add the raw telegrams to the deamon. In that case I could add direct ebusd support to the binding. In that case we could use the ebusd for the low level access yo the bus.

1 Like

That sounds good. Im looking forward to test it, if and when its implemented.

Im also looking forward to test it …

Hello,

i installed the latest version

eBUS binding 2.4.0-RC4

with ttyebus.

If i start openhab and try to “Configure eBUS Bridge” there i can only find /dev/ttyS0 Serial Port. How can i solve the problem to select ttyebus?

Do i also have to install “eBUS binding 2.4.0-RC4” when i installed ebus with this instruction https://github.com/john30/ebusd-debian/blob/master/README.md?