Enhance eBUS binding for Vaillant devices

[Christian S.]

Hello,

I started a new topic to support the enhancement of the eBUS binding for Vaillant devices. I own a Wolf device, so I need help from Vaillant owners. So please feel free to ask me and send your json configurations etc.

[nikoraes]

Here in attachment my work in progress on a vaillant config file for vrc470 and bai based on the ebusd config files. I haven't tested all of them yet, but I'll upload new versions once everything is debugged. 

I haven't figured out how to write something on the bus though. I would like to figure this out before I include more commands in the config file.

I also think there might be something missing in EBusTelegramParser.java as it doesn't seem possible to use the "uint" data type (required for waterpressure, but word seems to work as well). I now used "word" which works but seems to be x100 the expected value.

Op donderdag 28 mei 2015 10:42:17 UTC+2 schreef Christian S.:

[Christian S.]

Hello Nikoras,

thank you for you work. I'm currently working on a bigger update to enhance the eBUS writing. The current system is too simple and will not work well with vaillant devices.
So I hope I can present a test version this week.

The version shoud include:

+ Enhanced eBUS latency to prevent collisions on eBUS
+ Enhanced writing configurtion
+ Add UINT datatype to json configurations
+ Merge multiple openhab items to one complex eBUS telegram
+ Placeholders and Defaults for eBUS addresses
+ Rename eBus to eBUS in sources (cosmetic)

[Christian S.]

So, I'm still working on an update but the send routine is more complex than expected. I also work parallel on new Wolf eBUS commands that I can extract from Interface ISM7i.
So I hope I can create a new update next week.

[Christian S.]

So,

here a short help to convert ebusd configuration files.

First of all, read the excellent documentation that explains the ebusd configuration files and there data types (basic and template). -> https://github.com/john30/ebusd/wiki/4.-Configuration
Then you should read this document to get information about the jsnon format of this binding. -> https://github.com/csowada/openhab/blob/master/bundles/binding/org.openhab.binding.ebus/ebus-configuration.md

So with this information you can create configuration files that allows reading (incl. Polling) the eBUS. But at the moment there is no solution to set values, but you can send raw telegrams as workaround to do that.
I'm working on the set feature, but only on cloudy days :-)

And I attached my last beta with optimized write (raw) access to eBUS. Please give feedback if it works or not.

[Harpinder Sanghera]

Hi Christian,

As you know from my feedback already, the last ebus binding update you made works very well for my Vaillant devices.

I also figured out with help from John (the current contributor to ebusd, that my vrt350 has a newer firmware so the 350.csv doesn't work. However i used the vrc430 (430.csv) and it works perfectly for new devices which i recommend everyone to try in case anyone is having problems.

I loaded all the messages of my bai device and the 430.csv into a json file and all the values can be polled at once without any crashing. It does sometimes take a bit longer for the binding to read the values and display all the values on my site, maybe that can be improved.
Otherwise it works great and I have translated the commands into english.

The next thing I want to work on is the sitemap. At the moment i just have text items and no fancy ui or a nice way to present the values maybe nice Vaillant icons and a display lcd to display what i see ony bai and vrt350 units? I would need help with that but would be very cool to have.

I want to make sections such as simple temperature readings and an advanced section for all diagnostic and extra commands but I still don't know how to do that with my items and sites files. Once i can get help with this I can upload my config to you so that you can use it in your binding and also I am working on a full english guide to setting it all up because I think that is missing and stopping others from successfully trying it!

Also what is the significance of 'pos':'12' or 'pos':'14' in the json file? Your guide doesn't make it clear what that is and I have just used those without knowing what they mean.

[Christian S.]

Hi Harpinder,

thank you for your help in the last days to test the new version.
The pos parameter defines the start position for a value in received byte telegram. I attached the image that I prepeared for the wiki, that shows all relevant information.

[Harpinder Sanghera]

Hi Christian,

Thanks that helps me a lot. I can configure a separate sitemap to display raw values now!

Also, have you looked at openhab 2? It has a nice UI called Paper UI and it looks much better than the ios style ui of openhab 1.7.0. I'm still having issues trying to get my values to display correctly and was wondering if you would look at openhab 2? There is development on it at the moment and some bindings from openhab 1.7.0 work on it without much work apparently.

[Christian S.]

Hi Harpinder,

I'm nearly done with the setter commands, then I will add one or two new things. Afterwards I start a Pull-Request to openHAB to submit the update to openHAB repository.
Then I will have a look on openHAB2. But Harpinder, you can try it yourself, mabye it runs directly without any modification.

[Andrzej Szymkowicz]

Hi,

Glad to hear that you were able to run the setup for 430. Can you share the details of what and where should be configured. Eg. what does it mean that you have used 430.csv

Thanks

[Harpinder Sanghera]

Read the wiki documentation for the Binding. Christian has explained it all there. I just followed it for my own setup, which will be different to yours.

First thing you need is openhab 1.7.0 from Github. Once you have that running, copy the ebus json file fron nikoraes and copy it to your configurations directory. Download the ebus jar file from one of Christians posts from 12th June, copy that to your addons directory. Copy the items from Nikoraes's post to an items file called ebus.items in the items directory. Create a sitemap file called ebus.sitemap in the sitemap directory call the sitemap ebus, add text items that match the name of the items used in your items file. In the configurations directory edit openhab.cfg and ensure you change the values in the ebusd section to use a custom parser file and make these changes:

ebus.serialPort=/dev/ttyUSB0

ebus.parserUrl=platform:/base/../configurations/ebus-config.json

ebus.parsers=custom

The serialPort will be different in Windows, see the comment in the file for what you need to do for Windows.

Then start openhab, navigate to: 

http://<ip address of openhab>/openhab.app?sitemap=ebus

You should see your items displaying results after 2-3 minutes. If not, there is an error in your configuration.

Read the binding documentation carefully and also the post above by Christian on 12th June about the configuration. If you don't have a vrc430 or your BAI device has a significantly different firmware version or your software version in your controls are different, it won't work unless you have the correct messages and values in the configuration for your own devices. The ones Nikoraes posted coincidentally works for mine too, but that is a coincidence. I also added a significant amount of messages to my own for my own setup from the csv files in John30's ebusd project. Look up john30 in Github and have a read of his ebus and ebus-configuration projects there for information on how to get the right commands for your devices, they are in csv files. You will need to know how to understand what the csv files contain and what all the information does and means to write your own ebus-config.json file if the one above doesn't work as it may not be compatible with your devices as they are probably different. I'm in the UK and my configuration is specific to the UK. 

I'm an linux engineer with development experience so many of these concepts are familiar to me, your own mileage will vary depending on your skills to understand how this works and how to tailor it to your devices. I would do some reading first until you are confident you can do this by yourself as you would be taking a risk in damaging your devices if you don't and make a mistake.

I am working on a blog post which will completely explain how to set all of this up but it will take me a long time to compile it, maybe weeks or months. Also OpenHab2 is around the corner and so my blog will no longer be relevant when it is released.

[Harpinder Sanghera]

Hi Christian,

For Openhab2, I extracted the openhab2 runtime from the zip file, copied the binding to the addons directory, json file to the conf directory and my sitemap/items and the cfg file as per the Openhab2 documentation (which is similar to Openhab 1.x documentation). I can't get the items to appear in my sitemap as the site is blank and the log shows nothing at all about the ebus binding. The openhab2 guide says that the bindings that so far work from version 1 use the standard API's without any 'dirty things'. Please have a look here: https://github.com/openhab/openhab2/blob/master/docs/sources/installation/compatibilitylayer.md and https://github.com/openhab/openhab2.

Maybe it's a quick fix just to get the ebus binding from openhab 1.7.0 to work with the compatibility layer instead of completely rewriting it from scratch? Please could you test an openhab2 environment with your current binding and see if you can make it work easily?

Also, how are the setter commands coming along?

Thanks

[Christian S.]

Hello Harpinder,

I'm interested in porting the binding to openHAB2, but currently the major update of the binding is stopping me from further research at the moment.

The current state of the major update is:

Done:
+ Impovements in send timings
+ Set single values to eBUS
+ Support to set multiple values to eBUS (not directly supported by openHAB)
+ Support to set multiple values directly via Rules
+ Write raw byte telegrams (all, marked debug, unknown) preformated to CSV files to analyse it easier and maybe replay it later (idea)

Open:
+ Map values to commands in item configuration, similar to paramter "data" for command ids
- Reorganize json configuration files, split in smaller pieces (per device)
- Add additional Kromschröder/Wolf CRC8 bytes for setter telegrams as new data type in json configurations (not important for vaillant)
- Change item configuration structure like:
   get:value.class, set:command.class to pull value from device
   get:value.class, set:command.class, refresh:60 to pull value from device every 50sec.
   get:value.class, set:value.command.class to set value and get result

   get:value.class, set:value1.command.class, flag:multi set value in memory and wait for more value with flag multi or send with flag flush_multi
   get:value.class, set:value2.command.class, flag:flush_multi set the value to a pending telegram and sends it out

Ideas:
- Add device configurations (json) to bundle all relevant configurations, eBUS addresses per device. ( Example: My Heating unit was sold as Wolf CSZ-2 an includes burner CGB-2, Solar Module SM1 and Controller BM2)
- Add placeholders for eBUS addresses in json configuration

So you can see, I'm still working on a new release to support

[Andrzej Szymkowicz]

Thanks a lot  for help. I'm geting some values from VRC 430 and BAI ;-)

Do you know how to write a value e.g. room setpoint temperature?

Regards

[Harpinder Sanghera]

See Christian for that.

--
You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/AHMQSrHXUvY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/f92175ce-4189-4eab-9eae-c7340e3140c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christian S.]

