search

openv / vcontrold

:fire: vcontrold Daemon for control and logging of Viessmann® type heating devices
https://github.com/openv/openv/wiki
GNU General Public License v3.0
102 stars 55 forks source link

wrong length for setTempWWsoll in 300/vito.xml #123

Open philippoo66 opened 1 year ago

philippoo66 commented 1 year ago

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 commented 1 year ago

Thanks for mentioning this, fixed with 7ac1c2494b671095bab06051a367633e6462ca6c

l3u commented 1 year ago

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 commented 1 year ago

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

philippoo66 commented 1 year ago

ö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 commented 1 year ago

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

l3u commented 1 year ago

What do you use then?!

philippoo66 commented 1 year ago

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 commented 1 year ago

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

l3u commented 1 year ago

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

Me neither ;-)

philippoo66 commented 1 year ago

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

philippoo66 commented 1 year ago

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

sirtiger commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

l3u commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago 
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 commented 1 year ago

uff, is there a way to preserve line breaks?

philippoo66 commented 1 year ago

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 commented 1 year ago

grafik

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 commented 1 year ago

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 commented 1 year ago

did you reboot everything after changing xml?!

philippoo66 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

philippoo66 commented 1 year ago

grafik

these bytes were correct ('normal') in Timo's log

philippoo66 commented 1 year ago

man, the suff is over ten years old an still buggy!?

l3u commented 1 year ago

If you search for software without bugs, my best bet would be the only one to find is TeX ;-)

What do those values represent? And where do they come from? Would be nice if we could track this down …

l3u commented 1 year ago

Here we are. My vcontrold.xml file was too old and never updated to the current state.

It still contained

<protocols>
  <protocol name='P300'>
    ...
    <macro name='SETADDR'>
      <command>SEND 01 F4</command>
    </macro>
  </macros>

where the command definition should be

<command>SEND 00 02</command>

(cf. https://github.com/openv/vcontrold/issues/63 )

Et voilà: It works:

vctrld>setTempWWsoll 47
DEBUG:Mon Feb 13 14:36:46 2023 : Command: setTempWWsoll 47
DEBUG:Mon Feb 13 14:36:46 2023 : Send Exp: V [V=47.000000]
DEBUG:Mon Feb 13 14:36:46 2023 : Type: uchar (bytes: 2F )  
DEBUG:Mon Feb 13 14:36:46 2023 : >SENT: 41
DEBUG:Mon Feb 13 14:36:46 2023 : >SENT: 06
DEBUG:Mon Feb 13 14:36:46 2023 : >SENT: 00
DEBUG:Mon Feb 13 14:36:46 2023 : >SENT: 02
DEBUG:Mon Feb 13 14:36:46 2023 : >SENT: 63
DEBUG:Mon Feb 13 14:36:46 2023 : >SENT: 00
DEBUG:Mon Feb 13 14:36:46 2023 : >SENT: 01
DEBUG:Mon Feb 13 14:36:46 2023 : >SENT: 2F
DEBUG:Mon Feb 13 14:36:46 2023 : >SENT: 9B
DEBUG:Mon Feb 13 14:36:46 2023 : <RECV: len=1 06 (50.0 ms)
DEBUG:Mon Feb 13 14:36:46 2023 : <RECV: received 06
DEBUG:Mon Feb 13 14:36:46 2023 : >FRAMER: framer_set_actaddr framer_current_addr = 0063 (was FFFF)
DEBUG:Mon Feb 13 14:36:46 2023 : >FRAMER: Command send
DEBUG:Mon Feb 13 14:36:46 2023 : >FRAMER: no preset result
DEBUG:Mon Feb 13 14:36:46 2023 : <RECV: len=1 41 (0.0 ms)
DEBUG:Mon Feb 13 14:36:46 2023 : <RECV: received 41
DEBUG:Mon Feb 13 14:36:46 2023 : <RECV: len=1 05 (0.0 ms)
DEBUG:Mon Feb 13 14:36:46 2023 : <RECV: received 05
DEBUG:Mon Feb 13 14:36:46 2023 : <RECV: len=6 01 (0.0 ms)
DEBUG:Mon Feb 13 14:36:46 2023 : <RECV: received 01 02 63 00 01 6C
DEBUG:Mon Feb 13 14:36:46 2023 : >FRAMER: framer_reset_actaddr framer_current_addr = FRAMER_NO_ADDR (was 0063)
DEBUG:Mon Feb 13 14:36:46 2023 : 00 -> OK
DEBUG:Mon Feb 13 14:36:46 2023 : OK
OK

Damn. This whole configuration thing is really confusing. There really should be an easier way to do it.

l3u commented 1 year ago

At least, I now can also confirm myself that, with the fix mentioned by @philippoo66, the set command actually works ;-)

l3u commented 1 year ago

Btw. @philippoo66 I think the data you collected should be part of https://github.com/openv/, with you having write access to it, no?!

sirtiger commented 1 year ago

Ok… Great. It works…

philippoo66 commented 1 year ago

sorry, I had to take a walk with the dog, she was really pushing... but you did it - great!

the 01 F4 from above are relicts of the KW protocol (01:Start, F4:Virtuell_Write). Certainly in case of KW (which ist still supported by the Vitotronics) the telegram should start with 01, not following the 41 06 of the 300 frame... Something got really mixed up in a strange way. But most important that you solved it ;-)

philippoo66 commented 1 year ago

Btw. @philippoo66 I think the data you collected should be part of https://github.com/openv/, with you having write access to it, no?!

you mean the DP lists and how to 'find' even more DP addresses? Probably you are right. I'm new to github and don't know if/how I can put it there. But e.g. the enums are missing. I haven't figured out a reasonable way to put them up and the links to the DPs. So still 'under construction', even if I don't know how far this old stuff is still interesting since the new E3 gen is up since quite a while. And currently we are some busy trying to unscramble its 'secrets', even we did not get too far up to now....

philippoo66 commented 1 year ago

do you have write access to the openv? A link in the right side bar to 'my' address lists might make sense... (in fact they had been there since sarnau Markus figured out Vitosoft. I only printed them out)

grafik

l3u commented 1 year ago

Yes I have, but mostly because I cleaned up the code and ported the ancient build system to cmake back then. Not really because I have extensive knowledge of vcontrold's internals ;-)

I think the best would be if you wrote to @speters – it would definitely be a good idea to compile everything about communication with Viessmann heatings in one place. And as this is not only the account for the vcontrold, but also for some other (discontinued) software, building instructions or circuit plans for optolink adapters, wikis about this stuff and so on, I think this is the place to be for your data :-)

l3u commented 1 year ago

Hmmm … looks like this is not so easy :see_no_evil: Well, maybe, if I mention @speters here, he will see it comment here …

philippoo66 commented 1 year ago

:+1:

philippoo66 commented 1 year ago

after you recovered the line breaks in Timo's log (thank you!) I took another look at it. And what we see there is that writing WW_Soll works even if data_len_to_be_written is sent as 2.

So (at least in case of hotwater setpoint) Vitotronic's set-procedure seems to 'know' the length of the value and ignores that information transfered in the telegram. It work with 1 (as we see in your log) as well as with 2.

Probably this is the reason, why nobody cared for the wrong len information with 'setTempWWsoll' in vito.xml. But what is sure is that 'Bedien_WW_Solltemperatur~0x6300' is type 'Byte' which is a 1-byte value, and that it gets read and written with that specific length.

:wink:

philippoo66 commented 1 year ago

ps. @l3u and since you have write access, perhaps you might add that simple example for using a set-command (with value as parameter) in the documentation?!