Vaillant aroTherm

Begonnen von JimKnopf, 30 Juli 2023, 14:51:29

Vorheriges Thema - Nächstes Thema

JimKnopf

address 05: slave #1, scanned "MF=Vaillant;ID=VR921;SW=2801;HW=5703", loaded "vaillant/05.vr921.csv"
#diese Datei ist noch leer
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0902;HW=5103", loaded "vaillant/08.hmu.csv"
#Daten müssen aktiv abgefragt werdenaddress 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0902;HW=5103", loaded "vaillant/hcmode.inc" diese Datei wird von 08.hmu.csv nachgeladen
# Ich habe den Namen für ciricut hinzugefügt und die Values auf eigene Felder mit Namen verteilt, damit entsprechend readings angelegt werden
# in FHEM muss beim entsrpechend MQTT2 Device in der ReadingList volgendes Hizugefügt werden: ebusd2/hmu/Status01:.* { json2nameValue($EVENT, 'hmu_', $JSONMAP) }
#r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,
r,hmu,Status01,,,,,01       ,VorlaufTemp,,temp1,,,   ,RuecklaufTemp,,temp1,,,   ,AussenTemp,,temp2,,,   ,WWTemp,,temp1,,,   ,SpeicherTemp,,temp1,,,   ,Pumpenstatus,,pumpstate,,,

address 15: slave #2, scanned "MF=Vaillant;ID=CTLV2;SW=0514;HW=1104", loaded "vaillant/15.ctlv2.csv"
#Diese Datei enthält die Kopie aus der Datei 15.700.csvEtliche Daten können direkt aktiv abgefragt werden. Leider wurde wieder kein ciricut Name angegeben, das habe ich bei mir nachgeholt.
address 76: slave #9, scanned "MF=Vaillant;ID=VWZIO;SW=0901;HW=5103", loaded "vaillant/76.vwzio.SW0901.csv"
#Diese Datei ist noch leeraddress ec: slave, scanned "MF=Vaillant;ID=SOL00;SW=0514;HW=1104", loaded "vaillant/ec.sol.sc.csv"
#Diese Datei ist noch im Originalzustand
FHEM,LaCrosse,PCA301,Revolt,MAX!,HM,FS20, MQTT2, ebusd 3.4.v3.4-96-g96d5623, ebus Adapter 3.0 mit 20201219-offset , Wolf  CGB (-K)-20, Wolf ISM7, Wolf Solar SM, Speicher/WR E3DC S10, eGolf, Keba P30, Phoenix Contact EV, OpenWB

JimKnopf

#1
Hallo Zusammen!
Wir haben jetzt unsere Wärmepumpe aroTherm VWL 75/6 von Vaillant bekommen. Leider fehlen noch extrem viele Daten. Dazu kommt, dass viele Daten anscheinend nicht mher passen durch Änderung der Hardware- oder Softwareversionen.
Geräte im System: VWL75/6, MEH 97, sensoCOMFORT VRC 720, sensoNET VR 921 Internetgateway.
Einige bekannte Einträge sind meiner Meinung nicht optimal in verbindung mit MQTT und FHEM.
Deswegen würde ich an dieser Stelle gerne eine Liste mit Änderungen zu den offiziellen Configdateien erstellen in Zusammenhang mit den Soft- und Hardware Versionen.
Sobald hier weitere Daten eintreffen, werde ich die liste im ersten Post ergänzen. Ich beziehe mir nur auf die Versionen in "en/Vaillant" Ordner, da hier mehr Daten enthalten sind.
Meiner Meinung nach sollte die Sprachauswahl in den csv Dateien erfolgen, damit man sofort die Unterschiede zwischen englisch und deutsch sieht.


Ich lade alle aroTherm Besitzer ein hier ihre Daten anzugeben, vor allem auch entschlüsselte Werte zusammen mit den Soft- und Hardwaresänden.
Dazu bitte wie folgt vorgehen. EbusD starten. Über einen TCP Clienten den Befehl "info" an ebusd senden und aus der Antwort die wichtigen Daten übernehmen, siehe mein Beispiel unten.
Ich nutze dazu "ebusctl -p 8889" als TCP client. ACHTUNG! Ich nutze Port 8889 da ich zwei ebusd instanzen laufen habe, standard wäre Port 8888.
Am Ende finden die neuen Decodierungen vielleicht den Weg in die offizielle config.

