wrong length for setTempWWsoll in 300/vito.xml

[philippoo66]

Addr 6300h (TempWWsoll) is a 1-byte value. For the get cmd it is right, for the set cmd len is given as 2 - does not work. https://github.com/openv/vcontrold/blob/master/xml/300/vito.xml greetings!

[l3u]

Thanks for mentioning this, fixed with 7ac1c2494b671095bab06051a367633e6462ca6c

[l3u]

What you said seemed to be reasonable, so I simply changed it … now I actually wanted to test it with my heating ;-)

Turns out this doesn't work here, neither with len 1, nor 2.

How exactly do you invoke vclient to use this?

[l3u]

As of now, the vclient documentation does not tell how to format parameters for set commands …

[philippoo66]

öhm, not sure what you mean. Here it is working for a 20 CB 00 2B. Certainly it depends on your device if hot water setpoint is 'mapped' to 6300h, but it seems to be quite common for the more recent Vitodens. With my 20 CB 1F C9 / F0:01 it is also working. 300 telegram is e.g. 41 06 00 02 63 00 01 2B 97 to set 6300h to 43dec

[philippoo66]

ahh ok (who t f is vclient... ;-) - sorry I never used it.

[l3u]

What do you use then?!

[philippoo66]

I wrote a bloody OptoLinkCommAsync.dll for Windows to 'clean up' ViessData2... (forked from the openv project a long time ago). A completely different matter... But you are right - there should be examples in the vclient docu how a simple job like setting a one-byte parameter is done. I took a quick look at the sources but couldn't figure out how values are expected as parameter. have you tried something like $ vclient -h 127.0.0.1:1234 -c setTempWWsoll 43 ?

[philippoo66]

but probably wouldn't work since the xml file isn't mentioned.... urghs sorry - no idea...

[l3u]

I took a quick look at the sources but couldn't figure out how values are expected as parameter.

Me neither ;-)

[philippoo66]

with my dll it is really easy: "Write1ByteValueA(addr, val)"... no xml, no string command, no worry, simply using....

[philippoo66]

isn't there the 'setaddr' cmd with vcontrold that could be used in a similar way?

[sirtiger]

Hi I3u,

does your vcontrold daemon work correctly? Do you get a correct value when you execute this command (vclient -h localhost:3002 -c getTempA)

Timo

[l3u]

Yeah, of course. My installation has been querying my heating each five minutes for all kind of temperatures for 7 years now ;-)

Maybe, my device simply doesn't support this specific set command.

But: How is a set command intended to be used with vclient at all?! As said, the documentation lacks the syntax, and my C is not good enough to yank it from the sources :see_no_evil:

[sirtiger]

If the get-command work connect the server with this line in the cli. telnet localhost 3002

Now you work with the vcontrold cli. With “help“ command you get a list with commands you can use. The „commands“ command lists all commands from the Vito.xml. For example: with getTempWWsoll you get the target temperature, with setTempWWsoll 55 you set the target temperature to 55 degrees.

Timo

[l3u]

So does this mean this can't be done via vclient, and I do have to use a telnet session (or similar)?

[l3u]

Okay, seems like my device (20CB) simply doesn't support this (or the address differs?!): No matter if the length is 1 or 2, I get:

vctrld>getTempWWsoll
46.000000 Grad Celsius
vctrld>setTempWWsoll 47
ERR: <RECV: read timeout
>FRAMER: read failure
Error in recv, terminating
Error executing setTempWWsoll 47

So the get command works as it should, but the set sommand yields an error …

[sirtiger]

That could be. I tried it but it didn’t work. I use the iobroker with the viessmann adapter. Set temperature works only with the adapter or over telnet.

[sirtiger]

Okay, seems like my device (20CB) simply doesn't support this (or the address differs?!): No matter if the length is 1 or 2, I get:

vctrld>getTempWWsoll
46.000000 Grad Celsius
vctrld>setTempWWsoll 47
ERR: <RECV: read timeout
>FRAMER: read failure
Error in recv, terminating
Error executing setTempWWsoll 47

So the get command works as it should, but the set sommand yields an error …

I havt the 20CB too. You have to change the length to 1 Byte in the Vito.xml

It‘s funny…

[philippoo66]

Hi @ all!

Maybe, my device simply doesn't support this specific set command.

Since WWTemp can get set via ioBroker->vcontrold the device definitely does support.

Is there a way to make vc'd logging what happens when ioBroker sets the value?

