-
-
Notifications
You must be signed in to change notification settings - Fork 132
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
Comments
the sender address always has to be a master address, so 15 is not valid but 10 is. |
I've tried all master addresses using Is there any known secret to writing installer messages or is my bai just too stubborn? |
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. |
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? |
@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??? |
yes thats an option. please post the result of |
Here we go:
|
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 |
I have to correct myself. I've found |
ok, I've tried something very stupid:
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? |
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 |
Closing this one as no longer an issue for me. Instead of fiddling with the |
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.
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!
Here's the parameter definition that worked for me:
(note: I changed to "r1" because I wanted to read out this parameter more frequently) |
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):Here's the corresponding bus log:
Now, I've tried to use VRC700 as sender address
15
instead, none of which is working:Maybe I'm using the wrong sender address for "faking"
QQ
:I've verified though that basically every bus message that is not from ebusd is sent by either
00
,03
,10
or52
(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.The text was updated successfully, but these errors were encountered: