Problem with SET commands

[WojtusJ]

Hi,

I have successfully installed VControld and and it actually works when it coms to reading things - like outside temperature, water temperature, water pump status, etc. The problem is that I am not able to perform any actions using GET commands - for example I failed running "setBetriebPartyM1 1" or "setPumpeStatusZirku 1". When I run set command I get:

vctrld>setBetriebPartyM1 1
ERR:
>FRAMER: Command send
<RECV: read timeout
>FRAMER: read failure
Fehler recv, Abbruch
Fehler beim ausfuehren von setBetriebPartyM1 1

I have Vitodens 200-W (B2HB) with Vitotronic 200 (HO2B). I used configuration files under "~/xml-32/xml_p300" and set DEVICE ID to "20CB".

Am I doing something wrong, or it's some general issue?

[philverh]

First make sure you have the latest version of vcontrold running. The current version should show something like Version: 0.98.9-2-g09b789e when executing the "version" command. That will ensure you have all the fixes which went into vcontrold.

As a rule, "set" commands work without problems, if:

• the definition is correct for the device you are trying to control (protocol, address, length, type). vito.xml is device dependent

• the value is one of the supported values. Again this is influenced by the definition in vcontrold.xml/vito.xml

• the address supports to be written on your device. Many Viessmann addresses are defined as read-only, such as for example the "status" of different elements.

Check the vito.xml you are using to make sure it contains the correct commands for a 20CB device.

[WojtusJ]

Hi philverh,

Thank you for the response, I think I have the latest version as this is a pretty fresh installation: Version: 0.98.2_IPv6 I was not able to get "setPumpeStatusZirku" to work, but I managed to run "setBetriebPartyM1" because I found somewhere in the internet that the address should be "2330" instead of "2303" as it was originally in VITO.XML and I had to change:

<macro name='SETADDR'>
<command>SEND 01 F4</command>
</macro>

to

<macro name='SETADDR'>
<command>SEND 00 02</command>
</macro>

I'm not sure if my heater is different, or it is an error in VITO.XML and VCONTROLD.XML?

Anyway, still I'm struggling with circulation, I tried to use setTimerZirku commands (as getTimerZirku work), but I keep getting errors like:

vctrld>setTimerZirkuDi 22:00 23:00
ERR: >FRAMER: addr was still active FE06
>FRAMER: Command send
>FRAMER: unexpected length 2 02
Fehler recv, Abbruch
Fehler beim ausfuehren von setTimerZirkuDi 22:00 23:00
vctrld>

Any chance you could advice to me what to do about it?

[WojtusJ]

A little update on the above. Even though the execution returned an error the times have been changed according to the request. So it actually work. The question is what to do in order to not get the error in return?

[philverh]

"send 01 F4" is a SETADDR command for the KW2 protocol if I'm not mistaken. "send 00 02" is the same but for the P300 protocol... Check your vcontrold.xml, to make sure it has all the required commands for the protocol you need, and your vito.xml to make sure you defined your device with a reference to the correct protocol. In my vito.xml I have the following in the first few lines: ... <vito> <devices> <device ID="2046" name="Vitocal 300-G with WPR-300 controller, VBC700_BW_WW" protocol="P300"/> </device> ... Notice the protocol="P300" at the end of the device statement, which refers to the protocol named "P300" in vcontrold.xml. I actually also commented out the KW2 and GWG protocols in vcontrold.xml, as I don't need them for my device.

As for the version of vcontrold you ar using, there are many fixes which went in between 0.98.2 and 0.98.9.2 I would first get the latest version of vcontrold, then make sure vcontrold.xml and vito.xml are OK for the exact heating device you have, as each device uses different addresses and command subsets.

[WojtusJ]

I have updated to the newest version and the problem still exists. I have picked the right protocol, because other commands work fine, just the set* schedule commands behave in a strange way - that is they return error mentioned above but the action they are supposed to perform is done correctly.

Is there any way to turn on some additional debugging or logging to see what is going on? Why is the error returned if the command changes correctly what it's supposed to change?

[hmueller01]

Is there any way to turn on some additional debugging or logging to see what is going on? Why is the error returned if the command changes correctly what it's supposed to change?

Yes, use debug on.