eBUS Binding 3.x [3.4.0;3.9.9)

Silly me. I have to apoplogise :man_facepalming:
I switched about 2a ago from an USB eBus adapter to a GPIO version. Totally forgot about it. So all I had to do was to set the RasPi accordingly (some extra settings are needed in openhabian config etc.).
What still needs to be done after a reboot is to touch the .kar file to get it loaded.
Thanks for all your hints.

OK, that means we still have to issues, right?

  • touch of *.kar file is necessary
  • Settings icon does not appear in the binding config

At the moment I’ve no clue how to fix this issues. It has maybe something to do with the internal feature name. But there is no additional development information available.

Hi @LuiSauberhorn It is the wrong area in openHAB. Go to “Settings” → “Bindings” → “eBUS Binding”

There should be the Gear symbol.

Hi @witek_1308 ,

is it possible that you have installed the eBUS binding via market place and upgraded later to 4.x ? Can you check on the console what versions are installed? For me it sounds like a conflict with two versions.

feature:list | grep -i ebus
bundle:list | grep -i ebus

For all openHAB 4.x users, I’ve created a new Marketplace Entry just for openHab 4.x

So the market place should now also work with 4.x

3 Likes

Thanks for putting the binding in the Marketplace. Alas, it does not work. It shows as installed


but is not (grepped “us” to be sure that something is returned). And yes, I did a reboot :wink: :

openhab> bundle:list | grep us
246 │ Active │  80 │ 4.0.3                  │ openHAB Core :: Bundles :: Configuration USB-Serial Discovery for Linux using sysfs scanning
247 │ Active │  80 │ 4.0.3                  │ openHAB Core :: Bundles :: Configuration USB-Serial Discovery using ser2net mDNS scanning

So, something still is strange…

Use grap with -i to ignore case

You are right, however, I looked through the result of bundle:list “manually” line by line. No line found like the one below. In addition, after a reboot no data were fetched. Reinstalling and “touch”-ing the .kar file brought the bundle to life again:

325 │ Active │  80 │ 4.0.19.202309141819    │ openHAB Add-ons :: Bundles :: eBUS Binding

I use a fresh Windows installation to test my binding for versions I not use. I’m still on 3.x.

Can you check also the feature list when the binding ist not started? My guess is that is shows uninstalled.

@csowada my installation looks like that:

openhab> feature:list | grep -i ebus
openhab-binding-ebus                              │ 4.0.19.SNAPSHOT  │          │ Uninstalled │ org.openhab.binding.ebus-4.0.19-SNAPSHOT │ eBUS Binding
openhab-binding-onebusaway                        │ 4.0.3            │          │ Uninstalled │ openhab-addons-4.0.3                     │ OneBusAway Binding
x-openhab-binding-ebus                            │ 3.4.16           │          │ Uninstalled │ org.openhab.binding.ebus-3.4.16          │ eBUS Binding
org.openhab.binding.ebus                          │ 3.4.16           │          │ Uninstalled │ org.openhab.binding.ebus-3.4.16          │ openHAB Add-ons :: Bundles :: eBUS Binding
openhab> bundle:list | grep -i ebus
239 │ Active │  80 │ 1.1.8                  │ eBUS library configuration
240 │ Active │  80 │ 1.1.11                 │ eBUS core library
243 │ Active │  80 │ 3.4.16                 │ openHAB Add-ons :: Bundles :: eBUS Binding
312 │ Active │  80 │ 0                      │ wrap_file__var_lib_openhab_tmp_kar_org.openhab.binding.ebus-3.4.16_org_lastnpe_eea_eea-all_2.2.1_eea-all-2.2.1.jar

obviously uninstalled .19 SNAPHOST , as mentioned before, it was crashing my OH periodically. Not sure in which state I’m now…
Since yesterday I see 2 new bindings appeared in the marketplace - 4.0.19 snapshot + abovementioned binding 4.x.
What should be installed to make it working:

  • uninstall 3.x
  • install 4.x
  • what to do with 4.0.19 snapshot then? is it still needed on top of biding 4.x?

@csowada, thanks and works!! Somehow I was not aware that bindings are listed here, even if there are imported via files.

BTW, did you see my message from Aug 20th? There is a type in the Wolf400 config that blocks writing.

And a second note: With the market binding, I also have the problem that was seen with the .19 kar-file. The things that belong to the binding are not recognized after an openhab restart. While the touch worked with the *.kar-file, this is obviously not working with the file.

for me it works, thank you.

BTW, has anyone got the RecovAir via VR32 running and a working configuration? I’m trying for years to make something with it.

I did some searching in the source code. openHAB 4.x does some things differently here than openHAB 3.x.

Can you see if the following helps you?

Add ebus to the binding entry in conf/services/addon.cfg. Remove comment # if not already used.

# Access Remote Add-on Repository
# Defines whether the remote openHAB add-on repository should be used for browsing and installing add-ons. (default is true)
#
#remote = true

# Some add-on services may provide add-ons where compatibility with the currently running system is not expected.
# Enabling this option will include these entries in the list of available add-ons.
#
#includeIncompatible = false

# The add-on configuration in the lists below is applied EVERY TIME openHAB is started.
# Add-ons installed using the UI that do not occur in the lists will be uninstalled each startup.
# When lists are commented again any add-ons in the list remain installed and are not removed.
# So if you want to uninstall all add-ons part of a list, first remove all add-ons from it, restart
# openHAB and then comment the list.

# A comma-separated list of automation services to install (e.g. "automation = groovyscripting")
#automation = 

