I use a Rasperry Zero WH together with the FHEM Ebus adapter 2.1. I have compiled ttyEbus and EbusD myself.
Note that this only happens from time to time. It seems to have been coincidence that it happened after start two times in a row. When I obtained the log last time, it did start and took a while before I got the exception.
Nevertheless you should probably make your code a little bit more robust and catch the exceptions like I already mentioned.
A have a new heating pump with VRC 700. Using an Esera USB Koppler I was able to integrate all ebus-devices without any problem. After creating the ebus-bridge, all devices showed up automatically as things in the inbox and I was able to link the things to items. Reading the status of the items is working. However, I do not understand how I can write to the ebus. Simply sending commands to an item (string or number) is not working.
Adding a throwable handler to the sender thread revealed another exception:
java.lang.NullPointerException: null
at de.csdev.ebus.core.EBusQueue.checkSendStatus(EBusQueue.java:106) ~[bundleFile:?]
at de.csdev.ebus.core.EBusEbusdController$EBusSenderThread.run(EBusEbusdController.java:112) [bundleFile:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_152]
Looks like the access to the queue should be synchronized.
Edit: Do you want me to create a pull request with my fixes?
Have anyone succesfully updated time or date in VRC700? I have items like VaillantVRC700General_Vrc700_general_gen_time_ActualTime in paper ui and I’m not able to change time. I can change it using ebus-ctl
Hello Everyone.
For the last few days I have been trying to set up Openhab ebus binding.
My heating system consists of: Vaillant ecoTEC VC 246/3-5, calorMATIC 430f, VR60.
I am running Openhab2 (version 2.5.4) on Raspberry Pi.
As ebus converter I am using ESERA eBus coupler USB.
I have compiled and installed latest ebusd from github.
Everything seems to run OK, but according to ebus bridge, 80% of telegrams are unresolved. Only a few values in “items” are correct.
I have tried already different bindings versions (1.14, 2.5.1-6, 2.5.1-7 (currently using 2.5.1-7)). Tried both ebusd and use of serial link in ebus bridge configuration - same result.
Please find below link to screenshots and logs:
https://drive.google.com/open?id=1LnFNBC04oLD1GghVd9F8zlIL77Z7Yn1Y
Could you please advise what could be the problem?
Thank you in advance.
Best regards,
Maciej.
Hello All,
I’m currently busy with other topics. But I’ll submit my local changes to github. It contains thwo fixes to the ebusd controller. But for the moment I’n not sure how to fix the blocked threads issue. Maybe it is part of the openhab core.
I’m experiencing problems after update to 2.5.1-7 - openend a seperate thread for better readability!
[eBUS 2.0] much more problems/errors since update to 2.5.1-7
At the moment the version 2.5.1-7 is not working well with ebusd, please use the previous version.
The blocked threads issue are still happen on my system, but always if I have no time to analyse a thread dump.
Thanks for the info. Maybe this is useful information for others too…
Do you suggest using the binding directly with the ttyUSB device instead of having ebusd in between?
Hello
Seems I have been impacted by the" ebus queue issue" as well:-(
The problem starts over 2 weeks ago (this might be after last updates of my RPI3 to openhab 2.5.5-1 but not sure)
Now I have the following error message
2020-06-21 17:33:53.843 [WARN ] [rm.AbstractFileTransformationService] - Could not transform '-' with the file 'en.map' : Target value not found in map for '-'
2020-06-21 17:34:26.396 [ERROR] [de.csdev.ebus.core.EBusQueue ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2020-06-21 17:36:12.448 [WARN ] [rm.AbstractFileTransformationService] - Could not transform '-' with the file 'en.map' : Target value not found in map for '-'
2020-06-21 17:37:10.288 [WARN ] [dev.ebus.core.EBusLowLevelController] - eBUS Watchdog Timer!
2020-06-21 17:37:12.429 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Poll command "ebus:V6100:58c13b58:50:V6100_Flow1Sensor#temp" with "FF 50 B5 09 03 0D 00 00 4E" ...
2020-06-21 17:37:12.437 [ERROR] [de.csdev.ebus.core.EBusQueue ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2020-06-21 17:37:16.326 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Poll command "ebus:bai:58c13b58:08:bai_boiler_state-diverter-valve#state-diverter-valve" with "FF 08 B5 09 03 0D 54 00 AC" ...
2020-06-21 17:37:16.393 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Poll command "ebus:V6100:58c13b58:50:V6100_IsInHoliday#IsInHoliday" with "FF 50 B5 09 03 0D 08 00 57" ...
2020-06-21 17:37:20.366 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Poll command "ebus:vrc430:58c13b58:15:vrc430_heating_program-heating-circuit#program" with "FF 15 B5 09 03 0D 2F 00 03" ...
2020-06-21 17:37:23.398 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Poll command "ebus:V6100:58c13b58:50:V6100_Mixer1State#Mixer1State" with "FF 50 B5 09 03 0D 03 00 78" ...
.....
eBUS related things are on line and seems pooling works but NO values displays in the sitemap!
I am using standard binding with ttyUSB0 (and Esera couppler), network driver: Raw, Serial port Driver: RXTX, ebus binding 2.5.1-6
Additional log on queue - after each 20 the queue is full:
2020-06-21 18:23:23.396 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 16 ...
2020-06-21 18:23:26.325 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 17 ...
2020-06-21 18:23:26.394 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 18 ...
2020-06-21 18:24:11.325 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 19 ...
2020-06-21 18:24:12.319 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 20 ...
2020-06-21 18:24:12.392 [ERROR] [de.csdev.ebus.core.EBusQueue ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2020-06-21 18:24:12.428 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 2 ...
2020-06-21 18:24:14.320 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 3 ...
2020-06-21 18:24:16.324 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 4 ...
2020-06-21 18:24:16.391 [DEBUG] [de.csdev.ebus.core.EBusQueue ] - Size of send queue is 5 ...
I performed several restarts of openhab but did not helped.
Any hint how to investigate further?
Hello All,
I’ve released a small update. It runs here since several days without any issue (serial rxtx). But I also disabled amazon echo binding.
The release also contains fixes for ebusd regarding the thread stop issue. Another issue was the ebus connection status update,it was called every thread run also if the the status was unchanged.
I have loaded new kar version 2.5.1-8 (before I had 2.5.1-8)
openhab> feature:list|grep -i ebus
ebus-binding x 2.5.1.8 x x x Started x ebus-distro-2.5.1-8 x eBUS 2.0 binding incl. eBUS core libs
openhab-binding-onebusaway x 2.5.5 x x Uninstalled x openhab-addons-2.5.5 x OneBusAway Binding
openhab-binding-ebus1 x 1.14.0 x x Uninstalled x openhab-addons-2.5.5 x eBUS Binding
But after first openhab restart I can see still the same error as follows:
2020-06-21 23:16:23.807 [ERROR] [de.csdev.ebus.core.EBusQueue ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2020-06-21 23:18:23.807 [ERROR] [de.csdev.ebus.core.EBusQueue ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2020-06-21 23:19:07.238 [WARN ] [dev.ebus.core.EBusLowLevelController] - eBUS Watchdog Timer!
2020-06-21 23:20:23.806 [ERROR] [de.csdev.ebus.core.EBusQueue ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
After clear cache and restart openhab I can not initialize the eBus bridge now (the status INITIALIZING) and the following warnig appeared:
2020-06-21 23:58:23.364 [WARN ] [dev.ebus.core.EBusLowLevelController] - eBUS Watchdog Timer!
I will test again tomorrow.
But your list also shows the v1 ebus binding installed. You should uninstall it first. It maybe blocks the adapter.
I have loaded again last kar file but also upgraded to Openhab 2.5.6-2 last release and I have created symlink for ttyUSB0 (well maybe too many changes at the same time:(
After loading kar file seems I have ebus-binding started and openhab-binding-ebus1 uninstalled:
openhab> feature:list|grep .*ebus.*
ebus-binding x 2.5.1.8 x x x Started x ebus-distro-2.5.1-8 x eBUS 2.0 binding incl. eBUS core libs
openhab-binding-onebusaway x 2.5.6 x x Uninstalled x openhab-addons-2.5.6 x OneBusAway Binding
openhab-binding-ebus1 x 1.14.0 x x Uninstalled x openhab-addons-2.5.6 x eBUS Binding
But the eBUS bridge status is INITIALIZING and no values nor error in logs:
020-06-22 21:07:00.885 [TRACE] [internal.things.EBusTypeProviderImpl] - Add channel ebus:vrc700_hc1_hc1_curve-adapt_value for method GET
2020-06-22 21:07:00.888 [TRACE] [internal.things.EBusTypeProviderImpl] - Add channel definition value
2020-06-22 21:07:00.890 [DEBUG] [internal.things.EBusTypeProviderImpl] - Generated all eBUS command collections ...
2020-06-22 21:07:00.906 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - Use eBUS binding 2.5.1.202006152014 [eBUS core: 1.0.8.202006152013, eBUS configuration: 1.0.7.202005171351]
2020-06-22 21:07:00.919 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - eBUS core -> timestamp 202006152013, commit: #d3e0f59, build-no: #null
2020-06-22 21:07:00.926 [INFO ] [ing.ebus.internal.EBusHandlerFactory] - eBUS configuration -> timestamp 202005171351, commit: #35cd31b, build-no: #null
==> /var/log/openhab2/events.log <==
2020-06-22 21:07:01.022 [hingStatusInfoChangedEvent] - 'ebus:bridge:58c13b58' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
==> /var/log/openhab2/openhab.log <==
2020-06-22 21:07:01.042 [TRACE] [s.internal.handler.EBusBridgeHandler] - EBusBridgeHandler.initialize()
2020-06-22 21:07:01.050 [DEBUG] [ternal.services.EBusDiscoveryService] - Start eBUS discovery service ...
2020-06-22 21:07:01.051 [WARN ] [s.internal.handler.EBusBridgeHandler] - Enable advanced logging for eBUS commands!
At the moment I have permanent INITIALIZING status of eBus (with the message in logs: eBus Watchdog Timer!)and I have no idea what to investigate further?
Can you use the version 2.5.1-6 to check if it is release dependent? Is the port in use? ebusd Daemon? Can you access the port with minicom etc? Is the ebus v1 binding still in the add-ons.cfg file. Is there an ebus.cfg file? It is not needed with V2.
2.5.1-8 is suggested for testing with ebusd? or is better to keep using 2.5.1-6?
It should fix the ebusd thread issue, but untested from my side. Switching the version is normally easy. So give it a try.
Download is confusing: Please correct the typo in Version 2.5.1-7 from 21.06.2020 to Version 2.5.1-8 from 21.06.2020. The download link is correct!
Done! 