[eBUS 2.0] New binding - Release Candidate 7b

witek_1308 · October 20, 2017, 11:58am

I’ve just installed Alpha 11 and don’t see any change in own parsers (ie. what worked works now, what didn’t work for me - still doesn’t). For example I tried to get HC2 Heating Curve from mixer (device 50) and polling is fine but can’t get value
2017-10-20 13:51:35.243 [INFO ] [hab.binding.ebus.handler.EBusHandler] - Poll command “ebus:custom-vr61:8643da98:custom-vr61_heating_temp-hcurve2#temp-hcurve” with “FF 50 B5 09 03 0D 15 00 26” …

same for heating hours for DHW from BAI (heating hours for HC works fine from same device so I expected the same to be for DHW, I don’t think there is a mistake in the parser as I’ve taken same thing as for working HC hours).

Interestingly binding discovers my mixer (address of 50) but within there are only standard ebus things, nothing which will be interesting for me like curve, pump state, etc.
I hope you’ll find time one day @csowada to have a look what’s wrong.

openhab> smarthome:ebus devices
MA | SA | Identifier     | Device         | Manufacture          | ID | Firmware   | Hardware   | Last Activity
---+----+----------------+----------------+----------------------+----+------------+------------+---------------------
FF | 04 |                | <interface>    | eBUS Library         |    | null       | null       | ---
   | 50 | 56 36 31 30 30 | ---            | null                 | B5 | 4.18       | 19.02      | Fri Oct 20 13:59:41 CEST 2017
10 | 15 | 34 37 30 30 30 | vrc430         | null                 | B5 | 4.2        | 14.03      | Fri Oct 20 13:59:41 CEST 2017
70 | 75 | 56 38 31 30 30 | vr81           | null                 | B5 | 2.02       | 25.02      | Fri Oct 20 13:54:19 CEST 2017
03 | 08 | 42 41 49 30 30 | ---            | null                 | B5 | 6.08       | 55.02      | Fri Oct 20 13:59:40 CEST 2017
----------------------------------------------------------------------------------------------------------------------
MA = Master Address / SA = Slave Address / ID = Manufacture ID

csowada · October 20, 2017, 12:11pm

Thank you, I’ve fixed the url in my first post.

csowada · October 20, 2017, 2:58pm

I think that not all devices have the same send-signal quality, so you can receive the strong master telegram but not the weak slave answer.
And you long cables could work as large antenna, because the wires have no shield !? Together with a weak device this could be a problem?

csowada · October 20, 2017, 3:04pm

Could you send me please a new log with debug level and the custom parser that not work. I will check this with the newest version.

This is the default behavior of the discovery function, it always add eBUS Standard thing to the inbox and if the device was identified it also put the specific thing to the inbox.

petxya · October 20, 2017, 7:31pm

Hello guys,

Can someone please help me out… I am getting these errors while no data shown in Paper UI except for Vendor, Device ID, Software Version and Hardware Version. eBus Bridge configured, master address set to FF. What am I doing wrong??

21:10:45.500 [ERROR] [.ebus.service.device.EBusDeviceTable] - ups, no master address!
21:10:45.501 [INFO ] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from address 10 to 50 with command common.identification
21:10:45.502 [TRACE] [hab.binding.ebus.handler.EBusHandler] - eBUS node handler doesn’t support this collection id …
21:10:47.968 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: 10 EC 07 04 00 D4]

Automatically discovered by eBus binding (Alpha11):

What I actually have:

Vaillant VRC470f Controller
Vaillant VR61/4 Mixer module
Vaillant VR81 Room thermostat
Vaillant ecoTEC pro boiler

esera eBus - LAN gateway

Peter

ChrisPe · October 20, 2017, 11:12pm

Well, I made lots of test and feel ever more confused now.

So I tested:

