Hi csowada,
I can confirm the “old” binding is running and I can receive values from my heating system.
Regards
Hello All,
I`m behind my schedule because I ve migrated my productiv environment to ESXi VM and Docker x64 from an Arm device. So I
ve spend time for other things 
. But with this setup I can switch faster to a 3.0 environment.
hi @csowada
I did some additional testing, full deinstall of the bindung. Also the latest version works now for me.
one additional thing:
I tried to include an additional config.json for my VRC 700 because I want to have the fuel consumption. But when I do so I get the following error:
de.csdev.ebus.cfg.EBusConfigurationReaderException: Unable to find a template for id vaillant.templ.tempv!
How can I add the fuel consumption?
@csowada I am looking at 3.0 topic currently and I see you keep your binding code with big OH monorepo. Do you maybe wish to separate it and host separately just like I did for some of connectorio bindings or you plan to submit PR to official addons once migration to 3.0 is over?
Yes, I’ve checked already if it is possible to extract the Openhab pom.xml to an own repo. There is no benefit to use the big repo.
Hi @csowada,
I have to latest binding successful running with an ESERA USB device connected via USB to my Raspberry Pi in combination with a Wolf CGB2 and a BM2 Module. Reading the current values is no problem, but how do i set for example the heating program. I found in your git repo this script:
val ebusAction = getActions("ebus","ebus:bridge:<uid>")
val values = newLinkedHashMap(
'temp_d_lead_water' -> 45.5,
'temp_d_srv_water' -> 40.0,
'turnoff_water_heating' -> true,
'turnoffservice_water_heating' -> true
)
ebusAction.sendCommand("bai", "boiler.control.setopdata", "00", values)
Can I use this to set the heating program (standby/auto/etc.)? I have tried it like that, but no luck.
val ebusAction = getActions("ebus","ebus:bridge:873224b9")
val values = newLinkedHashMap(
'bm2_heating_program-heating-circuit' -> 1
)
ebusAction.sendCommand("bai", "boiler.control.setopdata", "35", values)
Any hints, how to figure out the correct parameters?
Thanks, Sven
Ok, I read again the excellent readme in your github repo and found out, which parameters were wrong:
val ebusAction = getActions("ebus","ebus:bridge:873224b9")
val values = newLinkedHashMap(
'program' -> 1
)
//"mapping": {"0": "standby", "1": "auto", "2": "heating mode", "3":"economy mode"}
ebusAction.sendCommand("bm2", "heating.program_heating_circuit", "00", values)
The third parameter is the destination address. Where do I get this? Is it the slave address?
Hello @sven,
It depends on the message type. For a master-slave it is the slave address, for a broadcast or master-master it is the master address. I’m not sure but it is possible that the command translates a master to slave and vise versa if it is wrong !?
But can’t you directly set the value to the connected item?
Here my BM2 configuration. Mhhh, maybe not perfect configured as string 
My sitemap entry
Selection item=HU_Program_HC label="Prog. Heizung [%s]" mappings=[0="Standby",1="Automatik",2="Heizbetrieb",3="Sparbetrieb"]
My item
String HU_Program_HC "Programm Heizkreis [MAP(hu_heat_prog_de.map):%s]" <control> (HeatingUnit) {channel="ebus:bm2:home:35:bm2_heating_program-heating-circuit#program"}
My mapping
-=Unbekannt
NULL=Unbekannt
0=Standby
1=Automatik
2=Heizbetrieb
3=Sparbetrieb
UNDEF=undefiniert
Hello All,
It’s been a bit quiet around the project as I’m currently re-setting up the entire setup. There will be an automatic build process. The maven repositories are now populated correctly.
As a further step I have introduced null pointer annotations and fixed many potential null point exceptions. Additionally the project will be monitored by more quality checks.
As a further step the Binding Repository was separated from the openHAB Addons2 Repository to have no dependencies. Now it contains only the eBus binding and its commits.
That was a lot of code line changes. But I have been using the new version successfully for several days now.
I have also done the migration to openHAB 3.0. But the release has to wait until version 2.5 is completely finished.
I’ve tried that, but it did not work. In the logs I see the following messages:
2020-12-20 10:09:03.408 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0x07 is not equal to send byte 0x4F! Stop send attempt …
2020-12-20 10:09:03.583 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0x43 is not equal to send byte 0x4F! Stop send attempt …
2020-12-20 10:09:03.839 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0x43 is not equal to send byte 0x4F! Stop send attempt …
2020-12-20 10:09:04.095 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0x43 is not equal to send byte 0x4F! Stop send attempt …
2020-12-20 10:09:04.347 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0x09 is not equal to send byte 0x4F! Stop send attempt …
2020-12-20 10:09:04.778 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0x44 is not equal to send byte 0x4F! Stop send attempt …
After setting the level to debug, I see the following log messages:
2020-12-20 10:14:57.440 [DEBUG] [s.internal.handler.EBusBridgeHandler] - eBUS telegram error; Slave answered with D5 [ERROR: UNEXPECTED_RESPONSE, DATA: FF 30 50 23 09 30 74 27 00 00 5D 01 00 00 4F D5]
2020-12-20 10:14:57.601 [DEBUG] [s.internal.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: FF 30 50 23 09 30 74 27 00 00 5D 01 00 00 4F]
2020-12-20 10:14:57.766 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0xD1 is not equal to send byte 0x00! Stop send attempt …
2020-12-20 10:14:57.951 [DEBUG] [s.internal.handler.EBusBridgeHandler] - eBUS telegram error; Slave answered with D5 [ERROR: UNEXPECTED_RESPONSE, DATA: FF 30 50 23 09 30 74 27 00 00 5D 01 00 00 4F D5]
2020-12-20 10:14:58.097 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0x0F is not equal to send byte 0x4F! Stop send attempt …
2020-12-20 10:14:58.102 [DEBUG] [s.internal.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! F5 [ERROR: INVALID_SOURCE_ADDRESS, DATA: 30 08 50 22 03 CC 17 27 1A 00 02 00 80 AC 00 00 AA 00 80 00 80 00 88 28 49 00 00 0A 00 A4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
2020-12-20 10:14:58.280 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0x4E is not equal to send byte 0x00! Stop send attempt …
2020-12-20 10:14:58.440 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0x4B is not equal to send byte 0x4F! Stop send attempt …
2020-12-20 10:14:58.536 [DEBUG] [s.internal.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: FF AA]
2020-12-20 10:14:58.696 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0x43 is not equal to send byte 0x4F! Stop send attempt …
2020-12-20 10:14:58.792 [DEBUG] [s.internal.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: FF AA]
2020-12-20 10:14:58.889 [DEBUG] [s.internal.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! 50 [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]
2020-12-20 10:14:58.921 [DEBUG] [s.internal.handler.EBusBridgeHandler] - eBUS telegram error; Master CRC invalid! IS:94 SHOULD:19 [ERROR: MASTER_CRC_INVALID, DATA: 30 50 14 07 03 80 29 00 19]
2020-12-20 10:14:59.080 [DEBUG] [s.internal.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: FF 30 50 23 09 30 74 27 00 00 5D 01 00 00 4F]
2020-12-20 10:14:59.083 [DEBUG] [s.internal.handler.EBusBridgeHandler] - eBUS telegram error; Unable to send telegram FF 30 50 23 09 30 74 27 00 00 5D 01 00 00 4F after 10 attempts … [ERROR: TOO_MANY_ATTEMPS, DATA: FF 30 50 23 09 30 74 27 00 00 5D 01 00 00 4F]
Do you have any hint, what could be wrong?
Hello @sven,
It looks like your adapter is not able to write to the bus. Could you try to reduce the FTDI Serial Buffer from 16 to 1ms? If you use an FTDI serial usb converter! Or you must adjust the adapter level !? And you can switch to another serial driver in the binding configuration, maybe it helps you …
echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
A new release if ready for download. I’ll create a nicer release info after Christmas.
The release uses a new version to prevent conflicts with Openhab.
The new binding 2.50.9 is, similar to version 2.5.1.8, not able to connect the esera Ethernet eBus bridge. Binding 2.5.1.7 connects the bridge immediately. Already reported this behavior in October earlier.
Mh, I thought it is also fixed. Okay , I’ll check that.
not able to use the new version:
WARN ] [ore.thing.internal.ThingRegistryImpl] - Cannot create thing. No binding found that supports creating a thing of type ‘ebus:bridge’
rollback to version org.openhab.binding.ebus-2.5.1-8.kar
Do you have restarted the server? Which server version? Win/Linux?
yes restarted openhab2 ; I’m using on raspberry
now I’ve checked this version on a a fresh openhab 2.5.11 installation (win) . I was able to install and run the binding.I’ve used a ethernet connection to the USB converter via socat to emulate an ethernet connection. Everything works fine with one exception, the binding restarts on every TCP reconnect approx every 2-5mins. Maybe another issue …
I think that this could be an cache issue.
Can you please set the log level to debug with the command log:set DEBUG org.openhab.binding.ebus and log:set DEBUG de.cs-dev.ebus. Please restart your server afterwards. Then please extract the ebus log messages and post it here or send me a complete log file from the start + 5mins as a private message.
My example
20:07:34.734 [WARN ] [.internal.things.EBusTypeProviderImpl] - eBUS command boiler.control.setopdata only contains a setter channel!
20:07:34.745 [DEBUG] [.internal.things.EBusTypeProviderImpl] - Generated all eBUS command collections ...
20:07:34.760 [INFO ] [ding.ebus.internal.EBusHandlerFactory] - Use eBUS binding 2.50.9 [eBUS core: 1.1.3, eBUS configuration: 1.1.3]
20:07:34.761 [INFO ] [ding.ebus.internal.EBusHandlerFactory] - eBUS core -> timestamp 202012251830, commit: #a40a200, build-no: #null
20:07:34.762 [INFO ] [ding.ebus.internal.EBusHandlerFactory] - eBUS configuration -> timestamp 202012251847, commit: #0cafc13, build-no: #null
20:08:19.937 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'ebus:bridge:305d53c7' changed from UNINITIALIZED to INITIALIZING
20:08:19.949 [DEBUG] [nternal.services.EBusDiscoveryService] - Start eBUS discovery service ...
20:08:19.972 [DEBUG] [us.internal.handler.EBusBridgeHandler] - Received telegram from address FF to 08 with command wpm.temp_dhw
20:08:19.974 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'ebus:bridge:305d53c7' changed from INITIALIZING to ONLINE
20:08:19.973 [DEBUG] [us.internal.handler.EBusBridgeHandler] - Received telegram from address FF to 08 with command heating.temp_flow
20:08:19.972 [DEBUG] [us.internal.handler.EBusBridgeHandler] - Received telegram from address FF to 08 with command heating.temp_return
20:08:19.974 [INFO ] [ig.discovery.internal.PersistentInbox] - Added new thing 'ebus:std:305d53c7:04' to inbox.
20:08:19.974 [DEBUG] [us.internal.handler.EBusBridgeHandler] - No handler has accepted the command wpm.temp_dhw from FF to 08 ...
20:08:19.974 [DEBUG] [us.internal.handler.EBusBridgeHandler] - Received telegram from address FF to 08 with command boiler.modulation
20:08:19.976 [DEBUG] [us.internal.handler.EBusBridgeHandler] - Received telegram from address FF to 08 with command dhw.temp_dhw
20:08:19.975 [DEBUG] [us.internal.handler.EBusBridgeHandler] - No handler has accepted the command heating.temp_return from FF to 08 ...
20:08:19.975 [INFO ] [smarthome.event.InboxAddedEvent ] - Discovery Result with UID 'ebus:std:305d53c7:04' has been added.
20:08:19.975 [DEBUG] [us.internal.handler.EBusBridgeHandler] - No handler has accepted the command heating.temp_flow from FF to 08 ...
20:08:19.977 [INFO ] [smarthome.event.InboxAddedEvent ] - Discovery Result with UID 'ebus:std:305d53c7:08' has been added.
20:08:19.976 [DEBUG] [us.internal.handler.EBusBridgeHandler] - Received telegram from address FF to 08 with command dhw.temp_return
20:08:19.976 [DEBUG] [us.internal.handler.EBusBridgeHandler] - No handler has accepted the command dhw.temp_dhw from FF to 08 ...
20:08:19.976 [DEBUG] [us.internal.handler.EBusBridgeHandler] - No handler has accepted the command boiler.modulation from FF to 08 ...
20:08:19.976 [INFO ] [ig.discovery.internal.PersistentInbox] - Added new thing 'ebus:std:305d53c7:08' to inbox.
20:08:19.977 [DEBUG] [us.internal.handler.EBusBridgeHandler] - No handler has accepted the command dhw.temp_return from FF to 08 ...
20:08:19.977 [DEBUG] [us.internal.handler.EBusBridgeHandler] - Received telegram from address FF to 08 with command dhw.temp_flow
20:08:19.979 [DEBUG] [us.internal.handler.EBusBridgeHandler] - No handler has accepted the command dhw.temp_flow from FF to 08 ...
20:08:19.979 [INFO ] [ig.discovery.internal.PersistentInbox] - Added new thing 'ebus:std:305d53c7:76' to inbox.
20:08:19.979 [INFO ] [smarthome.event.InboxAddedEvent ] - Discovery Result with UID 'ebus:std:305d53c7:76' has been added.
Maybe the output of both commands are helpful for debugging
bundle:list org.openhab.binding.ebus
feature:list
Okay, the snapshot is already finished today 
.
I’m not sure if the direct link works: https://github.com/csowada/openhab-ebus-binding/suites/1728664762/artifacts/32730001
If not, could you please download and extract the “artifact-kar” from the last build.