[eBUS 2.0] New binding - Release Candidate 4

ebus
binding
Tags: #<Tag:0x00007f51dcb27ed0> #<Tag:0x00007f51dcb27d40>

(Scantineau) #523

Hi @csowada,

I have some questions for you about your binding.

  1. Do you have a tool to translate an ebusd configuration file to a json file for your binding ?
  2. You asked help to support more devices (on your README). Is there a path to shared configuration files ?
  3. Last but not least : Could it be possible with your binding to spoof an eBus device ? I mean, I don’t have any VR90 installed but I want to simulate it.
    My heating configuration is not really optimal… I have 2 pumps (floor heating and radiators) but I only have a VRC700. So the configuration is that the VRC700 handle the temperature control of the floor heating and the first floor (radiators) are in permanent heating even if not needed (the room temperature is controlled with valves).
    So my goal is to use sensors in each room and to combine them to act as a VR90.

KR


(Thomas Kropf) #524

Hi @csowada
I just migrated to openHAB 2.4.0~S1443-1 (Build #1443) and your newest binding eBUS binding 2.4.0-RC3. Everything went quite smoothly, various things got autodetected on eBus. I even was able to link values to my KNX installation.
One annoyance remains, though. The log constantly shows the following error message every 5 second:

2018-11-25 18:18:48.349 [ERROR] [bus.service.parser.EBusParserService] - Error while firing onTelegramResolved events!
java.lang.NullPointerException: null
	at org.openhab.binding.ebus.handler.EBusHandler.assignValueToChannel(EBusHandler.java:137) ~[?:?]
	at org.openhab.binding.ebus.handler.EBusHandler.handleReceivedTelegram(EBusHandler.java:338) ~[?:?]
	at org.openhab.binding.ebus.handler.EBusBridgeHandler.onTelegramResolved(EBusBridgeHandler.java:276) ~[?:?]
	at de.csdev.ebus.service.parser.EBusParserService.fireOnTelegramResolved(EBusParserService.java:115) [224:de.cs-dev.ebus.ebus-core:0.9.19.SNAPSHOT]
	at de.csdev.ebus.service.parser.EBusParserService.onTelegramReceived(EBusParserService.java:95) [224:de.cs-dev.ebus.ebus-core:0.9.19.SNAPSHOT]
	at de.csdev.ebus.core.EBusControllerBase$2.run(EBusControllerBase.java:119) [224: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) [?:?]

Any help?
Thomas


(csowada) #525

In your case one of the received values is NULL and causes an exception, I’ll fix it next days.


(csowada) #526

So, the new bugfix version should fix your null point exception.


(Thomas Kropf) #527

Hi @csowada,

many thanks, error fixed. I now get log messages like the following, confirming the reception of NULL values:

2018-12-03 23:10:01.884 [WARN ] [hab.binding.ebus.handler.EBusHandler] - Unexpected datatype NULL for channel ebus:std_controller_op-data-rc2bc_value-fuel !
2018-12-03 23:10:01.889 [WARN ] [hab.binding.ebus.handler.EBusHandler] - Unexpected datatype NULL for channel ebus:std_controller_op-data-rc2bc_modulation !
2018-12-03 23:10:01.894 [WARN ] [hab.binding.ebus.handler.EBusHandler] - Unexpected datatype NULL for channel ebus:std_controller_op-data-rc2bc_pressure-d-boiler !

Still struggling to get the mapping from Wolf devices to things right, but that’s for another evening…
Thanks again,
Thomas


(csowada) #528

Oh, not really better. Null is also a valid value, I will change this next time.


(Łukasz Dywicki) #529

Well done @csowada!
I had a test run with binding and it works fine both on my RPI. What I wanted to ask is support for textual configuration of things - is it possible to define & version configuration as it was possible with 1.x version of binding?

As small tip - since several months - it is possible to automate discovery of serial devices with mechanism introduced in ESH. Thanks to that known devices such USB adapters can be automatically added to inbox without asking user to find proper /dev/ttyUSBx.

Below I attach small screenshot with statistics of my Vaillant ecoTec/calormatic 430. From most annoying parts - I can not read part load which is one of most interesting fields to have.

Cheers,
Łukasz


(N) #530

Thanks @csowada for this binding. This is also my first post, as I am quite new to openHAB.
I have just recently bought the latest version of the FHEM forum eBus boardv2.2 and have had success with ebusd /ebusctl to retrieve values from both my ecoTEC boiler and VRC700, however not so much with the binding for openhab.

The first problem I had is related to my VRC700f, which was recognised as 15.b7v00 rather than 15.700 by ebusd, thus I had to manually download the CSV files, which might mean it does not get automatically recognised with the openhab binding either and how would one go about including the file here? It might just be me (openHAB noob), but it seems there is a lot of talk about these files in this thread, but not the location mentioned these have to be dropped, just in case this could be resolved with a simple copy/rename solution in my case.

The second issue seems to be getting no readings from any items (just NULL). I have used the textual configuration for things and items, as the PaperUI did not seem to pick up anything in the beginning as well as that I wanted to be able to version control my configuration. I have used the serial connection in the end, as the network one did not work on the localhost and the binding tried several times to connect to no avail.

Thirdly, is the network option for ebusd not supported and only for commercial products?

ebus.things:

Bridge ebus:bridge:ebusBridge "eBUS Bridge" @ "Cabinet" [ serialPort="/dev/ttyUSB0", masterAddress="00", advancedLogging=true ] {
Thing vrc700_zone1 zone1 [ slaveAddress="15", polling=true ] 
Thing bai boiler [ slaveAddress="08", polling=true ]
}

ebus.items

Number VRC700_Room_Temp      "VRC700 room temperature"   <temperature>     (Heating_Group)  {channel="ebus:vrc700_zone1:ebusBridge:zone1:vrc700_zone1_z1_room-temp#value"}
Number Boiler_Outside_Temp      "Boiler outside temperature"   <temperature>     (Heating_Group)  {channel="ebus:bai:ebusBridge:boiler:bai_boiler_control_datetime#temp-outside"}

output from openhab-cli

openhab> smarthome:ebus devices
MA | SA | Identifier     | Device         | Manufacture               | ID | Firmware   | Hardware   | Last Activity
---+----+----------------+----------------+----------------------+----+------------+------------+---------------------
00 | 05 |                | <interface>    | eBUS Library              |    | null       | null       | ---
10 | 15 | 42 37 56 30 30 | ---            | Joh. Vaillant GmbH & Co.  | B5 | 4.22       | 55.03      | Mon Dec 17     10:44:54 GMT 2018
03 | 08 | 42 41 49 30 30 | bai            | Joh. Vaillant GmbH & Co.  | B5 | 6.03       | 91.02      | Mon Dec 17        10:44:54 GMT 2018
----------------------------------------------------------------------------------------------------------------------

openhab> smarthome:status Boiler_Outside_Temp
NULL
openhab> smarthome:status VRC700_Room_Temp
NULL

and ebusctl_info, when I had ebusd running, before trying to use the openHAB binding

 update check: revision v3.2-12-g45b9bad available, broadcast.csv: different version available,        vaillant/bai.308523.inc: different version available, vaillant/broadcast.csv: different version available,    vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available
signal: acquired
symbol rate: 58
max symbol rate: 113
min arbitration micros: 2076
max arbitration micros: 3372
min symbol latency: 4
max symbol latency: 6
reconnects: 0
masters: 3
messages: 555
conditional: 3
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0603;HW=9102", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=B7V00;SW=0422;HW=5503", loaded "vaillant/15.b7v00.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd

cheers,
Nils

Edit: I now have tried to access eBus through PaperUI, but failed. I added the bridge through serial on /dev/ttyUSB0 and can see the same device as before on the opehab-cli. After discovery, I added the Valiant BAI00 thing, but again could not get any item to return any values, the log does not give any hints on what is going wrong, apart from spamming (every 10s) it with the following messages (which were there before, but added here just for completeness)

2018-12-17 14:38:08.427 [WARN ] [hab.binding.ebus.handler.EBusHandler] - Unexpected datatype NULL for channel ebus:bai_boiler_control_getopdata_temp-outside !
2018-12-17 14:38:08.696 [WARN ] [hab.binding.ebus.handler.EBusHandler] - Unexpected datatype NULL for channel ebus:bai_boiler_control_setopdata_temp-d-srv-water !

(Bartek) #531

Hello,
@witek_1308 @csowada I also have problems with a few (so far) settings. Especially:

  • DWH read works, write doesn’t - datagram is sent via eBus but nothing happens
  • setting date and time in VRC 470 doesn’t work
  • I cannot get any information about my second heating circuit (HC2) - there is no such setting in current plugin. How can I set/find it?

Hardware: Vaillant ecoTec VC206 + VRC 470 + boiler (BAI00) + VR 61/4
Software: OH 2.4 + binding 2.4.0.RC3-fix1

BTW yesterday, after upgrading to OH2.4 + 2.4.0.RC3-fix1 I saw 2 more autodiscovered devices in Inbox. Both recognized as eBUS Standard (right now I have 6 of those discovered). Why is that? Is it related to extended list of Supported Things in binding? On list is new VC206 but it isn’t discovered…

Update: I’ve checked logs from last month and all 6 eBUS standard devices where there. But some of them very rare.


(Witek) #532

@vangass, for the HC2 you need to discover/add the VR61/4 element which manages info about HC2. I created couple example items for it (e.g. flow temperature, don’t remember what else) for that circuit and it was added by @csowada to the json repository. Have a look, if you can’t find it let me know so I can send it on priv


(csowada) #533

Hello All,

I’m a bit busy at the moment, but I think I’ll find some free time after Christmas to answer your questions.


(Chaot Y2k) #534

Hi,

I habe big trouble that my VR470 is detected:

Thing UID                                | Label                                    | Refreshed ?
-----------------------------------------+------------------------------------------+-----------
ebus:std:c8836016:08                     | eBUS Standard (08)                       | true      
ebus:std:c8836016:15                     | eBUS Standard (15)                       | true      

what could I do that my devices are recognized?

Thanks for every help


(csowada) #535

Hello @ChaotY2k,

you can add a device manually, so if the automatic discovery is not working you should got that way. The binding has only a limit set of Vaillant devices on board.


(csowada) #536

Hello @vangass,

the binding adds an eBUS standard thing for every known eBUS device, that is normal. Many devices uses eBUS standard and Vendor specific commands.

Have you seen any error while sending commands? Maybe it is a timing issue. You could try the new serial drive if you use a serial connection.


(csowada) #537

@All,

I try to help, but I need more details to help. So please provide raw command examples if possible, than I’m able to reproduce the conversation from openHAB to eBUS raw telegrams. And if your setup is running properly with ebusd please provide some example output.
Another information is how the eBUS interface is connected to the binding (ethernet/serial)?

But every one should know that the binding only contains a subset of the ebusd configurations.


(csowada) #538

Yes, it possible. You can find the description in the README.MD of the binding source.

Really interesting change. I will have a look on it next days.

I guess that you also run an ebusd setup, so can you provide a valid “set” command from ebusd include the values to set? With this I can compare the result of the current configuration.


(csowada) #539

Yes, I’ve a small program to convert from ebusd to ebus binding. But it is more a quick and dirty solution. But I can upload it to github. You can find converted configurations from the tool here:

I have an official github repositiory for the included configurations. Help is always welcome, you can always create a pull request.

I would say that this will not really work. The binding is not able to act as slave device. So you can’t handle master-slave telegrams. If you only set values it could work.


(Mark Stroeve) #540

@lukics and @csowada i have two similar units but they are called Brink Renovent 300 and are used in a master/slave setup.

I added the ebus 2.0 binding and the bridge is online (I use a Esera USB coupler) it also discovered two things.
Named eBUS Standard (3C) and eBUS Standard (56).

I found this mapping CSV https://github.com/dstrigl/ebusd-config-brink-renovent-excellent-300
But maybe your config will work ? It also states it may work with Wolf in the CSV file

My logs currently gives warnings about:

[WARN ] [hab.binding.ebus.handler.EBusHandler] - Unexpected datatype NULL for channel ebus:std_common_identification_software-version !

Any suggestions how I would get this to work with the Brink Renovent 300?


(Bartek) #541

Hi,
@witek_1308 I send You PM 10day ago, but I didn’t find anything more about HC2. Could You please send those to me?
Thx.

@csowada Thank You for an answer.
When I set “log:set TRACE org.openhab.binding.ebus” then in logs there is “Received telegram from address FF to 15 with command dhw.program_dhw_circuit” but no raw command.
What do You mean by “new serial drive”? I have Esera usb coupler and majority of commands works as expected.


(Scantineau) #543

Could you please check if this is a misstype ?
Under ebus-configuration/src/main/resources/commands/ vaillant-bai00-configuration.json

You fill find 2 times “boilder”. Did you mean “boiler” ?