Could you post your “Roundtrip time” from the eBUS bridge? This value is in micro seconds. My value with a direct connected ARM computer is around 14.000us with an FTDI Serial USB converter.
Now I’ve tweaked the FTDI driver a bit and the result is 6.000us, that is really fast. It worked without restarting the binding.
# cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
16
# echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
# cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
1
I don’t know where to find this on my devices. The pi zero has an adapter board directly connected to the GPIO header with a custom device driver (GitHub - eBUS/ttyebus: Real time linux kernel module for the ebusd using the PL011 UART on a Rasperry Pi). There is no usb or serial device in the setup. There also is nothing in /sys/bus that resembles ttyebus.
On the openHAB pi, there is only the device created by socat:
lrwxrwxrwx 1 root root 10 Feb 19 15:56 /dev/ttyEBUS → /dev/pts/1
And also nothing in /sys/bus for this device. At least nothing I could find.
The problem might be that the pi zero only does not have a network port, but is connected over wifi. But I already have a HM-MOD-RPI-PCB connected to the openHAB pi, which makes it impossible also to connect the eBUS adapter.
Another thing i noticed while fiddling with the socat options: the things do not go ONLINE again after failures to read from the device and reconnect.
openhab2.log:
2019-02-20 08:10:28.713 [ERROR] [de.csdev.ebus.core.EBusController ] - An IO exception has occured! Try to reconnect eBUS connector ...
java.io.IOException: Input/output error in nativeavailable
at gnu.io.RXTXPort.nativeavailable(Native Method) ~[242:com.neuronrobotics.nrjavaserial:3.14.0]
at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1409) ~[242:com.neuronrobotics.nrjavaserial:3.14.0]
at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1323) ~[242:com.neuronrobotics.nrjavaserial:3.14.0]
at de.csdev.ebus.core.connection.AbstractEBusConnection.readBytes(AbstractEBusConnection.java:53) ~[260:de.cs-dev.ebus.ebus-core:0.9.19.SNAPSHOT]
at de.csdev.ebus.core.EBusController.run(EBusController.java:208) [260:de.cs-dev.ebus.ebus-core:0.9.19.SNAPSHOT]
2019-02-20 08:10:28.720 [WARN ] [de.csdev.ebus.core.EBusController ] - Retry to connect to eBUS adapter in 5 seconds ...
2019-02-20 08:10:29.640 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command "ebus:bai:49e3d158:08:bai_dhw_state-dhw-demand-ebus#state-dhw-demand-ebus" with "FF 08 B5 09 03 0D 47 04 AC" ...
2019-02-20 08:10:34.410 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: FF 08 B5 09 03 0D 47 04 AC]
2019-02-20 08:10:34.420 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Unable to send telegram FF 08 B5 09 03 0D 47 04 AC after 2 attempts ... [ERROR: TOO_MANY_ATTEMPS, DATA: FF 08 B5 09 03 0D 47 04 AC]
2019-02-20 08:10:34.422 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! 21 [ERROR: INVALID_SOURCE_ADDRESS, DATA: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
2019-02-20 08:10:34.445 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Master CRC invalid! IS:B4 SHOULD:00 [ERROR: MASTER_CRC_INVALID, DATA: FF B5 10 09 00 00]
2019-02-20 08:10:35.615 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from address 10 to 08 with command boiler.control.getopdata
2019-02-20 08:10:35.618 [DEBUG] [hab.binding.ebus.handler.EBusHandler] - Handle received command by thing Vaillant BAI00 (08) with id ebus:bai:49e3d158:08 ...
events.log:
2019-02-20 08:10:28.732 [hingStatusInfoChangedEvent] - 'ebus:bridge:49e3d158' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Input/output error in nativeavailable
2019-02-20 08:10:28.744 [hingStatusInfoChangedEvent] - 'ebus:bai:49e3d158:08' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
2019-02-20 08:10:28.774 [hingStatusInfoChangedEvent] - 'ebus:vrc430:49e3d158:15' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
2019-02-20 08:10:46.612 [vent.ItemStateChangedEvent] - Ebus_Date changed from 2019-02-20T08:10:18.000+0100 to 2019-02-20T08:10:49.000+0100
And I do sometimes see NPEs in the log:
java.lang.NullPointerException: null
at de.csdev.ebus.command.datatypes.ext.EBusTypeDateTime.decodeInt(EBusTypeDateTime.java:77) ~[260:de.cs-dev.ebus.ebus-core:0.9.19.SNAPSHOT]
at de.csdev.ebus.command.datatypes.ext.EBusTypeDateTime.decodeInt(EBusTypeDateTime.java:1) ~[260:de.cs-dev.ebus.ebus-core:0.9.19.SNAPSHOT]
at de.csdev.ebus.command.datatypes.EBusAbstractType.decode(EBusAbstractType.java:106) ~[260:de.cs-dev.ebus.ebus-core:0.9.19.SNAPSHOT]
at de.csdev.ebus.command.EBusCommandUtils.decodeValueList(EBusCommandUtils.java:374) ~[260:de.cs-dev.ebus.ebus-core:0.9.19.SNAPSHOT]
at de.csdev.ebus.command.EBusCommandUtils.decodeTelegram(EBusCommandUtils.java:426) ~[260:de.cs-dev.ebus.ebus-core:0.9.19.SNAPSHOT]
at de.csdev.ebus.service.parser.EBusParserService.onTelegramReceived(EBusParserService.java:94) ~[260:de.cs-dev.ebus.ebus-core:0.9.19.SNAPSHOT]
at de.csdev.ebus.core.EBusControllerBase$2.run(EBusControllerBase.java:119) [260:de.cs-dev.ebus.ebus-core:0.9.19.SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
I also have seen restarts of openHAB when I did restart socat, it looks like the underlying serial library completely crashes openHAB when the device is gone while it is connected. This does not happen every time, but maybe every second time.
You can find the “Roundtrip time” on the eBUS Bridge thing in PaperUI. This is the last arbitration time in microseconds. It is one of the metrics values.
So,
I’ve release a new minimal modified version. Now the additional serial driver should work. Maybe it is useful for someone. And the warnings from the previous version are disabled. More details on github.
I quickly checked the roundtrip time values and they mostly are around 6500, but I also saw 8900 once.
So in general not too bad. I’ve 6500us on my usb connected device.
The link for RC4 points to an old 2.2.0 jar file.
So is it normal that there are failed telegrams? What is a normal failed ratio?
Edit: did you look at the status problem (you should set status ONLINE in onTelegramReceived as you mark it OFFLINE in onTelegramException) and the NPE or shall I write an issue in your github project for the ebus library?
Ups, thats wrong.
When I turn on polling in the BAI thing, openHAB becomes unresponsive after a while. The thread dump shows 2000 HTTPClient threads, and only a restart makes everything work again. This happened twice yesterday, so I have for now uninstalled the binding. Has not happened since.
When I woke up this morning, it had 27 degrees in my house. The VRC430 showed a message like “no connection to heating unit” and I had to cut power to the heating to get everything working again. I could bet that this has something to do with openHAB being blocked (most likely by your binding, as this has never happened before).
I will keep an eye on things and report back.
Wow, that’s weird. Did you pull the Rpi off after the crash? Maybe the adapter blocked the serial line. So the bus wasn’t released again. Maybe the driver is not so hardened here.
I don’t remember using http connections. Only TCP connections should be used.
I’ve fixed the RC4 download link, now it works.
So, I’ve checked the sources and HTTPClient is not used on the ebus binding. Can you send me some logs?
I’ve stuck with this one as well on RPI3+ (Openhabian installation).
I do have a stream of data on the serial port but I do not see anything in OpenHab logs.
First thing I have solved was the issue with:
Caused by: java.lang.ClassNotFoundException: gnu.io.SerialPortEventListener cannot be found by org.openhab.binding.ebus_1.13.0
I have installled librxtxserial_2_1_7.so and RXTXcomm.jar in Zulu libs. That solved the problem as no more such things in the logs.
The problem is that I cannot find anything else in the logs as well:
2019-02-22 23:57:39.835 [INFO ] [ab.binding.ebus.internal.EBusBinding] - Update eBus Binding configuration ...
2019-02-22 23:57:40.961 [INFO ] [org.quartz.core.QuartzScheduler ] - Scheduler openHAB-job-scheduler_$_NON_CLUSTERED started.
2019-02-22 23:57:41.225 [INFO ] [ab.binding.ebus.internal.EBusBinding] - Enable CSV writer for eBUS all,debug,unknown
I have tried to switch from serial to network with ser2net and absolutely nothing. I was expecting that might help because I do not see that when serial is used it is used with 2400 8DATABITS NONE 1STOPBIT
from Karaf console I also do not see much
bundle:list .*ebus.*
START LEVEL 100 , List Threshold: 50
ID │ State │ Lvl │ Version │ Name
────┼────────┼─────┼─────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
215 │ Active │ 80 │ 1.13.0 │ This is the eBus binding of the open Home Automation Bus (openHAB)
I’ve been trying the connection with ebusd and I do see a stream of data, so there is something on the wire.
# Serial port of eBUS interface
# Valid values are e.g. COM1 for Windows and /dev/ttyS0 or /dev/ttyUSB0 for Linux
#serialPort=COM2
#serialPort=/dev/ttyUSB0
# TCP Hostname and Port
# Warning: Only use ebus.hostname or ebus.serialPort
hostname=192.168.8.127
port=8888
# Custom parser configuration file
# This example tries to load a configuration ${openhab_home}/configurations/ebus-config.json
#parserUrl=platform:/base/../configurations/ebus-config.json
# Define one or more parsers for you eBUS device. You can find the latest devices below or on the wiki page.
# https://github.com/openhab/openhab/wiki/eBUS-IDs
#
# >> Deprecated
#
# >> _vaillant - All older vaillant telegrams (will be merged in other files)
# >> _wolf-35 - All older Wolf eBUS dst address 0x35 telegrams (will be merged in other files)
#
# >> Productive
#
# >> common - Commands from eBUS standard
# >> vaillant-bai00 - All Vaillant BAI000 telegrams
# >> vaillant-vrc430 - All Vaillant VRC430 telegrams
# >> vaillant-vrc470 - All Vaillant VRC470 telegrams
# >> vaillant-vrc630 - All Vaillant VRC630 telegrams
# >> vaillant-vr90 - All Vaillant VR90 telegrams
# >> wolf-cgb2_hc - All boiler Wolf CGB2 heating curve telegrams
# >> wolf-cgb2 - All boiler Wolf CGB2 telegrams
# >> wolf-sm1 - All Wolf Solar Module SM1 telegrams
# >> custom - Use configuration defined by ebus:parserUrl
#
# default uses common and all vendor specified telegrams
parsers=common,_wolf,_testing,custom
# Write all/debug/unknown telegrams to a CSV file in folder {openhab}/etc/ebus
record=all,debug,unknown
# Set the sender id of this binding, default is "FF"
#senderId=FF
What to check? what to do? to get this thing working and be present in OH2 in other for than those 2 entries in the log
You use the 1.x binding, but this topic is about the 2.x binding. This binding is not part of the official openhab installation.
Sorry for stating that this is caused by your binding. I still had the problem after uninstalling your binding, it only took some more time for openHAB to get unresponsive. The threads do not show the culprit, they all look like this:
“HttpClient@1fa9a2b-scheduler” #156 prio=5 os_prio=0 tid=0x5bd38000 nid=0x66dc waiting on condition [0x5a89e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x6a337750> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
I had to uninstall several bindings one by one and check the thread count with
sudo -u openhab jstack |grep HttpClient | wc -l
The problem seems to be the HarmonyHub binding. My hub seems to have gotten a firmware update that breaks the connection to the binding. Uninstalling the HarmonyHub binding got rid of the problem.
I will try your RC4 next.
Shame on me 
But that moved me forward as with 1.x binding I had nothing. With RC4. I’m somewhere. However, I still cannot announce a full success.
This is what I have after installing 2.4 and auto-detection kicked in. Not much. I do have Wolf CGS-20. It is however not recognized here but at least there is some activity on eBus. I do use Esera eBus RS-232 coupler with FTDI RS to USB converter.
openhab> smarthome:ebus devices
MA | SA | Identifier | Device | Manufacture | ID | Firmware | Hardware | Last Activity
---+----+----------------+----------------+----------------------+----+------------+------------+---------------------
FF | 04 | | <interface> | eBUS Library | | null | null | ---
00 | 05 | | --- | null | | null | null | Sat Feb 23 14:18:18 CET 2019
----------------------------------------------------------------------------------------------------------------------
There is nothing fancy in less /var/log/openhab2/ebus-unresolved.csv
Pretty much all zeros.
Date/Time;SRC;DST;CMD;REMAIN_DATA;
2019-02-23 13:08:53;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 13:12:54;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 13:12:55;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 13:19:29;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 13:28:43;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 13:38:25;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 13:39:11;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 13:40:45;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 13:42:01;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 13:55:58;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 13:56:43;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 14:01:16;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 14:16:33;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 14:18:18;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 14:24:03;"00";"00";"00 00";"00 00 00 00 00";
2019-02-23 14:25:43;"00";"00";"00 00";"00 00 00 00 00";
After bumping the logs with
openhab> log:set TRACE org.openhab.binding.ebus
openhab> log:set TRACE de.csdev.ebus
I do see:
2019-02-23 14:31:20.688 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
2019-02-23 14:31:20.736 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to SRC_ADDR
2019-02-23 14:31:20.767 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from SRC_ADDR to TGT_ADDR
2019-02-23 14:31:20.815 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from TGT_ADDR to UNKNOWN
2019-02-23 14:31:20.818 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: FF DD AA]
2019-02-23 14:31:21.350 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
2019-02-23 14:31:21.445 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to SRC_ADDR
2019-02-23 14:31:21.493 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from SRC_ADDR to TGT_ADDR
2019-02-23 14:31:21.526 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from TGT_ADDR to PRIMARY_CMD
2019-02-23 14:31:21.574 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from PRIMARY_CMD to SECONDARY_CMD
2019-02-23 14:31:21.622 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from SECONDARY_CMD to UNKNOWN
2019-02-23 14:31:21.625 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: F7 FD BA BA AA]
2019-02-23 14:31:21.845 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
2019-02-23 14:31:21.894 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to SRC_ADDR
2019-02-23 14:31:21.942 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from SRC_ADDR to TGT_ADDR
2019-02-23 14:31:21.973 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from TGT_ADDR to PRIMARY_CMD
2019-02-23 14:31:22.021 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from PRIMARY_CMD to SECONDARY_CMD
2019-02-23 14:31:22.069 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from SECONDARY_CMD to UNKNOWN
2019-02-23 14:31:22.074 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: FF FF FD FF AA]
2019-02-23 14:31:22.612 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
2019-02-23 14:31:22.660 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
2019-02-23 14:31:22.665 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! D5 [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF FF FD FF AA DF EB AA AB D5 AA 00 00 00 00 00 00 00 00 1E F0 7B A4 82 F5 FA FF AF D5 D5 BB E0 AE AA FD D5 FD FD F5 F7 D5 AA CF 00 00 B5 4E 03 FF AA]
2019-02-23 14:31:22.740 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
2019-02-23 14:31:22.788 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
2019-02-23 14:31:22.792 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! DD [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF FF FD FF AA DF EB AA AB D5 AA 00 00 00 00 00 00 00 00 1E F0 7B A4 82 F5 FA FF AF D5 D5 BB E0 AE AA FD D5 FD FD F5 F7 D5 AA CF 00 00 B5 4E 03 FF AA]
2019-02-23 14:31:22.836 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
2019-02-23 14:31:22.884 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
2019-02-23 14:31:22.888 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! DD [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF FF FD FF AA DF EB AA AB D5 AA 00 00 00 00 00 00 00 00 1E F0 7B A4 82 F5 FA FF AF D5 D5 BB E0 AE AA FD D5 FD FD F5 F7 D5 AA CF 00 00 B5 4E 03 FF AA]
2019-02-23 14:31:23.108 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
2019-02-23 14:31:23.156 [TRACE] [ev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
2019-02-23 14:31:23.160 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! F5 [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF FF FD FF AA DF EB AA AB D5 AA 00 00 00 00 00 00 00 00 1E F0 7B A4 82 F5 FA FF AF D5 D5 BB E0 AE AA FD D5 FD FD F5 F7 D5 AA CF 00 00 B5 4E 03 FF AA]
Any hints? How to move this forward and have the Wolf properly recognized? Do I miss anything in the config?
You should adjust your adaptor first if it is possible. You can see some metrics in the ebus bridge in paper ui. You should see many unresolved telegrams. And the errors should not too high.
But another problem is that we have only limited support for wolf devices.
Hi @ all.
I´m trying to get this binding to work with my Vaillant heating system.
Since now, i´m stuck to get the communication between ebusd & the binding. I already read, that i can´t establish the bridge directly to ebusd to get it work.
So i´ve tried it with ser2net, but i dont know how to configure ser2net and what i´ve to put in the bridge settings.
I´m sorry, but i´m not really familiar with Linux at all.
I use a Raspberry Pi 3B+ (openhabian-image) with RPi-Board v2.2 from FHEM-Forum. The communication to my Vaillant works very well and i can read several values via ebusd.
It would be very nice, if someone could help me.
THX
If you have your ebus HW on another device than openHAB, follow these steps:
8888:raw:0:/dev/ttyebus:2400 8DATABITS NONE 1STOPBITDepending on whether network access works in the ebus binding rc4:
3. create an ebus bridge, configure the ip adress of the remote device running ser2net and the port (in this example 8888).
4. run discovery and vaillant heating things will be found
If the discovery does not find vaillant things, but generic ebus things:
3. on the openHAB host, setup socat to create a local device forwarding traffic to the ser2net port:
/usr/bin/socat -d -d -s pty,link=/dev/ttyEBUS,raw,group=dialout,mode=0660,echo=0 tcp:192.168.178.61:8888
This forwards traffic from 192.168.178.61:8888 to /dev/ttyEBUS. Adjust ip address and port to the ser2net host.
4. create an ebus bridge, configure the device /dev/ttyEBUS. If it is not available add it to /etc/default/openhab2
5. run discovery and vaillant heating things will be found
If you have you ebus HW on the same host as openHAB:
Hi vbier,
you´re awsome! This worked for me. Thank you so much! Yes, i´ve the eBus-Module conntected to the GPIO an on the same Raspi i installed openhabian.
The missing /dev/ttyebus in openhab was the showstopper. after adding this and a reboot i was able to choose the ttyebus under serial connection of the bridge. Until now i don´t have configured ebusd service running at startup… do i still have to get rid (uninstall) of it?
After this 3 new things where shown in my inbox. I´ve selected them and got them shown in Control. A minute later 7 new things (called "Vaillant VRC 700 xxx) arrived my inbox… so i added them to.
Now unter Control the ebus bridge shows me the metrics. Hurray.
But only “Temperature Broadcast” & “Date Broadcast” where readed out of my Vaillant.
I´ve tried to manage some items of the thing and configured the Flow Temperature for example to poll all 5 seconds… but nothing happend.