In my case I have Unresolved telegrams ratio at 61.2%. I wonder which is the recommended value for it?
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
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 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.
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
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
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.
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.
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
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ā!
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.