Gruß,
Burkhard
FHEM,LaCrosse,PCA301,Revolt,MAX!,HM,FS20, MQTT2, ebusd 3.4.v3.4-96-g96d5623, ebus Adapter 3.0 mit 20201219-offset , Wolf  CGB (-K)-20, Wolf ISM7, Wolf Solar SM, Speicher/WR E3DC S10, eGolf, Keba P30, Phoenix Contact EV, OpenWB

JimKnopf

#2
Ich habe vor einigen Jahren einiges zur Wolf GasTherme entschlüsselt, was auch seinen Weg in die offizielle Config gefunden hat. Nun musste ich mit dem Thema ganz von vorne anfangen und mir mühsam wieder erarbeiten, wie die Ebus-Telegramme aufgebaut sind.
Hier für alle Neu- und Wiedereinsteiger einge kurze Zusammenfassung:

BroadCast Telegram:    10feb505025c00
Master-Slave Telegram: 1008b5110101 / 0927270080ffff0000ff
----------------------->Masterpart< --> Slavepart<--------
Der Aufbau von Broadcasttelegramm und dem Masterpart sind identisch:
10-fe-b505-02-5c00
QQ-ZZ-PBSB-CB-DB
QQ ist die Quelle die sendet
ZZ ist das Ziel, in diesem Beispiel bedeutet fe ein senden an alle, deswegen Broadcast. Im Beispiel des Masterparts ist das Ziel die Adresse 08.
PBSB ist der primäre Dienst und der secundäre Dienst und beschreibt worum es eigentlich gehen soll. Wir nutzen es einfach als Erkennung
CB steht für CountingBytes, für die Anzahl der nachfolgenden Datenbytes. In diesem Fall folgen zwei Datenbytes. Dieser Wert wird für unsere Entschlüsselung nicht verwendet und taucht nicht wieder auf
DB das sind die Datenbytes

Broadcasttelegramme haben eine eigene Entschlüsselungsdatei broadcast.csv. Ich gehe davon aus, dass, wenn ein Hersteller erkannt wurde, erst in dem Herstellerordner die broadcast.csv ausgewertet wird. Wird ebusd da nicht fündig wird die broadcast.csv aus den config Ordner genommen, den man beim Programmaufruf angegeben hat, z.B. "/etc/ebusd/en/broadcast.csv"
In jeder csv Datei ist in der ersten Zeile der Aufbau der einzelnen Zeilen nochmal angegeben:
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,commentfür obiges Telegram wäre folgendes einzutragen:
b,broadcast,,10,fe,b505,5c,hello,,HEX:1,,,HalloDie Abschnitte einzeln:
"b," b ist leider in der Anleitungszeiele nicht mit drin, steht für broadcast. "r" steht für read=lesen, "w" für write=schreiben. Ein broadcast kann nicht von ebusd ausgelöst werden. Ein "w" bedeutet, dass der Master an den Slave daten sendet. Somit stehen die gesuchten Daten im Master-part. Bei "r" fragt der Master beim Slave Daten ab, die dann im Slave-part stehen. Ebusd kann diese Telegramme auch selbst auslösen, sprich Werte aktiv lesen(anfragen) oder schreiben. "ur" steht für update-read. Ebusd kann dieses telegram nur passiv mitlesen. Gleiches bei "uw".
"broadcast," ist der ciricut name. Hier kann man einen Sinnvollen namen angeben, nachdem die ausgewerteten Daten gruppiert werden.
"," hier könnte man dem Telegram einen Namen geben
"10," hier kann der Wert QQ angegeben werden, für den Fall das andere Sender die gleiche PBSB und ID verwenden aber andere Daten übertragen werden. Lässt man es leer werden alle Quellen berücksichtigt.
"fe," das enstpricht dem Feld ZZ
"b505," dem Feld PBSB
"5c," hier wird es schon spannender. Dies ist mindestes das erste Datenbyte. Da wir nur zwei Bytes in diesem Beispiel erhalten müssen wir das zweite für den Wert übrig lassen.
Bis hierhin haben wir nur das Telegram eindeutig zugeordnet, erst jetzt werden Daten ausgewertet
"hello," in der Anleitungszeile als feld1 bezeichnet ist dies der Name des einzelnen übertragenen Wertes der möglichst Sinnig gewählt werden sollte.
"," in der Anleitung mit "part (m/s)" beschrieben. Hier ist mir im Moment die Verwendung nicht ganz klar, ist aber für einfach Fälle nicht notwendig.
"HEX:1,,Hallo" hier wird der Datentyp oder das template angegeben, das den Wert umwandelt. Eine Übersicht dern internen Datentypen finden man unter: Builtin data types die namen der templates findet man in den Dateien _templates.csv im config Ordner. HEX:1 bedeutet, dass ein Datenbyte als HEX Zahl ausgegeben wird.
"," hier kann ein Divider oder auch Wertübersetzter angegeben werden. 1000 z.B. um Watt in Kilowatt ausgeben zu lassen. Oder "0=off;1=standby" um Werte in Text umsetzten zu lassen
"," Unit, hier kann man dem Wert eine Einheitsangabe anzänge lassen, z.B. "%," oder "kW,"
"Hallo"  als Komentar was der Wert eigentlich bedeuten soll.

