[eBUS 2.0] New binding - Release Candidate 7b

csowada · January 23, 2018, 1:26pm

the network connection is not for an ebusd deamon. It is for the ethernet interface or an wrapped serial to ethernet connection like socat or ser2net. And you use habmin? No idea if this works, please try PaperUI.

csowada · January 23, 2018, 1:37pm

I try to support the last special Vaillant datatypes for a next release. The datetime should be fixed in the last snapshot, but I’m working on the date/time datatypes.

The json file format is very similar, so converting should be easy.

Compare 1.x binding to

github.com

openhab/openhab1-addons/blob/main/bundles/binding/org.openhab.binding.ebus/src/main/resources/vaillant-vrc430-configuration.json

[
    {
        "comment": "<Controller> Displayed room temperature (°C)",
        "device":  "Vaillant VRC 430",
        "id":      "temp_room_disp",
        "class":   "controller",
        "command": "B5 09",
        "data":    "0D 80 00",
        "dst":     "15",

        "values": {
            "temp_room_disp": {"type": "data2c", "pos": 12, "label": "Room temperature"}
        }
    },

    {
        "comment": "<Controller> Raw room temperature (°C)",
        "device":  "Vaillant VRC 430",
        "id":      "temp_room",
        "class":   "controller",

This file has been truncated. show original

to 2.x binding

github.com

csowada/ebus-configuration/blob/master/src/main/resources/commands/vaillant-vrc-configuration.json

{
    "id":           "vrc430",
    "vendor":       "Vaillant",
    "label":        "Vaillant VRC 430(f)/470(f)",
    "description":  "Programming unit Vaillant VRC 430, 430f, 470 and 470f",

    "authors":      [
                    "Christian Sowada, opensource@cs-dev.de",
                    "Christophe P @ openhab community"
                    ],

    "identification": [
                    "34 33 30 30 30",
                    "34 37 30 30 30",
                    "46 34 37 30 30",
                    "46 34 33 30 30"
                    ],

    "commands":
    [

This file has been truncated. show original

The configuration switched from absolute positions to gapless ordered values like in ebusd.

dkuschmierz · January 23, 2018, 9:37pm

@csowada

Hi,

one question regarding the configuration files. Does the broadcast type only recognise commands which are real broadcast messages (FF) or can i use the broadcast type as a sniffer? There are a lot of messages on the bus which i could sniff instead of using the corresponding get-commands?

ChrisPe · January 24, 2018, 1:36pm

From what I saw during my tests with the broadcast messages, only real messages (with master = FF) are captured by the broadcast type…

However, using the log trace from the advance setting is very convenient to make trace of all valid telegrams. Then you can import the csv file in Excel and use pivot table to determine every kind of messages exchanged on the bus.

ihtgtwtd · January 25, 2018, 5:43pm

Hi @csowada
thanks, I think I misunderstood some things the ebus connector is now connected via serial interface and the bridge is online. Thanks for this awesome work!

mikulaos · January 26, 2018, 1:03am

Configuration files for the VRC700 can be used. They are not released yet, so it might be good to try and report any issues. If you want to test it, please look for download link here: [eBUS 2.0] Configuration support/contribution

andi_x · January 26, 2018, 6:45pm

well … i updated to the latest snapshot from 25.01.2018.
i found immediately new things in my inbox: vaillant vrc 700 (H)VAC, general, heating circuit 1 and 2, hot water circuit, zone 1 and 2.
yeah - vrc700 - this is mine
i have choosen a pooling with 180 secs and after a view minutes a lot of the items gets the data.

then i realized there is something missing, my outside temp and the datetime (normaly this values are broadcasted).
next step was to stop all the polling, rebooting my raspberry and checking again the logs - still no broadcasts

i was on version 2017-12-04 (alpha 14) before with the VRC 430, so i tried to add the thing VRC 430 with the new binding version, but still the same - no more broadcast ?

well - i’m sure i did something wrong, but i have no idea.

i moved back to alpha 14, vrc 430 -> and the broadcasts are back again (but funny - all the new VRC700 things are still available)

2018-01-26 19:18:53.419 [vent.ItemStateChangedEvent] - ebus_vrc430_a916041f_vrc430_controller_bc_temp_outside_temp_outside changed from 6 to 5.8125

2018-01-26 19:19:50.666 [vent.ItemStateChangedEvent] - ebus_vrc430_a916041f_vrc430_controller_bc_datetime_datetime changed from 2018-01-26T19:18:50.000+0100 to 2018-01-26T19:19:50.000+0100

here we go: question 1: any suggestions what i did wrong, about the missing broadcasts?

question 2: i got data for general stuff, hot water and my zone 1 / heating circuit 1; but what is the (H)VAC file ???

great amazing work @csowada @mikulaos there is a lot of time in this project, thank you guys.

update: ok, i found the json files now and there are some commands missing in the new vrc700 files
"B5 16" controller.bc.temp_outside and controller.bc.datetime … ?
did i have to add the vrc700 and vrc430 things?

mikulaos · January 26, 2018, 8:05pm

What weather sensor are you using? VRC693 or VRC9535?
I am using VRC693 and my VRC700 is not broadcasting anything.
VRC 9535 gets radio time code from DCF station. I’m sure that is difference.
Could you, please, provide raw telegrams for this broadcast from ebus-unresolved and I will add it to VRC700 general configuration file. Have you noticed some other issues?

FYI: You can read date, time and outside temperature from VRC700 anyway. It is in VRC700-general thing (gen.date, gen.time, gen.display_outside)

andi_x · January 26, 2018, 8:13pm

how can i figure out my sensor? i only know there is a dcf station and the temperature sensor outside in the box.
but depending on the google pictures, it should be a VRC9535.

about the raw telegrams, yes i can do that. could you please just explain in which way i should do it?
i know how to change the log level of the binding, but i think there is a way to get the telegrams in a csv file?

update:

Date/Time;SRC;DST;CMD;REMAIN_DATA;
2018-01-26 21:16:17;"10";"FE";"B5 16";"08 00 16 16 21 26 01 05 18 D5 AA";BROADCAST > vrc430.controller.bc.datetime
2018-01-26 21:16:18;"FF";"15";"07 04";"00 0B 00 0A B5 37 30 30 30 30 01 10 21 03 D8 00";GET > std.common.identification
2018-01-26 21:16:18;"FF";"15";"07 04";"00 0B 00 0A B5 37 30 30 30 30 01 10 21 03 D8 00";GET > vr90.controller.identification
2018-01-26 21:16:18;"FF";"15";"07 04";"00 0B 00 0A B5 37 30 30 30 30 01 10 21 03 D8 00";GET > pmw.pmw.identification
2018-01-26 21:16:20;"10";"FE";"B5 16";"03 01 80 04 D3 AA";BROADCAST > vrc430.controller.bc.temp_outside
2018-01-26 21:17:17;"10";"FE";"B5 16";"08 00 17 17 21 26 01 05 18 CD AA";BROADCAST > vrc430.controller.bc.datetime
2018-01-26 21:17:20;"10";"FE";"B5 16";"03 01 40 04 10 AA";BROADCAST > vrc430.controller.bc.temp_outside
2018-01-26 21:18:20;"10";"FE";"B5 16";"03 01 40 04 10 AA";BROADCAST > vrc430.controller.bc.temp_outside
2018-01-26 21:19:18;"10";"FE";"B5 16";"08 00 18 19 21 26 01 05 18 A0 AA";BROADCAST > vrc430.controller.bc.datetime
2018-01-26 21:19:21;"10";"FE";"B5 16";"03 01 40 04 10 AA";BROADCAST > vrc430.controller.bc.temp_outside

this is what i get with the alpha 14 and the vrc430, hope that is what you need?

mikulaos · January 26, 2018, 8:27pm

If you get readings in openhab then the vrc430 file is sufficient, but this is to see if there are any differences. Have you noticed some other issues regarding the VRC700 configuration? Maybe we should move this conversation to [eBUS 2.0] Configuration support/contribution?

andi_x · January 26, 2018, 9:13pm

no other issues until now, just the broadcast thing.

i recognize some errors in the log, but i will do a fresh and clean setup and check again
(i moved between alpha 14 and the latest snapshot several times today, not sure everything was fine at this time)

2018-01-26 18:49:23.500 [ERROR] [e.csdev.ebus.core.EBusControllerBase] - Error while firing onTelegramReceived events!
java.lang.NumberFormatException: null
        at java.math.BigDecimal.<init>(BigDecimal.java:494) [?:?]
        at java.math.BigDecimal.<init>(BigDecimal.java:383) [?:?]
        at java.math.BigDecimal.<init>(BigDecimal.java:806) [?:?]
        at java.math.BigDecimal.valueOf(BigDecimal.java:1274) [?:?]
        at de.csdev.ebus.command.datatypes.std.EBusTypeFloat.decodeInt(EBusTypeFloat.java:43) [239:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.datatypes.std.EBusTypeFloat.decodeInt(EBusTypeFloat.java:24) [239:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.datatypes.EBusAbstractType.decode(EBusAbstractType.java:102) [239:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.EBusCommandUtils.decodeValueList(EBusCommandUtils.java:374) [239:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.command.EBusCommandUtils.decodeTelegram(EBusCommandUtils.java:426) [239:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.service.parser.EBusParserService.onTelegramReceived(EBusParserService.java:94) [239:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.core.EBusControllerBase$2.run(EBusControllerBase.java:102) [239:de.csdev.ebus.ebus-core:0.9.16.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) [?:?]

2018-01-26 18:58:45.825 [ERROR] [bus.service.parser.EBusParserService] - Error while firing onTelegramResolved events!
java.lang.NullPointerException: null
        at org.openhab.binding.ebus.handler.EBusHandler.supportsTelegram(EBusHandler.java:342) [240:org.openhab.binding.ebus:2.2.0.201801251907]
        at org.openhab.binding.ebus.handler.EBusBridgeHandler.onTelegramResolved(EBusBridgeHandler.java:268) [240:org.openhab.binding.ebus:2.2.0.201801251907]
        at de.csdev.ebus.service.parser.EBusParserService.fireOnTelegramResolved(EBusParserService.java:115) [239:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.service.parser.EBusParserService.onTelegramReceived(EBusParserService.java:95) [239:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.core.EBusControllerBase$2.run(EBusControllerBase.java:102) [239:de.csdev.ebus.ebus-core:0.9.16.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) [?:?]

2018-01-26 18:58:48.755 [ERROR] [bus.service.parser.EBusParserService] - Error while firing onTelegramResolved events!
java.lang.NullPointerException: null
        at org.openhab.binding.ebus.handler.EBusHandler.supportsTelegram(EBusHandler.java:342) [240:org.openhab.binding.ebus:2.2.0.201801251907]
        at org.openhab.binding.ebus.handler.EBusBridgeHandler.onTelegramResolved(EBusBridgeHandler.java:268) [240:org.openhab.binding.ebus:2.2.0.201801251907]
        at de.csdev.ebus.service.parser.EBusParserService.fireOnTelegramResolved(EBusParserService.java:115) [239:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.service.parser.EBusParserService.onTelegramReceived(EBusParserService.java:95) [239:de.csdev.ebus.ebus-core:0.9.16.SNAPSHOT]
        at de.csdev.ebus.core.EBusControllerBase$2.run(EBusControllerBase.java:102) [239:de.csdev.ebus.ebus-core:0.9.16.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) [?:?]

and still some messages about the message queue:

2018-01-26 18:43:48.546 [ERROR] [de.csdev.ebus.core.EBusQueue        ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2018-01-26 18:43:59.570 [ERROR] [de.csdev.ebus.core.EBusQueue        ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2018-01-26 18:44:39.560 [ERROR] [de.csdev.ebus.core.EBusQueue        ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2018-01-26 18:45:11.992 [ERROR] [de.csdev.ebus.core.EBusQueue        ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2018-01-26 18:45:43.543 [ERROR] [de.csdev.ebus.core.EBusQueue        ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2018-01-26 18:46:56.514 [ERROR] [de.csdev.ebus.core.EBusQueue        ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2018-01-26 18:47:09.592 [ERROR] [de.csdev.ebus.core.EBusQueue        ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.
2018-01-26 18:48:01.976 [ERROR] [de.csdev.ebus.core.EBusQueue        ] - Send queue is full! The eBUS service will reset the queue to ensure proper operation.

maybe a problem of the massive polling or the esera ebus gateway.
same with that issue, i will check again with a fresh clean setup.

ChrisPe · January 27, 2018, 4:37pm

Finally received the ebus 2 adapter developed by FHEM team, and it’s working very well.

I have now an error rate around 12.5% (instead of 75% with the esera commercial ethernet coupler.). My boiler and controller was detected out of the box on first try, seems like I will be able to work on unidentified telegram again

dasebi · February 9, 2018, 11:43am

Hi Benn,
How far are you with your json file for the 620?
I’m trying to get my auromatic 560 working.
Could you post your json parser?
Thanks
Sebastian

ChrisPe · February 10, 2018, 11:04am

Hi @csowada

I still have the issue that if the ebus controller get disconnected for whatever reason, the binding just stop there collecting data and does not reconnect automatically.

I wonder if adding udp support to the controller, instead of just TCP, could be an elegant way to fix that.
UDP, is sessionless and is supported on the esera coupler as well as the ebusd-esp provided with the FHEM ebus adaptor v2.

In addition, udp would be slighly less sensitive to latency.

Can this be a possible enhancement ?

tkropf · February 10, 2018, 11:48pm

Hi @csowada

first a big thank you for your binding. I installed it and it immediately autodiscovered at least some of my Wolf components. I do have a Wolf, CGB-24, MM, BM2 and SM1.
Thus I was able to put e.g. outside and hot water temperature on my KNX bus. Really great.

Two questions remain:

is there any way to initiate a command to activate an immediate hot water heating, in German called “Speicherladung”?
There are quite some error messages in the log file, e.g. “No handler has accepted the command boiler.modulation from FF to 08 …”. Same for command boiler.starts, command boiler.runtime, boiler.modulation and some others. Any ideas how to fix this?

By the way, I am using the eBus Adapter Version 2.0 from the fhem community - works like a charm!

Thanks
Thomas

andi_x · February 17, 2018, 12:05pm

Hi,
i’ve on my testsystem a 2nd ebus adapter for testing issues.
as i understand it’s not possible to have 2 gateways with the same ebus Master address on the bus.

so on my production system i’ve FF as master adress and on my testing system i was trying another adress.

there are 2 issues:

i got always a error 500 if i change the existing bridge master adress.
–> no problem, i can remove the bridge and add it again without that error,
but there is another problem:
OFFLINE - CONFIGURATION_ERROR eBUS master address is not a valid master address!

is FF the only valid master adress?

thanks

Benny · February 18, 2018, 12:44pm

Hi, sorry for the late answer,
vaillant-vrc620-configuration.json (3.9 KB)

Benny

csowada · February 18, 2018, 8:20pm

Hello @andi_x,

you could also use 00

andi_x · February 19, 2018, 7:11pm

Hi,

00 work … but only for a few minutes, then my vaillant is going in an error mode.
it seems there is another problem if i have 2 ebus adapters at the same time online.

csowada · February 19, 2018, 8:14pm

Maybe also ``00` is already used,

you could try 01 or 31. I use the master list from the pdf file Spec_Prot_7_V1_6_1_Anhang_Ausgabe_1.pdf.