till 2 days I try to get data from my Vaillant ecoTec with VRC470. but not with success
I got an ebus 2.1 adapter from FHEM-Forum which is sending data over WLan and it still works with FHEM, but now I wanna try OH2.
Therefore I’ve downloaded Alpha 15 of ebus 2.0 Binding and put it in my Addon-Folder of OH2.
After that I could see the ebus-bridge and configured it with the IP-Address and port of ebus-adapter.
The Status of Bridge is ONLINE, but without receibing any data.
I opened console of OH2 and smarthome:ebus devices will only show
FF null null
After a quick check I think this is not a normal Ethernet adapter. It looks a bit smarter. So this binding is maybe not compatible. But I had no time yet to check the details.
Hi,
In my case using the FHEM WLAN adaptor let the things being discovered perfectly… @Allodo, What happens when you connect to the ip and port with an advanced terminal, like RealTerm ? @csowada, by the way, I saw you started to implement udp on Github, did you progress on this ? I’m still looking for a way to reconnect to the network port once disconnected, and using Wifi this is not that unusual.
@ChrisPe, possibly, I was just looking into this. Now I see the Esera device can be configured to be a server or a client. Which operating mode should I select to work with the binding ?
@csowada
I’m not sure what you mean. I inserted the Jar-File to Addons an then I see the ebus-bridge on Binding. In there are a lot of Things which I can choose e.g. Vaillant VRC430/470 and so on.
I do not have the interface right in front of me, but logically the esera device should act as a RAW telnet server, and the ebus binding act as a client.
I have a VRC470 as well, and it’s detected out of the box.
I have no way to check right now if it’s possible, but maybe using a tcpdump on the OH2 device could tell you if the device is sending data over the network ? use a filter to show only traffic related to the ip of the ebus adapter to make it readable
Oh you mean you have another connection on your adapter ? The TCP server can accept only one connection at time, so the other one should be disconnected before starting the OH2 ebus binding.
I’ve now deleted the ebus-config from my fhem.cfg so that FHEM didn’t know the ebus-adapter.
Do I have to restart OH2?
@ChrisPe
What do you mean, it’s detected out of the box?
When you choose the ebus-Binding there is only the VRC470 or what did you do?
Which Port do you use? The ebusd-TCP-Port or the Management TCP port?
Usually, my BAI boiler and VRC470 is discovered within 5 seconds after creation of the bridge. But before that, ensure that the ebus connected shows “no” on the adaptor web page, otherwize there is something still connected to it and your connection from the binding will fail to connect.
And yes, you have to connect to 192.168.1.40 and port 8889.
Hi,
I managed to make the ebus binding talk to the bridge, but there is still some problem with the configuration.
I created a thing for the bridge and one for the Vaillant (Ecotec Plus) burner with HEX slave address 08 in PaperUI.
In the burner thing, there’s a long list of items that I can activate, but when I activate them none returns a neaningfull value.
There is a No response from slave error message in the openhab log. The other ebus related log messages are added for reference.
Am I missing something ? I’m using 2.2.0.201712041912 version of the binding.
14:33:59.381 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: 10 53 07 04 00 57]
14:34:00.479 [INFO ] [inding.ebus.handler.EBusBridgeHandler] - Received telegram from address 10 to 08 with command boiler.control.getopdata
14:34:00.526 [INFO ] [nhab.binding.ebus.handler.EBusHandler] - Handle received command by thing ketelVaillant with id ebus:bai:3db5cfc1:08 ...
14:34:00.589 [DEBUG] [nhab.binding.ebus.handler.EBusHandler] - Key status_lead_heating with value null
14:34:00.620 [DEBUG] [nhab.binding.ebus.handler.EBusHandler] - Key temp_outside with value null
14:34:00.648 [DEBUG] [nhab.binding.ebus.handler.EBusHandler] - Key temp_return_srv_water with value 36
14:34:00.678 [DEBUG] [nhab.binding.ebus.handler.EBusHandler] - Key temp_srv_water with value 47
14:34:00.709 [DEBUG] [nhab.binding.ebus.handler.EBusHandler] - Key temp_return_lead_water with value 51
14:34:00.769 [DEBUG] [nhab.binding.ebus.handler.EBusHandler] - Key status_servicewater_heating with value null
14:34:00.838 [DEBUG] [nhab.binding.ebus.handler.EBusHandler] - Key temp_lead_water with value 52
For reference, on the fysical bus, there is a vaillant Ecotec plus VCW burner and a tado extension kit. Below are the responses I get when I use ebusd to interrogate the bus. I switch off ebusd when the ebus binding is switched on and vise-versa.
ebusctl info
version: ebusd 3.0.595c7c0
update check: version 3.1 available, broadcast.csv: different version available, memory.csv: different version available, vaillant/15.370.csv: different version available, vaillant/bai.308523.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version availab
access: *
signal: acquired
symbol rate: 22
max symbol rate: 111
reconnects: 0
masters: 3
messages: 354
conditional: 3
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0414;HW=7401", loaded "vaillant/bai.308523.inc" ([HW=7401]), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=37000;SW=0129;HW=6002", loaded "vaillant/15.370.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
after a long time I’ve created a complete new version with the latest changes. You can see all changes on github since a while. Please notice the new file format. At the moment I publish both formats, I’m not sure witch solution is better.
See first post for all information and download links.