Hey @Tallman, tried it, may be I am too stupid but I don’t get it. I follow your path but don’t have any gear here…
Also when clocking on the binding, there is no gear… Sorry!
Hey @Tallman, tried it, may be I am too stupid but I don’t get it. I follow your path but don’t have any gear here…
Also when clocking on the binding, there is no gear… Sorry!
Don’t know why but still can’t make it working with either .18 or .19 SNAPSHOT on 4.0.3 (sometimes it does starts and loads values but then keeps them without update). The only working thing is time from VRC from some reason
I don’t see it either and have couple of files to be added too. Maybe this is my problem why I can’t make it working with 4.0.3…
Did you try to clean cache of OH and restart OH again after it once finished full startup? This sometimes worked for me.
Also folder and file owner and permission of ebus.kar are accessible to OH? Sometimes I forget about that
I clean cache every time I do something, privilidges are fine too. It was all good in 4.0.2 but don’t want to rollback, must be something with 4.0.3 environmental. I’ve given up for the moment, will wait for 4.0.4 or whatever next to see if it helps
Same phenomenon here. Bundle gets recognized only after the touch command.
(added:) THE FOLLOWING HAS BEEN SOLVED. It was a silly mistake from my side, see below.
In addition, when I then try to create a bridge with the same settings as in OH3.4.4 (Serial Port: /dev/ttyUSB0 and Serial Port Driver: nrjavaserial (RXTX) then I get the following message in Log Viewer:
2023-10-07 16:58:37.173 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'ebus:bridge:ad6dbc72b4' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_CONFIGURATION_PENDING): {serialPort=Der Wert /dev/ttyUSB0 ist nicht in den erlaubten Optionen enthalten. Erlaubte Optionen sind: [ParameterOption [value="/dev/ttyAMA0", label="/dev/ttyAMA0"]]}
When using /dev/ttyAMA0 and Serial Port Driver nrjavaserial (RXTX) the bridge goes online but nothing is received. With the buildin driver if fails to connect:
023-10-07 17:15:21.779 [ERROR] [dev.ebus.core.EBusLowLevelController] - An IO exception has occured! Try to reconnect eBUS connector ...
java.io.IOException: End of eBUS stream reached!
at de.csdev.ebus.core.EBusLowLevelController.run(EBusLowLevelController.java:205) ~[?:?]
2023-10-07 17:15:21.783 [WARN ] [dev.ebus.core.EBusLowLevelController] - Retry to connect to eBUS adapter in 40 seconds ...
I do have an FHEM eBus interface with USB.
I probably will downgrade the OH version as this eBus binding together with the KNW binding has become an integral part of our home automation (e.g., showing the water temp in the bathroom on a MDT KNX device).
Hmm, I am on buildin driver since the recent upgrade. Maybe need to try the java one
Built in works for me…
it drives me crazy. If I re-enable .19 snapshot I’m getting periodic crash with this error:
2023-10-07 20:35:09.878 [INFO ] [internal.things.EBusTypeProviderImpl] - Load custom 'url' configuration file 'file:///home/pi/ebus-vaillant_vc206.json' ...
2023-10-07 20:35:09.897 [INFO ] [internal.things.EBusTypeProviderImpl] - Load custom 'url1' configuration file 'file:///home/pi/ebus-vaillant_vr61.json' ...
2023-10-07 20:35:09.980 [WARN ] [internal.things.EBusTypeProviderImpl] - eBUS command boiler.control.setopdata only contains a setter channel!
2023-10-07 20:35:10.144 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - Use eBUS binding 3.4.16 [eBUS core: 1.1.11, eBUS configuration: 1.1.8]
2023-10-07 20:35:10.147 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - eBUS core -> timestamp 202303261721, commit: #e9dd4fd, build-no: #null
2023-10-07 20:35:10.150 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - eBUS configuration -> timestamp 202303251717, commit: #af71b29, build-no: #null
2023-10-07 20:35:10.780 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NoSuchMethodError: 'void org.openhab.core.library.types.DecimalType.<init>(java.math.BigDecimal)'
at org.openhab.binding.ebus.internal.services.EBusMetricsService.lambda$0(EBusMetricsService.java:83) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
at java.lang.Thread.run(Thread.java:833) ~[?:?]
2023-10-07 20:35:10.827 [INFO ] [al.EBusSerialBuildInSerialConnection] - Use openhab build-in serial driver .................................................................
2023-10-07 20:35:10.921 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Bridge is not online yet ...
2023-10-07 20:35:10.932 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Bridge is not online yet ...
2023-10-07 20:35:10.947 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Bridge is not online yet ...
2023-10-07 20:35:10.981 [INFO ] [ng.ebus.internal.handler.EBusHandler] - (Re)Initialize all eBUS pollings for ebus:std:4e71d8b411:75 ...
2023-10-07 20:35:11.044 [INFO ] [ng.ebus.internal.handler.EBusHandler] - (Re)Initialize all eBUS pollings for ebus:bai:4e71d8b411:08 ...
it crashes around every 2 mins. Any hints?
Your log shows that oh tries to load 3.4.16 version of the binding. Also the Not found Exception was already fixed for 4.x.
Silly me. I have to apoplogise
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?
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
Thanks for putting the binding in the Marketplace. Alas, it does not work. It shows as installed
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.