[eBUS 2.0] New binding - Release Candidate 7b

Hello,

I have read a lot about the eBus binding, but there is one important question for me.
I have a VCR 700 (Vaillant) on my Boiler to controll it. How can I add support for this device to the eBus binding or is this device compatible?

Thank you for your help!

It is supported.

Just a minor hardware related note:

I’ve been trying to use the raspberry pi’s internal HW UART along with a home built Ebus converter but I’m getting a lot of errors. Telegram fail ratio is over 85%
It seems that, even though transmitted telegrams were usually initiated within 35ms after previous SYN, they got cancelled by the next SYN byte. The hexdump was full of source-address β€œff” bytes, immediately followed by SYN bytes

00009d0 aaaa 0810 10b5 0009 3900 ff78 00ff 0000
00009e0 0035 0101 009a aaaa aaaa aaaa ffaa aaaa
00009f0 aaaa aaaa aaff aaff aaaa aaaa ffaa ffaa```

I now bypassed the internal uart with an FTDI and fail ratio is under 20%
I doubt this has anything to do with the binding and it’s rather related to the rpi’s internal uart?
Just posting this as I can imagine others wanting to go the same route.

Thanks for all the hard work and devotion!

1 Like

Thank you, and is there anywhere a list with the available channels?

Hello @arnolievens,

I would guess that the RXTX ( nrjavaserial ) serial library is responsible for this behavior. Ebusd can directly access the hardware, in Java we need an additional library.

@johannesbonn,

you should install the binding and manually add an item. Or you check the json files here

Thank you for your help, but my problem is the item definition. Is there anywhere an example?

Have a nice evening!

Hey,

i have a VRT 392, which kind of protocol can i use?

Hello @Trainer,

I’m currently working on an ebusd configuration converter. I hope I can release a version this or next week. If everything works well, we can use all available ebusd configurations for the binding. I will start a new topic if I’m ready.

Hello @csowada ,

so with this configuration converter i can use it with my VRT 392??

That sounds great. Thank you for your hard work.

If you device is available in the ebusd configurations it should work.

My device is not on the list Vaillant.

Can i try a different protocol if it doesn’t match or can i damage my system if i try it?

if I understand it right, it is possible to create parsers easier? I have an own parser for my vaillant 620 and 560. But only some items. I would create a full parser. But with the tool it seems easier. Should I wait?

Hello @Trainer

you should check this repository. The is my source for the converter.

Hello @Cernon,

with converter I’m able to convert 99% of all configuration files automatically. The quality of automatic converted files are not good enough to add it directly to the binding. Maybe as marked as Experimental or as separate configuration package.
I’m not able to check the the configuration files with a Vaillant device, so I can only compare the generated configurations with the ones already included in this binding.

But it create an editional parserfile? So I can work on it and finetune and test it? But you open an own topic for this.

New topic for the Vaillant ebusd-configuration converter …

Hey @csowada
Thank you very much for your great work. I’m really enjoying your binding and switched from my ebsud/MQTT selfmade binding to your binding.
I too have the stability problem @witek_1308 has reported in this thread.

I have 11 Items configured with a polling interval of 180s. After a while the binding stops updating the values although the polling seems to continue. The log debug shows:

09:27:04.241 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:ebusbridge:vrc700_general:vrc700_general_gen_pressure#value" with "FF 15 B5 24 06 02 00 00 00 39 00 89" ... 09:27:04.297 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_hwc:ebusbridge:vrc700_hwc:vrc700_hwc_hwc_sf-mode#value" with "FF 15 B5 24 06 02 00 01 00 0D 00 40" ... 09:27:05.266 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_hwc:ebusbridge:vrc700_hwc:vrc700_hwc_hwc_holiday-end#value" with "FF 15 B5 24 06 02 00 01 00 0A 00 B7" ... 09:27:05.303 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_hwc:ebusbridge:vrc700_hwc:vrc700_hwc_hwc_op-mode#value" with "FF 15 B5 24 06 02 00 01 00 03 00 35" ... 09:27:05.313 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:bai:ebusbridge:bai:bai_boiler_temp-return#temp-return" with "FF 08 B5 09 03 0D 98 00 B7" ... 09:27:07.233 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:ebusbridge:vrc700_general:vrc700_general_gen_display-outside#value" with "FF 15 B5 24 06 02 00 00 00 73 00 F5" ... 09:27:07.278 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_hwc:ebusbridge:vrc700_hwc:vrc700_hwc_hwc_holiday-start#value" with "FF 15 B5 24 06 02 00 01 00 09 00 81" ... 09:27:08.249 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:ebusbridge:vrc700_general:vrc700_general_gen_operation-mode#value" with "FF 15 B5 24 06 02 00 00 00 7B 00 EC" ... 09:27:09.266 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_hwc:ebusbridge:vrc700_hwc:vrc700_hwc_hwc_holiday-end#value" with "FF 15 B5 24 06 02 00 01 00 0A 00 B7" ... 09:27:09.306 [ERROR] [de.csdev.ebus.core.EBusQueue ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation. 09:27:09.312 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:bai:ebusbridge:bai:bai_boiler_temp-return#temp-return" with "FF 08 B5 09 03 0D 98 00 B7" ... 09:27:11.300 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_hwc:ebusbridge:vrc700_hwc:vrc700_hwc_hwc_storage-temp#value" with "FF 15 B5 24 06 02 00 01 00 05 00 59" ... 09:27:13.245 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_general:ebusbridge:vrc700_general:vrc700_general_gen_maintenance-due#value" with "FF 15 B5 24 06 02 00 00 00 96 00 08" ... 09:27:16.318 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:bai:ebusbridge:bai:bai_boiler_temp-flow#temp-flow" with "FF 08 B5 09 03 0D 18 00 BC" ... 09:27:19.277 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:vrc700_hwc:ebusbridge:vrc700_hwc:vrc700_hwc_hwc_holiday-start#value" with "FF 15 B5 24 06 02 00 01 00 09 00 81" ... 09:27:19.313 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Poll command "ebus:bai:ebusbridge:bai:bai_boiler_temp-flow#temp-flow" with "FF 08 B5 09 03 0D 18 00 BC" ...

bundle:list
204 β”‚ Active β”‚ 80 β”‚ 2.4.0.201807101913 β”‚ eBUS Binding

OH2 Version 2.3

If I stop OH2, clear the cache (openhab-cli clean-cache) and start OH2 again everything works great for a few days, till it stops updating again. Ebusd was running about a year (with restarts in between of course) but without a similar issue. All other bindings continue to work fine, this only happens with the ebus binding.

Do you have an Idea how to solve this problem?

On diffentence to ebusd is that I must use a serial library to communicate with the device. SO I can’t control the serial device.

You could check this topic on lo latency, maybe it can help.

I’ve added an alternative serial library in the past for the 1.x binding, maybe it is useful for the 2.x binding too.