Change cable to a new 2*0.75 mm2.
Boiler alone connected to the ebus coupler.
Boiler alone connected to the ebus coupler with only 25 cm wire.
Captured raw data from ebusd during debug, with a tail -F on the raw log file.

So once the trimmer is well adjusted on the ebus coupler, connected to the boiler only with the short wire, each time I made a scan 08 from ebus, I get this exchange:

2017-10-20 23:40:04.530 >3108070400d1<0ab54241493030051074012f

It looks like the first byte of the answer is lost !

But with the VRC470 connected, I have a different answer:

2017-10-21 00:06:01.618 >3108070400d1<0ab54241493030051874012f

And 2 times I had what seems almost a proper answer, which is when I guess the boiler was properly identified.

2017-10-20 22:40:28.097 >3108070400d1<000ab54241493030051874012f>00

I have then a full trace of the boiler being powered on, then I went to the VRC470 to browse most of the menues to list the settings. Would that be helpfull ?

I’m out of idea now.

And FYI, with the version 11 I had once (and only once) the boiler detected automatically. I’ll let that run for the night.

csowada · October 21, 2017, 11:31am

It looks like the auto discovery doesn’t recognize you devices, but you can add you devices manually, add a Vaillant BAI00 device with slave address 08 and a Vaillant VRC4x0 with master address 15 etc.

Can you please send your console output for smarthome:ebus devices and please use the code fence feature from the editor. It’s much easier to read logs and other output.

csowada · October 22, 2017, 1:02pm

Hello Testers,

I’ve released a new version. Below is the changelog attached. Keep in mind that it could be necessary to remove all things and restart the binding/openhab ot run auto discovery.

I’ve also worked on the documentation, so please have check the first post if you want to create custom parsers.

openHAB eBUS 2.0 binding - Alpha 0.0.12 (2017-10-22)

Features:

Update to eBUS library 0.0.12, github
Smaller changes

Bugfixes:

Change item type from number to string if options are used

eBUS core library - Alpha 0.0.12 (2017-10-22)

Features:

new data types date and time for variable length signed / unsigned numbers
more source code documentation
enhance logging on firing event handler s

Bugfixes:

fix issue if master/slave CRCs are escaped
fix ignored properties for some non-standard properties in json files
adjust some maven build properties
fix and enhance manufacture id/name mapping

Configurations:

add date and time to Vaillant VRC470
fix identifier for Vailant BAI00

csowada · October 22, 2017, 1:11pm

Hello @ChrisPe,

I’ve checked your telegrams and and the first one has a wrong byte, so the whole telegram is invalid because of the wrong slave crc.

Here are the Acknowledge byte from master and slave missing.

Here is everything fine.

You should adjust your adapter after any change to your ebus network. It is a shared medium and the voltage of the bus could change.

Can you check your adapter with this manual ? The manual is in German language, but you can look at the screenshots or use a translator.

https://www.esera.de/media/pdf/f7/9d/88/12002-Konfiguration-eBus-Koppler-Ethernet-V1-2.pdf

Kristo · October 22, 2017, 4:48pm

Hello @csowada,

Thank you for updates, i see detection of Bai is corrected in Vaillant i have only issue with VRC 470 which is not discovered in my system and i see twice VR68 1st Slave EC 2nd Slave A0


openhab> smarthome:ebus devices
MA | SA | Identifier     | Device         | Manufacture          | ID | Firmware   | Hardware   | Last Activity
---+----+----------------+----------------+----------------------+----+------------+------------+---------------------
FF | 04 |                | <interface>    | eBUS Library         |    | null       | null       | ---
   | EC | 73 6F 6C 30 30 | VR68           | Joh. Vaillant GmbH & Co. | B5 | 3.15       | 10.02      | Sun Oct 22 18:45:02 CEST 2017
