eBUS Binding 3.x [3.4.0;3.9.9)

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

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.

How do I build the kar with the distribution project? Calling

maven install

results in

[ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.0.0:features-generate-descriptor (default-features-generate-descriptor) on project org.openhab.binding.ebus: Execution default-features-generate-descriptor of goal org.apache.karaf.tooling:karaf-maven-plugin:4.0.0:features-generate-descriptor failed: A required class was missing while executing org.apache.karaf.tooling:karaf-maven-plugin:4.0.0:features-generate-descriptor: javax/xml/bind/JAXBException

Yes, just mvn install

I was now able to compile everything with Java 8. I am not sure what I have changed, but it works.
I can load the kar and are now able to add debugging and find the cause of the problem.

Your distro and binding repos seem to be outdated.

Yes, the openhab “addons” repository ist outdated, but I only use it to build the binding. And the distro is only local up-to-date. You can also put the single jar files to the addons folder to debug, kar is only to bundle the osgi bundles in one file.
But keep the cache in mind, sometime it is not enough to replace the file.

@csowada, coming back to your question:
“Have you seen some other errors before your OH instance stops to work properly? Can you check which bindings do you use?”
in my case the sequence was always the same:

java.lang.OutOfMemoryError: unable to create new native thread

and then in matter of 30-60s

[ERROR] [de.csdev.ebus.core.EBusQueue        ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.

Hello All,

I’ve created a small new release to address smaller issues. This update is only important if you use the ebusd Connector.

Hello @witek_1308,

it looks like my issue is not the same as your issue. But I’ve added a flag to the new release to disable the discovery service. It is not tested, but it is simple and should work. Please add property to your openhab start script like start.sh. Afterwards you can also see a warning in your log about the disabled discovery.

-DEBUS_DISABLE_DISCOVERY=true

thanks, will give it a try in the coming days

edit: I don’t understand how this discovery service works but last week was running like crazy and leaking my threads whereas now it is stable, since yesterday’s restart didn’t grow (at least noticeably), before within 12h would be lots of BLOCKED threads. Not sure whether it is because I haven’t ran PaperUI in the meantime or something else but I can understand why some people don’t observe this behaviour.

@csowada, I just had the problem again with enhanced logging:

de.csdev.ebus.core.EBusDataException: Unable to send telegram FF 15 B5 09 03 0D 44 00 80 after 2 attempts … [ERROR: TOO_MANY_ATTEMPS, DATA: FF 15 B5 09 03 0D 44 00 80]
at de.csdev.ebus.core.EBusQueue.checkSendStatus(EBusQueue.java:114) ~[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]
2020-05-19 05:07:19.773 [ERROR] [.csdev.ebus.core.EBusEbusdController] - NPE! queue.getCurrent() is NULL
2020-05-19 05:07:19.777 [ERROR] [.csdev.ebus.core.EBusEbusdController] - error!
java.lang.NullPointerException: null
at de.csdev.ebus.core.EBusEbusdController.parseLine(EBusEbusdController.java:190) ~[bundleFile:?]
at de.csdev.ebus.core.EBusEbusdController.run(EBusEbusdController.java:280) [bundleFile:?]
2020-05-19 05:07:19.784 [WARN ] [.csdev.ebus.core.EBusEbusdController] - Stop sender thread!
2020-05-19 05:07:19.787 [INFO ] [.csdev.ebus.core.EBusEbusdController] - sender thread finished.
2020-05-19 05:07:19.817 [INFO ] [.eclipse.smarthome.model.script.ebus] - EBus bridge is offline!

It looks like a command cannot be send (which resets the send queue). This then triggers a following NPE while parsing the next line because queue.getCurrent() is NULL in the line

currentSendId = queue.getCurrent().id

The code is a little bit complicated for me to understand and fix myself. Maybe you have an idea on how to fix this.

Have you tried the new version? It should fix your issue.

Hi,
First, thank you for your EBUS binding.

I’m trying to read parameters from my VR91. It’s send 2 telegrams every 5min.

EBUSD logs

2020-05-20 08:05:38.411 [update notice] received unknown MS cmd: 3015b5240a06010a010f000000b741 / 02000a
2020-05-20 08:05:39.450 [update notice] received unknown MS cmd: 3015b5240a06010a01070000002842 / 02000a
2020-05-20 08:10:40.498 [update notice] received unknown MS cmd: 3015b5240a06010a010f000000b741 / 02000a
2020-05-20 08:10:40.770 [update notice] received unknown MS cmd: 3015b5240a06010a01070000002c42 / 02000a
2020-05-20 08:15:42.517 [update notice] received unknown MS cmd: 3015b5240a06010a010f000080b741 / 02000a
2020-05-20 08:15:42.790 [update notice] received unknown MS cmd: 3015b5240a06010a01070000002c42 / 02000a

My custom json file:

{
    "id":           "vrc700_custom",
    "vendor":       "Vaillant",
    "label":        "Vaillant VR91",
    "description":  "Vaillant VR91",

    "authors":      ["Christian Sowada, opensource@cs-dev.de",
                     "humback@gmail.com"],

    "identification": ["37 30 30 30 30"],

    "commands": [

        {
            "label":    "VR91 Temperature",
            "id":       "VR91_T",
            "command":  "B5 24",
            "get": {
                "master": [
                    {"type": "static", "default": "06 01 0A 01 0F 00 "},

                    {"name": "T2", "type": "float", "label": "Zone 2 temperature",  "format":"%.1f°C"}
                ],
                "slave": [

                   {"type": "static", "default": "00 0A"}
                ]
            }
        },

        {
            "label":    "VR91 Humidity",
            "id":       "VR91_H",
            "command":  "B5 24",
            "get": {
                "master": [
                    {"type": "static", "default": "06 01 0A 01 07 00 "},

                    {"name": "H2", "type": "float", "label": "Zone 2 humidity",  "format":"%.1f%"}
                ],
                "slave": [

                   {"type": "static", "default": "00 0A"}
                ]
            }
        }

    ]
}

The problem is that humidity telegram is resolved each time, but temperature telegram is visible in ebus_resolved.csv randomly (do not appear in the ebus_unresolved.csv and in openhab.log either)

2020-05-20 01:43:03;"30";"15";"B5 24";"0A 06 01 0A 01 0F 00 00 80 BA 41 14 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_T
2020-05-20 01:43:05;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 01:48:05;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 34 42 99 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 01:53:07;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 34 42 99 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 01:58:10;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 34 42 99 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 02:03:12;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 34 42 99 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 02:08:14;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 02:13:15;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 02:18:17;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 02:23:19;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 02:28:22;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 02:33:26;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 02:38:26;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 02:48:29;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 02:53:31;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 02:58:35;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 03:03:36;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 03:08:38;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 03:13:40;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 03:18:41;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 03:23:45;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 03:28:47;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H
2020-05-20 03:33:48;"30";"15";"B5 24";"0A 06 01 0A 01 0F 00 00 80 B8 41 B9 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_T
2020-05-20 03:33:50;"30";"15";"B5 24";"0A 06 01 0A 01 07 00 00 00 30 42 58 00 02 00 0A 26 00 AA";GET > vrc700_custom.VR91_H

Have you any idea what is a reason?

Update:
The problem is with ebusd daemon, not all telegrams visible in ebusd logs are forwarded to TCP port.
I replace my setup:
adapter – >ebusd_esp --> ebusd daemon --> openhab(ebusd)
to
adapter --> espeasy ser2net --> openhab(raw)

Now everything works.

1 Like

I have just tried, but it makes things worse. It does not work at all. It throws exceptions on startup of openHAB and never gets a single value.

2020-05-20 15:09:18.090 [ERROR] [.csdev.ebus.core.EBusEbusdController] - error!
de.csdev.ebus.core.EBusDataException: Unable to send telegram FF 08 B5 09 03 0D 17 00 52 after 2 attempts … [ERROR: TOO_MANY_ATTEMPS, DATA: FF 08 B5 09 03 0D 17 00 52]
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-20 15:09:18.094 [ERROR] [.csdev.ebus.core.EBusEbusdController] - error!
java.lang.NumberFormatException: For input string: “0:”
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[?:1.8.0_152]
at java.lang.Integer.parseInt(Integer.java:580) ~[?:1.8.0_152]
at java.lang.Integer.valueOf(Integer.java:740) ~[?:1.8.0_152]
at de.csdev.ebus.utils.EBusUtils.toByteArray2(EBusUtils.java:308) ~[bundleFile:?]
at de.csdev.ebus.core.EBusEbusdController.parseLine(EBusEbusdController.java:211) ~[bundleFile:?]
at de.csdev.ebus.core.EBusEbusdController.run(EBusEbusdController.java:271) [bundleFile:?]
2020-05-20 15:09:18.090 [ERROR] [.csdev.ebus.core.EBusEbusdController] - error!
de.csdev.ebus.core.EBusDataException: Unable to send telegram FF 08 B5 09 03 0D 17 00 52 after 2 attempts … [ERROR: TOO_MANY_ATTEMPS, DATA: FF 08 B5 09 03 0D 17 00 52]
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-20 15:09:18.145 [WARN ] [.csdev.ebus.core.EBusEbusdController] - Stop sender thread!

Edit: I cleaned the cache and made sure only the new version is running, problem persists.

Edit2: reverted to the old version, binding starts again.

Hello @vbier,

could you please run the binding with trace logging enabled? For me it to hard to find a solution without additional information.

log:set TRACE org.openhab.binding.ebus

or 

log:set TRACE  de.csdev.ebus.core.EBusEbusdController

I once again installed 2.5.1-7 to get a log. I hope this helps.

2020-05-24 12:14:59.234 [TRACE] [ng.ebus.internal.handler.EBusHandler] - Poll command “ebus:bai:e011a23d:08:bai_boiler_state-diverter-valve#state-diverter-valve” with “FF 08 B5 09 03 0D 54 00 AC” …
2020-05-24 12:14:59.388 [TRACE] [.csdev.ebus.core.EBusEbusdController] - -->>|-s FF 08B509030D5400|
2020-05-24 12:14:59.389 [TRACE] [.csdev.ebus.core.EBusEbusdController] - -->>|-s FF 08B509030D5400|
2020-05-24 12:14:59.399 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<–|-s FF 08B509030D5400|
2020-05-24 12:14:59.401 [DEBUG] [.csdev.ebus.core.EBusEbusdController] - Unknown send response: -s FF 08B509030D5400
2020-05-24 12:14:59.403 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<–|-s FF 08B509030D5400|
2020-05-24 12:14:59.405 [DEBUG] [.csdev.ebus.core.EBusEbusdController] - Unknown send response: -s FF 08B509030D5400
2020-05-24 12:14:59.408 [TRACE] [.csdev.ebus.core.EBusEbusdController] - <<–|:ERR: invalid numeric argument|
2020-05-24 12:14:59.411 [ERROR] [.csdev.ebus.core.EBusEbusdController] - error!
java.lang.NumberFormatException: For input string: “0:”
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[?:1.8.0_152]
at java.lang.Integer.parseInt(Integer.java:580) ~[?:1.8.0_152]
at java.lang.Integer.valueOf(Integer.java:740) ~[?:1.8.0_152]
at de.csdev.ebus.utils.EBusUtils.toByteArray2(EBusUtils.java:308) ~[bundleFile:?]
at de.csdev.ebus.core.EBusEbusdController.parseLine(EBusEbusdController.java:211) ~[bundleFile:?]
at de.csdev.ebus.core.EBusEbusdController.run(EBusEbusdController.java:271) [bundleFile:?]
2020-05-24 12:14:59.417 [DEBUG] [.csdev.ebus.core.EBusEbusdController] - eBUS connection thread is shutting down …
2020-05-24 12:14:59.420 [WARN ] [.csdev.ebus.core.EBusEbusdController] - Stop sender thread!
2020-05-24 12:14:59.495 [INFO ] [.eclipse.smarthome.model.script.ebus] - EBus bridge is offline!

In order to fix the problem for me, I have added a catch NumberFormatException to EbusUtils.toByteArray2 that then throws an EbusDataException. Also added the exception to the throws list in mergeHexDumpStrings. No restarting of the sender thread needed.

I also added a try finally around the code of the sender thread and set the status to disconnected to make sure crashes in the sender thread are reflected in the thing status.

Hello @vbier,
the initial issue is that the telegram that is send to ebusd causes an error. This error :ERR: invalid numeric argument is returned as a new line, but it should be part of -s FF 08B509030D5400 like -s FF 08B509030D5400::ERR: invalid numeric argument. But in general such an error should not stop the sender thread. I’ll check some things here.

Hallo @vbier,

I’m not sure why ebusd sends the response splitted into two lines? Can you say something about your setup?

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.