eBUS Binding 3.x [3.4.0;3.9.9)

Hi @csowada ,

I dare to unburry an old request:

If I force polling a variable (Solar return temperature of a Wolf SM1) then I do get an emergency break:

2021-01-30 11:59:37.799 [ERROR] [dev.ebus.core.EBusLowLevelController] - emergency break!!!!

I hoped that this error got fixed in th 2.50.10 release but unfortunately not. Any help?

Hi folks,

is there any possibility to add this binding as a pull request to openhab-addons?
I’ve tried placing the KAR to my openhab3 installation but it didn’t do anything.

I’ve used Version 2.5.1-8 (latest according to OP).

Thanks for your work!!! :slight_smile:

Best,
Sascha

The current 3.0 version is only loading with Openhab 3.0.0, not 3.0.1. I’ve fixed that today, but is not tested yet. But you can find it on GitHub as a new release.

1 Like

Thanks (again?) for the binding - been super useful.

I’ve recently updated to OH3 and was using the 3.0.10 binding with 3.0.1, but was experiencing an issue with items not polling as expected. I updated to 3.0.11 but this hasn’t resolved the issue. Struggling to tell if it’s binding or core.

The issue is that I’ve bound a number of channels to items (using the UI) and explicity defined the polling period to 60 seconds for each (I found on OH2 that blanket setting everything at binding level would eventually slow everything down). Initially this worked fine, but on restarting openhab I noticed two related but distinct issues. Some, but not all channels were not polling as expected. They were not showing in the logs and were displaying last values on the UI - graphs showing a straight line.

  1. For some of these channels, if I re-set the polling period (value was already in there in the text box) they would start updating as expected and apparently had been just fine, as the graph showed full history.
  2. For others, after re-setting the polling period there was no history but were now polling again.

It appears to affect the same channels on every restart. It’s almost as if the polling period was not persisted after shutdown or read on startup. A bit bizzare, but reproducable. Please let me know if there’s anything specifically you need and I’ll do it.

Hello @drc,

could you please set the log level trace please.

log:set TRACE org.openhab.binding.ebus.internal.handler.EBusHandler

Then please restart your server and check the logs. Can you see errors? Can you find the missing channels in the log? Please send me the log, maybe I can identify the issue.

Hello @drc ,

I’ve checked the sources, but I can’t see any issue. But I’ve changed smaller things and added some more log details. Could you please try this snapshot release?

SNAPSHOT 3.0.12

I have not looked in sources BUT channelLinked methods are basically broken in OH3 due to the way how refreshed internals work (linking is fine until restart, on startup mine usually do not work). Do you rely on these to start polling?

EDIT - I just had a look and that’s the case: openhab-ebus-binding/EBusHandler.java at main · csowada/openhab-ebus-binding · GitHub
What happens internally is that starting of thing handlers is too early compared to links so when links are “activated” and channelLinked method is about to be called handler is not initialized yet. This results in situation where links work when you create them, but break after restart. For my multicore desktop its always a case, maybe for slower ones its better.
I found this in bacnet binding which used channelLinked with OH 2.x. For OH 3.x as an workaround I initialize polling when handler is initialized.

The ultimate solution is holding up link activation until thing handlers are initialized using newly introduced ReadyTracker service. I am not sure how configuration could look a like, but in general - if you aim compatibility with OH 3.0 avoid use of links.

1 Like

Continuing the discussion from [eBUS 2.0,3.0] Binding - Release 2.50.11 & 3.0.11:

I’ve updated to binding 3.0.12 and restarted. In the log, you’ll see a few channels that I’ve bound routinely pulling values back, as well as temp_outside being pushed ad-hoc. I’ve trimmed some of the bulk after things settle to highlight the relevant parts.

  • At 22:42:49 I change the polling period value of temp_room to 59 and back to 60 (I don’t think the UI sends anything if you leave it as is). Shortly after, values start coming through as expected.
  • At 22:43:00 I change the polling period value of temp_d_flow to 59 and back to 60, and it too starts to come through.

ebus.trace.openhab.log (325.0 KB)

Obvoiusly I have difficulties getting an answer to a simple question. I will post it again here. If this is the wrong place please point me to the support thread.

Is the Vaillant VCR700 supported just by installing the binding?
Maybe no as it is not in list on github.
If not where can I find the VCR700 configuration file.
The links on github under eBUS Configuration do not work.

Unfortunately I have not found any other documentation that answers this question.

Hi @splatch,

thank you for sharing your information. That is as always very helpful.

Okay, old reply is now away :wink: Could you please check if the latest snapshot fix your issue?

Looks good now - thanks!

Thanks, than I can start fine-tuning to create an official release.

I just could not get it to work with my friends openhab installation (3.0.1) using v3.0.11.

We use ebusd-esp and ebus-Adapter “FHEM Version 2.2 GH2”. Using ebusd we get up to the point where we see data regularly coming in:

