Howto write installer registers on ecoTEC plus?

[andig]

To improve the behaviour of my VRC700 I need more control about desired values, FlowsetHcMax being one that appears easier to modify. Unfortunately, any write access is without effect (access level is granted):

ebusctl -s nas.fritz.box r FlowsetHcMax
64

ebusctl -s nas.fritz.box w -def 'wi,BAI00,FlowsetHcMax,,,"08","B509","0e0e04",,,uin,,,' 60
done

ebusctl -s nas.fritz.box r FlowsetHcMax
64

Here's the corresponding bus log:

2018-10-20 09:40:14.895 [bus notice] >3108b509030d0e046c<00024003e7>00
2018-10-20 09:41:43.629 [bus notice] >3108b509050e0e043c0028<000000>00

Now, I've tried to use VRC700 as sender address 15 instead, none of which is working:

ebusctl -s nas.fritz.box w -s 15 -def 'wi,BAI00,FlowsetHcMax,,,"08","B509","0e0e04",,,uin,,,' 60
ERR: invalid address

ebusctl -s nas.fritz.box w -def 'wi,BAI00,FlowsetHcMax,,"15","08","B509","0e0e04",,,uin,,,' 60
ERR: bad definition: temporary:2: ERR: invalid address, qq 15

Maybe I'm using the wrong sender address for "faking" QQ:

address 00: master #1
address 03: master #11
address 05: slave #1, scanned "MF=Vaillant;ID=COM00;SW=1203;HW=3103"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0609;HW=5502", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0510;HW=6403", 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", loaded "vaillant/52.vr_70.csv"

I've verified though that basically every bus message that is not from ebusd is sent by either 00, 03, 10 or 52(VR70). Not a single one is sent by the VRC700 as scanned above?

I would appreciate and hint how to further tweak sending wi writes to the bus.

[john30]

the sender address always has to be a master address, so 15 is not valid but 10 is.

[andig]

I've tried all master addresses using -s <id>, to no avail. Write reports done but FlowsetHcMax isn't changed. Retried after https://github.com/john30/ebusd-configuration/pull/107 was merged and active.

Is there any known secret to writing installer messages or is my bai just too stubborn?

[john30]

maybe the definition isn't right. the data is a "temp" field based on D2C according to bai.0010015600.inc, so it consists of 2 bytes and the value is signed and divided by 16. so for an actual temperature of 60 degrees the value in UIN notation is 960. the bai knows for each register the valid value range and will probably recognize that 60 (as UIN) is out of range.

[andig]

Not sure what you mean. Its properly decoded to the expected value when reading. Same problem after using the updated ecotec file, i.e. without custom definition. Also same problem for basically every installer value I‘ve tried to write to. It looks as if the bai just won‘t let me in. Maybe ˋ0eˋ is the wrong prefix for installer writes?

[andig]

@john30 to be clearer: the problem persists even when not using custom message definitions. I can read basically all installer parameters and the values appear plausible. I can however not write a single one although ebusctl always shows done.

I had the idea to observe bus writes to installer messages but couldn‘t find one that actually is triggered by another unit.

I‘m beginning to get a little desparate and thought about trying other pbsb prefixes than 0e already but that seemed a little dangerous.

Would you happen to have any other idea? Different templates for writing than reading???

[john30]

yes thats an option. please post the result of ebusctl f -f -a FlowsetHcMax

[andig]

Here we go:

pi@server:~ $ ebusctl -s nas.fritz.box f -f -a FlowsetHcMax
r,bai,FlowsetHcMax,d.71 Max. Vorlauftemp. Heizbetrieb,,08,b509,0d0e04,temp,s,D2C,,°C,Einstellung des maximalen Vorlaufsollwert im Heizbetrieb (bei Linksanschlag des Poti)
w,bai,FlowsetHcMax,d.71 Max. Vorlauftemp. Heizbetrieb,,08,b509,0e0e04,temp,m,D2C,,°C,Einstellung des maximalen Vorlaufsollwert im Heizbetrieb (bei Linksanschlag des Poti)

[john30]

ok then I don't understand why you were using UIN as data type during the write test. as mentioned before, the value range is totally different with these two types

[andig]

I can read basically all installer parameters and the values appear plausible.

I have to correct myself. I've found ReturnRegulation which is onoff and I can write it! So its not as if the bai would prevent this in principle.

[andig]

ok, I've tried something very stupid:

for i in {0..255};do echo "$i: " $(ebusctl -s nas.fritz.box w -c bai partloadhckw $i >/dev/null && ebusctl -s nas.fritz.box r -f partloadhckw); done

The result was always 3 (which is the limit set in the bai) or $i. The funny thing is this:

It looks as if the max power (violet) actually was changed (the orange temperature followed) though it could not (immediately) be read?

[john30]

maybe it writes to internal storage after a certain delay only, so you could try with waiting for lets say 10 or 30 seconds before reading again

[andig]

Closing this one as no longer an issue for me. Instead of fiddling with the BAI controls, I've fixed the physical problems in the heating installation and do no longer need this level of control.