Select things → + → ebus Binding and the wheel at the very right for configuration.
1 Like
Have updated my system from OH 3.4 to 4.0 (raspberry 4). In general it is working. All values are taken, where the telegrams are transfered between the components on the ebus.
But polling is not working. Even if I set a slight other second value.
Did somewhere else done the update, do it work there? Or a idea what I could do?
Additional… Found out when I start the eBUS Bridge thise Warning comes up. Think there is a relation to the missing polling feature:
2023-08-02 10:46:58.072 [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) ~[?:?]
I have the same problem. The binding also does not work any more after the OH upgrade to 4.0. I have the same exception in the logs that you have, it looks like the binding code is not yet fully compatible with OH4.
Same here - since upgrade to 3.4.2 polling seems to be broken.
i use the a local installed ebusd - which works fine.
2023-07-28 21:16:58.052 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 1 ...
2023-07-28 21:17:00.346 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 2 ...
2023-07-28 21:17:07.404 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 3 ...
2023-07-28 21:18:46.248 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 4 ...
2023-07-28 21:18:58.057 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 5 ...
2023-07-28 21:19:00.353 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 6 ...
2023-07-28 21:19:07.409 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 7 ...
2023-07-28 21:20:58.061 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 8 ...
2023-07-28 21:21:00.357 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 9 ...
2023-07-28 21:21:07.413 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 10 ...
2023-07-28 21:22:56.143 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 11 ...
2023-07-28 21:22:58.064 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 12 ...
2023-07-28 21:22:58.168 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 13 ...
2023-07-28 21:23:00.361 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 14 ...
2023-07-28 21:23:07.417 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 15 ...
2023-07-28 21:23:10.157 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 16 ...
2023-07-28 21:24:58.067 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 17 ...
2023-07-28 21:25:00.365 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 18 ...
2023-07-28 21:25:07.421 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 19 ...
2023-07-28 21:26:58.071 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 20 ...
2023-07-28 21:27:00.369 [ERROR] [de.csdev.ebus.core.EBusQueue ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2023-07-28 21:27:00.525 [ERROR] [.csdev.ebus.core.EBusEbusdController] - error!
de.csdev.ebus.core.EBusDataException: Unable to send telegram 00 15 B5 24 06 02 00 01 00 08 00 4C after 2 attempts ... [ERROR: TOO_MANY_ATTEMPS, DATA: 00 15 B5 24 06 02 00 01 00 08 00 4C]
at de.csdev.ebus.core.EBusQueue.checkSendStatus(EBusQueue.java:117) ~[bundleFile:?]
at de.csdev.ebus.core.EBusEbusdController$EBusSenderThread.run(EBusEbusdController.java:112) [bundleFile:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
2023-07-28 21:27:07.425 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 1 ...
currently i reduced the polling to an absolute minimum, but i still got problems.
2023-08-02 11:04:03.182 [INFO ] [ng.ebus.internal.handler.EBusHandler] - (Re)Initialize all eBUS pollings for ebus:vrc700_hc1:5c3e6143b9:15 ...
2023-08-02 11:04:03.355 [INFO ] [ng.ebus.internal.handler.EBusHandler] - (Re)Initialize all eBUS pollings for ebus:vrc700_hwc:5c3e6143b9:15 ...
2023-08-02 11:04:03.359 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "hwc.flow_temp" every 120 sec. (initial delay 6 sec.)
2023-08-02 11:04:03.381 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "hwc.setpoint" every 1800 sec. (initial delay 2 sec.)
2023-08-02 11:04:03.404 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "hwc.sf_mode" every 1800 sec. (initial delay 16 sec.)
2023-08-02 11:04:03.411 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "hwc.storage_temp" every 120 sec. (initial delay 13 sec.)
2023-08-02 11:04:03.416 [INFO ] [ng.ebus.internal.handler.EBusHandler] - Register polling for "hwc.op_mode" every 1800 sec. (initial delay 4 sec.)
2023-08-02 11:04:03.457 [INFO ] [ng.ebus.internal.handler.EBusHandler] - (Re)Initialize all eBUS pollings for ebus:std:5c3e6143b9:08 ...
2023-08-02 11:04:03.549 [INFO ] [ng.ebus.internal.handler.EBusHandler] - (Re)Initialize all eBUS pollings for ebus:std:5c3e6143b9:04 ...
Mh, looks like a simple bug. Should be easy to fix. But I’m on holiday, so not fix before next week.
1 Like
I can not confirm a polling issue running 3.4.0 to actually 3.4.4. Here everything looks good.
Dear forum,
I need help with getting my WOLF heater to openhab please!
I bought a Esera ebus coupler with ethernet, But i can’t get it to work with the binding:
i also have a WOLF CGB2 and i read the ebus adress from the display it say it’s 1 so under slave adress i enetered 01
i also turned the potentiomenter on the esera device until the data led started blinking howeve in openhab i don’t get any updated values
Does anyone know what i am doing wrong?
What do you see under metrics data of the bridge thing (see channels).
Did you change the „data packing condition“ within the coupler config tool from 0 to 2 ms?
1 Like
Csowada, hope you had a good holiday…
Maybe you can have a look on an other point. With OH3.4 the parameters of the ebus-binding could be changed via the way settings->things->(+). There the binding was listed, and parameter could be changed.
Now with OH4.0 the ebus-binding is not listed there. Only other bindings (as least here in my environment).
Hi,
Thanks for getting back at me. We might be on to something here. i think maybe the other fields in the packaging condition would need some value as well other that 0. Any idea what that needs to be ?
I only set the timer value. 2ms reduced the roundtrip time from vallues of approx. 40000 to now approx. 5000.
But you still have no received telegrams. Here the number should upcount quickly if its operational. I remember that the threshold potentiometer adjustment has been quite delicate.
What does the Karaf console show if you type: ebus devices ? You should see something like this:
@Roland62 and @vbier
Same for me after updating from OH 3.4.4 to 4.0.1: WrappedScheduledExecutorService error when the binding starts.
The openhab log shows that the polling is working:
2023-08-06 12:19:40.665 [DEBUG] [s.internal.handler.EBusBridgeHandler] - Received telegram from address FF to 15 with command vrt392.room.temperature
2023-08-06 12:19:40.667 [TRACE] [ng.ebus.internal.handler.EBusHandler] - eBUS handler cfg EBusHandlerConfiguration [slaveAddress=15, masterAddress=null, filterAcceptMaster=false, filterAcceptSlave=true, filterAcceptBroadcasts=true, polling=61.0]
2023-08-06 12:19:40.668 [DEBUG] [ng.ebus.internal.handler.EBusHandler] - Handle received command by thing ebus Vaillant 39200 (15) thermostaat with id ebus:392:b6146b839f:6cbbae15a3 ...
2023-08-06 12:19:40.669 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key temp_living with value 22.3125
But the events log shows no changes of the item values. The binding seems to discard the received values.
@Roland62 I also noticed that there is no possibility anymore to add a ConfigurationUrl to the binding: when selecting Things → + → ebus Binding, there is no more cogwheel visible.
So, I’ve now updated the binding for openHAB 4.0 only. This snapshot should fix both issues.
I’ve changed the feature name, so the update need some clean cache and/or multiple restart of the server.
But I’m still not on openHAB 4.0, so I can’t really check the functions. So this is the reason why it is just a snapshot release.
1 Like
I just double checked the settings under “packing condition”: the lowest field should be 0A and not 00. But don’t know which impact this has.
I currently have installed the ebus community binding (release 3.4.16) on my fresh OH4. I would like to test 4.0.17-SNAPSHOT with my Vaillant VCR470.
Can someone tell me what to do to replace my current version?
Uninstall the release 3.4.16. Restart openhab. Put the snapshot file into the “addons” folder. Restart openhab.
Edit: If the running release 3.4.16 is also in the “addons” folder, delete it first in order to uninstall it.
Thank you, that snapshop fixed my problems with OH4 
Have installed today. The most important thing is working - the polling. Ebus do still not appear (Settings → Things → [+]).
In the first step I had used the harder method - after uninstalling the old ebus also cleaned the cache via ‘sudo openhab-cli clean-cache’ but than lots of errors are coming up.Even with a view restarts.
Re-Installing the old version and than the steps like described by dk8pn works. Think with one additional restart at the end.
Yes, with the snapshot ebus is missing in things-+, was still there with the last Version.