difficulty with the write command

[minscof]

Hello,

I try to write the SetMode register that has multiple fields. I read that I need to write all the fields.

I read them through the command
ebusctl read -v -c bai SetMode

I get this reply
bai SetMode hcmode=130;flowtempdesired=0.5;hwctempdesired=4.0;hwcflowtempdesired=0;disablehc=0;disablehwctapping=0;disablehwcload=0;remoteControlHcPump=0;releaseBackup=0;releaseCooling=0

then I do
ebusctl write -V -c bai SetMode hcmode 132;flowtempdesired 0.5;hwctempdesired 4.0;hwcflowtempdesired 0;disablehc 0;disablehwctapping 0;disablehwcload 0;remoteControlHcPump 0;releaseBackup 0;releaseCooling 0

and I have these error messages
`usage: write [-s QQ] [-d ZZ] -c CIRCUIT NAME [VALUE[;VALUE]*]
or: write [-s QQ] [-c CIRCUIT] -h ZZPBSBNNDx
Write value(s) or hex message.
-s QQ override source address QQ
-d ZZ override destination address ZZ
-c CIRCUIT CIRCUIT of the message to send
NAME NAME of the message to send
VALUE a single field VALUE
-h send hex write message:
ZZ destination address
PB SB primary/secondary command byte
NN number of following data bytes
Dx data byte(s) to send

-bash: flowtempdesired: command not found
-bash: hwctempdesired: command not found
-bash: hwcflowtempdesired: command not found
-bash: disablehc: command not found
-bash: disablehwctapping: command not found
-bash: disablehwcload: command not found
-bash: remoteControlHcPump: command not found
-bash: releaseBackup: command not found
-bash: releaseCooling: command not found`

Can you help me to find what is wrong with my command or my configuration ?

Thanks

[john30]

the write command does neither support specifying key/value pairs nor the -V option, see wiki.
instead you'd have to do the write like this (in dquotes due to shell):
ebusctl write -c bai SetMode 132;0.5;4.0;0;0;0;0;0;0;0

[minscof]

Thanks for your help

I try this command
ebusctl write -c bai SetMode "132;0.5;4.0;0;0;0;0;0;0;0"

and I get this error
ERR: element not found

and these logs
2018-04-01 20:56:20.604 [bus error] prepare message part 0: ERR: element not found
2018-04-01 20:56:20.604 [main error] write bai SetMode: ERR: element not found

however, if I do
ebusctl f -w

the reply shows that SetMode exists
bai clearerrorhistory = no data stored bai DSNOffset = no data stored bai FlowsetHcMax = no data stored bai FlowsetHwcMax = no data stored bai SetFactoryValues = no data stored bai SetFlowTempMax = no data stored bai SetFlowTempMin = no data stored bai SetMode = no data stored broadcast id = no data stored broadcast queryexistence = no data stored memory eeprom = no data stored memory ram = no data stored

What I have to do ?

Thanks

[john30]

you probably have to authorize yourself in order to have that message available, or let ebusd just ignore any authorization stuff (--accesslevel="*")

[minscof]

I have already put accesslevel="*", it is the reason why I open this issue.

What can I do ?

[john30]

check how the message is defined exactly. and check that --accesslevel="*" is correctly added to /etc/default/ebusd

[minscof]

I check what you said

• --accesslevel="*"

is set in /etc/default/ebusd
and it is ok

You told me to check how the message is defined exactly.

The message is in the hcmode.inc, it is defined for read as well for write. I didn't find where is the problem.

Can you help more ?

[john30]

check the definition with ebusctl f -w -f -e -c bai setmode and post the result

[Mathadon]

I seem to have the same problem. I added --accesslevel=\"*\" in /etc/default/ebusd and ebusctl info returns

version: ebusd 3.2.v3.2-11-g18bd21f
update check: OK
access: "*"
signal: acquired
symbol rate: 23
max symbol rate: 89
min arbitration micros: 3124
max arbitration micros: 5760
min symbol latency: 6
max symbol latency: 10
reconnects: 0
masters: 3
messages: 212
conditional: 3
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0604;HW=1303", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=E7C00;SW=0206;HW=7402"
address 31: master #8, ebusd
address 36: slave #8, ebusd

Writing does not work:

write -c bai SetMode auto;0.0;60.0;-;1;0;0;0;0
ERR: element not found

ebusctl f -w -f -e -c bai setmode returns ERR: element not found.

This does work:

ebusctl read -v -c bai SetMode
bai SetMode hcmode=auto;flowtempdesired=0.0;hwctempdesired=60.0;hwcflowtempdesired=-;disablehc=1;disablehwctapping=0;disablehwcload=0;remoteControlHcPump=0;releaseBackup=0;releaseCooling=0

any ideas on how to write to that register?

