Help decoding VR33 heat demand

[codeaholics]

I have a Vaillant EcoFit Pure boiler with a VR33 OpenTherm to eBus adapter.

The boiler parameter d.09 shows the flow temperate demand sent from the VR33. But I cannot find any of the existing csv/inc files which show that properly. Those that say they show d.09 don't appear to show the right value.

I believe a better way to capture this data is to get it from the VR33 itself, since it must be sent from the VR33 to the boiler. I think I've found the message, but I can't work out how to write the message format for it. (Actually, someone else found it, but I don't appear to be able to tag him for credit!)

From a grab, I have these:

7f08b51009000014ffff0001ff00 / 0101 = 21: bai Mode
7f08b5100900005affff6400ff00 / 0101 = 171: bai Mode
7f08b51009000086ffff0000ff00 / 0101 = 3: bai Mode
7f08b5100900008affff0000ff00 / 0101 = 2: bai Mode
7f08b5100900008cffff0000ff00 / 0101 = 3: bai Mode
7f08b5100900008effff0000ff00 / 0101 = 2: bai Mode
7f08b51009000090ffff0000ff00 / 0101 = 3: bai Mode
7f08b51009000092ffff0000ff00 / 0101 = 1: bai Mode
7f08b51009000094ffff0000ff00 / 0101 = 1: bai Mode
7f08b51009000096ffff0000ff00 / 0101 = 2: bai Mode
7f08b51009000098ffff0000ff00 / 0101 = 3: bai Mode
7f08b5100900009affff0000ff00 / 0101 = 3: bai Mode
7f08b5100900009cffff0000ff00 / 0101 = 1: bai Mode
7f08b5100900009effff0000ff00 / 0101 = 4: bai Mode
7f08b510090000a0ffff0000ff00 / 0101 = 2: bai Mode
7f08b510090000a2ffff0000ff00 / 0101 = 1: bai Mode
7f08b510090000a4ffff0000ff00 / 0101 = 2: bai Mode
7f08b510090000a6ffff0000ff00 / 0101 = 3: bai Mode
7f08b510090000a8ffff0000ff00 / 0101 = 2: bai Mode
7f08b510090000aaffff0000ff00 / 0101 = 3: bai Mode
7f08b510090000b4ffff0000ff00 / 0101 = 37: bai Mode

7f is the VR33, and 08 is the boiler. B510/00 is already decoded in hcmode.inc, but I believe this is decoding the response (0101) and, interestingly, it never seems to have any other value on my boiler.

I think the data I'm interested in is here:

7f08b510090000[b4]ffff0000ff00 / 0101 = 37: bai Mode

I think this is a D1C encoded byte. You can see the (decoded) values range from 10 (no demand) to 90 (full demand, limited by the boiler configuration to 75). But, it's in the request side of the message. Specifically, the VR33 seems to broadcast this message fairly regularly with the desired flow temperature in it, and the boiler appears to respond with 0101 every time!

How do I decode this message correctly given B510/00 already exists, and the data I want is in the request side of the message?

[codeaholics]

OK, I'm making progress, but I still need some help.

Here are my devices:

> ebusctl i
version: ebusd 3.0pre.7a569e2
update check: revision 9420946 available, different configuration files available
signal: acquired
symbol rate: 23
max symbol rate: 157
reconnects: 0
masters: 3
messages: 197
conditional: 2
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0610;HW=1303", loaded "vaillant/bai.0010015600.inc" ([PROD='0010020398']), "vaillant/08.bai.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 7f: master #24
address 84: slave #24, scanned "MF=Vaillant;ID=OTS00;SW=0205;HW=9101", loaded "vaillant/84.ots.csv"

> ebusctl scan result
08;Vaillant;BAI00;0610;1303;21;17;15;0010020398;1300;505266;N1
84;Vaillant;OTS00;0205;9101

If I comment out the B510 (Operation mode) line from hcmode.inc and create an 84.ots.csv file with the following content, it works, except, of course, the Mode decode doesn't happen:

u,ot,TargetFlowTemperature,,,08,B510,00,,m,IGN:1,,,,TargetFlowTemperature,m,temp1,,,,

(For some reason I haven't figured out yet, the ZZ field is important).

Now, if I re-instate the line from hcmode.inc and do ebusctl reload, nothing changes. In particular, the Mode messages aren't matched. Restarting also has the same effect. (At some point I was getting "duplicate ID" errors, but now I'm writing this message, I can't reproduce them!)

> ebusctl find -V -i B51000
bai Mode = mode=standby [ZZ=08, lastup=2017-06-14 15:01:50, active read]
ot TargetFlowTemperature = TargetFlowTemperature=10.0 °C [temperature] [ZZ=08, lastup=2017-06-14 15:03:25, passive read]

(In the example above, the Mode message was grabbed after the 08.bai.csv file was loaded, but before the 84.ots.csv file was loaded.)

In an effort to make both work, I extended the ID part of my definition from 00 to 0000 (and dropped the IGN:1 field that was skipping that byte):

u,ot,TargetFlowTemperature,,,08,B510,0000,TargetFlowTemperature,m,temp1,,,,

Still nothing changes. I get TargetFlowTemperature messages, but none of the old Mode messages:

> ebusctl find -V -i B51000
bai Mode = mode=standby [ZZ=08, lastup=2017-06-14 15:09:06, active read]
ot TargetFlowTemperature = TargetFlowTemperature=38.0 °C [temperature] [ZZ=08, lastup=2017-06-14 15:10:06, passive read]
>ebusctl find -V -i B5100000
ot TargetFlowTemperature = TargetFlowTemperature=38.0 °C [temperature] [ZZ=08, lastup=2017-06-14 15:10:06, passive read]

It's not obvious to me why a rule for B510 00 has been created when the file only specifies B510 0000.

So, at the moment, I have no way of getting both decodes. In essence, I guess it's simply that a message gets matched against one rule and then doesn't get tried against any others.

In order to try and get the old Mode message back, I dropped my 84.ots.csv file completely, and changed hcmode.inc as follows:

r,,Mode,Operation mode,,,B510,00,mode,,UCH,0=off;1=standby;2=heat;3=water,,,,m,IGN:1,,,,TargetFlowTemperature,m,temp1,,,,

> ebusctl r Mode TargetFlowTemperature
38.0
> ebusctl r Mode
38.0;standby

This works, but from an engineering perspective, it gives me a couple of issues:

1. The fact that the target flow temperature is a field inside "Mode" is kind of weird.
2. Who knows what I might have broken for anybody else depending on "Mode"
3. I have no idea whether every Vaillant device (hcmode.inc is pretty much included from everywhere) can send a message that looks like this, or what it would mean if it were sent from a boiler.

So, I'm further forward in terms of having figured out how to get values from the request side of the message, but it feels like I should be able to define two different rules for parsing this message and have them both work, but I can't.

Help, please!

[codeaholics]

Thinking about this some more, in general I think it would be useful to allow a given message to be decoded by multiple rules. For example, I can request StateNumber and it gives me the traditional Vaillant status code (S.04 for heating, S.07 for overrun, etc.) as a number (e.g. 4, 7, etc.)

I would be nice to also be able to have a StateNumberText (or StateText) rule which uses a UCH type to turn those numbers into words.

My understanding is that this currently can't be done.

[MikiDi]

I also have come across this already ... With the latest commits however an option to be able to push messages to an mqtt broker was added. The ebusd-mqtt client has the option --mqtttopic=TOPIC, which, if set to /%circuit/%name/%field, publishes all message fields to a separate topic that has the field name in it.

Having the fieldnames available with messages in TCP-client would indeed be very useful. (pushing similar json-format as in the HTML-client through the TCP-client maybe? That way all messages including field names are received live without having to poll the HTML-client.)

[john30]

to be honest, I didn't read your whole story, it's just too much information mixed with irrelevant stuff. did you have a look at the many wiki pages already? a lot is explained there and I just don't have the time to answer so many questions individually every time. if you didn't have a look at it yet and really want to dive deep into message definition: read it!

anyway, as far as I understood, you want to decode the message 7f08b5100900005affff6400ff00 / 0101. now this message contains most of the relevant data in the master part, as you already noticed, since the slave (heating circuit) usually just answers with "01". the defintion of the message in hcmode.inc already covers a bit of the interesting part of the message, which starts at the second byte of the master DD: 005affff6400ff00 The first byte is supposed to be the operation mode, which is coded as UCH and mapped to a list of key/value pairs (which answers your last comment: you can use "ebusctl read -n mode" in order to get the numeric values instead of the resolved key/value). I am already working on a more appropriate definition of that message. You might want to try this one: *uw,,,,,,"B510",,,,,,, uw,,ModeDesired,Betriebsart,,,,00,,,hcmode,,,,flowtempdesired,,temp1,,,,hwctempdesired,,temp1,,,,hwcflowtempdesired,,temp0,,,,,,IGN:1,,,,disablehc,,BI0,,,,disablehwctapping,,BI1,,,,disablehwcload,,BI2,,,,,,IGN:1,,,,remoteControlHcPump,,BI0,,,,releaseBackup,,BI1,,,,releaseCooling,,BI2,,,,

[codeaholics]

I'm not sure I've ever seen anyone accuse somebody of putting too much information in a ticket before, and, to be honest, calling it irrelevant is rather rude, IMHO. The information is there 1) to demonstrate that I've actually tried to solve the problem myself and not just thrown my arms up in the air and demanded someone else solve it for me, and 2) to help you understand what I've tried so that your time isn't wasted suggesting things I've already tried.

Yes, I've read the wiki. Do you think I'd have got this far just with blind luck?

I'm away from home at the moment, so I'll respond to your suggestion once I've had a chance to look at it in detail and try it.

[john30]

I didn't accuse you in any way and I sure didn't want to be mean. Sorry if that came across in the wrong way! Instead I just wanted to point out that I don't have the time to answer to such a huge amount of questions, tries, findings and stuff thoroughly. Since I'm the only developer in this project, the number of messages I have to answer every week significantly influences the time I can spend on development. Today I had to answer around 20 messages and there was just no time left for developing.

[andig]

@john30 totally offtopic but your efforts are highly appreciated!