Closed andig closed 4 years ago
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 -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?
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.
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 ebusctl f -f -a FlowsetHcMax
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)
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 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.
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?
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 BAI
controls, I've fixed the physical problems in the heating installation and do no longer need this level of control.
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.