Hi Folks,
these changes should now be transferred to the official openhab repository.
Can you give me feedback as to whether these changes are working properly?
That would be wonderful.
Hello All
Finally I connected ebus -> tcp koppler to may vrc 430
My open openhab.cfg looks like this
ebus:hostname=vaillant
ebus:port=5000
ebus:parserUrl=${openhab_home}/configurations/ebus-config.json
ebus:parsers=vaillant,custom
and my simple item looks like this
Number e_Temp_Zew “Temp. outdoor [%.1f °C]” (Vaillant) { ebus=“id:controller.temp_outside, src:03”}
but I only get
2015-12-12 17:48:04.922 [WARN ] [.ebus.internal.utils.EBusUtils] - Unexpect ack value in EBus telegram, skip data!
Any idea what i doing wrong ???
Which version are you using?
With the new version the folowing should work for a polling item (B5 09)
Number e_Temp_Zew “Temp outside [%.1f °C]” { ebus=“id:controller.temp_outside.temp_outside, cmd:controller.temp_outside, dst:15, refresh:300” }
But you need this in one of your configs:
{
"comment": "<Controller> Outside temperature (°C)",
"device": "Vaillant VRC 470",
"id": "temp_outside",
"class": "controller",
"command": "B5 09",
"data": "0D 62 00",
"dst": "15",
"values": {
"temp_outside": {"type": "data2c", "pos": 12, "label": "Outside temperature"},
"status": {"type": "uchar", "pos": 14, "label": "Outside temperature status",
"mapping": {"0":"Ok", "85":"Circuit", "170":"Cutoff"}}
}
},
Alternatively, you can use the b5 11 commands
Number e_Temp_Zew “Temp outside [%.1f °C]” { ebus=“id:boiler_common.boiler_data.temp_outside” }
With this config (this was also available in the old version. I haven’t finished cleaning this up but the following should work)
{
"comment": "<Boiler> Boiler data",
"id": "boiler_data",
"class": "boiler_common",
"command": "B5 11",
"data": "01",
"dst": "08",
"values": {
"temp_flow": {"type": "data1c", "pos": 10, "label": "Flow temperature"},
"temp_return": {"type": "data1c", "pos": 11, "label": "Return temperature"},
"temp_outside": {"type": "data2b", "pos": 12, "label": "Outside temperature"}
}
},@csowada Where can i find the source of what you want to merge? I’ll check with my config again.
There used to be an error in my config for supply temp and the boiler modulation is actually the pump modulation (description is wrong in ebusd). So this should be checked.
I use 1.8 snapshot version binding
I use your file for vrc 430 and I rename it to ebus-config.json
I 'm afraid that the problem is in the ebus -> tcp coupler.
I use the trimmer to achieve good data. The led is blinking but in openhab.log i get now
[ERROR] [.b.e.i.c.AbstractEBusConnector] - eBus telegram buffer overflow - not enough sync bytes received! Try to adjust eBus adapter
I have no idea what can i do…
@nikoraes You can find all information here and the source here. It would be great if you could leave feedback at his topic.
@Tomek Could you try to connect with a terminal program like Realterm etc. to adjust your tcp coupler. Its important to see many 0xAA bytes. The led is not accurate enought. You also could increase the logging for the binding.
Hello @csowada
I set up ebusd on my RP2 and I get
2015-12-13 16:03:06.690 [update notice] unknown MS cmd: 1008b510090000005effff45ff00 / 0101
2015-12-13 16:03:14.949 [update notice] unknown BC cmd: 10feb505020400
2015-12-13 16:03:16.729 [update notice] unknown MS cmd: 1008b5100900002e5effff44ff00 / 0101
2015-12-13 16:03:26.851 [update notice] unknown MS cmd: 1008b5100900002e5effff44ff00 / 0101
2015-12-13 16:03:34.896 [update notice] unknown BC cmd: 10feb516080019031613120714
2015-12-13 16:03:36.926 [update notice] unknown MS cmd: 1008b5100900002e5effff44ff00 / 0101
2015-12-13 16:04:03.043 [update notice] unknown BC cmd: 10feb51603010006
2015-12-13 16:04:23.377 [update notice] unknown BC cmd: 10feb505020400
Could you tell me how I can connect to ebus coupletr using Realterm ?
I have this one https://www.eservice-online.de/produkte/ebus/142/ebus-koppler-ethernet
Regards
Tomek
Mh, I not know the logs from ebusd but it looks good so far. You should increase the logs for the ebus binding.
Here you can read what you must change: https://github.com/csowada/openhab/tree/ebus-update-pr1/bundles/binding/org.openhab.binding.ebus#logging
<configuration scan="true">
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS} %-5level %logger{30}[:%line] - %msg%n%ex{0}</pattern>
</encoder>
</appender>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>${openhab.logdir:-logs}/openhab.log</file>
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss} %-5level %logger{30}[:%line]- %msg%n%ex{5}</pattern>
</encoder>
</appender>
<appender name="EVENTFILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${openhab.logdir:-logs}/events.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- weekly rollover and archiving -->
<fileNamePattern>events-%d{yyyy-ww}.log.zip</fileNamePattern>
<!-- keep 30 days' worth of history -->
<maxHistory>30</maxHistory>
</rollingPolicy>
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss} - %msg%n</pattern>
</encoder>
</appender>
<logger name="runtime.busevents" level="WARN" additivity="false">
<appender-ref ref="EVENTFILE" />
<appender-ref ref="STDOUT" />
</logger>
<logger name="org.openhab" level="INFO"/>
<!-- this class gives an irrelevant warning at startup -->
<logger name="org.atmosphere.cpr.AtmosphereFramework" level="ERROR" />
<logger name="org.openhab.binding.ebus" level="TRACE" />
<!-- disable packet logging -->
<!-- temporary workaround for https://bugs.eclipse.org/bugs/show_bug.cgi?id=402750 -->
<logger name="OSGi" level="OFF" />
<root level="WARN">
<appender-ref ref="FILE" />
<appender-ref ref="STDOUT" />
</root>
</configuration>
But this causes heavy logs!
The log looks fine. You can see the non-polling items like b5 10, b5 16, … Somehow they are all sent from address 10 but this is normal.
I believe it’s just an issue with your item configuration. You were filtering everything from source 03, but nothing comes from 03, so you shouldn’t use the src filter normally.
Are you sure the definition you are referring to is available in your configuration?
I too get crc and ack errors sometimes, but it doesn’t mean that it doesn’t work.
I’ll try to review the configurations as soon as possible, but a busy last week at work ahead…
@csowada
So I have stopped ebusd and start openhab within ceased logging
I have got
19:18:51.510 [ERROR] [o.o.b.e.i.c.EBusTCPConnector :65 ] - java.net.ConnectException: Connection refused
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0]
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) ~[na:1.8.0]
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) ~[na:1.8.0]
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) ~[na:1.8.0]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[na:1.8.0]
at java.net.Socket.connect(Socket.java:589) ~[na:1.8.0]
at java.net.Socket.connect(Socket.java:538) ~[na:1.8.0]
at java.net.Socket.(Socket.java:434) ~[na:1.8.0]
at java.net.Socket.(Socket.java:211) ~[na:1.8.0]
at org.openhab.binding.ebus.internal.connection.EBusTCPConnector.connect(EBusTCPConnector.java:56) ~[bundlefile:na]
at org.openhab.binding.ebus.internal.connection.AbstractEBusConnector.reconnect(AbstractEBusConnector.java:163) [bundlefile:na]
at org.openhab.binding.ebus.internal.connection.AbstractEBusConnector.run(AbstractEBusConnector.java:197) [bundlefile:na]
Can you tell me how I can connect to ebus coupler with a terminal program like Realterm ?
@nikoraes
I think that I have problem to get valid data from bus coupler because I have only get connection refuse or eBus telegram buffer overflow - not enough sync bytes received! or Unexpect ack value in EBus telegram, skip data! I
Often such devices allows only one conection. Is the ebusd daemon really stopped?
Sorry my fault I do ps -ef|grep ebus but I kill another process…
Hi sorry to chip in here, am I right in thinking that you have the Ebus Koppler working with John30’s ebusd, and you are able to set the modulation on a Vaillant boiler from the Koppler? Or are you still using the VR430 vaillant controller, and just sniffing the protocol using the Koppler?
I currently control a Vaillant boiler (Ecotec plus 637) with just a relay to turn it on and off, and I tend to get a bit of overshoot. What I would like is to be able to set the modulation level, or the heating water temperature. Can you say if that works?
I’m thinking of buying a Koppler and paying an installer to connect it (assuming he’ll do it). But are we still at the stage of trying to guess the proprietary protocol between the official controller and the boiler?
Many thanks
Hagrid.
@csowada
Hi again. I increase logging and after few hours i get huge log.
So all log looks like this
08:24:21.202 [DEBUG] [.ebus.internal.parser.Analyses:300 ] - 10 08 B5 12 02 00 00 CA 00 00 00 00 AA
08:24:21.203 [DEBUG] [.ebus.internal.parser.Analyses:333 ] - >>> [Analyse] Vaillant: Pumpenstatus 2???
08:24:24.977 [WARN ] [.ebus.internal.utils.EBusUtils:399 ] - Unexpect ack value in EBus telegram, skip data!
08:24:24.978 [DEBUG] [.b.e.i.c.AbstractEBusConnector:297 ] - Received telegram was invalid, skip!
08:24:29.033 [WARN ] [.ebus.internal.utils.EBusUtils:399 ] - Unexpect ack value in EBus telegram, skip data!
08:24:29.034 [DEBUG] [.b.e.i.c.AbstractEBusConnector:297 ] - Received telegram was invalid, skip!
08:24:31.039 [WARN ] [.ebus.internal.utils.EBusUtils:399 ] - Unexpect ack value in EBus telegram, skip data!
08:24:31.040 [DEBUG] [.b.e.i.c.AbstractEBusConnector:297 ] - Received telegram was invalid, skip!
08:24:31.307 [WARN ] [.ebus.internal.utils.EBusUtils:399 ] - Unexpect ack value in EBus telegram, skip data!
08:24:31.308 [DEBUG] [.b.e.i.c.AbstractEBusConnector:297 ] - Received telegram was invalid, skip!
08:24:35.077 [WARN ] [.ebus.internal.utils.EBusUtils:399 ] - Unexpect ack value in EBus telegram, skip data!
08:24:35.078 [DEBUG] [.b.e.i.c.AbstractEBusConnector:297 ] - Received telegram was invalid, skip!
08:24:39.117 [WARN ] [.ebus.internal.utils.EBusUtils:399 ] - Unexpect ack value in EBus telegram, skip data!
08:24:39.118 [DEBUG] [.b.e.i.c.AbstractEBusConnector:297 ] - Received telegram was invalid, skip!
08:24:41.058 [WARN ] [.ebus.internal.utils.EBusUtils:399 ] - Unexpect ack value in EBus telegram, skip data!
08:24:41.059 [DEBUG] [.b.e.i.c.AbstractEBusConnector:297 ] - Received telegram was invalid, skip!
08:24:43.155 [WARN ] [.ebus.internal.utils.EBusUtils:399 ] - Unexpect ack value in EBus telegram, skip data!
08:24:43.156 [DEBUG] [.b.e.i.c.AbstractEBusConnector:297 ] - Received telegram was invalid, skip!
08:24:49.189 [WARN ] [.ebus.internal.utils.EBusUtils:399 ] - Unexpect ack value in EBus telegram, skip data!
08:24:49.190 [DEBUG] [.b.e.i.c.AbstractEBusConnector:297 ] - Received telegram was invalid, skip!
08:24:51.221 [DEBUG] [.ebus.internal.parser.Analyses:300 ] - 10 08 B5 11 01 02 8A 00 05 03 3C 96 50 68 94 00 AA
08:24:51.222 [DEBUG] [.ebus.internal.parser.Analyses:333 ] - >>> [Analyse] Vaillant: Brenner zu Regler
08:24:53.246 [DEBUG] [.ebus.internal.parser.Analyses:300 ] - 10 08 B5 10 09 00 00 35 5E FF FF 04 FF 00 72 00 01 01 9A 00 AA
08:24:53.247 [DEBUG] [.ebus.internal.parser.Analyses:333 ] - >>> [OK] Vaillant: Regler zu Brenner
08:24:59.310 [WARN ] [.ebus.internal.utils.EBusUtils:399 ] - Unexpect ack value in EBus telegram, skip data!
08:24:59.311 [DEBUG] [.b.e.i.c.AbstractEBusConnector:297 ] - Received telegram was invalid, skip!
08:25:01.278 [WARN ] [.ebus.internal.utils.EBusUtils:399 ] - Unexpect ack value in EBus telegram, skip data!
08:25:01.279 [DEBUG] [.b.e.i.c.AbstractEBusConnector:297 ] - Received telegram was invalid, skip!
08:25:01.504 [WARN ] [.ebus.internal.utils.EBusUtils:399 ] - Unexpect ack value in EBus telegram, skip data!
08:25:01.505 [DEBUG] [.b.e.i.c.AbstractEBusConnector:297 ] - Received telegram was invalid, skip!
08:25:03.335 [DEBUG] [.ebus.internal.parser.Analyses:300 ] - 10 08 B5 10 09 00 00 35 5E FF FF 04 FF 00 72 00 01 01 9A 00 AA
08:25:03.336 [DEBUG] [.ebus.internal.parser.Analyses:333 ] - >>> [OK] Vaillant: Regler zu Brenner
08:25:09.361 [WARN ] [.ebus.internal.utils.EBusUtils:399 ] - Unexpect ack value in EBus telegram, skip data!
08:25:09.361 [DEBUG] [.b.e.i.c.AbstractEBusConnector:297 ] - Received telegram was invalid, skip!
08:25:13.403 [WARN ] [.ebus.internal.utils.EBusUtils:399 ] - Unexpect ack value in EBus telegram, skip data!
08:25:13.404 [DEBUG] [.b.e.i.c.AbstractEBusConnector:297 ] - Received telegram was invalid, skip!
The most messages are invalid.
Any idea to fix it ???
Maybe signal level is too hight or too low ???
Hello @Tomek,
your log shows me that the binding is running and you get few valid ebus telegrams. I think you should adjust the trimmer on the coupler to get a good signal for all bus participants. I had the same problem in the past with my installation that not every participant has a strong signal. You should open a live console and adjust at the same time to get the optimal value.
But keep in mind that is normal to get some errors on the bus.
You could also create a raw log with the configuration described here
# Write all/debug/unknown telegrams to a CSV file in folder {openhab}/etc/ebus
ebus:record=all
Then the binding will write the raw data to a csv file. You can send it to me and I will look on it.
Hello @csowada
Thanks for your help
I connect to coupler using telnet (xterm) and I get strange characters .Do you thing that is the problem with signal level ???
Regards
Tomek
You need a terminal program that can show the raw data in hex not as characters. Under windows I use realterm …
Hello again @csowada
I connect to ebus coupler using realterm and I get
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAA1008B511010189000932309042000000AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1008B50401003D0A00441823FFFF9000
AAAAAAAAAA10FEB5050204000BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1008B510090000375E001301019A00AAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1008
B51101018909323090FF420000D300AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1008B510090000375E1300
01019A00AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAA
Is it OK or I sholud tune signal ???
Regards
Tomek
It looks good so far. You have many many 0xAA sync bytes, that is normal. Have you adjusted the trimmer? Or is this the setting you used for the previous post?
I did not adjust the trimmer becouse I 'am far away from my home. I do it remotely. It is localed in my second home in the mountain so I will go there for the weekend. For this time I can use only ssh:)