eBUS Binding 3.x [3.4.0;3.9.9)

[mwildbolz]

@csowada Just one question: Is it normal, that the binding in OH3 (after copying the kar file into addons-folder) is not shown in MainUI->Configuration->Bindings?
Why I ask: Where/how should i configure the bundleFileUrl??

BR,
MW

[mwildbolz]

Another question regarding ebus Binding 3.0.10 with OH3:
Does anybody also see a very high number of errors in the log when using this ebus binding? Binding is working quite normal (as far as I can see), but there are a lot of errors like (and many more):

• bundle org.openhab.core.model.item:3.0.0.202012201729 (256)[org.openhab.core.model.item.internal.GenericItemProvider(307)] : Error during instantiation of the implementation object - java.lang.IllegalArgumentException: argument type mismatch
• bundle org.openhab.core.model.thing:3.0.0.202012201733 (266)[org.openhab.core.model.thing.internal.GenericThingProvider(310)] : The activate method has thrown an exception
• bundle org.openhab.core.karaf:3.0.0.202012201715 (255)[org.openhab.core.karafaddons(340)] : Error during instantiation of the implementation object

Also, the API Explorer is not useable (generates an error message in the logs).

openhab_ebus_Erststart.log (923.4 KB)
openhab_ebus_Restart.log (493.9 KB)

openhab_noebus_Erststart.log (2.5 KB)
openhab_noebus_Restart.log (2.5 KB)

Details to my environment:
Fresh installed OH3 via Docker image with 3.1.0-SNAPSHOT (Build #2160)
ebus 3.0.10 kar-file

What could I do to get rid of this?

Thanks,
MW

[csowada]

Mh, looks like a general openhab cache issue !? I’ve tested the binding with 3.0.0 release on windows and linux docker. But you use a SNAPSHOT release, maybe it is currently broken. Please test with the latest openhab release, I can’t help with snapshot releases of openhab.

[mwildbolz]

Good Morning!

You are right, looks like a problem introduced in the current snapshot build.
When using 3.0.0 no problems like the one’s mentioned before - but another one with one specific thing where I’m not able to get rid of:

[ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handler of thing 'ebus:vrc700_general:hzg:15': can't parse argument number:
java.lang.IllegalArgumentException: can't parse argument number:
        at java.text.MessageFormat.makeFormat(MessageFormat.java:1451) ~[?:?]
        at java.text.MessageFormat.applyPattern(MessageFormat.java:491) ~[?:?]
        at java.text.MessageFormat.<init>(MessageFormat.java:370) ~[?:?]
        at java.text.MessageFormat.format(MessageFormat.java:859) ~[?:?]
        at de.csdev.ebus.command.EBusCommandException.<init>(EBusCommandException.java:34) ~[?:?]
        at org.openhab.binding.ebus.internal.utils.EBusClientBridge.generatePollingTelegram(EBusClientBridge.java:259) ~[?:?]
        at org.openhab.binding.ebus.internal.handler.EBusHandler.getChannelTelegram(EBusHandler.java:276) ~[?:?]
        at org.openhab.binding.ebus.internal.handler.EBusHandler.initializeChannelPolling(EBusHandler.java:417) ~[?:?]
        at org.openhab.binding.ebus.internal.handler.EBusHandler.updateChannelPolling(EBusHandler.java:613) ~[?:?]
        at org.openhab.binding.ebus.internal.handler.EBusHandler.updateHandler(EBusHandler.java:624) ~[?:?]
        at org.openhab.binding.ebus.internal.handler.EBusHandler.initialize(EBusHandler.java:383) ~[?:?]

Thing Definition:
Thing vrc700_general 15 "Vaillant VRC700 General" [ slaveAddress="15", polling=600 ]

This Thing (and only this one) has also the status UNINITIALIZED - HANDLER_INITIALIZING_ERROR - can’t parse argument number:

Any idea for that? The exact same configuration worked with the 3.1.0 snapshot and also in my current OH2.5 environment…

Greetings from Austria

[tlc (Cristian Toader)]

Hello, does anyone have a cascade configuration with at least Vaillant 2 heaters and a Calormatic 630 controller?

I have such a configuration and I would like to know if devices that are behind a VR32 bus coupler are visible on the “master” ebus via an ebus adapter.

To be more specific, I have the following devices:
1 x Vaillant Ecotec heater - connected via ebus +/- on the mainboard
1 x Vaillant Ecotec heater - with a VR32 ebus coupler inside (this device joins the 2nd ebus of the 2nd heater to the “master” ebus together with Heater 1)
1 x Calormatic 630 controller - connected to the same “master” ebus.

What happens if you change for example “target flow temperature” from the smart home platform? Does the Calormatic 630 perceive and acknowledge the parameter change? Or it will be in conflict with the new value set via smart home?

I am waiting for the new ebus adapter 3 from fhem to arrive, but until then I am gathering as much information as I can.

Thanks,
Cristian

[mikeww1]

I have posted a beginners question here:

Ebus 2 and Vaillant VRC700 problems to get it working

After reading long threads for a couple of hours I was sure that my Vaillant VRC700 is supported out of the box now. Using the Esera USB device I get a lot of items in my configuration. Unfortunately none seems to be right for VRC700. The only information I get from the bus is date/time and outside temp and boiler temp. Here are screenshots. Am I missing something. Is the VRC700 configuration not included? Maybe someone can give me directions for the correct next steps. [grafik] [grafik] [gr…

I did not want to spoil this thread with these type of questions. As I have not received an answer I link it here.

[tkropf (Thomas K.)]

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?

[eBUS 2.0] New binding - Release Candidate 7b

Hi @csowada, thanks for your quick reply, much appreciated I tried “E1 - Return temp” , same issue. If I force a read on my BM directly, the correct value shows up in your binding. Thus, SM1 address and variable address seem to work. As soon as I force a polling, the error message occurs. Strange. I discovered your BM heating program command. Unfortunately, it does not work, same error message as above. Eventually, I will have to dig myself in the eBus protocol, which I avoided until now (…

[Sascha_]

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!!!

Best,
Sascha

[csowada]

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.

Release v2.50.11 · csowada/openhab-ebus-binding

Release v3.0.11 · csowada/openhab-ebus-binding

[drc (Dan)]

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.

[csowada]

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.

[csowada]

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

[splatch (Łukasz Dywicki)]

@csowada

But I’ve changed smaller things and added some more log details

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/bundles/org.openhab.binding.ebus/src/main/java/org/openhab/binding/ebus/internal/handler/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.

[drc (Dan)]

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)

[mikeww1]

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.

[csowada]

Hi @splatch,

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

[csowada]

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

Release 3.0.12 Snapshot Release · csowada/openhab-ebus-binding

[drc (Dan)]

Looks good now - thanks!

[csowada]

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

[Sascha_]

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

Best,
Sascha