[eBUS 2.0] New binding - Release Candidate 7b

Hi,

Having some trouble getting set up and hope someone can help.

I’m running OH2 and have installed the latest binding. This is running ok and is talking with my ebus interface (ESERA RS232) though FTDI on /dev/ttyUSB0, which is connected to a Vaillant VRC 470f directly to the boiler unit. The problem I have is that I cannot for the life of me get it to recognise any telegrams - everything is marked as failed.

I have been through the hardware setup instructions for ebusd and tried adjusting the potentiometer for hours. I am not able to get a stable AA heartbeat, just a few blocks every now and then. The stable signal position gives the results seen below.

In the logs, the most common error is “Telegram starts with an invalid source address!” which happens 3/4 times a second. Each time the source address listed is different. Log snippet at bottom.

I suspected it might have been a bad connection but have since replaced the cable with solid core, twisted pair CAT6 (ebus spec compliant) which made no difference.

Update - 24th Feb
I have a strong suspicion that the ESERA coupler is at fault and am following in ChrisPe’s footsteps by ordering the new v2.1 ebus interface from John30 et al on the FHEM forums. They are putting it together and testing it beforehand so hopefully everything will be good soon. Shall update again once it arrives.

Update - 12th March
It has arrived and it works! Very disappointed in ESERA - the coupler was not cheap and their support was non-existant. I can only recommend you don’t buy from them and instead get something from FHEM instead. Now onto the next issue of unidentified telegrams…

Log

