so where is the last version of the configuration files? here https://oss.sonatype.org/content/repositories/snapshots/de/cs-dev/ebus/ebus-configuration/1.0.7-SNAPSHOT/ ?
No, this are the compiled files. It works, but I prefer the content on GitHub
1 Like
Hi @Chiuaua79,
this is not a bug, its a feature. I have a Wolf CWL400 and a Wolf Control panel. Once you disconnect the Wolf control panel, the fan switches back to level 1 exactly after 120s. I think this function is to avoid that the ventilation system remains at a low or high level in case of a failure.
What I do is to set the level every 60s, like a normal poll. Even if one message would get lost, the configures level remains constantly. This works now since one week.
Meanwhile I have finished a mostly complete configuration file for the CWL series. Only two three minor things are missing. I will align with @csowada how to get that into the code.
I hope that helps
Best, Lui
Hello @LuiSauberhorn. Thank you for some explanation and your work of creating such an extensive configuration file.
In my case I only have the bare minimum configuration, so no heaters, no RH sensor. Only the Brink Renovent Excellent 400 ventilation unit and the Brink Air Control (old version comparable to Wolf BML).
This morning I set up the TRACE logging to see what was happening when I went to take a shower whilst setting ventilation to maximum (3). My openhab eBus was only listening to the eBus, nothing more. It appeared that the controller (master address 01) was sending a kind of ākeep-aliveā every 30 seconds for the set maximum ventilation:
01 7C 40 A1 06 00 03 00 03 00 00 D2 00 02 22 00 E5 00
I have not tested the response without the controller, but it seems that the controller also has the logic of sending keep-alives (like you are doing with openhab every 60 seconds), which means that the controller and openhab probably cannot co-exist setting the ventilation mode.
One more thing I noticed is that the controller actually sends two telegrams to the ventilation unit when changing the ventilation mode (other than the keep-alive that sends only the one telegram). In case of setting ventilation mode to ā2ā:
01 7C 40 A1 06 00 02 00 02 00 00 4B 00 02 22 00 E5 00
01 7C 40 A3 04 01 02 E4 07 F1 00 0B 05 22 00 00 00 02 00 00 04 00 00 D6 00
Decompiling the telegram:
01 7C is controller to ventilation unit
40 A3 where 40 is for manufacturer Encron, but the A3 is not yet described anywhere.
04 01 02, meaning 4 bytes to follow, 01 is always 01 and 02 is the ventilation mode (so can also be 00, 01 and 03)
E4 07 is an ever changing code. Others found are FF FF, 01 00, 00 00, FE FF, 13 00, 04 00, 16 36, etc. They donāt appear to have a structure.
Finally F1 is the sent messageās CRC.
For the response from the ventilation unit 00 0B 05 22 00 00 00 xx 00 00 04 00 00 yy 00, I have marked xx what the ventilation mode response is (either 00, 01, 02 or 03) and yy the CRC for the response.
It intrigues me what that the effect is of the second (40 A3) telegram.
Krgds
Cor.
Hi @Chiuaua79,
the problem is understood. Both devices are polling their last configuration to the system. How do you simply listen to the bus (ebusd?). I have an ethernet ebusd controller since three weeks now and donāt know how to do it. Once I now it, I could compare your behavior with what I see when my control panel is connected.
Regarding your problem: There should be a solution (even if I donāt know it yet). I checked the manual for my control panel BM-2 (attached but German, which is not connected at the moment). On page 14, they describe how to connect several control panels, so there must be a way to tell the other panels that the level was changed (so that they poll the right value or stop polling).
Hello @LuiSauberhorn.
I do have a raspberry pi with a āproductionā Openhab server that I use for all my automation and is kind of a āfit and forgetā system (donāt tamper with it unless you need to). On my PC I have a āplaygroundā virtual machine where I can play around with Openhab and other Linux appliances and which system can be reinstalled without pain if a mess it up too bad. On that virtual machine I started with the eBus binding and I try out configuration files (like yours) before using (parts of) such configuration on my production server.
I monitor the eBus with the playground installation where I remove the configuration file for the Wolf CWL, to prevent the eBus binding translating telegrams to items from the configuration file, which prevents me from seeing the RAW telegram. To monitor I need to temporarily disable the openhab eBus bridge on my production server as only one openhab instance can be connected to the wifi ebus adapter at a time.
Next is to enter the openhab console (for instance via ssh) and set the ebus logging to TRACE. Now all ebus messages that fly by are recorded in your openhab.log. Let it run for a while and set ebus logging back to INFO.
Probably this can also be achieved in PaperUI by checking the āadvanced loggingā, but how that works is not clear to me (and I get what I want anyway).
For the room controller, I own a system that was installed in 2014/2015 and I think they did not have the BM-2 back then. When searching for documentation on Wolf CWL and Wolf BML (my room controller) there are several Wolf manuals that note only one BML can be installed in a system. I also noticed the iSM-7e module that links the ventilation (eBus) system to Wolfās telephone app, making it possible to control the system with oneās phone. I have searched for a cheap second hand unit to try to intercept messages of that module to the eBus to see if it also send messages to the room controller and learn from its behavior to implement in Openhab, but unfortunately I have not found one yet.
Krgds
Cor
I have the same issue. I also configured my thing via *.things file.
Bridge ebus:bridge:52d3004b "ebus interface" [
ipAddress="192.168.xxx.xxx",
port=8888,
networkDriver="raw",
serialPort="",
serialPortDriver="()"
]
I also used ebusd as network driver but the status of the bridge stays at INITIALIZING
My setup look as follows: Openhab 2.5 inside Docker on Server, ebusd deamon on raspberrypi with FHEM ebus adapter. Port and IP Address matches the on configured for ebusd on raspi.
I need help to get this working.
Regards
Switch networkDriver to ebusd should help.
No it does not help. It still stay at INITIALIZING
Mh, correct ebusd version? You need a newer version. Could you provide some log information?. You should switch to debug logging level in your kafaf console.
maybee my ebusd not not correctly configured.
EBUSD_OPTS="--scanconfig --enablehex -d /dev/ttyebus -p 8888 -l /var/log/ebusd1.log"
ebusd should be the latest version I think
ebusd 3.4.v3.3-51-g57eae05
Hello,
good to hear that i am not alone :-).
In my earlier posts i copied a part of the .json file which is compatiple to your things file. In my opinion, the syntax is inconsistent if i look to the quotes. Donāt know if this is the issue but am sure that it is the binding itself. Unfortunately the author has currently no time to analyze this.
Regards,
Willi
Hi csowada,
I enabled to DEBUG logging for
eBUS library configuration Version 1.0.7.202005171351
eBUS core library Version 1.0.8.202006152013
openHAB Add-ons :: Bundles :: eBUS Binding Version 2.5.1.202006152014
the only output I can find is:
2020-11-05 09:42:21.675 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'ebus.things'
2020-11-05 09:42:21.687 [INFO ] [.csdev.ebus.core.EBusEbusdController] - Run connect ...
2020-11-05 09:42:21.789 [INFO ] [.csdev.ebus.core.EBusEbusdController] - Run direct mode ...
2020-11-05 09:42:21.890 [INFO ] [.csdev.ebus.core.EBusEbusdController] - Use ebusd version: ebusd 3.4.v3.3-51-g57eae05
2020-11-05 09:42:21.890 [INFO ] [.csdev.ebus.core.EBusEbusdController] - ebusd direct mode enabled!
2020-11-05 09:42:21.890 [WARN ] [.csdev.ebus.core.EBusEbusdController] - Stop sender thread!
2020-11-05 09:47:21.890 [WARN ] [.csdev.ebus.core.EBusEbusdController] - eBUS Watchdog Timer!
2020-11-05 09:47:21.891 [WARN ] [.csdev.ebus.core.EBusEbusdController] - Stop sender thread!
2020-11-05 09:47:22.173 [ERROR] [.csdev.ebus.core.EBusEbusdController] - error!
java.io.IOException: Stream closed
at java.io.BufferedReader.ensureOpen(BufferedReader.java:122) ~[?:1.8.0_265]
at java.io.BufferedReader.readLine(BufferedReader.java:317) ~[?:1.8.0_265]
at java.io.BufferedReader.readLine(BufferedReader.java:389) ~[?:1.8.0_265]
at de.csdev.ebus.core.EBusEbusdController.run(EBusEbusdController.java:274) [bundleFile:?]
2020-11-05 09:47:22.175 [INFO ] [.csdev.ebus.core.EBusEbusdController] - Try to reconnect to ebusd daemon ...
2020-11-05 09:47:22.175 [WARN ] [.csdev.ebus.core.EBusEbusdController] - Retry to connect to ebusd daemon in 5 seconds ...
2020-11-05 09:47:27.175 [WARN ] [.csdev.ebus.core.EBusEbusdController] - Stop sender thread!
2020-11-05 09:47:27.176 [INFO ] [.csdev.ebus.core.EBusEbusdController] - Run connect ...
2020-11-05 09:47:27.278 [INFO ] [.csdev.ebus.core.EBusEbusdController] - Run direct mode ...
2020-11-05 09:47:27.379 [INFO ] [.csdev.ebus.core.EBusEbusdController] - Use ebusd version: ebusd 3.4.v3.3-51-g57eae05
2020-11-05 09:47:27.380 [INFO ] [.csdev.ebus.core.EBusEbusdController] - ebusd direct mode enabled!
2020-11-05 09:47:27.380 [WARN ] [.csdev.ebus.core.EBusEbusdController] - Stop sender thread!one more log output from openhab console
Exception in thread "ebus-sender" java.lang.NullPointerException
at de.csdev.ebus.core.EBusEbusdController$EBusSenderThread.run(EBusEbusdController.java:110)
at java.lang.Thread.run(Thread.java:748)I installed an older Version
org.openhab.binding.ebus-2.5.1-6.kar
and my bridge change to online immediately
Ah, okay. A good finding. Iāll try to check it this evening. So the binding is running?
Also installed older version, here org.openhab.binding.ebus-2.5.1.7.kar and my bridge was immediately āOnlineā.
Thus, the problem is the binding 2.5.1-8 which obviously doesnāt allow to connect the eBUS-coupler via Ethernet.
Hi @csowada,
Current version is running fine for me on 2.5.10. Thanks for this!
As the second Milestone for OpenHab 3.0 is out I was wondering about your plans for making the binding ready for 3.0.0 or providing a dedicated version. Just being curios 
Thanks
Iām working on a version 3.0 release. Iāve done the changes required for 3.0, now I must test against a real heating device.
why using ebus-configuration-1.0.7-20200517.192845-1/index-configuration.json the Unresolved telegrams ratio is 85%? I have a standard vaillant burner and some mixed circuit, all are fully working with ebus 3.4