[john30]

@Mathadon actually, you have to use "--accesslevel=*" instead

[Mathadon]

I tried that but then ebusctl info does not contain access: "*" as posted above. That's correct?

In any case, I still get

write -c bai SetMode auto;0.0;60.0;-;0;0;0;0
ERR: element not found

btw: from a user point of view it is not clear what it means that 'element is not found'. I.e. does it not find 'bai' or 'SetMode', or?

edit:
In both cases I get:

f -w    
broadcast id = no data stored
broadcast queryexistence = no data stored

while f -r returns about a hundred results from bai, general, memory and scan.

[john30]

then please post the content of /etc/default/ebusd or the command line you were using.
"element not found" is a hint that there is no message with the given search criteria. so I'd say it pretty well describes the issue. the search criteria is made of "bai" being the circuit and "SetMode" being the name of the message. If that's not available there is not much that can be done from ebusd point of view.
since "f -w" does not include the message, the client either does not have the rights to see it or it wasn't even loaded at all.

[Mathadon]

Okay, so if I understand correctly then 'element' refers to the message name and ebusd does not recognize SetMode (despite that it does read it messages with the same name)?

Contents of /etc/default/ebusd:

# /etc/default/ebusd:
# config file for ebusd service.

# Options to pass to ebusd (run "ebusd -?" for more info):
#EBUSD_OPTS="--scanconfig"
EBUSD_OPTS="--scanconfig --accesslevel=*"

# MULTIPLE EBUSD INSTANCES WITH SYSV
# In order to run multiple ebusd instances on a SysV enabled system, simply
# define several EBUSD_OPTS with a unique suffix for each. Recommended is to
# use a number as suffix for all EBUSD_OPTS settings. That number will then be
# taken as additional "instance" parameter to the init.d script in order to
# start/stop an individual ebusd instance instead of all instances.
# Example: (uncomment the EBUSD_OPTS above)
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd1.log"
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/log/ebusd2.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3.log"

# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /usr/lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.

[john30]

found it:
hcmode.inc:10
the message is defined as passive write ("uw"), i.e. you cannot write it actively with ebusd

[Mathadon]

So the heater does not support writing to it? Then how is the thermostat able to change set points? From the bus traffic it seems that the thermostat is using SetMode to change the setpoints so perhaps the hcmode.inc is wrong? Can I force-write somehow to see whether it works?

[john30]

of course the thermostat is writing to it, but the CSV does not allow you to change it on purpose, because the thermostat will override it again next time, so it does not make sense to write to it with ebusd anyway.
if you want to do it nevertheless, you'd have to remove the "u" of the "uw" in the CSV file.

[Mathadon]

@john30 thanks for the feedback! I'll try that and throw out the thermostat if necessary. The way it looks now, the thermostat does not write all that often so unless the thermostat immediately overwrites my command once it identifies the command then I can just overwrite the thermostat whenever it writes.

From a developer point of view I find this design choice a bit odd though, so some constructive criticism:
For me the whole point of using ebusd is to be able to write on ebus. It seems a bit harsh to disable the write functionality without notice simply because - the way I understand it now - it would not work for a specific heater & thermostat combination unless you do some further thinking. It would for instance be more informative if you return a warning stating that the variable SetMode is not design to be overwritten and therefore you should not expect it to work? And to provide a way to force-write. Right now it looks like ebusd is bugging out and hence users (i.e. me) start making issues instead of dealing with the actual problem. If you agree then I can perhaps look into making a pull request when I find some free time to study the code.

[john30]

please keep in mind that this issue is related to CSV configuration and not to ebusd. so please post complaints about config files in that repo.
and don't forget that especially the configs are very critical and every mistake therein might lead to ruining your devices.

[andig]

