eBUS Binding 3.x [3.4.0;3.9.9)

csowada · May 2, 2020, 8:13pm

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?

witek_1308 · May 2, 2020, 8:34pm

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?

witek_1308 · May 4, 2020, 6:27am

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?)

RafalO · May 6, 2020, 6:55pm

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:-)

witek_1308 · May 7, 2020, 6:42am

@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.

RafalO · May 7, 2020, 9:06pm

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?

csowada · May 8, 2020, 4:33am

Your URL should start with file://

RafalO · May 8, 2020, 6:01pm

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!

John_Doe · May 9, 2020, 5:01am

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.

RafalO · May 9, 2020, 6:15pm

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)

csowada · May 10, 2020, 7:33am

This issue should be fixed with a newer vaillant_template.json file. There is a bug with nested commands in the library.

github.com

csowada/ebus-ebusd-configuration/blob/master/src/main/resources/vaillant/vaillant_template.json

{
	"id": "vaillant",
	"templates": [
		{
			"name": "templ",
			"template": [
				{"name":"cntstarts","type":"bcd","label":"start counter","length":3},
				{"name":"cntminutes","type":"bcd","label":"operation minutes","format":"%.1fmin"},
				{"name":"cnthours","type":"bcd","label":"operation hours","format":"%.1fh","length":3},
				{"name":"cntfuel","type":"bcd","label":"fuel quantity","length":4},
				{"name":"unit","type":"byte","label":"unit",
					"mapping": {"0":"all","1":"l","2":"m³"}},
				{"name":"fueltype","type":"byte","label":"fuel type",
					"mapping": {"0":"any","1":"oil","2":"gas"}},
				{"name":"countertype","type":"byte","label":"type of meter",
					"mapping": {"0":"starts","1":"hours1","2":"hours2","3":"hours3","4":"hours4","5":"modulating","16":"fuelquantity"}},
				{"name":"opdatacyclic","type":"byte","label":"cyclic transmission",
					"mapping": {"170":"start","85":"stop"}},
				{"name":"opdatatransfer","type":"byte","label":"data transmission",
					"mapping": {"0":"stop","1":"cyclic","2":"event","3":"cyclicandevent"}},

This file has been truncated. show original

It would be nice if you guys could add your enhanced files to the github repository.

witek_1308 · May 10, 2020, 9:44am

@csowada, will you maybe have time to have a look at the BLOCKED threads issue with discovery?

vbier · May 11, 2020, 2:04pm

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.

csowada · May 11, 2020, 2:14pm

This is my distribution project to build the kar files.

RafalO · May 11, 2020, 8:05pm

Thank you. It works with the recent vaillant_template.json file. I have VR61 Cu thing with number of channels available

witek_1308 · May 12, 2020, 12:10pm

@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’

csowada · May 16, 2020, 1:09pm

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.

witek_1308 · May 16, 2020, 2:26pm

I agree, in my case instability started after upgrade to 2.5.3. Before it was rock solid stable

csowada · May 16, 2020, 4:57pm

Damn, my thread log is empty. So I’m not able to check the threads again. But there was not much eBus stuff in the log. Maybe it is not complete the same issue. The first issue before the log starts with several other issues was from the “amazonechocontrol” binding.

@witek_1308 Have you seen some other errors before your OH instance stops to work properly? Can you check which bindings do you use?

Here my other bindings

astro1
comfoair1,
exec1
http1
milight1
snmp1
expire1
wol1
mqtt
systeminfo
network
fritzboxtr0641
amazonechocontrol
homematic
openweathermap
meteoblue
dwdunwetter

And versions from addons folder

miio
espmilighthub
ebus

vbier · May 17, 2020, 8:36am

I just have the problem with the send queue being full. Looking at the thread dump, I can see that the ebus-sender thread is no longer there:

openhab> shell:threads | grep ebus
at de.csdev.ebus.core.EBusEbusdController.run(EBusEbusdController.java:257)
“pipe-grep ebus” Id=227357 in RUNNABLE

After restarting the binding it looks like this again:

openhab> shell:threads | grep ebus
at de.csdev.ebus.core.EBusEbusdController.run(EBusEbusdController.java:257)
“ebus-sender” Id=227462 in TIMED_WAITING
at de.csdev.ebus.core.EBusEbusdController$EBusSenderThread.run(EBusEbusdController.java:112)
“pipe-grep ebus” Id=227538 in RUNNABLE

The problem with the openhab threads is that you do not see any exceptions in the log if you do not print the stacktrace yourself. And you are not allowed to catch Exception if you want your binding to get merged.

Edit: even though the sender thread was dead, the bridge was still ONLINE.