Hello @ChrisPe,
for me it looks like a hardware issue. I would contact the eBUS interface seller.
So I’m out of ideas what could be wrong.
Any news to the Alpha 12 release? I’ve optimized the error handling, so I hope in your case we will get an error log now.
Here is the result for that:
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 | --- | Joh. Vaillant GmbH & Co. | B5 | 4.18 | 19.02 | Tue Oct 24 13:08:08 CEST 2017
30 | 35 | 56 38 31 30 30 | vr81 | Joh. Vaillant GmbH & Co. | B5 | 2.02 | 25.02 | Tue Oct 24 13:08:00 CEST 2017
| 26 | 46 34 37 30 30 | --- | Joh. Vaillant GmbH & Co. | B5 | 1.14 | 61.02 | Tue Oct 24 13:08:06 CEST 2017
03 | 08 | 42 41 49 30 30 | bai | Joh. Vaillant GmbH & Co. | B5 | 6.09 | 55.02 | Tue Oct 24 13:08:08 CEST 2017
----------------------------------------------------------------------------------------------------------------------
MA = Master Address / SA = Slave Address / ID = Manufacture ID
Yes I agree, I will contact them to figure out how to fix that first. I’ll go back to try your binding when this will be fixed.
So, I’m out for a while. My productive system crashed and I need to restore the system first. It has nothing to do with the binding, the emmc memory are broken.
Till today Alpha12 working properly
I detected some issue with name of channel when added manually vs autodetected
In manual mode we have
ebus:std:id of item
in auto
ebus::id of item
so we do not have std in middle in auto is that correct?
Yes you are right and this is already fixed in the next version. But at the moment I’m not able to finish the version because I must repair my broken productive system. Maybe after the weekend …
The name schema change then to ebus:std:08 etc.
OK thank’s for informantion,
one remark, is it possible to have two thing with same ID as last positon is thingID in Openhab?
as we can have ebus:std:15 & ebus:vrc430:15
yes, no problem. I’ve seen no issue until now.
Ok, So waiting new revision
Ouch ! That’s exactly why my “production” openHAB is going to be hosted on a NAS, with good old spinning storage with RAID protection 
I tried to get some help from esera support but I have a very bad feeling about them, already two detailed email and not a single answer, that sucks 
In the mean time I continue various tests. as I can have good formed telegram when using RealTerm. I’m now testing the version 1.8 ebus binding and start to get values from the VRC470 AND the boiler ! So maybe it’s not that related to hardware issue after all. I’ll go as far as I can, that will be helpful to go back to the test with the ebus2 binding.
hi,
I installed Alpha12 today and my observations so far:
- my own parser for running time from BAI works OK (before it didn’t read DWH running time for some reason). when I tried however to add reading system pressure it doesn’t work.
- my own parser for VR61 for HC2 curve (based on your original json for HC1 curve) eventually reads some value, but it’s different than what is on VRC470 (address I’ve taken from john30 but it’s possible it’s wrong there and I read something else than curve)
- I tried to use VRC470 time / date value but it gives an error in the log file
2017-11-01 12:53:32.030 [WARN ] [hab.binding.ebus.handler.EBusHandler] - Unexpected datatype EBusDateTime for channel ebus:vrc430_controller_time_time !
2017-11-01 12:53:32.032 [WARN ] [hab.binding.ebus.handler.EBusHandler] - Unexpected datatype EBusDateTime for channel ebus:vrc430_controller_time_time !
bindings seem to be very stable, with v12 I can’t say much but v11 was working extremely stable for me for many days, and I’m reading 19 parameters from ebus, many of them updated every 60sec. Deserves high appreciation!
Would be happy to hear others’ experience with VR61 mixer channels .
So, I’m back on track. I’ve set up a new productive server on ARM Linux with openhab Docker. It runs now and I can go back to the eBUS binding. My latest version is running since yesterday without any trouble. The next step is to check date/time issue.
And afterwards I think it is time to create a “eBUS binding - Custom configuration” thread to share your custom parsers.
Hi @csowada
i found one mistake in BAI command D.047 shoud be 7600 not 0200 (this is water pressure)
This was a copy and past issue. The correct command was above this command. It is fixed in the new version.
Hi guys, nice binding. I have a heating system Vaillant VWS 82/3 and the binding don´t work. I have the Ebus Ethernet Coupler. What can i do to find the master and slave adress an what thing can i use to decode my heating system. Thanks a lot.
You must add a eBUS bridge first, than normally auto discover should find some devices in Paper UI. And please add your log.
So, a new version is out. You can see the changes in the change log below.
openHAB eBUS 2.0 binding - Alpha 0.0.13 (2017-11-02)
Features:
- Update to eBUS library 0.0.13, github
- Restructure configuration loading, add listener for updates
Bugfixes:
- Fix mapping for EBusTypeDate and EBusTypeTime to openHAB DateTime
- Update console commands incl. help
- Fix discovered thing ids
eBUS core library - Alpha 0.0.13 (2017-11-02)
Features:
- restructure internal configuration handling
- removed outdated maven modules from source
Configurations:
- add identification for Vaillant VRC430f and VRC470f
- add pressure for Vailant BAI00
- fix outside_temp for Vailant BAI00
1 Like
Hello @csowada,
thank you for new relase, Testing started
one remark
VR68 - added automaticly - slave address on the end
VRC470 manually - no slave address in link
DateTime have also some issue with decoding:
Date is wrong, time 06:15 is looking like MM:SS
Configguraiton of DateTime item
"Time [%1$tA, %1$td.%1$tm.%1$tY %1$tH:%1$tM]"
