Vaillant ecoTec current heating power?

[andig]

Stock display of the ecotec shows the currently used heating power using a small pictogram. I've tried to find the source register (something with either a power value or a percent value) in the bai registers but no success.

Does anybody know where this value might come from?

[john30]

did you check ModulationTempDesired (which is a percentage value) multiplied by PartloadHcKW?

[andig]

ModulationTempDesired is a good start however the 2nd register doesn't exist although it's defined:

pi@raspberrypi:~ $ ebusctl read PartloadHcKW
ERR: invalid position

I've also found a range of other regs that show ERR if those are of interest I'd be happy to somehow export the list of errors. This is my installation:

pi@raspberrypi:~ $ ebusctl info
version: ebusd 2.3.a991a37
signal: acquired
symbol rate: 83
reconnects: 0
masters: 3
messages: 557
conditional: 3
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0609;HW=5502", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903"

[john30]

what is your exact product number? you can find that out by issuing a scan and then retrieving "scan result". And please post the result of "ebusctl grab result all|grep PartloadHcKW".

[andig]

ebusctl scan full
ebusctl scan result

08;Vaillant;BAI00;0609;5502;21;16;39;0010019268;0001;007789;N5
15;Vaillant;70000;0209;4103;21;16;32;0020171314;0082;044996;N2
52;Vaillant;VR_70;0109;2903;21;16;40;0020184843;0082;015594;N4
ec;Vaillant;70000;0209;4103;21;16;32;0020171314;0082;044996;N2

grab sofar (updated 12/9):

0315070400 / 0ab5373030303002094103 = 52: scan.15
10feb516080013281809120516 = 1567: broadcast vdatetime
10feb51603014009 = 1567: broadcast outsidetemp
1008b5110100 / 08c2021531040f0081 = 1567
1008b5160111 / 00 = 1
1052b5160111 / 090103010e0130010301 = 1
1052b5230103 / 0f0080008000800080a0025102c87d00 = 9365
1008b5040100 / 0a00ffffffffffffff4009 = 1567: bai DateTime
1008b51009000059ffffff000000 / 0101 = 9382: bai Mode
1008b5110101 / 09594e4009ff6d0100ff = 9314: bai Status01
1008b5110102 / 06033c96468c6e = 3133: bai Status02
1008b512020000 / 00 = 1238
1008b512020064 / 00 = 329
1008b5120204ff / 0101 = 1567
1008b513020508 / 00 = 156
1008b5100305ff01 / 0101 = 1567
1052b5030c0700ffffffffffffffffffff / 0101 = 104
1052b516081000ffff03042120 / 0b2000ff0304882100000000 = 3
1052b516081002ffff03046121 / 0b2201ff03046a2100000000 = 28
1052b52309000101000202000000 / 0101 = 1
1052b5230402010000 / 02019c = 2867
1052b5230402010147 / 020105 = 591
1052b523040201014a / 0201dd = 654
1052b523040201014b / 0201dd = 648
1052b5230402010148 / 0201fb = 2206
1052b5230402010149 / 02011e = 213
1052b523040200014e / 020137 = 680
1052b523040201014e / 020128 = 682
1052b523040200014f / 02015f = 1590
1052b523040201014c / 020137 = 954
1052b523040200014d / 02010f = 230
1052b523040201014d / 020141 = 460
1052b5230402000150 / 020128 = 264
1052b5230402000151 / 020123 = 103
1052b5230402010157 / 0201ec = 99
1052b523040200015a / 020164 = 78
1052b523040200015b / 020164 = 130
1052b5230402000158 / 020150 = 593
1052b5230402000159 / 020114 = 2129
1052b523040200015e / 020105 = 412
1052b523040200015f / 020105 = 891
1052b523040200015c / 020164 = 406
1052b523040200015d / 020128 = 162
1052b5230402000162 / 020164 = 391
1052b5230402000163 / 020164 = 682
1052b5230402000160 / 020164 = 290
1052b5230402000161 / 02010a = 291
1052b523040200016f / 02010f = 51
1052b5230801ffffffffffff00 / 0101 = 9346

[john30]

@andig okay, your BAI is too new (produced end of September) so that it will get bai.308523.inc as fallback configuration. That explains why many of the messages don't fit (report an ERR of any kind).

[andig]

Shall I just try to read any register defined or is there a better way for systematically finding the errors?

[john30]

to be honest I wouldn't look so much for finding the errors, but rather try to determine the meaning of the messages in hex instead. for your BAI, most of the messages just don't fit at all and could mean something totally different. there might be a little chance that messsages defined identically in all of the bai.*.inc files are valid for your BAI as well. you could also checkout the manuals of the variants and try to find common settings there. it's all pretty exhausting work to do...

[andig]

I've read through https://github.com/john30/ebusd/wiki/HowTos to understand the decryption process and got as far as master request / slave response. What does the = part tell me?

[john30]

the number behind the equal sign is how often that message was seen, see https://github.com/john30/ebusd/wiki/3.-Commands#grab

[andig]

Thanks. Closing for time being- will report anything I can find out and check back often.

[andig]

Back to these messages:

1052b5230402010148 / 020123 = 683
1052b5230402010149 / 020100 = 797
1052b523040200015a / 020164 = 683
1052b523040200015b / 02014b = 797

1052b5230801ffffffffffff00 / 0101 = 1480
1052b5230103 / 0f0080008000800080c102b602c87d00 = 1512

They're all addressing the mixer (52?). In the first block they're all 230402 and they're executed quite heavily. After that it's 0101or 0001followed by 48,49,5a or 5b.

Wondering what those are- not temperatures I guess?

Funnily grap creates much less messages than 2 days ago?

