Okay, thanks! I will do that and hope ebusd finds a match.
Hello All,
I’m a bit behind my schedule. The issues has already been fixed on guthub. But there is still no time for a new release.
But you can always use the bundle url to overwrite the build-in version with the latest from github.
Hi,
Looking inside the csv log files, I have a strange issue, a specific telegram is marked in both files.
In ebus-resolved csv file, I have:
2018-02-09 14:21:33;"FF";"15";"B5 09";"03 0D 60 00 25 00 03 20 15 0E E9 00";GET > vrc430.controller.time
And in ebus-unresolved csv file, I have:
2018-02-09 14:21:33;"FF";"15";"B5 09";"03 0D 60 00 25 00 03 20 15 0E E9 00";
This message is the only one to have this strange behavior.
Hi,
coming back to the forum after some time of absence as only now have time to play again with the binding…
I discovered some time ago that Heating Curve template doesn’t work properly for setting the value (it is good for reading though). When I used it in my HC2 Curve decoding (from VR61) I actually replicated the same issue to more files which are not posted to the binding repository.
It wouldn’t be an issue normally but practically, try to set the Curve is so wrong that it can set it to 0.00 typically (or some crazy high value when pressing many time) causing a big issue when away cause what is seen in PaperUI is always 0 but on the Calormatic it gets set to different values. So good to fix it.
I think the issue is related to ‘factor’ and ‘step’ on the item vs way it is displayed in PaperUI (or wherever, eg. in BasicUI with Setpoint). I’m not sure I understand well how value from PaperUI (or basicUI) is mapped to the factor when setting it up. I don’t think attaching logs here is so important (can produce them however) as probably someone experienced with creating json’s will immediately know how to connect definition in the ‘set’ section with definition of the setpoint or item.
BTW, with calormatic heating curves are displayed in X.XX format whereas definition of the item (at least in v14) is using x.x which probably is the first problem. But even if I changed it for my own HC2 definition to be %.2f it maps to some ‘strange’ (= not clear to me) values on calormatic.
Would appreciate someone experienced to help. Thanks in advance!
Hello,
I am new to openhab but very interested in the ebus connection
I am currently busy making some Json files for the ebus 2.0 binding
i have one question, with all values i have a character and fonts do not allign
is this something that needs changing in openhab or in the binding ?
thanks in advance for a hint
Erik
You should use an editor that supports UTF-8
Hi
I have This behavior with all screens, not only the ones that i created
The values are correct…
Reg
Erik
Hello,
I am new to EBUS, this weekend I succeeded in communicating via EBUSD with the VRC700. As an openHAB user it would be great to do this directly via openHAB.
I did not figure out how to add this VRC700, can someone help with some pointers to get me going?
thanks in advance,
Uitgeslapen
Hello,
I try to decipher my eBus data and I think I have to start at the very beginning. My eBus scan output looks lie this:
openhab> smarthome:ebus devices
MA | SA | Identifier | Device | Manufacture | ID | Firmware | Hardware | Last Activity
---+----+----------------+----------------+----------------------+----+------------+------------+---------------------
FF | 04 | | <interface> | eBUS Library | | null | null | ---
| 51 | 01 14 00 10 00 | --- | G. Kromschröder AG | 50 | 2.08 | null | Tue Jul 24 20:39:07 CEST 2018
10 | 15 | 01 18 00 00 00 | --- | G. Kromschröder AG | 50 | 2.04 | null | Tue Jul 24 20:39:14 CEST 2018
70 | 75 | 01 18 00 00 00 | --- | G. Kromschröder AG | 50 | 2.04 | null | Tue Jul 24 20:39:07 CEST 2018
30 | 35 | 01 18 00 00 00 | --- | G. Kromschröder AG | 50 | 2.04 | null | Tue Jul 24 20:38:51 CEST 2018
71 | 76 | 01 15 00 00 80 | sm1 | G. Kromschröder AG | 50 | 2.27 | null | Tue Jul 24 20:39:15 CEST 2018
03 | 08 | 01 06 33 42 02 | --- | G. Kromschröder AG | 50 | null | 51.3 | Tue Jul 24 20:39:14 CEST 2018
F1 | F6 | 01 18 00 00 00 | --- | G. Kromschröder AG | 50 | 2.04 | null | Tue Jul 24 20:39:15 CEST 2018
----------------------------------------------------------------------------------------------------------------------
MA = Master Address / SA = Slave Address / ID = Manufacture ID
I have no experience with the eBus, but first I wonder that a device which has one identification, sends on different slave and master addresses. Is this in general possible?
Physically connected to the eBUS should be the devices:
- BM1
- MM
- SM1
That makes three devices but the scan found four devices
Hello @visper,
you forgot your heating untit/burner itself in your list? I attached my devices from a Wolf CSZ-2 heating unit. Maybe it is helpful.
Manufacture | ID | Firmware | Hardware | Last Activity
---+----+----------------+----------------+----------------------+----+------------+------------+---------------------
FF | 04 | | <interface> | eBUS Library | | null | null | ---
| 50 | 01 21 00 5A 00 | mm1 | Wolf GmbH | 19 | 60.01 | 0 | Wed Jul 25 08:23:38 CEST 2018
30 | 35 | 00 20 00 00 C0 | bm2 | Wolf GmbH | 19 | 2.04 | 0 | Wed Jul 25 08:23:38 CEST 2018
00 | 05 | | ism7 | (ISM7 Module) | | null | null | Wed Jul 25 02:37:25 CEST 2018
71 | 76 | 01 15 00 00 80 | sm1 | G. Kromschröder AG | 50 | 2.27 | null | Wed Jul 25 08:23:29 CEST 2018
03 | 08 | 01 21 00 5A 40 | cgb2 | Wolf GmbH | 19 | 60.01 | 0 | Wed Jul 25 08:23:36 CEST 2018
F1 | F6 | | --- | null | | null | null | Wed Jul 25 08:23:30 CEST 2018
----------------------------------------------------------------------------------------------------------------------
MA = Master Address / SA = Slave Address / ID = Manufacture ID
Hello @csowada
yes I have also installed a heater: CGB-11 So I assume the fourth device in my list is the heater.
I am still wondering why one device with identification “01 18 00 00 00” sends on four different master addresses. But as long as I read the specification this is not prohibited.
How is the identification received by eBusd at all? Since I have also installed a MM1 device there should be identification “01 21 00 5A 00” like on your system.
You can try to add the MM1 manually, some devices has more than one valid identifier. If it work I can add the identifier to the configuration file. I also have an mini BM1 configuration here. I will update the git repo in 1-2 hrs. Then you can overwrite your build-in configuration with the version from github.
Use this url
The files on Github do not contain any of my identifiers. So I downloaded for example the mm1 file and replaced the identifier with the one I expect to be the mm1 identifier. But the things do not update, they are still treated as “eBUS standard xy”.
openhab> smarthome:ebus reload
Reload all eBUS configurations ...
openhab> smarthome:ebus update
Refresh all available eBUS Things ...
Thing UID | Label | Refreshed ?
-----------------------------------------+------------------------------------------+-----------
ebus:std:9b17db74:08 | eBUS Standard (08) | true
ebus:std:9b17db74:F6 | eBUS Standard (F6) | true
ebus:std:9b17db74:51 | eBUS Standard (51) | true
ebus:std:9b17db74:35 | eBUS Standard (35) | true
ebus:std:9b17db74:15 | eBUS Standard (15) | true
ebus:std:9b17db74:76 | eBUS Standard (76) | true
ebus:std:9b17db74:75 | eBUS Standard (75) | true
ebus:sm1:9b17db74:76 | Wolf SM1 (76) | true
openhab> smarthome:ebus device
openhab> smarthome:ebus devices
MA | SA | Identifier | Device | Manufacture | ID | Firmware | Hardware | Last Activity
---+----+----------------+----------------+----------------------+----+------------+------------+---------------------
FF | 04 | | <interface> | eBUS Library | | null | null | ---
| 51 | 01 14 00 10 00 | --- | G. Kromschröder AG | 50 | 2.08 | null | Wed Jul 25 20:08:07 CEST 2018
10 | 15 | 01 18 00 00 00 | mm1 | G. Kromschröder AG | 50 | 2.04 | null | Wed Jul 25 20:08:09 CEST 2018
70 | 75 | 01 18 00 00 00 | mm1 | G. Kromschröder AG | 50 | 2.04 | null | Wed Jul 25 20:08:07 CEST 2018
30 | 35 | 01 18 00 00 00 | mm1 | G. Kromschröder AG | 50 | 2.04 | null | Wed Jul 25 20:07:48 CEST 2018
71 | 76 | 01 15 00 00 80 | sm1 | G. Kromschröder AG | 50 | 2.27 | null | Wed Jul 25 20:08:11 CEST 2018
03 | 08 | 01 06 33 42 02 | --- | G. Kromschröder AG | 50 | null | 51.3 | Wed Jul 25 20:08:09 CEST 2018
F1 | F6 | 01 18 00 00 00 | mm1 | G. Kromschröder AG | 50 | 2.04 | null | Wed Jul 25 20:08:10 CEST 2018
----------------------------------------------------------------------------------------------------------------------
MA = Master Address / SA = Slave Address / ID = Manufacture ID
Okay I managed to get updated Things listed as “MM1” type using my own configuration file. But the “eBUS Standard (xy)” devices are also found and listed in my Inbox in PaperUI. Is there a way that the found MM1 devices are not also listed?
When I configure the commands for my mm1-device which has multiple master/slave addresses, I get displayed all comands on all devices. This is because all use the same identification. But only I expect only a subset of the commands on each address. Is there a way to tell the eBUS-Binding that these addresses all form only one device and that a specific command is only expected on a certain address?
Hi Ben,
Did you ever get openhab to interface with your brink allure heater? I’ve just bought a house with such a heater (brink allure b-10 hdr) and am looking into possibilities for automation.
Would love to hear if you got it to work or not and if so, how.
Hi Peter
Unfortunately I was never able to get it to work properly so I gave up for now… If you have more success in the future I would love to hear from you as well.
That is too bad, I’m a bit reluctant to buy the hardware if I have no idea if it’s going to work so I might just keep with the on/off in stead of modulating. If you have anything else you can share from your research that might be helpful though.
Cheers
Peter
Is it possible to configure a filter for DST address in the json file?
In particular, I have Protherm unit (sub-family of Vaillant BAI00) and there are the same commands (snippet from ebusd csv conf):
comment QQ ZZ PBSB ID
Target fan speed 10 08 B509 0D2400
Target room temperature 10 15 B509 0D2400
differing by just the ZZ field (destination).
I found an existing json config:
{
"label": "Fan speed target value D.033",
"id": "boiler.speed_d_fan",
"command": "B5 09",
"get": {
"master": [
{"type": "static", "default": "0D 24 00"}
],
"slave": [
{"name": "speed_d_fan", "type": "uint", "label": "Fan speed target value", "format":"%d rpm"}
]
}
},
which is fine for the first command. How to duplicate for the destination: 15 as per the second command?
EDIT: Ok, my misunderstanding. The “destination” is a thing - actually its slave address and its identification as shown by smarthome:ebus devices
Hi all,
How to get changes in ebus-XXX.json propagated PaperUI?
So far, it seems that:
- To re-read the json configuration of ebus binding, the binding must be reloaded (enough to click on edit of Ebus binding and save without changes).
- However, this does not update the existing Thing and its Channels. I have to delete the Thing and create it again - this generates a new id, which I have to change in my sitemap for the defined Items eventually.
- When I simply tried to to re-type the id of the newly added Thing to the old id, it did not seem to show the changes from updated json file.
- I also noticed that even that I deleted a Thing in PaperUI, the Items from sitemape continued to update.
I am a bit confused by the behaviour and looking for a way how to update the ebus binding configuration and verify in OH.
Is there a recommended workflow?
back in November 2016 I´ve started this topic here ([eBus]: Vaillant Colormatic 700 (VRC 700)) as I own a Vaillatint VRC 700. I´m not too deep into all the stuff and after it seemed that there was no progress on that topic, I´ve lost it a bit out of my mind. Now, after 2 years, I came back on the Vallaint topic and just read what you guys have done in the past months. 
Just wanna say a big thanks for all the time you spent and for the work you´ve done! 
It helps people like me, who are not familiar with all that stuff, really a lot! THANKS!!!