eBUS Binding 3.x [3.4.0;3.9.9)

In my case I have Unresolved telegrams ratio at 61.2%. I wonder which is the recommended value for it? :slight_smile:
From the user point of view I see correct values but that is true that the biggest number of warnings in my OpenHab logs came form eBus binding :confused:

Not sure how to improve it - I thought it is rather physical connectivity issue rather than binding itself?

Since I have an Essera USB Coupler so maybe I shall use the small screwdriver to adjust better synhronization ?
But also in my case I have Esera USB coupler connected via 4 wires (2x2 wires) of ethernet cable (~ 30 meters distance) which is below the diamiter of the eBUS standard cable requirements.

Rafal - I am using very similar configuration.
In my case I use two wires of cat5 Ethernet cable, about 10m length.
To adjust the Esera USB coupler I followed this guide: https://github.com/john30/ebusd/wiki/6.-Hardware
I think the problem lies not on the hardware part - telegrams are being received (in my case only 3% ratio of failed telegrams), but not ā€œunderstoodā€ by the binding (unresolved telegram ratio 81%).
EBus configuration files?

Ok, I understand the difference between unresolved and failed telegrams now, in my case I have similar ratio of failed telegrams at 3.6%. Regarding unresolved telegrams I am wondering if it might be related to json and/or channels unused in bindings?

2020-06-29 20:49:25.433 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0x00 is not equal to send byte 0x08! Stop send attempt ...
2020-06-29 20:49:33.382 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0x08 is not equal to send byte 0x09! Stop send attempt ...

I mean that ebus binding listen to all telegrams in eBus network and some of them are not linked to any items/things ? I think that the best person to comment on that would be the author of this binding :slight_smile:

csowada

Itā€™s basically thatā€¦
For me ā€œunresolved counterā€ went down from 80+% to slightly above 40% when implementing custom json config adopting the ebusd configuration files.
I only added about 20 telegrams to be resolved.

Same situation. Iā€™m interested about JSON config filesā€¦ Can you show me an example or where to download?

I canā€™t help with the configuration files, but everyone is welcome to commit good configuration files to the the project.

ok, only an example, a starting pointā€¦

To see the used json files of ebus you can open the kar-file e.g. with 7zip. Going there in the different folders you find them and you will have good examples.
Those was also helpful for me to create my own custom json and have an ā€˜unresolved telegram ratioā€™ of 0%.

Hope I am not wrongā€¦
Unresolved telegram ratio do not mean errors by reading the telegram. It is unknown how to handle the incomming bytes.
To check the physical configuration the ā€˜Failed telegrams ratioā€™ is the right value

Hello @Roland62,

you are right, it only means that the valid byte data canā€™t be resolved with any configuration file. The easiest way to check the build-in configurations it to use the git repository.

Iā€™ve got a question to other VRC 700 owners like @fhatz @Trainer @falter @Roland62. : Would it be possible to remove the VRC 700 from the setup and control everything directly with openHAB when using the ESERA-Automation / E-Service GmbH: eBus Koppler USB?

Because in my opinion the VRC 700 is ugly as hell. The thing is unnecessary big and I do not want it on my living room wall.

I have temperature sensors through out my house, so I would like to use their data to control my heating system (geoTHERM 3 kW heat pump from my Volthera PVT system).

I would never use openhab to control the core functionality of an heating system. I would rather use it to add extra value on an higher level and log data. If openhab crashes or the binding, your house is maybe frozen while you are on Christmas Holiday :wink:

I have faith in openHAB :grin:

1 Like

Try Tado. Looks nice, comes with app and is reliable as your internet connection (depends on it).

There is no way to control the heating system over eBus-binding without VRC 700. Not all eBus messages are well understood and the binding allows nicely to read out the VRC 700 and to put some commands to the VRC 700. For this the VRC 700 does not need to be in the living room, mine is in the heating room.

fhz

1 Like

The VRC 700 is the real control system for your heating system.
But if you want not to have it in your department you can place it in the boiler. Right of the control panel there is a bezel (ā€œPlastik-Blendeā€). You can put it out, and place the VRC-700 whitout the casing into the boiler.