I‘ll try exactly the same. My VRC700 has a really ugly behaviour (see
https://www.haustechnikdialog.de/Forum/t/211124/Heizverhalten-Vaillant-ecoTEC-plus-optimieren or contact me if you have similar problems) that I‘d like to fix by using SetMode myself.
While FlowTempDesired is not writable on my BAI although it should be, this can be achieved by SetMode. The VRC700 seems to send SetMode every 5-10 Minutes or so so it might be possible to sneak between those writes. I‘ll need to check if the VRC will pick up another rhythm or allow me to do that...

[andig]

@Mathadon can we exchange thoughts how to create a ´-def´ message definition that would allow writing ´SetMode´?

[Mathadon]

sure, feel free to contact me on < e-mail address removed >

[andig]

Here's what I came up with for a writable SetModeOverride custom message definition:

wi,BAI,SetModeOverride,Betriebsart,,08,B510,00,hcmode,,UCH,,,,flowtempdesired,,D1C,,,,hwctempdesired,,D1C,,,,hwcflowtempdesired,,UCH,,,,,,IGN:1,,,,disablehc,,BI0,,,,disablehwctapping,,BI1,,,,disablehwcload,,BI2,,,,,,IGN:1,,,,remoteControlHcPump,,BI0,,,,releaseBackup,,BI1,,,,releaseCooling,,BI2

Write like this (auto mode, set flowtempdesired):

ebusctl -s nas.fritz.box w -c bai SetModeOverride '0;34;-;-;0;0;0;0;0;0'

This comes WITHOUT ANY WARRANTY

[andr2000]

@andig Could you please confirm that over time your SetModeOverride finding proved to be correct?
Thank you

[andig]

Could you please confirm that over time your SetModeOverride finding proved to be correct?

Confirmed as far as FlowTempDesired is concerned. I didn't use or validate other values but they match the original definition. You'll have to decide for yourself if these are safe to use.

In the end using this didn't work for me since- as John pointed out- SetMode will be overridden by the VRC700 I have anyway.

[andr2000]

hm, in order to test it I changed "wi" to "r", so I can read it and I only have:

~# ebusctl r -f -V SetModeOverride
ERR: invalid position in decode

~# ebusctl grab result all | grep SetMode
3108b5100100 / 0100 = 8: BAI SetModeOverride
3108b5110100 / 08e0011522040f0001 = 109: uw SetMode

Is it possible that your command is for write only and cannot be used for reading?
Anything else I could try to debug?

[andig]

Is it possible that your command is for write only and cannot be used for reading?

It is. You cannot read it as its defined as wi, but opposed to uw you can at least write it now.

The BAI will show you that its working if you take a look by reading FlowTempDesired and the other affected values instead.

[andr2000]

Ah, understood. But at the same time I see that reading SetMode returns 0.5 for FlowTempDesired and this cannot be fixed? So for this reason you read FlowTempDesired directly and don't read SetMode?

[andig]

SetMode is not readable with any of the available configurations: https://github.com/john30/ebusd-configuration/search?q=SetMode&unscoped_q=SetMode

If you're getting results from reading SetMode you should open a new issue with steps to reproduce as this might indicate a bug.

[andr2000]

No bug here, this is because I changed it from "uw," to "r,uw"
Do you think this hack won't help me getting the real SetMode values? Because I'm getting

ebusctl r -f -V SetMode
uw SetMode hcmode=224 [boiler mode];flowtempdesired=0.5 °C [temperature];hwctempdesired=10.5 °C [temperature];hwcflowtempdesired=34 °C [temperature];disablehc=1;disablehwctapping=1;disablehwcload=1;remoteControlHcPump=1;releaseBackup=0;releaseCooling=0

[RadianM]

I've been using @andig writable SetModeOverride custom message definition successfully on the command line i.e.

ebusctl write -c bai SetModeOverride '0;65;-;-;-;0;0;0;-;0;0;0'

It works fine, adjusting the boiler flow temperature as required, although I don't understand why the log shows sent SetMode then write SetModeOverride done:

2023-02-01 15:18:55.759 [update notice] sent update-write bai SetMode QQ=31: auto;65.0;-;-;0;0;0;0;0;0
2023-02-01 15:18:55.760 [main notice] write bai SetModeOverride: done

However, I can't figure outwhy it doesn't work when attempting to do the same write via MQTT:

2023-02-01 15:09:18.477 [mqtt error] received unmatchable topic ebusd/bai/SetModeOverride/set
2023-02-01 15:09:18.650 [update notice] sent update-write bai SetMode QQ=31: auto;65.0;-;-;0;0;0;0;0;0
2023-02-01 15:09:18.650 [mqtt notice] write bai SetModeOverride: 0;65;-;-;-;0;0;0;-;0;0;0

First the log says it's an unmatchable topic, but then it shows sent SetMode as above using the command line and write with the correct parameters. But the boiler does not respond to the message.

I did try wrapping the MQTT data in single quotes as seem necessary for the command line but that throws ERR: invalid numeric argument. Is there a correct way to use SetModeOverride over MQTT?

Edit: Have raised this as a discussion https://github.com/john30/ebusd/discussions/828#discussion-4817256

[dulek]

So I too tried what @andig proposed and it indeed changed FlowTempDesired for a while, but after some time it got reset to what the heater has as a setting and I don't have a VRC700 on the circuit. I wonder if it isn't required to send SetMode periodically.

[dulek]

So I too tried what @andig proposed and it indeed changed FlowTempDesired for a while, but after some time it got reset to what the heater has as a setting and I don't have a VRC700 on the circuit. I wonder if it isn't required to send SetMode periodically.

Oh, just found a comment confirming that:

The boiler will expect you to write an update via setmode at least every 10 mins or it will reset to defaults ( I send an update every 5-10 secs).