03 | 08 | 42 41 49 30 30 | bai            | Joh. Vaillant GmbH & Co. | B5 | 5.18       | 74.01      | Sun Oct 22 18:45:00 CEST 2017
   | A0 | 73 6F 6C 30 30 | VR68           | Joh. Vaillant GmbH & Co. | B5 | 3.15       | 10.02      | Sun Oct 22 18:44:41 CEST 2017
----------------------------------------------------------------------------------------------------------------------
MA = Master Address / SA = Slave Address / ID = Manufacture ID

csowada · October 22, 2017, 7:11pm

Hello @Kristo,

You output looks good so far. I’m not an Vaillant expert but for me it looks like your solar module uses two different slave addresses. I have seen the same setup in the ebusd configurations. This is a new information for me, later on I must enhance the auto discovery to support such devices.

Regarding your VRC device, I would wait 10-20 minutes. The auto discovery only listen to the bus and add all unknown/new slave addresses to the table. Afterwards the auto discovery tries to get additional information from a slave to identify it.

ChrisPe · October 22, 2017, 8:07pm

Yes I tried to adjust the trimmer to several position after each test. I know that when the ebus led is either lit or off the signal is not transmitted so I stay between this 2 extreme position, close to the always lit position, close to the led off position, and several intermediate position, without any change of the behavior, from your binding or from ebusd scan 08…

