vcontrold error output

[hmueller01]

Currently I have a lot of communication problems with my vito. But this is another story.

I use vclient --host localhost --port 3002 -f vito-commands.txt -t vito-update.tmpl.py -x /dev/shm/vito-update.py to create a Python script with the data read from vito. If there is a communication error the corresponding value in vito-update.tmpl.py is replaced by e.g.

ERR: >FRAMER: could not close (3 attempts)
Error opening /dev/vitoir0

The problem is the line break which breaks execution of the Python script. Because there are lots of data read out of vito it would be nice if the script runs despite the error. So it would be good if vcontrold does not output the error in that case (and leaves the value empty). I quickly tested this by setting errClass always to 99 in common.c::logIT(). But this should be done by a command line switch. Should I use an new switch like -q or should we use e.g. -vwhich is currently not really used (no error output to fd per default, only triggered by switch)?

Or is there another solution which I haven't seen?

[philverh]

Preliminary note : I'm quite new working with the Vito protocols. I may have overseen the obvious. ;-)

I read through the code, and especially the IO.C my_send routine catched my eye. Before sending a byte to the device, the INPUT queue is purged twice before sending data to the OUTPUT.

• The comment speaks about (around line 132) tcflush being unreliable, replacing it with a read call, then still calls tcflush of the input queue. One flush would be enough in my mind.
• The code replacing the "failing" tcflush call uses direct fnctl calls to set and re-set non-blocking mode, while the person who wrote IO.C created functions to handle this. Wouldn't it be more coherent to use the functions defined in IO.C instead of direct fnctl calls.
• Why blindly flushing the INPUT when trying to OUTPUT something? If some reply were received after sending the previous byte in a string, wouldn't it get purged by the following send? This obviously is timing dependent, both on the side of the Viessmann device and also on the device running vcontrold. In this case this would lead to data loss and mainly to protocol misses, requiring constant re-syncs.

Food for thought. I'll take some time to experiment.

[hmueller01]

@philverh You are right. It is strange why tcflush does not work. And I also think using the io.c functions for non-blocking mode is better.

At least in non P300 protocol the vitronic sends 0x05 periodic. This or other bytes might be in the input buffer, so it must be cleared before as we want only the answer to our request ...

But maybe the discussion about the implementation of io.c (and others) might be started in another issue as I like to know what command line option is best if we want to suppress the error output in the normal output. BTW: The errors are still written to syslog. So one can still see that there was something wrong.

[hmueller01]

I was thinking about my suggestion. Meanwhile I think it is better to modify vclient instead of changing the daemon. The issue is only on $Rn variables. What do you think about changing that code in vclient.c line 443 to

                            // if tPtr->raw starts with "ERR:" output only if verbose
                            if (!((verbose == 0) && strncmp(tPtr->raw, ERR, strlen(ERR)) == 0)) {
                                fprintf(ofilePtr, "%s", tPtr->raw);
                            }

So vclient without -v will suppress the output, while telnet or vclient with -v will still show the error.