[eBUS 2.0] New binding - Release Candidate 7b

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 :smiley:
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 :frowning:

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?

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)

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?

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?

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.

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 :slight_smile:

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

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 ?

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

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:

  1. 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:
  2. OFFLINE - CONFIGURATION_ERROR eBUS master address is not a valid master address!

is FF the only valid master adress?

thanks

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

Benny

Hello @andi_x,

you could also use 00

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.

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.

Hi,

Having some trouble getting set up and hope someone can help.

I’m running OH2 and have installed the latest binding. This is running ok and is talking with my ebus interface (ESERA RS232) though FTDI on /dev/ttyUSB0, which is connected to a Vaillant VRC 470f directly to the boiler unit. The problem I have is that I cannot for the life of me get it to recognise any telegrams - everything is marked as failed.

I have been through the hardware setup instructions for ebusd and tried adjusting the potentiometer for hours. I am not able to get a stable AA heartbeat, just a few blocks every now and then. The stable signal position gives the results seen below.

In the logs, the most common error is “Telegram starts with an invalid source address!” which happens 3/4 times a second. Each time the source address listed is different. Log snippet at bottom.

I suspected it might have been a bad connection but have since replaced the cable with solid core, twisted pair CAT6 (ebus spec compliant) which made no difference.

Update - 24th Feb
I have a strong suspicion that the ESERA coupler is at fault and am following in ChrisPe’s footsteps by ordering the new v2.1 ebus interface from John30 et al on the FHEM forums. They are putting it together and testing it beforehand so hopefully everything will be good soon. Shall update again once it arrives.

Update - 12th March
It has arrived and it works! Very disappointed in ESERA - the coupler was not cheap and their support was non-existant. I can only recommend you don’t buy from them and instead get something from FHEM instead. Now onto the next issue of unidentified telegrams…

Log