Sorry for my lack of understanding - can you explain how things stick together (vc'd, vclient, telnet, ioBroker, CLI)?!

Ok, for ioBroker I read it communicates with vc'd via network port (3002). Most likely vc'd utilizes vito.xml during that since the correction of len in the xml caused ioBroker to be able to set WW Temp. What is communicated via port 3002? commands or telegram bytes?

Isn't this the same with vclient? and with telnet? Is it possible that 'set' commands / set value parameters are not implemented with vclient??

by whom/for what vcontrold.xml is used?

ps. @l3u Tobias could you please 're-correct' the len because it is definitely 1 byte, in both directions (as veryfied by Timo's ioBroker experience)...

thx & greetings! Phil

[sirtiger]

iobroker@iobroker:~ $ telnet localhost 3002
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
vctrld>getDevType
UNKNOWN
vctrld>debug on
vctrld>getTempWWsoll
DEBUG:Mon Feb 13 11:40:32 2023 : Command: getTempWWsoll
DEBUG:Mon Feb 13 11:40:32 2023 : >SENT: 41
DEBUG:Mon Feb 13 11:40:32 2023 : >SENT: 05
DEBUG:Mon Feb 13 11:40:32 2023 : >SENT: 00
DEBUG:Mon Feb 13 11:40:32 2023 : >SENT: 01
DEBUG:Mon Feb 13 11:40:32 2023 : >SENT: 63
DEBUG:Mon Feb 13 11:40:32 2023 : >SENT: 00
DEBUG:Mon Feb 13 11:40:32 2023 : >SENT: 01
DEBUG:Mon Feb 13 11:40:32 2023 : >SENT: 6A
DEBUG:Mon Feb 13 11:40:32 2023 : <RECV: len=1 06 (20.0 ms)
DEBUG:Mon Feb 13 11:40:32 2023 : <RECV: received 06
DEBUG:Mon Feb 13 11:40:32 2023 : >FRAMER: framer_set_actaddr framer_current_addr = 0063 (was FFFF)
DEBUG:Mon Feb 13 11:40:32 2023 : >FRAMER: Command send
DEBUG:Mon Feb 13 11:40:32 2023 : >FRAMER: no preset result
DEBUG:Mon Feb 13 11:40:32 2023 : <RECV: len=1 41 (0.0 ms)
DEBUG:Mon Feb 13 11:40:32 2023 : <RECV: received 41
DEBUG:Mon Feb 13 11:40:32 2023 : <RECV: len=1 06 (0.0 ms)
DEBUG:Mon Feb 13 11:40:32 2023 : <RECV: received 06
DEBUG:Mon Feb 13 11:40:32 2023 : <RECV: len=1 01 (0.0 ms)
DEBUG:Mon Feb 13 11:40:32 2023 : <RECV: len=1 01 (10.0 ms)
DEBUG:Mon Feb 13 11:40:32 2023 : <RECV: len=1 63 (0.0 ms)
DEBUG:Mon Feb 13 11:40:32 2023 : <RECV: len=1 00 (0.0 ms)
DEBUG:Mon Feb 13 11:40:32 2023 : <RECV: len=1 01 (0.0 ms)
DEBUG:Mon Feb 13 11:40:32 2023 : <RECV: len=1 33 (0.0 ms)
DEBUG:Mon Feb 13 11:40:32 2023 : <RECV: len=1 9F (10.0 ms)
DEBUG:Mon Feb 13 11:40:32 2023 : <RECV: received 01 01 63 00 01 33 9F
DEBUG:Mon Feb 13 11:40:32 2023 : >FRAMER: framer_reset_actaddr framer_current_addr = FRAMER_NO_ADDR (was 0063)
DEBUG:Mon Feb 13 11:40:32 2023 : Typ: uchar (in float: 51.000000)
DEBUG:Mon Feb 13 11:40:32 2023 : (FLOAT) Exp: V [B0:33 B1:00 B2:00 B3:00 B4:00 B5:00 B6:00 B7:00 B8:00 B9:00 ]
DEBUG:Mon Feb 13 11:40:32 2023 : 51.000000 Grad Celsius
51.000000 Grad Celsius
vctrld>setTempWWsoll 52
DEBUG:Mon Feb 13 11:40:47 2023 : Command: setTempWWsoll 52
DEBUG:Mon Feb 13 11:40:47 2023 : Send Exp: V [V=52.000000]
DEBUG:Mon Feb 13 11:40:47 2023 : Type: uchar (bytes: 34 )  
DEBUG:Mon Feb 13 11:40:47 2023 : >SENT: 41
DEBUG:Mon Feb 13 11:40:47 2023 : >SENT: 06
DEBUG:Mon Feb 13 11:40:47 2023 : >SENT: 00
DEBUG:Mon Feb 13 11:40:47 2023 : >SENT: 02
DEBUG:Mon Feb 13 11:40:47 2023 : >SENT: 63
DEBUG:Mon Feb 13 11:40:47 2023 : >SENT: 00
DEBUG:Mon Feb 13 11:40:47 2023 : >SENT: 02
DEBUG:Mon Feb 13 11:40:47 2023 : >SENT: 34
DEBUG:Mon Feb 13 11:40:47 2023 : >SENT: A1
DEBUG:Mon Feb 13 11:40:47 2023 : <RECV: len=1 06 (40.0 ms)
DEBUG:Mon Feb 13 11:40:47 2023 : <RECV: received 06
DEBUG:Mon Feb 13 11:40:47 2023 : >FRAMER: framer_set_actaddr framer_current_addr = 0063 (was FFFF)
DEBUG:Mon Feb 13 11:40:47 2023 : >FRAMER: Command send
DEBUG:Mon Feb 13 11:40:47 2023 : >FRAMER: no preset result
DEBUG:Mon Feb 13 11:40:47 2023 : <RECV: len=1 41 (0.0 ms)
DEBUG:Mon Feb 13 11:40:47 2023 : <RECV: received 41
DEBUG:Mon Feb 13 11:40:47 2023 : <RECV: len=1 05 (0.0 ms)
DEBUG:Mon Feb 13 11:40:47 2023 : <RECV: received 05
DEBUG:Mon Feb 13 11:40:47 2023 : <RECV: len=1 01 (10.0 ms)
DEBUG:Mon Feb 13 11:40:47 2023 : <RECV: len=1 02 (0.0 ms)
DEBUG:Mon Feb 13 11:40:47 2023 : <RECV: len=1 63 (0.0 ms)
DEBUG:Mon Feb 13 11:40:47 2023 : <RECV: len=1 00 (10.0 ms)
DEBUG:Mon Feb 13 11:40:47 2023 : <RECV: len=1 02 (0.0 ms)
DEBUG:Mon Feb 13 11:40:47 2023 : <RECV: len=1 6D (0.0 ms)
DEBUG:Mon Feb 13 11:40:47 2023 : <RECV: received 01 02 63 00 02 6D
DEBUG:Mon Feb 13 11:40:47 2023 : >FRAMER: framer_reset_actaddr framer_current_addr = FRAMER_NO_ADDR (was 0063)
DEBUG:Mon Feb 13 11:40:47 2023 : 00 -> OK
DEBUG:Mon Feb 13 11:40:47 2023 : OK
OK
vctrld>getTempWWsoll
DEBUG:Mon Feb 13 11:41:14 2023 : Command: getTempWWsoll
DEBUG:Mon Feb 13 11:41:14 2023 : >SENT: 41
DEBUG:Mon Feb 13 11:41:14 2023 : >SENT: 05
DEBUG:Mon Feb 13 11:41:14 2023 : >SENT: 00
DEBUG:Mon Feb 13 11:41:14 2023 : >SENT: 01
DEBUG:Mon Feb 13 11:41:14 2023 : >SENT: 63
DEBUG:Mon Feb 13 11:41:14 2023 : >SENT: 00
DEBUG:Mon Feb 13 11:41:14 2023 : >SENT: 01
DEBUG:Mon Feb 13 11:41:14 2023 : >SENT: 6A
DEBUG:Mon Feb 13 11:41:14 2023 : <RECV: len=1 06 (30.0 ms)
DEBUG:Mon Feb 13 11:41:14 2023 : <RECV: received 06
DEBUG:Mon Feb 13 11:41:14 2023 : >FRAMER: framer_set_actaddr framer_current_addr = 0063 (was FFFF)
DEBUG:Mon Feb 13 11:41:14 2023 : >FRAMER: Command send
DEBUG:Mon Feb 13 11:41:14 2023 : >FRAMER: no preset result
DEBUG:Mon Feb 13 11:41:14 2023 : <RECV: len=1 41 (0.0 ms)
DEBUG:Mon Feb 13 11:41:14 2023 : <RECV: received 41
DEBUG:Mon Feb 13 11:41:14 2023 : <RECV: len=1 06 (0.0 ms)
DEBUG:Mon Feb 13 11:41:14 2023 : <RECV: received 06
DEBUG:Mon Feb 13 11:41:14 2023 : <RECV: len=1 01 (0.0 ms)
DEBUG:Mon Feb 13 11:41:14 2023 : <RECV: len=1 01 (10.0 ms)
DEBUG:Mon Feb 13 11:41:14 2023 : <RECV: len=1 63 (0.0 ms)
DEBUG:Mon Feb 13 11:41:14 2023 : <RECV: len=1 00 (0.0 ms)
DEBUG:Mon Feb 13 11:41:14 2023 : <RECV: len=1 01 (10.0 ms)
DEBUG:Mon Feb 13 11:41:14 2023 : <RECV: len=1 34 (0.0 ms)
DEBUG:Mon Feb 13 11:41:14 2023 : <RECV: len=1 A0 (0.0 ms)
DEBUG:Mon Feb 13 11:41:14 2023 : <RECV: received 01 01 63 00 01 34 A0
DEBUG:Mon Feb 13 11:41:14 2023 : >FRAMER: framer_reset_actaddr framer_current_addr = FRAMER_NO_ADDR (was 0063)
DEBUG:Mon Feb 13 11:41:14 2023 : Typ: uchar (in float: 52.000000)
DEBUG:Mon Feb 13 11:41:14 2023 : (FLOAT) Exp: V [B0:34 B1:00 B2:00 B3:00 B4:00 B5:00 B6:00 B7:00 B8:00 B9:00 ]
DEBUG:Mon Feb 13 11:41:14 2023 : 52.000000 Grad Celsius
52.000000 Grad Celsius
vctrld>

my log

[philippoo66]

uff, is there a way to preserve line breaks?

[philippoo66]

FRAMER: framer_set_actaddr framer_current_addr = 0063 (was FFFF) FRAMER: framer_reset_actaddr framer_current_addr = FRAMER_NO_ADDR (was 0063)

address bytes wrong order?!

41 06 00 02 63 00 01 2B 97 to set 6300h to 43dec

[philippoo66]

here still faulty vito.xml is utilized!! is there another one somewhere?? or deamons require restart?

order of addr bytes in telegram is correct even if mentioned wrong in log text.

[l3u]

I havt the 20CB too. You have to change the length to 1 Byte in the Vito.xml

No matter if the length is 1 or 2, I get:

I did try it with both values …

[philippoo66]

did you reboot everything after changing xml?!

[philippoo66]

with Timo's target (same as yours) it works with ioBroker after changing len to 1...

put your logs here and I tell you if telegram is correct. above it's not and hence it does not work. make the stuff sending the correct telegram and it will work. Vitotronic is not poked that bad... ;-)

[l3u]

did you reboot everything after changing xml?!

Yeah, of course ;-)

Fair enough, here we are again: 70ef62b318c2188b6ffd865f9c4d571a508b1eda

Here's the debug log trying with the correctly set len for setTempWWsoll:

telnet localhost 3002
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
vctrld>getTempWWsoll 
46.000000 Grad Celsius

So the communication works ...

vctrld>debug on
vctrld>setTempWWsoll 47
DEBUG:Mon Feb 13 13:08:02 2023 : Command: setTempWWsoll 47
DEBUG:Mon Feb 13 13:08:02 2023 : Send Exp: V [V=47.000000]
DEBUG:Mon Feb 13 13:08:02 2023 : Type: uchar (bytes: 2F )  
DEBUG:Mon Feb 13 13:08:02 2023 : >SENT: 41
DEBUG:Mon Feb 13 13:08:02 2023 : >SENT: 06
DEBUG:Mon Feb 13 13:08:02 2023 : >SENT: 01
DEBUG:Mon Feb 13 13:08:02 2023 : >SENT: F4
DEBUG:Mon Feb 13 13:08:02 2023 : >SENT: 63
DEBUG:Mon Feb 13 13:08:02 2023 : >SENT: 00
DEBUG:Mon Feb 13 13:08:02 2023 : >SENT: 01
DEBUG:Mon Feb 13 13:08:02 2023 : >SENT: 2F
DEBUG:Mon Feb 13 13:08:02 2023 : >SENT: 8E
DEBUG:Mon Feb 13 13:08:02 2023 : <RECV: len=1 06 (30.0 ms)
DEBUG:Mon Feb 13 13:08:02 2023 : <RECV: received 06
DEBUG:Mon Feb 13 13:08:02 2023 : >FRAMER: framer_set_actaddr framer_current_addr = 0063 (was FFFF)
DEBUG:Mon Feb 13 13:08:02 2023 : >FRAMER: Command send
DEBUG:Mon Feb 13 13:08:02 2023 : >FRAMER: no preset result
DEBUG:Mon Feb 13 13:08:07 2023 : <RECV: read timeout
DEBUG:Mon Feb 13 13:08:07 2023 : <RECV: received
DEBUG:Mon Feb 13 13:08:07 2023 : >FRAMER: framer_reset_actaddr framer_current_addr = FRAMER_NO_ADDR (was 0063)
DEBUG:Mon Feb 13 13:08:07 2023 : >FRAMER: read failure
DEBUG:Mon Feb 13 13:08:07 2023 : Error in recv, terminating
DEBUG:Mon Feb 13 13:08:07 2023 : Error executing setTempWWsoll 47
ERR: <RECV: read timeout
>FRAMER: read failure
Error in recv, terminating
Error executing setTempWWsoll 47

[l3u]

uff, is there a way to preserve line breaks?

The backticks are used for inline code. For a code block, you have to indent each line by four spaces.

[philippoo66]

len looks better but still some strange values in telegr. bytes, but there are some 'toggle bits' or so so I need to check further

Error executing setTempWWsoll 47

does not mean too much... Did you check if the change got performed on the Vito?

[l3u]

It isn't changed, the device displays the original value, as a subsequent getTempWWsoll call also returns …