Yes I double checked the configuration, Esera provided me an English version (here: https://www.eservice-online.de/media/pdf/a1/74/ac/12002-Manual-eBus-coppler-ETH.pdf )

and in addition I found the full documentation of the WIZ107SR on which the coupler is based.

The devices is detailed here: http://www.wiznet.io/product-item/wiz107sr/
The setup tool is detailed here: http://www.wiznet.io/wp-content/uploads/wiznethome/S2E%20Module/WIZ107_108SR/Document/WIZ107SR_UM.pdf
And even the network protocol to configure the coupler is detailed here: http://www.wiznet.io/wp-content/uploads/wiznethome/S2E%20Module/WIZ107_108SR/Document/WIZ107_108SR_AN_S2E-Programming-Guide_V100E.pdf

So my network configuration is this one:

The serial setting is configured like this:

And the option settings are like this:

ChrisPe · October 22, 2017, 8:17pm

I think there is an issue with the devices persistence.

I created manually several devices, after upgrading to alpha12, in addition to the bridge, I created a Standard thing, a BAI00 and a VRC470.
So using karaf, I can read devices and thing like this:

openhab> smarthome:ebus list
Thing UID                                | Label                                    | Type
-----------------------------------------+------------------------------------------+-----------
ebus:bridge:4957141a                     | eBUS Bridge                              | bridge
ebus:std:1104a534                        | eBUS Standard                            | node
ebus:bai:e29ed20e                        | Vaillant BAI00                           | node
ebus:vrc430:7d9d56d3                     | Vaillant VRC 430/470                     | node

openhab> smarthome:ebus devices
MA | SA | Identifier     | Device         | Manufacture          | ID | Firmware   | Hardware   | Last Activity
---+----+----------------+----------------+----------------------+----+------------+------------+---------------------
FF | 04 |                | <interface>    | eBUS Library         |    | null       | null       | ---
03 | 08 |                | ---            | null                 |    | null       | null       | Sun Oct 22 21:49:50 CEST 2017
----------------------------------------------------------------------------------------------------------------------
MA = Master Address / SA = Slave Address / ID = Manufacture ID

Then I manually delete them all,
I got this:

openhab> smarthome:ebus devices

openhab> smarthome:ebus list
Thing UID                                | Label                                    | Type
-----------------------------------------+------------------------------------------+-----------

But just after creating the bridge again, without anything auto-discovered, I still have the boiler reference remaining from a previous (lucky) detection:

openhab> smarthome:ebus list
Thing UID                                | Label                                    | Type
-----------------------------------------+------------------------------------------+-----------
ebus:bridge:17092881                     | eBUS Bridge                              | bridge

openhab> smarthome:ebus devices
MA | SA | Identifier     | Device         | Manufacture          | ID | Firmware   | Hardware   | Last Activity
---+----+----------------+----------------+----------------------+----+------------+------------+---------------------
FF | 04 |                | <interface>    | eBUS Library         |    | null       | null       | ---
03 | 08 |                | ---            | null                 |    | null       | null       | Sun Oct 22 22:10:55 CEST 2017
----------------------------------------------------------------------------------------------------------------------
MA = Master Address / SA = Slave Address / ID = Manufacture ID

The log show then:

2017-10-22 22:10:48.024 [ThingAddedEvent ] - Thing ‘ebus:bridge:17092881’ has been added.
2017-10-22 22:10:48.052 [hingStatusInfoChangedEvent] - ‘ebus:bridge:17092881’ changed from UNINITIALIZED to INITIALIZING
==> /var/log/openhab2/openhab.log <==
2017-10-22 22:10:48.061 [DEBUG] [org.openhab.binding.ebus ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=304, service.bundleid=193, service.scope=singleton} - org.openhab.binding.ebus
==> /var/log/openhab2/events.log <==
2017-10-22 22:10:48.081 [hingStatusInfoChangedEvent] - ‘ebus:bridge:17092881’ changed from INITIALIZING to ONLINE
==> /var/log/openhab2/openhab.log <==
2017-10-22 22:10:49.119 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Slave answered with 01 [ERROR: UNEXPECTED_RESPONSE, DATA: 10 08 B5 10 09 00 00 47 64 FF FF 00 00 00 6B 01]
2017-10-22 22:10:55.110 [ERROR] [.ebus.service.device.EBusDeviceTable] - Error while firing onEBusDeviceUpdate events!
java.lang.NullPointerException
at org.openhab.binding.ebus.internal.EBusDiscovery.updateDiscoveredThing(EBusDiscovery.java:85)[193:org.openhab.binding.ebus:2.2.0.201710221201]
at org.openhab.binding.ebus.internal.EBusDiscovery.onEBusDeviceUpdate(EBusDiscovery.java:118)[193:org.openhab.binding.ebus:2.2.0.201710221201]
at de.csdev.ebus.service.device.EBusDeviceTable.fireOnDeviceUpdate(EBusDeviceTable.java:166)[193:org.openhab.binding.ebus:2.2.0.201710221201]
at de.csdev.ebus.service.device.EBusDeviceTable.updateDevice(EBusDeviceTable.java:151)[193:org.openhab.binding.ebus:2.2.0.201710221201]
at de.csdev.ebus.service.device.EBusDeviceTableService.onTelegramReceived(EBusDeviceTableService.java:152)[193:org.openhab.binding.ebus:2.2.0.201710221201]
at de.csdev.ebus.core.EBusControllerBase$2.run(EBusControllerBase.java:101)[193:org.openhab.binding.ebus:2.2.0.201710221201]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_144]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_144]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_144]
2017-10-22 22:10:55.117 [INFO ] [ervice.device.EBusDeviceTableService] - DATA TABLE UPDATE EBusDevice [masterAddress=0x03, slaveAddress=0x08, lastActivity=1508703055109, manufacturer=null(null), deviceId=, softwareVersion=null, hardwareVersion=null]
2017-10-22 22:10:55.121 [WARN ] [ervice.device.EBusDeviceTableService] - Unable to load command with id common.identification
2017-10-22 22:10:57.195 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Slave answered with 05 [ERROR: UNEXPECTED_RESPONSE, DATA: 10 08 B5 11 01 02 8A 05]
2017-10-22 22:11:05.067 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Slave answered with 09 [ERROR: UNEXPECTED_RESPONSE, DATA: 10 08 B5 11 01 01 89 09]
2017-10-22 22:11:07.155 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Slave answered with 0A [ERROR: UNEXPECTED_RESPONSE, DATA: 10 08 B5 04 01 00 3D 0A]
2017-10-22 22:11:09.102 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: 03 64 B5 12 02 02 FE 98]