Here in my environment it was the other way. The engineer placed it in the boiler, I had already cabeling to my kitchen. Afterwards I saved the cabinet and the bezel and placed it in my kitchen.
The positive affect to have it in your living space: You can configure temperature sensor of the VRC-700 to switch of the boiler in general. E.G. in summer if the room temperature is over 23 Degree no room has to be heated and the heating system of the boiler can to be switched off. Without any summer/winter configuration.

1 Like

Hi I am using openhab.binding.ebus-2.5.1-6 which worked well quite a long time. Since a few weeks i get these type of messages in the openhab log:
ā€œ[WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0xFF is not equal to send byte 0x15! Stop send attempt ā€¦ā€
It comes repeatedly with different bytes but always this message.

I have tried updating the Raspberry Pi, restarted several times, deleted the logs, cleared the cache ,checked the hardware - no change. If somebody has an idea i would appreciate a hint in the correct direction.

Hi Dobie, those is happened if another device was sending in the same time, where your openhab try to send somewhat.
If this error comes quite seldom I think you can ignore it. If it comes more often try to configure your system makes less traffic on the ebus.
One simple option is to increase the polling time.
Little bit more effort - some information where you are interested in are transferred between different devices already on the ebus. Try to find out, take those parameter without an own poll. Here I have a vrc-700. And I found out that I can re-use a lot of pices of information witch are coming or sent by those one.
Good look - Roland

Hi Roland, thanks - i will try that.
The actual problem is that the Ebus communication stops completly after a few hours. So ignoring it is not a solution :wink:

Yesterday evening i restarted Openhab and got the log contents below.
It seems to point in the direction of too much pollingā€¦

But right in the beginning of the EBUS initialization it says:
ā€œUnable to find command method GET boiler.control.setopdata bai !ā€

The fatal sentence in the log says:
ā€œ[ERROR] [dev.ebus.core.EBusLowLevelController] - emergency break!!!ā€

Strange that it worked so longā€¦

2020-09-09 21:49:19.049 [INFO ] [ng.ebus.internal.handler.EBusHandler] - (Re)Initialize all eBUS pollings for ebus:vrc700_hc1:5caf246a:15 ā€¦
2020-09-09 21:49:19.084 [INFO ] [ng.ebus.internal.handler.EBusHandler] - (Re)Initialize all eBUS pollings for ebus:bai:5caf246a:08 ā€¦
2020-09-09 21:49:19.121 [ERROR] [ebus.internal.utils.EBusClientBridge] - Unable to find command method GET boiler.control.setopdata bai !
2020-09-09 21:49:19.123 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Unable to create raw polling telegram for ā€œboiler.control.setopdataā€ !
2020-09-09 21:49:19.126 [ERROR] [ebus.internal.utils.EBusClientBridge] - Unable to find command method GET boiler.control.setopdata bai !
2020-09-09 21:49:19.127 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Unable to create raw polling telegram for ā€œboiler.control.setopdataā€ !
2020-09-09 21:49:19.139 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for ā€œboiler.control.getopdataā€ every 120 sec. (initial delay 2 sec.)
2020-09-09 21:49:19.143 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for ā€œboiler.flameā€ every 120 sec. (initial delay 16 sec.)
2020-09-09 21:49:19.146 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for ā€œboiler.control.getopdataā€ every 120 sec. (initial delay 6 sec.)
2020-09-09 21:49:19.153 [ERROR] [ebus.internal.utils.EBusClientBridge] - Unable to find command method GET boiler.control.setopdata bai !
2020-09-09 21:49:19.159 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Unable to create raw polling telegram for ā€œboiler.control.setopdataā€ !
2020-09-09 21:49:19.164 [ERROR] [ebus.internal.utils.EBusClientBridge] - Unable to find command method GET boiler.control.setopdata bai !
2020-09-09 21:49:19.165 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Unable to create raw polling telegram for ā€œboiler.control.setopdataā€ !
2020-09-09 21:49:19.178 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Raw telegram already in use for polling, skip addition polling for ā€œebus:bai:5caf246a:08:bai_boiler_control_getopdata#temp-lead-waterā€!

ā€¦
2020-09-10 00:28:27.548 [ERROR] [dev.ebus.core.EBusLowLevelController] - emergency break!!!

Writing to the bus heavily depends on the latency of your adapter. Have you set a ā€œlow latency modeā€ in the past? One problem is the write buffer, it should be disable to directly answer after each byte. For FTDI serial converters you can set it on Linux. It should be mentioned in the reader file of the binding.