[john30]

do you have both outputs of V70 connected? then the first differing byte in the master would probably be the index of the two outputs and for each output the message is sent every 10 seconds. from the values following I guess the second output is hot water and the first would be a mixer. the values themselves could be a percentage of valve opening/closing for the mixer (maximum is 100 in dec) and something similar including off (00) for the hot water. the answer might be the pump on/off state followed by the current difference to the desired position as signed single byte.

[andig]

do you have both outputs of V70 connected?

Yes. And I can already read the status of the VRC700 (pump state plus mixer movement)- so it should be possible to compare the values?

from the values following I guess the second output is hot water and the first would be a mixer

hc1 is Heizkörper and hc2 is Fußbodenheizung. Hot water is done by the boiler itself and not the VC70.

the values themselves could be a percentage of valve opening/closing for the mixer (maximum is 100 in dec) and something similar including off (00) for the hot water.

Doesn't the valve have differential encoding, that is plus/minus for direction instead of absolute position? That's what the VRC700 seems to indicate at least?

the answer might be the pump on/off state followed by the current difference to the desired position as signed single byte.

The pumps are off over night so we should see some zeros which is not the case. As for position I really don't know if the valves are aware of position?

Here's a couple more:

1052b5230402 00 01 45 / 0201 14 = 733
1052b5230402 00 01 46 / 0201 41 = 114
1052b5230402 00 01 47 / 0201 46 = 292
1052b5230402 00 01 48 / 0201 46 = 287
1052b5230402 00 01 49 / 0201 32 = 1444

1052b5230402 00 01 58 / 0201 4b = 129
1052b5230402 00 01 59 / 0201 55 = 107
1052b5230402 00 01 5a / 0201 55 = 723
1052b5230402 00 01 5b / 0201 4b = 2082
1052b5230402 00 01 5c / 0201 05 = 323
1052b5230402 00 01 5d / 0201 37 = 108
1052b5230402 00 01 5e / 0201 64 = 692

1052b5230402 01 01 38 / 0201 00 = 172
1052b5230402 01 01 39 / 0201 05 = 782
1052b5230402 01 01 3a / 0201 0f = 465
1052b5230402 01 01 3b / 0201 0f = 1436

1052b5230402 01 01 47 / 0201 14 = 129
1052b5230402 01 01 48 / 0201 05 = 830
1052b5230402 01 01 49 / 0201 23 = 2345
1052b5230402 01 01 4a / 0201 37 = 586
1052b5230402 01 01 4b / 0201 14 = 273

[andig]

@john30 I know how to change the load limit via the device itself (3kw, 4kw etc). Could you point me to the ebusctl command needed for motoring the bus for specific unknown commands of the bus that I could issue to track down the partial load command for the ecoTEC? Would also appreciate a quick hint how to set the value once identified.

And... are you accepting donations?

[john30]

you could just look for "unknown" in the ebusd log and of course monitor changes in the grab result. If you can change the value n the controller, then issue a grab result before doing the change and compare that to the grab result after doing the change. sure, have a look at the wiki :-)

[andig]

you could just look for "unknown" in the ebusd log and of course monitor changes in the grab result.

No success. I have done a ebusctl grab followed by ebusctl grab result | sort wrapped in watch -n 1. I can't see any messages popping up when I change the limit value- I do see other unknowns though.

Is it possible that ebusd already thinks it knows the message in question but isn't able to properly read it? See here:

pi@raspberrypi:~ $ ebusctl r PartloadHcKW
ERR: invalid position in decode

So maybe it wouldn't appear as unknown?

update I've also tried with grab result all, same thing. Is it possible that changing the limit doesn't generate any ebus message??

[john30]

yes sure, as said, the CSV is not valid for your device, it's merely used as fallback, but you can't rely on the definitions set therein. you could try to comment out the PartloadHcKW line in the bai.308523.inc, then issue a "ebusctl reload", and afterwars do the exercise with the grab again.

Is it possible that changing the limit doesn't generate any ebus message??

yes, that's possible, too. where do you actually set the limit? directly on the heater or in a controller?

[andig]

you could try to comment out the PartloadHcKW line in the bai.308523.inc, then issue a "ebusctl reload", and afterwars do the exercise with the grab again.

No success. Grab result doesn't show anything when changing it.

yes, that's possible, too.

Yikes!

where do you actually set the limit? directly on the heater or in a controller?

Directly in the boiler, it has a small controller/display unit, too. Its separate from the VRC700.

[john30]

Directly in the boiler, it has a small controller/display unit, too. Its separate from the VRC700.

then that's clearly why there is no message on the bus...

[andig]

Some further observations on the ecoTEC plus:

2016-12-29 18:08:25.269 [update notice] update bai Status01 QQ=10: 53.5;48.5;3.250;-;51.5;on
2016-12-29 18:08:25.839 [update notice] update bai Mode QQ=10: standby

Mode definition is imho wrong (0=off;1=standby;2=heat;3=water) unless it implies something else. When Status01 shows on the bai is running in heating mode- Status02 should be heat then instead of standby? I've also verified that Status01=on always goes with StateNumber=4 which is consistent.

[john30]

the correction of mode for heat circuits is already in progress

[andig]

the correction of mode for heat circuits is already in progress

@john30 has this been done so we can close this issue?

[john30]

hm, I've started it but never finished it I'm afraid. someone willing to test drive new definitions?

[andig]

hm, I've started it but never finished it I'm afraid. someone willing to test drive new definitions?

Sure, just let me know what to test.

[andig]

ping @john30 ready to close this one unless you want to keep it open for the mode tests

[john30]

lets do the mode testing separately