# A comma-separated list of bindings to install (e.g. "binding = knx,sonos,zwave")
binding = ebus

# A comma-separated list of miscellaneous services to install (e.g. "misc = openhabcloud")
#misc = 

# A comma-separated list of persistence services to install (e.g. "persistence = jpa,rrd4j")
#persistence = 

# A comma-separated list of transformation services to install (e.g. "transformation = jsonpath,map")
#transformation = 

# A comma-separated list of UIs to install (e.g. "ui = basic,habpanel")
#ui = 

# A comma-separated list of voice services to install (e.g. "voice = googletts,marytts")
#voice = 
 

Hi @csowada ,

does not work, I get the following error:

2023-10-09 10:32:07.475 [WARN ] [core.karaf.internal.FeatureInstaller] - The binding add-on 'ebus' does not exist - ignoring it.

Other bindings can be installed via the add-on.cfg normally.

Update: Could be a naming issue. When I install the 4.x binding manually, suddenly both are installed.

I have the same problem when installing via GUI - both are installed, and when installed they don’t allow sitemaps GUI to start (admin part is operational which allows for uninstalling it but other parts don’t start )

I’ve got a problem with the ebus binding and my Wolf CWL300. After Update to openhab V4.0.2 i did not getting values in my items. EBUSd works fine and i’m getting values in the log file of openab. but it seems that it did not assign it to the items or channels of the cwl thing. Does anybody know what is wrong?
The strange thing is, that there are 6 items which get values, but the other stays at NULL altought i’m getting value infos in the log…

Here you see the log file:

Does anybody has the same problem?

Hello,
i got a lot of

**Send queue is full! The eBUS service will reset the queue to ensure proper operation.**

messages.

What is the problem?
I am using OH 3.4.4.

Edit: after a while i also got this error messages:

17:41:38.787 [ERROR] [ing.ebus.internal.handler.EBusHandler] - **error!**

de.csdev.ebus.core.EBusControllerException: Controller not connected, unable to add telegrams to send queue!

at de.csdev.ebus.core.EBusControllerBase.addToSendQueue(EBusControllerBase.java:83) ~[bundleFile:?]

at de.csdev.ebus.client.EBusClient.addToSendQueue(EBusClient.java:131) ~[bundleFile:?]

at org.openhab.binding.ebus.internal.utils.EBusClientBridge.sendTelegram(EBusClientBridge.java:166) ~[bundleFile:?]

at org.openhab.binding.ebus.internal.handler.EBusHandler.handleCommand(EBusHandler.java:387) [bundleFile:?]

at jdk.internal.reflect.GeneratedMethodAccessor238.invoke(Unknown Source) ~[?:?]

at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]

at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]

at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]

at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]

at com.sun.proxy.$Proxy157248.handleCommand(Unknown Source) [?:?]

at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:85) [bundleFile:?]

at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]

at jdk.internal.reflect.GeneratedMethodAccessor237.invoke(Unknown Source) ~[?:?]

at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]

at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]

at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]

at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]

at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]

at java.lang.Thread.run(Thread.java:834) [?:?]

i also received a lot of values

21:50:04.698 [INFO ] [openhab.event.ItemCommandEvent ] - **Item 'VaillantVRT39239200Hc1ManualOPRoomTempDesiredHc1ManualOPRoomTempDesired' received command 20.375**

21:50:04.699 [INFO ] [openhab.event.ItemStatePredictedEvent] - **Item 'VaillantVRT39239200Hc1ManualOPRoomTempDesiredHc1ManualOPRoomTempDesired' predicted to become 20.375**

21:50:04.700 [INFO ] [openhab.event.ItemCommandEvent ] - **Item 'Vaillant_color_state' received command 1**

21:50:04.701 [INFO ] [openhab.event.ItemCommandEvent ] - **Item 'VaillantVRT39239200Hc1ManualOPRoomTempDesiredHc1ManualOPRoomTempDesired' received command 20.375**

21:50:04.703 [INFO ] [openhab.event.ItemStatePredictedEvent] - **Item 'VaillantVRT39239200Hc1ManualOPRoomTempDesiredHc1ManualOPRoomTempDesired' predicted to become 20.375**

21:50:04.705 [INFO ] [openhab.event.ItemCommandEvent ] - **Item 'Vaillant_color_state' received command 1**

21:50:04.706 [INFO ] [openhab.event.ItemCommandEvent ] - **Item 'VaillantVRT39239200Hc1ManualOPRoomTempDesiredHc1ManualOPRoomTempDesired' received command 20.375**

21:50:04.707 [INFO ] [openhab.event.ItemStatePredictedEvent] - **Item 'VaillantVRT39239200Hc1ManualOPRoomTempDesiredHc1ManualOPRoomTempDesired' predicted to become 20.375**

21:50:04.708 [INFO ] [openhab.event.ItemCommandEvent ] - **Item 'Vaillant_color_state' received command 1**

21:50:04.709 [INFO ] [openhab.event.ItemCommandEvent ] - **Item 'VaillantVRT39239200Hc1ManualOPRoomTempDesiredHc1ManualOPRoomTempDesired' received command 20.375**

21:50:04.710 [INFO ] [openhab.event.ItemStatePredictedEvent] - **Item 'VaillantVRT39239200Hc1ManualOPRoomTempDesiredHc1ManualOPRoomTempDesired' predicted to become 20.375**

I upgraded to 4.0.4 and reinstalled the binding via GUI. All works fine now :+1: