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.
I think this is rarly the same as my issue already created
[EBUS2] Send queue is full
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! 
I have to admit that the reason for not working ebus binding turned out to be the disconnected cable to ebus essera coupler 
Conclusion: if a thing has a pemanent INITIALIZING status, check if there is a physical connection! After conecting I can see values of eBUS in Basic UI!
(running 2.5.1-8 and environement as described in my previous posts).
Hello All.
I am still struggling with unresolved telegrams.
I thought that upgrading to the latest version (2-5.1-8) would solve the problem, but still 80% of telegrams received are unresolved.
Blockquote
2020-06-28 14:40:04.147 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 04 01 18 E7 00 06 00 00 00 45 01 05 A9 00
2020-06-28 14:40:06.174 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 03 02 00 03 43 00 0A FF FF FF FF FF FF FF FF FF FF 0F 00
2020-06-28 14:40:06.422 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 09 04 0E 01 00 00 54 00 00 00
2020-06-28 14:40:06.669 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 09 04 0E 20 00 00 2F 00 00 00
2020-06-28 14:40:06.966 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 08 B5 10 09 00 00 00 5E FF FF 01 FF 00 41 00 01 01 9A 00
2020-06-28 14:40:07.201 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 05 02 18 00 34 00 00 00
2020-06-28 14:40:08.129 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 05 02 30 01 48 00 01 01 9A 00
2020-06-28 14:40:10.185 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 03 02 00 01 41 00 0A FF FF FF FF FF FF FF FF FF FF 0F 00
2020-06-28 14:40:10.456 [DEBUG] [s.internal.handler.EBusBridgeHandler] - Received telegram from address 10 to 08 with command boiler.control.getopdata
2020-06-28 14:40:10.457 [TRACE] [ng.ebus.internal.handler.EBusHandler] - eBUS handler cfg EBusHandlerConfiguration [slaveAddress=08, masterAddress=03, filterAcceptMaster=false, filterAcceptSlave=true, filterAcceptBroadcasts=true, polling=null]
2020-06-28 14:40:10.458 [DEBUG] [ng.ebus.internal.handler.EBusHandler] - Handle received command by thing Vaillant BAI00 (08) with id ebus:bai:996338f5:08 …
2020-06-28 14:40:10.460 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key status_lead_heating with value false
2020-06-28 14:40:10.462 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key temp_outside with value null
2020-06-28 14:40:10.466 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key temp_return_srv_water with value 47
2020-06-28 14:40:10.472 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key temp_srv_water with value null
2020-06-28 14:40:10.475 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key temp_return_lead_water with value 40
2020-06-28 14:40:10.479 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key status_servicewater_heating with value false
2020-06-28 14:40:10.483 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key temp_lead_water with value 38
2020-06-28 14:40:12.173 [DEBUG] [s.internal.handler.EBusBridgeHandler] - Received telegram from address 10 to 08 with command boiler.control.getopdata.02b
2020-06-28 14:40:12.176 [TRACE] [ng.ebus.internal.handler.EBusHandler] - eBUS handler cfg EBusHandlerConfiguration [slaveAddress=08, masterAddress=03, filterAcceptMaster=false, filterAcceptSlave=true, filterAcceptBroadcasts=true, polling=null]
2020-06-28 14:40:12.180 [DEBUG] [ng.ebus.internal.handler.EBusHandler] - Handle received command by thing Vaillant BAI00 (08) with id ebus:bai:996338f5:08 …
2020-06-28 14:40:12.183 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key temp0_max with value 60
2020-06-28 14:40:12.188 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key temp0_target with value 65
2020-06-28 14:40:12.197 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key hwcmode with value 3
2020-06-28 14:40:12.203 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key srv_water_target_max with value 80
2020-06-28 14:40:12.211 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key srv_water_target with value 48
2020-06-28 14:40:14.207 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 04 01 18 E7 00 06 00 00 00 45 01 05 A9 00
2020-06-28 14:40:16.202 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 03 02 00 03 43 00 0A FF FF FF FF FF FF FF FF FF FF 0F 00
2020-06-28 14:40:16.443 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 09 04 0E 01 00 00 54 00 00 00
2020-06-28 14:40:16.698 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 09 04 0E 20 00 00 2F 00 00 00
2020-06-28 14:40:16.979 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 08 B5 10 09 00 00 00 5E FF FF 01 FF 00 41 00 01 01 9A 00
2020-06-28 14:40:17.215 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 05 02 18 00 34 00 00 00
2020-06-28 14:40:18.187 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 05 02 30 01 48 00 01 01 9A 00
2020-06-28 14:40:20.229 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 03 02 00 01 41 00 0A FF FF FF FF FF FF FF FF FF FF 0F 00
2020-06-28 14:40:20.513 [DEBUG] [s.internal.handler.EBusBridgeHandler] - Received telegram from address 10 to 08 with command boiler.control.getopdata
2020-06-28 14:40:20.514 [TRACE] [ng.ebus.internal.handler.EBusHandler] - eBUS handler cfg EBusHandlerConfiguration [slaveAddress=08, masterAddress=03, filterAcceptMaster=false, filterAcceptSlave=true, filterAcceptBroadcasts=true, polling=null]
2020-06-28 14:40:20.516 [DEBUG] [ng.ebus.internal.handler.EBusHandler] - Handle received command by thing Vaillant BAI00 (08) with id ebus:bai:996338f5:08 …
2020-06-28 14:40:20.517 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key status_lead_heating with value false
2020-06-28 14:40:20.520 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key temp_outside with value null
2020-06-28 14:40:20.523 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key temp_return_srv_water with value 47
2020-06-28 14:40:20.526 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key temp_srv_water with value null
2020-06-28 14:40:20.529 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key temp_return_lead_water with value 40
2020-06-28 14:40:20.531 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key status_servicewater_heating with value false
2020-06-28 14:40:20.536 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Key temp_lead_water with value 38
2020-06-28 14:40:22.181 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 FE B5 05 02 04 00 0B AA
2020-06-28 14:40:24.215 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 09 04 0E 01 00 00 54 00 00 00
2020-06-28 14:40:24.462 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 09 04 0E 20 00 00 2F 00 00 00
2020-06-28 14:40:24.719 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 04 01 18 E7 00 06 00 00 00 45 01 05 A9 00
2020-06-28 14:40:25.009 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 08 B5 10 09 00 00 00 5E FF FF 01 FF 00 41 00 01 01 9A 00
2020-06-28 14:40:26.243 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 03 02 00 03 43 00 0A FF FF FF FF FF FF FF FF FF FF 0F 00
2020-06-28 14:40:26.469 [TRACE] [s.internal.handler.EBusBridgeHandler] - Unknown telegram 10 50 B5 05 02 18 00 34 00 00 00
Any ideas?
Thanks in advance.