18:44:39.824 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Data -12
18:44:39.869 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Data -13
18:44:39.909 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Data -14
18:44:39.953 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Data -15
18:44:39.997 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Data -16
18:44:40.125 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Data -17
18:44:40.168 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from LENGTH1 to UNKNOWN
18:44:40.168 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA]
18:44:40.648 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:40.694 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:40.694 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! FD [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
^Z                                                                                                                                                                                                   [1]  suspended   log:tail
openhab> 18:44:41.816 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:41.860 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:41.860 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! D5 [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
18:44:42.033 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:42.073 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:42.073 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! AE [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
18:44:42.684 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:42.727 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:42.727 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! F5 [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
18:44:42.816 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:42.857 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:42.857 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! BE [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
18:44:43.419 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:43.461 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:43.461 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! AB [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
18:44:43.718 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:43.763 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:43.763 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! AE [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
18:44:43.893 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:43.978 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:43.978 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! DF [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]
18:44:44.023 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from UNKNOWN to SYN
18:44:44.109 [TRACE] [dev.ebus.core.EBusReceiveStateMachine] - Update state from SYN to UNKNOWN
18:44:44.110 [DEBUG] [inding.ebus.handler.EBusBridgeHandler] - eBUS telegram error; Telegram starts with an invalid source address! F5 [ERROR: INVALID_SOURCE_ADDRESS, DATA: FF DD F5 FD F5 FD FD F5 FE DD F5 AA FD AA AA F5 F5 FD AE D5 FF AF FE F5 FD FD F7 EE D5 EE AA EA AA FF AA FF FA AA 60 D8 DF F2 72 6C 13 67 7A 05 AD D2]

Hex Dump

0000000 fdee fbd7 aaaf f5eb d7d5 defd aaf5 d5ab
0000010 ebd5 fdf7 fdd5 fffd aad5 d7d5 12ab f5ca
0000020 6871 69f0 8e5f 4012 5a14 a2fc d7f5 ddf7
0000030 aafa faab f5aa ae86 baf5 d5fd f5d5 baaa
0000040 ead5 aaab eafd d7df d5dd abff aafe d5d5
0000050 bafd fe98 8336 c1c4 d7ff fddd abab aad6
0000060 aaf5 d5ea f5aa d5bf cb82 c1d5 82aa c0aa
0000070 bed5 d5af abff aafd abab fdd5 bad5 aaae
0000080 aaff baab baaa d7ee aaea d5fc d5ba ffd5
0000090 d7aa bfff fdab bbba aeaa bed5 ddff d5d5
00000a0 aad5 f7ea acd5 6398 3071 c971 a997 0ece
00000b0 d54d aaab dfbf abba faea d5df d5fc f5fd
00000c0 f7aa aaaa ebfd ebc1 ffaa d7d7 ddab fdef
00000d0 fdbf d5d5 abab aaaa f585 d5f5 afd5 aadd
00000e0 d7fd abf7 ddd7 fdaa aaf7 f5aa bbf5 aed7
00000f0 d5ab f5d7 aaab aaf4 ffeb beaa fdf5 ea8b
0000100 eaeb d3c5 f1bb 8deb 4244 3ad5 2b94 4746
0000110 f5e2 abaa d5aa 8bff abd5 aaea d5dd bbaa
0000120 d5d5 abf4 aafa c0ba ddf7 aeab f5f5 aad5
0000130 d5ff ffaa abae baae ddd5 97c2 6f2d 3ee7
0000140 40e0 4691 67a6 64f9 eaae caee d587 d7f5
0000150 d5dd aef5 f7fd fde8 87ba baaa fafd ebf5
0000160 c8aa d5ab f5d7 f5ab f5c9 ddbf d5df fdeb
0000170 baeb aa8b ffff dcf5 aed5 bfdd eaea aaaa
0000180 fef5 aaff abae aaba eaba d5ea eaae ddff
0000190 f5ba f5e5 eaa0 d4d5 c75a a491 ffc4 ffff
00001a0 ffcd f889 01a0 c2dd f5f5 d5aa d5ae 86c2

i have modified my esera ethernet adapter based on a prototyp for the usb adapter from galileo and the new informations from the fhem ebus adapter 2.0/2.1.
this stuff is working very very well.
my failure rate is now constantly below 8% instead of 75-80% before.

Hey,
i have a atmoTEC plus and would like to remote it with openhab2.
I use a FHEM E_BUS adapter, but i don’t get any Temperature values.

Is there an option, to adjust the potentiometer with ophenhab2?

Hi,

there is a new ebus adapter which could be connected directly on the gpio pins on the raspberry in the fhem forum (RPi).

with this adapter there is a special device driver /dev/ttyebus, which must be used.

but in the ebus bridge it’s not possible to select this device, only /dev/ttyS0 and /dev/ttyAMA0 is available.
maybe there is a way to do this in a config file?

Thanks
Andi

Hi Andi,

I’m using the same adapter (just received mine last friday) and was not able to use the new ebus binding with it.
What I’ve figured out so far with the new binding is, that

a) the /dev/ttyebus has root:root permissions and not root:tty as most other serial devices. When I add openhab to the root group its still not working. I’ve send a mail to Galileo about changing the group permanently to tty but he doesn’t know how to do this.

b) I also tried to add the /dev/ttyebus to the /etc/default/openhab2 file.

EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyebus"

… but still without any luck. At least now I receive a different ebus2-binding error

[220:org.openhab.binding.ebus:2.2.0.201712041912]                                                                                             2018-03-05 10:37:29.761 [ERROR] [de.csdev.ebus.core.EBusController   ] - java.lang.ArrayIndexOutOfBoundsException: Invalid length in readArray
java.lang.ArrayIndexOutOfBoundsException: Invalid length in readArray
        at gnu.io.RXTXPort.readArray(Native Method) ~[25:com.neuronrobotics.nrjavaserial:3.12.0.OH]
        at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1434) [25:com.neuronrobotics.nrjavaserial:3.12.0.OH]
        at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1323) [25:com.neuronrobotics.nrjavaserial:3.12.0.OH]
        at de.csdev.ebus.core.connection.AbstractEBusConnection.readBytes(AbstractEBusConnection.java:53) [220:org.openhab.binding.ebus:2.2.0.201712041912]                                                                 
        at de.csdev.ebus.core.EBusController.run(EBusController.java:179) 
        [220:org.openhab.binding.ebus:2.2.0.201712041912]
2018-03-05 10:37:29.833 [ERROR] [de.csdev.ebus.core.EBusController   ] - java.lang.ArrayIndexOutOfBoundsException: Invalid length in readArray
java.lang.ArrayIndexOutOfBoundsException: Invalid length in readArray

At the moment I’m using the adapter with ebusd and mqtt support which sends me the readings with a cronjob every 5 minutes to my openhab.
I hope we can make the ebus2 binding also work with the new ebsu2.1 raspberry shield.

Sebastian

… regarding your question: in the paperui I’ve added “/dev/ttyebus” in the Ebusd bridge settings under Serial Port. It’s a text field so you can put everything you want there. :wink: