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
100 stars 54 forks source link

Kessel liefert falsche Werte #111

Closed deep-e closed 1 year ago

deep-e commented 1 year ago

Umgebung: Kessel: Vitoligno 300-C mit Ecotronic (FW 2.12) (Model 2022) Rechner: RPI3 mit Raspbian vcontrold: Git-Ref 8501899 2022-08-31, Device ID="20CB" name="VScotHO1" protocol="P300" Verbindung über original Viessmann Optolink-USB Kabel Problem: Die vom Kessel zurückgelieferten Werte sind immer 0xFFFF. Es wurde ein Vitola 200 Kessel gegen die Vitoligno 300-C getauscht. Die Vitola konnte ich ohne Probleme per vclient auslesen, Werte ändern. Die Vitoligno kommuniziert fehlerfrei mit vcontrold, die empfangenen Daten sind aber sinnfrei.

Als Beispiel

  1. `vclient -h 192.168.x.y -v -c getTempA
  2. option -v
  3. option -c with value 'getTempA'
  4. sizeof optarg:4, strlen:8, sizeof commands:512, strlen:0, []
  5. Host: 192.168.x.y Port: 3002
  6. getTempA:
  7. -0.100000 Grad Celsius` (-0.1 * 10 = -1 = 0xffff

Zugehöriges vcontrold Log: getTempA.log

Irgendeine Idee zur Lösung?

speters commented 1 year ago

Ist die 20cb denn der echte, auf der Adresse 0xf8 gemeldete Typ (sh. getDevType in der XML hier im Repo)?

deep-e commented 1 year ago

Type 20CB ist der Einzige, bei dem es bei der Kommuikation zwischen Kesel und vcontrold nicht zu einem Timeout kommt. vclient getDevType liefert root@heat:~ # vclient -h 192.168.22.16 -v -c getDevType option -v option -c with value `getDevType' sizeof optarg:4, strlen:10, sizeof commands:512, strlen:0, [] Host: 192.168.22.16 Port: 3002 getDevType: UNKNOWN

Die Antwort der Ecotronic ist Frame: Leadin 41 Length 0d (13) Type 01 (1) Func 01 (1) Addr f800 (63488) DLen 08 (8) Chk 8b Data 20 34 00 18 00 00 01 0f Also meldet die Ecotronic wohl Type 2034

deep-e commented 1 year ago

I managed to capture the complete communication between Vitosoft and my Ecotronic based Vitoligno 300-C. The evaluation of the trace let to 141 different addresses being requested by Vitosoft, 43 addresses are known based on xml/300/vito.xml. One request may retrieve more than one known address (e.g. the first 4 error states are retrieved in one request). But what about the other nearly 100 addresses? Is there a defined method to map addresses to content, type and length? If somebody wants me to I can provide the trace and additional information.

deep-e commented 1 year ago

Well, I finally decided to no longer use vcontrold due to - from my point of view - design issues. I found a way to retrieve all addresses and related lengths/values/transformations for all Viessmann systems including "code to text" transformations. This information is in no way compatible with the current vcontrod data model. So I decided to develop my private solution. It fits my needs, but doesn't follow a generalized approach.

nerixs commented 1 year ago

Well, I finally decided to no longer use vcontrold due to - from my point of view - design issues. I found a way to retrieve all addresses and related lengths/values/transformations for all Viessmann systems including "code to text" transformations. This information is in no way compatible with the current vcontrod data model. So I decided to develop my private solution. It fits my needs, but doesn't follow a generalized approach.

Hello @deep-e , I come to you following your message: https://github.com/openv/vcontrold/issues/111 You have found a way to retrieve all addresses and associated lengths/values/transformations for all Viessmann systems. Would you share your solution? Like you I am not comfortable with the design of vcontrold. Best regards

deep-e commented 1 year ago

The general idea: Vissmann Vitosoft 300 must know everthing about the supported components. So I installed the 90 days demo version on a Win10 VM. I connected my Vissmann Vitoligno 300-C via Optolink to an existing Raspberry Pi --> /dev/ttyUSB0. I slightly modified the sources of ser2net to be able to capture all traffic from and to /dev/ttyUSB0 in a trace file in a parseable format. On Windows I installed hub4com/com0com. So Vitosoft was able to talk to the Vitoligno and I was able to see what's going on on the cable. Vitosoft comes with a number of XML-files plus a MSSQL-DB. These 2 sources carry all the information needed. Combined with the protocol trace I was able to identify all the values etc. Vitosoft retrieves. The rest was a lot of grep/sed/conversion/normalization/... resulting in a single JSON-file with all the definitions (I hate XML). Finally a Linux service acts as a bridge between Vitoligno and Mosquitto MQTT broker for set and get requests. I'll not provide the scripts, tools, ... I wrote them as a one shot, quick and dirty solution not as a general solution.

nerixs commented 1 year ago

Hello @deep-e, I would love to speak with you in private. If you agree. Best regards