I' currently working on that. I hope I can upload a new version next days.
But now we got our summer weather and the development will decrease because I will use my free time for outdoor activities.

[Andrzej Szymkowicz]

Good news. 

I'll keep my fingers crossed :-)

Regards

[Christian S.]

Short Update:

It's still summer, so I am working on other things. When it gets colder again I have more time for this project.
But my heating unit has been running successfully for weeks with the new version.

[Andrzej Szymkowicz]

OK. Mine also is workig for some time (reads parameters) but quite offten I see such warning:

15:17:37.162 WARN  o.o.b.e.i.c.AbstractEBusWriteConnector[:419]- Resend failed, remove data from sending queue ...

Is this normal?

Other observation is that first data apear few minutes after restarting openhab - it looks like request - response mode doesn't work form me.

Maybe this is a matter of eBus-rs232 adapter.

Regards

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/afbe9d9c-3939-4289-b15a-d5460fde7983%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Andrzej Szymkowicz

[Christian S.]

I optimized the send routine (the collision detection is time critical), so this kind of error should be reduced in the future. But this can happen from time to time and is normal.
I also had trouble with my self welded quick and dirty circuit. From time to time the ebus was still and I got timeouts, than all starts again. With a new ebus adapter all works well.

[Harpinder Sanghera]

Same I get this too. I use the eService ebus to usb coupler. Maybe its not an issue with the adapter

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/2d4336e2-7974-4a5b-ae6e-4018d1b8f020%40googlegroups.com.

[Christian S.]

Yes, I think the eService adapter works well. My first adapter was a minimal version and got very hot.
But maybe I can upload the current state this evening, than you can check the send routine.

I know that sending is important for vaillant devices. With my Wolf heating device there is no need to poll values, because the controller does the work for me. I only need to listen.

[Harpinder Sanghera]

I'd be happy to test it for you

On 7 Jul 2015 15:06, "Christian S." <in...@cs-dev.de> wrote:

Yes, I thing the eService adapter works well. My first adapter was a minimal version and got very hot.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/7b2736fd-56aa-43ca-b6c9-1e1008ab2b71%40googlegroups.com.

[Christian S.]

So, here is the lastest version from today. I hope this will decrease the send issues.
But keep in mind that I changed the json files for wolf and common.

You can now set a value if you use this item syntax:

Switch HW_Standby                 "HZ Programm Standby"         (Outdoor)    {ebus="id:byte, class:bai00, cmd:word.setter"}

Look at parameter cmd, you can set the value by joining the value id with the command id.

Here an extract from dummy json config:

    {
        "comment":    "<DUMMY> DUMMY: Set Timer Program",
        "device":     "DUMMY",
        "id":        "setter",
        "class":    "bai00",
        "command":    "B5 05",
        "data":        "09 00 00 00 00 00 00 00 00",
        "dst":        "08",
       
        "values": {
            "byte":            {"type": "byte", "pos": 7, "label": "Temperatur"},
            "data2b":        {"type": "data2b", "pos": 8, "label": "Temperatur"},
            "data2c":        {"type": "data2c", "pos": 10, "label": "Temperatur", "factor":0.1},
            "word":            {"type": "word", "pos": 12, "label": "Temperatur", "factor":0.01},
            "ms":            {"type": "byte", "pos": 14, "label": "Temperatur"}
        }
    },

