Hello @witek_1308,
In your log also other threads blocked on the same lock. I think the discovery service is the main reason for the block. The eBUS binding is not very elegant with discovering new things, it discovers and updates more than maybe required. But usually it works.
Could you create a stack trace of one blocked thread? I have an idea about the position, but I’m not sure. I would expect this line as blocker.
@csowada, please excuse my ignorance but how can I collect it? I tried jstack and jcmd but getting error (Unable to open socket file: target process not responding or HotSpot VM not loaded), I guess it’s because I’m doing it wrongly
Edit: I think I managed with -F option, not sure whether this is what you needed or maybe something more detailed:
Thread 3431: (state = BLOCKED)
- org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.thingDiscovered(org.eclipse.smarthome.config.discovery.DiscoveryService, org.eclipse.smarthome.config.discovery.DiscoveryResult) @bci=0, line=257 (Interpreted frame)
- org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.thingDiscovered(org.eclipse.smarthome.config.discovery.DiscoveryResult) @bci=148, line=279 (Interpreted frame)
- org.openhab.binding.ebus.internal.services.EBusDiscoveryService.updateDiscoveredThing(de.csdev.ebus.service.device.IEBusDevice, de.csdev.ebus.command.IEBusCommandCollection) @bci=242, line=139 (Interpreted frame)
- org.openhab.binding.ebus.internal.services.EBusDiscoveryService.onEBusDeviceUpdate(de.csdev.ebus.service.device.IEBusDeviceTableListener$TYPE, de.csdev.ebus.service.device.IEBusDevice) @bci=42, line=153 (Compiled frame)
- de.csdev.ebus.service.device.EBusDeviceTable.fireOnDeviceUpdate(de.csdev.ebus.service.device.IEBusDeviceTableListener$TYPE, de.csdev.ebus.service.device.EBusDevice) @bci=34, line=168 (Compiled frame)
- de.csdev.ebus.service.device.EBusDeviceTable.updateDevice(byte, java.util.Map) @bci=331, line=155 (Interpreted frame)
- de.csdev.ebus.service.device.EBusDeviceTableService.onTelegramResolved(de.csdev.ebus.command.IEBusCommandMethod, java.util.Map, byte[], java.lang.Integer) @bci=84, line=315 (Interpreted frame)
- de.csdev.ebus.service.parser.EBusParserService.fireOnTelegramResolved(de.csdev.ebus.command.IEBusCommandMethod, java.util.Map, byte[], java.lang.Integer) @bci=40, line=117 (Compiled frame)
- de.csdev.ebus.service.parser.EBusParserService.onTelegramReceived(byte[], java.lang.Integer) @bci=101, line=95 (Compiled frame)
- de.csdev.ebus.core.EBusControllerBase$2.run() @bci=35, line=152 (Compiled frame)
- java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @bci=95, line=1149 (Compiled frame)
- java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=624 (Interpreted frame)
- java.lang.Thread.run() @bci=11, line=748 (Interpreted frame)
Hello @witek_1308,
yes, your trace is very helpful to identify the lock position. And it looks likes an issue in the discovery registry. Can you see any issues in the discovery inbox or the log files?
Not really, my inbox has entries for devices from 3 different bindings (network, xiaomi, weather) which are expected there, nothing from ebus for the moment. Also nothing unusual in logs (but don’t have any debug enabled). Regarding discovery registry, do you suggest it is something environmental on my side or rather general problem?
After ~48h I’m getting ~850 BLOCKED states and still growing. I’m curious why others don’t report this problem (people have higher tasks limits and then restart OH more often?)
My answer is not a solution to your question/problem 
but only information that I have OpenHab2.5.3-1 on RPi3B+ with Esera USB Coupler, VRC430, VR61/4 and eBus 2.5.1-6 and fortunatelly alltogether work correctly since 2 weeks now. The following items (now things) were discoverd in my inbox:
eBUS Standard(04)
eBUS Standard(15)
sBUS Standard(50)
Vaillant BAI00 (08)
Vaillant VRC430(f)/470(f) (15)
Congratulations and and thank you @csowada for this new binding! and few questions:
which thing is related to VR61/4 (mixer)? is this sBUS Standard(50)?
is it possible to display parameters for HC2 (second heating circuit related to VR61/4) ?
I can see the status of circulation pump (D.13), which is triggered based on the VRC430 time ranges setting. Would it be possible to switch on/off circulation pump from Openhab (such a function would be very, very usefull)
I have warnings in log like the following
2020-05-06 20:46:35.414 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0x00 is not equal to send byte 0x15! Stop send attempt ...
are those warnings due to telegrams not addressed to OpenHab but detected on ebus line by eBus binding?
Please note I have not perfomed any json yet but if it is required to answer some of the questions I will start to learn and work on it:-)
@RafalO, your mixed thing is eBus standard(50) but to get info from HC2 (which is possible) you need to do some own work. I’ve created simple json to extract heating curve and VF2 temp (I didn’t need more). If you browse through this thread you’ll find the reference to that repository (as well as csowada’s guidance how to develop these, how to use proper data types etc), if you can’t manage let me know and I’ll try to dig myself. In general to create own json I used decoded values on the internet (I believe by john30 on github) which shows what are parameters and possible values (read/write) and this will respond your question whether circulation can be switched on or off. I agree it is nice to control it self, as VRC doesn’t give much options there. Myself, I have circulation pump connected to sonoff with Tasmota firmware and still controlled by OpenHab but independently from the eBUS. This allowed me to implement holiday/public holiday schedules, etc.
Thank you for hints!
I have found your json from Nov`17
I copied the file and defined the link to it in eBUS Configuration binding (paper UI)
///etc/openhab2/eBUS/VR61_Witek.json (I named the file with you nick/name😊)
Also I have tried with the file I have found on GitHub and defined as follows
///etc/openhab2/eBUS/V6100.50.v61.mc_configuration.json in eBUS Configuration
But in both cases no additional commands for HC2 appeared in papaer UI and I have the following error (example for V6100.50.v61.mc_configuration.json) :
2020-05-07 22:48:48.418 [ERROR] [internal.things.EBusTypeProviderImpl] - Error on loading configuration by url: no protocol: ///etc/openhab2/eBUS/V6100.50.v61.mc_configuration.json
2020-05-07 22:48:48.483 [WARN ] [internal.things.EBusTypeProviderImpl] - eBUS command boiler.control.setopdata only contains a setter channel!
Seems like some sort of a basic error while I am trying to add json? 
Shall I do something else in the set up?
Your URL should start with file://
Yes, so it was a basic error, indeed. 
. After correcting no more errors for ebus binding but nothing new in inbox 
I have read today the ebus forum a lot and I have a little bit better understanding. I have tried with 2 ready custom json files for VR61 in the forum:
but without result.
Then I have noticed that "identification": ["56 36 31 30 29"] in both files might be wrong. After changing to ["56 36 31 30 30"] I can see “Vaillant VR61 (50)” in Inbox!
Hi @RafalO
my vailant setup is a Esera USB Coupler, VRC470, VR61/2 and VR81.
For the VR61/2 i use this file: vaillant_template.json (14.1 KB) VR61.json (30.3 KB)
It works pretty well and maybe it works also with your VR61/4.
Thank youfor the new VR61json! 
It has a big number of options (while comparing to your VR61.json from DEC`19) - shall be very usefull.
So I have changed id in your VR61 file into
"identification": ["56 36 31 30 30"] and specified both files (vailant_template.json and VR61.json) in eBus binding. After restar OH2 I can see in Inbox: Vaillant VR 61 Cu (50)
But when I try to add a new thing Vaillant VR 61 Cu (50) (ebus:V6100:58c13b58:50) from the inbox
I have a an error 404 - Not Found and the following error in the log:
2020-05-09 19:24:34.209 [ERROR] [ore.internal.discovery.InboxResource] - Thing ebus:V6100:58c13b58:50 unable to be approved: Duplicate channels ebus:V6100:58c13b58:50:V6100_hcTimer_Wednesday#from
Very strange as I do not have any item with a channel starting with: ebus:V6100:58c13b58:50:
not mentioned the exact channel string in the error message. I have looked at your VR61.jons line 926 "id": "hcTimer.Wednesday" , but seems similar to other days (Manday, Thuesday, …) .
So I am a bit lost 
and hope I do not need to uninstall and install ebus 2 again and vrc430 things I have… I have configured back your VR61.json file from DEC`19 and no such an error (but there is no Wednesday nor other options in it)
This issue should be fixed with a newer vaillant_template.json file. There is a bug with nested commands in the library.
It would be nice if you guys could add your enhanced files to the github repository.
@csowada, will you maybe have time to have a look at the BLOCKED threads issue with discovery?
I have some problems with the stability of the binding. It rarely survives a week.
This night i had
2020-05-11 04:41:28.618 [ERROR] [.csdev.ebus.core.EBusEbusdController] - error!
de.csdev.ebus.core.EBusDataException: Unable to send telegram FF 08 B5 09 03 0D 44 00 9E after 2 attempts … [ERROR: TOO_MANY_ATTEMPS, DATA: FF 08 B5 09 03 0D 44 00 9E]
at de.csdev.ebus.core.EBusQueue.checkSendStatus(EBusQueue.java:114) ~[bundleFile:?]
at de.csdev.ebus.core.EBusEbusdController$EBusSenderThread.run(EBusEbusdController.java:110) [bundleFile:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_152]
2020-05-11 04:41:28.735 [ERROR] [.csdev.ebus.core.EBusEbusdController] - error!
java.lang.NullPointerException: null
at de.csdev.ebus.core.EBusEbusdController.parseLine(EBusEbusdController.java:179) ~[bundleFile:?]
at de.csdev.ebus.core.EBusEbusdController.run(EBusEbusdController.java:262) [bundleFile:?]
2020-05-11 04:41:28.740 [WARN ] [.csdev.ebus.core.EBusEbusdController] - Stop sender thread!
The day before I had lots of messages about the send queue being full. Both times a binding restart fixed the problem for a while. I have now added a rule that restarts the binding automatically when the bridge goes offline.
Do you have instructions on how to build the binding kar somewhere? I would then try to find the problem myself, this might be easier for me as I can reproduce it.
This is my distribution project to build the kar files.
Thank you. It works with the recent vaillant_template.json file. I have VR61 Cu thing with number of channels available
@vbier, I think you may have ran into same issues as myself. Please check blocked threads in the openhab console. For me the symptoms are the same - binding doesn’t last long, full queue errors etc, but I realized this is because of lack of free threads (and ebus binding leaking them in the discovery process).
Try this:
openhab> shell:threads | grep ‘BLOCKED’ | wc -l
and
openhab> shell:threads | grep ‘BLOCKED’
Hello All,
now it also happend here. It looks like there has something changed in openhab 2.5.3. I use the discovery API as explained in the documentation and nothing has changed since a long time in that area.
I agree, in my case instability started after upgrade to 2.5.3. Before it was rock solid stable