In diesem Beispiel wurde als "Nutzlast" nur ein Byte übertrage, das erste Datenbyte war ja die ID. Wären es zwei Bytes gewesen, würde unsere Zeile so noch nicht funktionieren, da ebusd nicht weiß was es damit anfangen soll. Es kommt die Fehlermeldung das etwas fehlt.
Man kann sie die Datenbytes nach der ID wie ein Stapel vorstellen. Die Auswertung eines Feldes nimmt die benötigten Bytes vom Stapel. HEX:1 demnach nur ein Byte.
Es verbleibt ein Byte. Für dieses würd nochmal eine gleiche Auswertung wie für feld1 angehängt. Nach dem Hallo würde erst noch ein "," folgen und dann die Auswertung nach dem gleichen Muster.

Bei Master-Slave Telegrammen sieht das geringfügig anders aus. Sendet der Master Werte an einen Slave können wir es behandeln wie beim broadcast:
u,geraetename,,10,08,b511,01,hello,m,HEX:1,,,HalloVorweg: die "08," seht ja für ZZ, das Ziel. Damit gehört dieser Eintrag in die Datei, die mit 08(.csv) beginnt. Überprüft, welche Datei bei Eucht überhaupt geladen wird.
Editiert Ihr z.B. die 08.csv, es wird aber die 08.hmu.csv geladen, wird sich nichts ändern. Prüft auch, ob aus der geladenen Datei heraus noch etwas nachgeladen wird.
In der Datei en/Vaillant/08.hmu.csv steht am Ende z.B.:
!include,hcmode.inc,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
!include,errors.inc,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Diese beiden Dateien werden als Teil von 08.hmu.csv behandelt und ausgewertet.
"u," steht für update. Wir lesen nur mit wenn ein Master einen Wert sendet. Mit "w," könnten wir selbst den Wert senden.
man sieht das "m," nach hello. Wir werten hier den Master-part aus.
In diesem Fall macht das keinen Sinn, den der Master hat keinen Wert an den Slave gesendet, sondern wohl eher eine Anfrage, deswegen ist der Slave-part auch so lang.
Wird vom Master ein Wert geschrieben, kommt vom Slave meist nur eine kurze Antwort dass der Wert übernommen wurde, oder abgelehnt wurde.

Um so eine Abfrage durch den Master mitzulesen sieht unsere Zeile nun eher so aus:
Nochmal das Telegram: 1008b5110101 / 0927270080ffff0000ff
r,geraetename,,10,08,b511,01,keineAhnung,s,HEX:9,,,unbekanntoder
r,geraetename,,10,08,b511,01,keineAhnung,s,HEX:4,,,unbekannt,keineAhnung2,s,HEX:5,,,unbekannt
Als erstes: die führende 09 aus dem Slave-part gibt an, wie viele Datenbytes folgen und zur Auswertung nicht weiter verwendet, wissen sollte man es aber trotzdem, da alle Bytes ausgewertet werden müssen.
Im ersten Beispiel habe ich "HEX:9" genommen. Somit wird die ganze Antwort als unter "geraetename keineAhnung_value" in Hex ausgewertet.
Im zweiten Beispiel habe ich einmal HEX:4 und einmal HEX:5 genommen, somit sind alle 9 Bytes verarbeitet. Zu finden unter "geraetename keineAhnung_value" und "geraetename keineAhnung2_value"

Soweit mein Wissenstand. Bitte korrigiert mich wenn ich etwas falsches geschrieben habe. Ich werde es so schnell wie möglich berichtigen.
Gruß,
Burkhard
FHEM,LaCrosse,PCA301,Revolt,MAX!,HM,FS20, MQTT2, ebusd 3.4.v3.4-96-g96d5623, ebus Adapter 3.0 mit 20201219-offset , Wolf  CGB (-K)-20, Wolf ISM7, Wolf Solar SM, Speicher/WR E3DC S10, eGolf, Keba P30, Phoenix Contact EV, OpenWB