Kristo · October 22, 2017, 8:48pm

@csowada

After eaven 2 h no detection of VRC 470 so i added manually and just after automatic one was detected

but i see issue showing - eBUS Standard 15 & EC - what is reason of this automatic creation for any Slave adress detected if not connected with proper commands are least concerning Slave EC ?

Rest so far is working OK

For future if you can add pooling functionality to Items:

{channel="ebus:vrc430:home:vrc430_controller_temp-room#temp-room, refresh:50 "}

Mappings are not visible/working in ClasicUi or Android app when using Sitemap/ items

csowada · October 23, 2017, 11:31am

I’ve asked the question in the community and it looks like this is fixed in a nighly build. But I also run an older version to build this binding.

This is a feature, the discovery add all found slave addresses to the discovery inbox. At this time the binding has no knowledge about the specific device. Later on the binding get more information and can also add the specific commands to the discovery inbox. But for all unknown devices the Standard commands are better than nothing. In my case Wolf also uses standard command for the controller and mixer. So I can use the already send information instead of poll it again.

csowada · October 23, 2017, 1:24pm

You can add the polling to the channel via PaperUI and then use the channel with your Item. Or do you specially ask to add to feature also to the items file?

Kristo · October 23, 2017, 1:47pm

Better solution will be to add feature to items (when you are restoring openhab configuration by items & sitemap it will be faster)

petxya · October 23, 2017, 7:00pm

Hi Guys,

I’ve just installed Alpha 12. It automatically discovered my BAI00 (ecoTEC pro) and VR81, the VRC 430/470 I had to add manually. I have these error messages in the log:

18:43:00.848 [INFO ] [nding.ebus.handler.EBusBridgeHandler] - Received telegram from address 10 to 35 with command common.identification
18:43:00.850 [INFO ] [nding.ebus.handler.EBusBridgeHandler] - No handler has accepted the command common.identification from 10 to 35 ...
18:43:01.525 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: 10 75 07 04 00 E7]
18:43:02.270 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: 10 75 07 04 00 E7]
18:43:03.072 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: 10 75 07 04 00 E7]
18:45:25.383 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: 00 AA]
18:45:26.082 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: 03 64 B5 12 02 02 FE 98]
18:45:31.260 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: 03 64 B5 12 02 02 FE 98]
18:45:36.615 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: 03 64 B5 12 02 02 FE 98]
18:45:41.972 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: 03 64 B5 12 02 02 FE 98]
18:48:23.864 [DEBUG] [nding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; No response from slave! AA [ERROR: NO_SLAVE_RESPONSE, DATA: 10 08 B5 11 01 02 8A]```

Do you have any idea what might be wrong?

Another silly question: Should I see data immediately in PaperUI or should I poll each channel??

Peter

csowada · October 23, 2017, 7:25pm

So I’ve spend time to get it running with the current version. But this way is not very nice.
It looks like we are not able to set additional parameters to item files for channels.

.thing file

Bridge ebus:bridge:home [ serialPort="COM1" ]
{
    Thing sm1 08 [slaveAddress="08"] {
      Channels:
          Type sm1_solar_temp-cylinder-24h-max_temp-cylinder-24h-max : sm1_solar_temp-cylinder-24h-max#temp-cylinder-24h-max [
              polling = 25
          ]
    }
}

.item file

Number  SolarTemp24h  "Solar Temp. 24h"  {channel="ebus:sm1:home:08:sm1_solar_temp-cylinder-24h-max#temp-cylinder-24h-max"}

csowada · October 24, 2017, 10:43am

If you can see log messages are defined as DEBUG and this can always happen on the bus. A master device tries to communicate with a slave device that is not available in your setup. So this is only interesting if something went wrong.

But could you send me your device table please? Use smarthome:ebus devices on your console. This can help me with the auto discovery feature.