The value will be written to the specified position of data bytes.

I know it's to short to understand how it works. I will explain it in detail tomorrow.

[Christian S.]

Hello,

now I updated the wiki documentation to new version. You can alo find the new ID's (https://github.com/csowada/openhab/blob/ebus-update/bundles/binding/org.openhab.binding.ebus/docs/json-configs.md) there.
https://github.com/csowada/openhab/tree/ebus-update/bundles/binding/org.openhab.binding.ebus

The last version ist not compatible, because I created a new parameter "set" instead of enhance"cmd" parameter.
I will add smaller changes this evening and than I'm done with the new version.

[Harpinder Sanghera]

That's great! I will test it later.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/c721c523-1d34-4ce8-aaf5-e5b3f1945008%40googlegroups.com.

[Christian S.]

So, here is the new release.

[Christian S.]

Here a new version with a small bugfix

[nikoraes]

I've tested the latest version for some time now and reading items seems to work. I still get a few collisions sometimes though, and on startup I get a lot of "no data to send" errors, but no real issues.

I don't seem to get the "set" commands working though.

To give an example, below a part of my ebus-config.json

{

"comment": "VRC 470 HC1 Operation mode",

"id": "hc1opmode",

"class": "vrc470",

"command": "B5 09",

"data": "0D 2F 00",

"dst": "15",

"values": {

"hc1opmode": {"type": "uchar", "pos": 12, "label": "HC1 Operation mode (0 = off, 1 = manual, 2 = auto, 3 = on, 4 = night, 5 = summer)"}

}

},

{

"comment": "VRC 470 HC1 Operation mode",

"id": "set_hc1opmode",

"class": "vrc470",

"command": "B5 09",

"data": "0E 2F 00",

"dst": "15",

"values": {

"hc1opmode": {"type": "uchar", "pos": 12, "label": "HC1 Operation mode (0 = off, 1 = manual, 2 = auto, 3 = on, 4 = night, 5 = summer)"}

}

},

And this is the relevant part in my items file

Number CVHC1OpMode "Bedrijfsmodus" (CV) { ebus="id:hc1opmode, class:vrc470, cmd:hc1opmode, dst:15, refresh:300" }

Number CVHC1OpModeSet "Bedrijfsmodus" (CV) { ebus="id:hc1opmode, class:vrc470, cmd:set_hc1opmode, set:hc1opmode, dst:15" }

In my sitemap I've made 2 separate items to test (in Dutch, but should be clear).

Selection item=CVHC1OpMode mappings=[2=Auto, 5=Zomer, 3=Dag, 0=Uit]
Selection item=CVHC1OpModeSet mappings=[2=Auto, 5=Zomer, 3=Dag, 0=Uit]

Reading the current operating mode works perfectly.

Changing the "set" item doesn't do anything though. I see it changes in the event log, but nothing in the ".ebus.internal.parser.Analyses" log indicates anything is being sent on ebus.

I do see that when the regular read item updates again, somehow the "set" item is also updated.

How should this be configured?

Even if it would work, would it then always be required to have 2 separate items in buth the config and the items file? It seems a bit complicated from a user point of view. 

Thank you,

Niko

Op dinsdag 14 juli 2015 22:23:41 UTC+2 schreef Christian S.:

[Christian Sowada]

Hello Niko,

I'm busy but try to help. I think your set "pos" is wrong. I would try pos 8 instead of 12.

{

"comment": "VRC 470 HC1 Operation mode",

"id": "set_hc1opmode",

"class": "vrc470",

"command": "B5 09",

"data": "0E 2F 00",

"dst": "15",

"values": {

"hc1opmode": {"type": "uchar", "pos": 8, "label": "HC1 Operation mode (0 = off, 1 = manual, 2 = auto, 3 = on, 4 = night, 5 = summer)"}

}

},

The other point with the two items is right, i will think about it. I already tried to solve this issue, but I'm not sure where i stopped.

To view this discussion on the web visit https://groups.google.com/d/msgid/openhab/8ae398a6-790a-41db-a488-3ee3e302af1a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Mit freundlichen Grüßen

Christian Sowada