No one any idea what’s wrong?
Please advise!
Thanks,
doktorpi
Hi,
i have troubles to remove my test entries “Configuration URL1” und “Configuration URL2” in the binding via the UI (/settings/addons/ebus/config)
Any Ideas or maybe a workaround to find that in the config files to do it manualy?
Thank you
Andi
Hi Andi,
you will find the configuration file settings here: C:\openHAB\userdata\config\binding\ebus.config
Please regard that i am a Windows10 user.
Regards,
Willi
1 Like
The ebusd configuration is not necessarily the same as the configuration contained within the openhab binding. I guess that you will need a custom config file for the “brennerstarts”. But you can retrieve the ebus telegram code using ebusd in order to setup this file.
Yes! That helped a lot.
I’m using a Debian Linux / Raspberry, the location for the config file is /var/lib/openhab/config/binding.
Hey guys, sorry for interrupting your discussion but I have problems to setup the binding with the eBUS adapter 5.
I am not sure if anyone tried this before because the version is new but there should be no huge difference to the adapter 3.
I have desribed my setup in this topic:
Configurations for the eBUS-binding [3.4.0, 4.0.0]
Now I get a lot of telegram errors but no received or failed telegram in the binding channels:
Following versions of eBUS are installed:
Small question. How do you add a ConfigurationUrl to the binding?
In the Openhab 3.4.4 UI, when I click on Settings, then Bindings, then Ebus, there is no configuration option visible.
Apparently it should be possible to add a file /var/lib/openhab/config/binding/ebus.config (on a Raspberry pi), but what is the syntax?
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