18:44:39.824 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Data -12
18:44:39.869 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Data -13
18:44:39.909 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Data -14
18:44:39.953 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Data -15
18:44:39.997 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Data -16
18:44:40.125 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Data -17
18:44:40.168 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from LENGTH1 to UNKNOWN
18:44:40.168 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA]
18:44:40.648 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:40.694 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:40.694 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! FD [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
^Z                                                                                                                                                                                                   [1]  suspended   log:tail
openhab> 18:44:41.816 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:41.860 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:41.860 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! D5 [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
18:44:42.033 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:42.073 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:42.073 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! AE [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
18:44:42.684 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:42.727 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:42.727 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! F5 [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
18:44:42.816 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:42.857 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:42.857 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! BE [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
18:44:43.419 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:43.461 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:43.461 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! AB [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
18:44:43.718 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:43.763 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:43.763 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! AE [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
18:44:43.893 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:43.978 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:43.978 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! DF [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
18:44:44.023 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:44.109 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:44.110 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! F5 [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]

Hex Dump

0000000 fdee fbd7 aaaf f5eb d7d5 defd aaf5 d5ab
0000010 ebd5 fdf7 fdd5 fffd aad5 d7d5 12ab f5ca
0000020 6871 69f0 8e5f 4012 5a14 a2fc d7f5 ddf7
0000030 aafa faab f5aa ae86 baf5 d5fd f5d5 baaa
0000040 ead5 aaab eafd d7df d5dd abff aafe d5d5
0000050 bafd fe98 8336 c1c4 d7ff fddd abab aad6
0000060 aaf5 d5ea f5aa d5bf cb82 c1d5 82aa c0aa
0000070 bed5 d5af abff aafd abab fdd5 bad5 aaae
0000080 aaff baab baaa d7ee aaea d5fc d5ba ffd5
0000090 d7aa bfff fdab bbba aeaa bed5 ddff d5d5
00000a0 aad5 f7ea acd5 6398 3071 c971 a997 0ece
00000b0 d54d aaab dfbf abba faea d5df d5fc f5fd
00000c0 f7aa aaaa ebfd ebc1 ffaa d7d7 ddab fdef
00000d0 fdbf d5d5 abab aaaa f585 d5f5 afd5 aadd
00000e0 d7fd abf7 ddd7 fdaa aaf7 f5aa bbf5 aed7
00000f0 d5ab f5d7 aaab aaf4 ffeb beaa fdf5 ea8b
0000100 eaeb d3c5 f1bb 8deb 4244 3ad5 2b94 4746
0000110 f5e2 abaa d5aa 8bff abd5 aaea d5dd bbaa
0000120 d5d5 abf4 aafa c0ba ddf7 aeab f5f5 aad5
0000130 d5ff ffaa abae baae ddd5 97c2 6f2d 3ee7
0000140 40e0 4691 67a6 64f9 eaae caee d587 d7f5
0000150 d5dd aef5 f7fd fde8 87ba baaa fafd ebf5
0000160 c8aa d5ab f5d7 f5ab f5c9 ddbf d5df fdeb
0000170 baeb aa8b ffff dcf5 aed5 bfdd eaea aaaa
0000180 fef5 aaff abae aaba eaba d5ea eaae ddff
0000190 f5ba f5e5 eaa0 d4d5 c75a a491 ffc4 ffff
00001a0 ffcd f889 01a0 c2dd f5f5 d5aa d5ae 86c2

i have modified my esera ethernet adapter based on a prototyp for the usb adapter from galileo and the new informations from the fhem ebus adapter 2.0/2.1.
this stuff is working very very well.
my failure rate is now constantly below 8% instead of 75-80% before.

Hey,
i have a atmoTEC plus and would like to remote it with openhab2.
I use a FHEM E_BUS adapter, but i don’t get any Temperature values.

Is there an option, to adjust the potentiometer with ophenhab2?

Hi,

there is a new ebus adapter which could be connected directly on the gpio pins on the raspberry in the fhem forum (RPi).

with this adapter there is a special device driver /dev/ttyebus, which must be used.

but in the ebus bridge it’s not possible to select this device, only /dev/ttyS0 and /dev/ttyAMA0 is available.
maybe there is a way to do this in a config file?

Thanks
Andi

Hi Andi,

I’m using the same adapter (just received mine last friday) and was not able to use the new ebus binding with it.
What I’ve figured out so far with the new binding is, that

a) the /dev/ttyebus has root:root permissions and not root:tty as most other serial devices. When I add openhab to the root group its still not working. I’ve send a mail to Galileo about changing the group permanently to tty but he doesn’t know how to do this.

b) I also tried to add the /dev/ttyebus to the /etc/default/openhab2 file.

EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyebus"

… but still without any luck. At least now I receive a different ebus2-binding error

[220:org.openhab.binding.ebus:2.2.0.201712041912]                                                                                             2018-03-05 10:37:29.761 [ERROR] [de.csdev.ebus.core.EBusController   ] - java.lang.ArrayIndexOutOfBoundsException: Invalid length in readArray
java.lang.ArrayIndexOutOfBoundsException: Invalid length in readArray
        at gnu.io.RXTXPort.readArray(Native Method) ~[25:com.neuronrobotics.nrjavaserial:3.12.0.OH]
        at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1434) [25:com.neuronrobotics.nrjavaserial:3.12.0.OH]
        at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1323) [25:com.neuronrobotics.nrjavaserial:3.12.0.OH]
        at de.csdev.ebus.core.connection.AbstractEBusConnection.readBytes(AbstractEBusConnection.java:53) [220:org.openhab.binding.ebus:2.2.0.201712041912]                                                                 
        at de.csdev.ebus.core.EBusController.run(EBusController.java:179) 
        [220:org.openhab.binding.ebus:2.2.0.201712041912]
2018-03-05 10:37:29.833 [ERROR] [de.csdev.ebus.core.EBusController   ] - java.lang.ArrayIndexOutOfBoundsException: Invalid length in readArray
java.lang.ArrayIndexOutOfBoundsException: Invalid length in readArray

At the moment I’m using the adapter with ebusd and mqtt support which sends me the readings with a cronjob every 5 minutes to my openhab.
I hope we can make the ebus2 binding also work with the new ebsu2.1 raspberry shield.

Sebastian

… regarding your question: in the paperui I’ve added “/dev/ttyebus” in the Ebusd bridge settings under Serial Port. It’s a text field so you can put everything you want there. :wink:

Uh, it looks like that the rpi driver is not really a serial device. And the serial support depends on nrjavaserial.
But you could try to use socat to create an ethernet connection.

@sebastian: did you manage it to remove the /dev/AMA0 device?

If you mean to remove it in general from the /dev/ folder, yes. You can do this via the raspi-config menu. See instructions here: https://github.com/ebus/ttyebus make sure that you disable both, the login shell and the serial port hardware.
Before you use the ebus2.0 binding I would make sure that your adapter works with ebusd.

maybe we are going offtopic, but yes i mean the remove of the device in the dev folder.
i use openhabian and with the openhabian-config it didn’t work, also if i did it manual.

about the text field “Serial connection; Serial port”: in paperui it’s a fixed list field and there is no chance to enter any other devices. (just in my setup …) :upside_down_face:

another issue with the bridge: if i’m testing the interface with

echo "led test" >/dev/ttyebus

my traffic light on the adapter flash (working), but as soon i go into the bridge config (even i didn’t save anything), this will not work again until i reboot the raspberry.

maybe we open a seperate thread to get the RPi adapter with the ttyebus driver and ebus 2.0 binding working?

This a feature of a newer OH2 version. But you could try to define a thing for the bridge. Maybe I find time next days to create an example.

i’m on latest stable and now i switched my testing enviroment to the latest unstable 2.3.0 build 1224.
this field is still not editable :thinking:

anyway, would be great to get the config syntax, because it’s my prefered way to do the config in the files instead of paperui :wink:

So, I found some minutes to create an example things file

The addresses used in this example are not correct, it should only show how it works.

Bridge ebus:bridge:home1 "eBUS Bridge1" @ "My location" [ serialPort="COM1", masterAddress="00", advancedLogging=true ] {
    Thing vrc700_zone1 zone1 [ slaveAddress="08", polling=true ]
    Thing vrc430 vrc [ slaveAddress="15", polling=true ]
}

or for ethernet

Bridge ebus:bridge:home2 "eBUS Bridge2" [ ipAddress="10.0.0.2", port=80 ] {
    Thing vrc700_zone1 zone1 [ slaveAddress="08" ]
    Thing vrc430 vrc [ slaveAddress="15" ]
}
1 Like

Dear all

After several attempts my ebus adapter (ESERA) and ebus binding together with my WOLF heating system starts to work (shielded wiring was key). After initializing the ebus bridge the system immediately identified 10 things, which i configured (i.e. ebus standard) :

However, how I see it, devices with SA 15, 35, F5, F6 and 0C belong to the same “physical” device as they have the same identifier. With devices with SA 51 and 52 I’m not sure (as they have slightly different Identifiers). In addition only devices with SA 08 and F6 send telegrams with some meaningful data in it as can be seen in openhab.log file:

and for some MAs there seem no handler to exist:

Now to my questions:

  1. As I understand a physical device can have several SAs (in my case up to 5). is that correct?
  2. I’m somehow surprised that I can only pull quite limited meaningful data out of the ebus. I would have expected more. Is the reason that only the standard ebus thing is being used or are there any other explanations for it?
  3. In fact my Wolf components are WPM-1, BM-1 and two MMs. Is there a way to get more out of these devices, e.g. by using more specific things? If yes, which ones and how should they be configured? As I’m a total beginner, I guess that I will not be able to program my own parsers.
  4. Could the telegrams where the log says that no handler exist by extracted (e.g. MA 70 or F0)?

Any help would be highly appreciated. Thank you in advance for it

Best regards
Rolf

Dear all

Another question. I try to link ebus to an item. I would prefer to do it in the item file with the following command:

Number Warmwasser “Warmwasser [%.1f °C]” {ebus=“id:auto_stroker.temp_dhw, src:F6”}

Unfortunately this does not work. The only way how can link ebus data to an item is via paper-ui in the thing configuration section of the thing (standard ebus).

So my question: is it not possible anymore to link ebus data via items file? If still possible, what is wrong with my command?

Any hints would be highly appreciated.

Best regards
Rolf

Sorry for the short answer. But is is not possible without a thing anymore. But you can create a thing text files without paper ui.

Dear Csowada

Thank you already very much for the hint regarding my last post. Have you seen my second last post as well (5d ago). I would be very thankful to get some hints on that.

Best regards
Rolf

I’m sorry, but currently my whole family is sick. So I can’t spend time on openhab at the moment. But I have your post on the radar. But feel free to remind me in 3-4 days.

Okay a short try. You should add two wolf mixer modules manually with slave address 51 and 52. And you could try to add a BM2 for your BM1, maybe some commands are compatible. My BM2 uses slave address 35.

@csowada thank you for your hard work !

I have following heating configuration:
a) vaillant ecoTEC plus VC 256/5
b) vaillant VR 70
c) VRC 700
d) VR 920 internet bridge

Tried to control heating with:
a) Raspberry 3b+
b) esera eBus Koppler USB
c) os:raspbian lite
d) ebusd (from John30)
e) Zulu Java: OpenJDK Runtime Environment (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 1.8.0_152-b76)
f) OpenHab 2.3.0-SNAPSHOT Build #1245

Results: I can succesfully connect using ebusd + esera port /dev/ttyUSB0

but I cannot connect using [ebus 2.0 Alpha 15]:
“[ERROR] [ion.EBusSerialNRJavaSerialConnection] - Unable to connect to serial port /dev/ttyUSB0”

Any ideas how to enable communication? this is about permissions?

Roberto