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 
@witek_1308, is it still running well? And did you or anybody else manage to get it to work with 4.1(.1)?
I am still on 3.4.4 and did a test install of binding 4.0.19 on OH4.1.1 on a non-productive system, without success 
Will try again on 4.0.4 
Thanks, Veit
Yes, rock solid, stable since my post without a restart
Hi,
anybody here with a successful upgrade to OH 4.1.1
it seems that 4.0.4 is the last working OH version?
Thanks
Andi
I upgraded from 3.4.5 to 4.1.1. Had to (of course) remove the kar file from the addon directory. This still gave several errors in the log that the 3.0.16 version of the binding was still installed. So time to clear the cache and punt the 4.0.19 version in the addons directory. No more errors in the log and working flawlessly.
So when upgrading the binding, clear the openhab cache.
One minor thing, which is also already mentioned in the 4.0.0 topic of the ebus binding: it seems that the config/setup option (to point to personal ebus config jsons) is missing for some unknown reason. However, in my experience I couldn’t update that list anyway (changes were not saved), so I had to manually edit the openhab ebus config file (is located somewhere in an openhab directory).
thank you for your fast reply. good to know, i currently have no personal config files.
but if someone needs that, i should be possible to do this with a local edbusd and you can transfer the values via OH rest api.
I’m on 4.1.0 for some time now and all works fine
Sorry I’m busy with other topics. But the missing UI configuration is a change in openHab 4.x , the gear icon is only visible if the binding uses the openhab namespace internal. With the openhab namespace it will mix the content with the old ebus 1.x binding in the marketplace. I should raise an issue in the core repo.
Hi,
first of all thanks for this nice binding.
I’m trying to read (poll e.g. every 60s) and manipulate the desired temperature for the hot water circuit. Therefore I already installed ebusd in a docker container and the ebus 5 adapter from john30. The connection seems to work fine since I’m getting some values via mqtt already and also manipulating the value HwcTempDesired using the ebusctl command works as expected.
So I thought it would be nice to use the Openhab binding. Therefore I added the ebusd docker as the bridge and it connects fine. Then I added a VRC700 general and connected an item to the outside temperature channel which works fine. However when adding the [
VRC 700 hot water circuit and connected the desired temperature channel I don’t get anything nor am I able to set the value. Note that I’m using the VRC720 but my understanding from ebusd config is that this should not matter since the VRC720 is linked to the VRC700 config. Does anybody has an idea what I’m doing wrong here and point me into the right direction.
I’m using:
Openhab 4.0.2
Installed the eBusd binding from official Bindings section and not from the marketplace
latest ebusd Docker
Thank you all in advance.
Does your problem still exist? If yes:
- define item als ‘number’
- set semantic class as ‘setpoint’ and semantic property as ‘temperature’
- set state description; pattern to %.1f °C; min to e.g. 45; max to e.g. 53; step to 1
- set ‘default list item widget’
Then something should work. I still run openHAB 3.4.5.