2021-02-07 15:25:01.933 [main debug] performing regular tasks
2021-02-07 15:25:02.210 [bus notice] ...<ffffffb88cf8b330ef06f7808360ffffffffffffb88cf8b330ef06f7808360...
2021-02-07 15:25:02.953 [bus notice] ...<3fffffffffffb88cf8b330ef06f78083601fffffffffb88cf8b330ef06f780...
2021-02-07 15:25:03.749 [bus notice] ...<83603fffffffffffb88cf8b330ef06f78083607fffffffffffb8f8f89ef8ee...
2021-02-07 15:25:04.234 [bus notice] ...<0367f6fc806360c080c080ccbcfb80ffffffffffb88cf8b330cfe03e838080...
2021-02-07 15:25:04.955 [bus notice] ...<be80ffffffffffb88cf8b330cfe07e838080be80ffffffffb88cf8b330cfe0...

Does this seem like valid data? Do we need to use ebusd as a bridge or is boiler/ebusd-esp/binding/openhab sufficient? It’s a Wolf CGB-2-(K)-20 boiler.

Thank you so much for your binding and hard work and your support! I’d really like to get my friends boiler to talk to openhab :wink:

Best,
Sascha

You also need the ebusd deamon running with the right parameters. Then create a bridge with network and driver “ebusd”.

1 Like

@csowada,
since i have upgraded to OH 3 and your Binding to 3.x i get an EBUS queue error every 3 or 4 days.
“…Send queue is full! The eBUS service will reset the queue to ensure proper operation. …”
Have you an idear what could be the problem and how can i fix it?

I use OH3 and the ebus Binding 3.0.12 Snapshot Release. The BUS connection is made via a USB coupler and the buildin serial driver.

Hi, @csowada, I need your help.

I have a command:

{
            "label":    "HWC Mode",
            "id":       "hwc.mode",
            "command":  "B5 04",

            "get": {
                "master": [
                    {"type": "static", "default": "01"}
                ],
                "slave": [
                    {"name": "temp_desired", "type":"uchar", "label": "Desired temperature"},
                    {"name": "operating_mode", "type": "uchar", "label": "Operating mode"}
                ]
            }
        },

But binding cant recognize answer, why?

11:18:40.266 [TRACE] [ing.ebus.internal.handler.EBusHandler] - Poll command "ebus:hwc:home:25:hwc_hwc_mode#temp-desired" with "FF 25 B5 04 01 01 76" ...
11:18:40.433 [TRACE] [us.internal.handler.EBusBridgeHandler] - Unknown telegram FF 25 B5 04 01 01 76 00 09 32 03 00 00 03 83 00 01 00 D3 00
11:18:40.508 [TRACE] [us.internal.handler.EBusBridgeHandler] - Unknown telegram 30 26 B5 04 01 0D 9E 00 05 28 00 3F 02 19 47 00
11:18:40.692 [TRACE] [us.internal.handler.EBusBridgeHandler] - Unknown telegram 30 26 B5 04 01 32 A1 00 0A 00 00 00 00 00 00 70 ED 00 00 E9 00
11:18:40.844 [TRACE] [us.internal.handler.EBusBridgeHandler] - Unknown telegram 30 26 B5 05 04 2D 12 00 00 F1 00 00 00
11:18:42.088 [TRACE] [ing.ebus.internal.handler.EBusHandler] - Poll command "ebus:vkk:home:08:vkk_boiler_pressure#pressure" with "FF 08 B5 09 03 0D 02 00 3A" ...
11:18:42.272 [DEBUG] [us.internal.handler.EBusBridgeHandler] - Received telegram from address FF to 08 with command boiler.pressure
11:18:42.274 [DEBUG] [us.internal.handler.EBusBridgeHandler] - No handler has accepted the command boiler.pressure from FF to 08 ...
11:18:42.286 [DEBUG] [us.internal.handler.EBusBridgeHandler] - Received telegram from address FF to 08 with command boiler.pressure
11:18:42.288 [TRACE] [ing.ebus.internal.handler.EBusHandler] - eBUS handler cfg EBusHandlerConfiguration [slaveAddress=08, masterAddress=null, filterAcceptMaster=false, filterAcceptSlave=true, filterAcceptBroadcasts=true, polling=60]
11:18:42.292 [DEBUG] [ing.ebus.internal.handler.EBusHandler] - Handle received command by thing Vailant VKK INT 476 with id ebus:vkk:home:08 ...
11:18:42.294 [TRACE] [ing.ebus.internal.handler.EBusHandler] - Key pressure with value 1.452
11:18:42.297 [TRACE] [ing.ebus.internal.handler.EBusHandler] - Key status with value 0

Hello everybody.

I still use the eBus binding in the old OpenHAB version.
I am currently switching to OH3 ( openHAB 3.0.1 ).
When I copy the “org.openhab.binding.ebus-3.0.11.kar” into the “openHAB-addons” folder and restart, I cannot find that under binding add-ons to install.
Am I doing something wrong?

Is the binding working after that error? Do you have used a FTDI buffer setting under Linux that is now not set anymore?

The slave answer you receive (9bytes) is much longer than in your config (2bytes). So this command is not correct for your device.

1 Like