Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Howto write installer registers on ecoTEC plus? #210

Closed
andig opened this issue Oct 20, 2018 · 13 comments
Closed

Howto write installer registers on ecoTEC plus? #210

andig opened this issue Oct 20, 2018 · 13 comments

Comments

@andig
Copy link
Contributor

andig commented Oct 20, 2018

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
Copy link
Owner

john30 commented Oct 20, 2018

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

@andig
Copy link
Contributor Author

andig commented Oct 20, 2018

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

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

@john30
Copy link
Owner

john30 commented Oct 20, 2018

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
Copy link
Contributor Author

andig commented Oct 20, 2018

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
Copy link
Contributor Author

andig commented Oct 21, 2018

@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
Copy link
Owner

john30 commented Oct 24, 2018

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

@andig
Copy link
Contributor Author

andig commented Oct 24, 2018

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
Copy link
Owner

john30 commented Oct 25, 2018

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
Copy link
Contributor Author

andig commented Oct 25, 2018

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
Copy link
Contributor Author

andig commented Oct 30, 2018

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:

screenshot 2018-10-30 at 21 09 04

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

@john30
Copy link
Owner

john30 commented Oct 31, 2018

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
Copy link
Contributor Author

andig commented Nov 4, 2019

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.

@andig andig closed this as completed Nov 4, 2019
@ooghes
Copy link

ooghes commented Sep 28, 2024

Hi all, I tought I'd share my experience with the above issue. I too wanted to configure the max flow temperature on my Vaillant ecoTEC plus boiler. My boiler type didn't have a matching hardware/software version, so the config files did a fallback to "bai.308523.inc", just like in the above comments. In this file, FlowsetHcMax is defined at address 0x0E04.
Using that address, I got the very same phenomenon:

ebusctl r -c bai r FlowsetHcMax
60
ebusctl w -c bai FlowsetHcMax 55
done
ebusctl r -c bai r FlowsetHcMax
60

So one can read, but not write.

I started playing around with the other bai.xxx.inc configuration files and noticed that in some of them, a different address is used, i.e. 0xA500. When testing my configuration with that address, I was successful!

ebusctl r -c bai r FlowsetHcMax
60
ebusctl w -c bai FlowsetHcMax 55
done
ebusctl r -c bai r FlowsetHcMax
55

Here's the parameter definition that worked for me:

r1;wi,,FlowsetHcMax,d.71 Max flow temperature,,,,"A500",,,temp,,,Adjustment of maximum central heating set point range (maximum end position of potentiometer)

(note: I changed to "r1" because I wanted to read out this parameter more frequently)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants