openv
openv copied to clipboard
openv
VitoConnect 100 mit Raspberry PI als Proxy
Meine neue Heizung (Vitodens-222 F) kann ich mittels der ViCare App "fernbedienen", leider ist der Funktionsumfang dieser App, na sagen wir mal, "begrenzt". Das schreit nach einer Verbesserung, wobei ich die wesentlichen Komponenten ja bereits habe und auch in ihrer bisherigen Funktion erhalten möchte.
Am schönsten wäre natürlich, ich könnte mich auf der VitoConnect anloggen und direkt (also ohne das Internet) meine Heizung abfragen und steuern. Das wüde den Nutzen so einer Box erheblich steigern, ist vom Hersteller aber wohl nicht vorgesehen (?). Also hab ich mir etwas ausgedacht.
Benötigte Bauteile: Eine Viessman Heizumg mit VitoConnect 100 Typ OPTO1, ein Raspberry PI Zero WH und ein CP2102 USB-Seriell Adapter.
Um sowohl zu verstehen, was die VitoConnect 100 mit meiner Heizung redet, als auch eigene Kommandos zu senden, habe ich zwischen das original OPTO-Link Kabel und die VitoConnect 100 einen Raspberry PI Zero gehängt, den ich um einen CP2102 USB-Seriell-Adapter erweitert habe.
Das Optolink Kabel verbinde ich über ein "USB-A Buchse auf Micro-USB Stecker"-Kabel mit der USB-Buchse vom PI-Zero. Den CP2102 Adapter verbinde ich über drei Leitung (GND, Tx, Rx) mit dem seriellen Port des PI Zero auf der GPIO Pinleiste und auf der USB-Seite mit der Vitoconnect 100. Fertig ist die Hardware. Dazu noch ein kleines Programm, das die beiden seriellen Schnitstellen miteinander verbindet und die Daten beim Durchreichen mitprotokolliert. Schon hat man einen einfachen Proxy mit man-in-the-middle Option.
Erste Erkenntnis: Die VitoConnect 100 redet ununterbrochen mit der Heizung. Also nicht nur, wenn ich mit der ViCare App eine Verbindung aufbaue oder etwas abfrage. Offenbar wird dabei das Protokoll 300 (bzw. eine erweiterte Variante) verwendet.
Ich sammle erstmal noch Daten. Sobald ich mehr davon verstehe, versuche ich auch eigene Kommandos auszuführen. Wer so einen Proxy nachbauen will oder wem diese kurze Beschreibung nicht konkret genug war, bitte einfach melden.
Zum Thema Mitschneiden des Datenverkehrs der vitoconnect 100 s.a. Bauanleitung USB_Duo Sniffer. Dort ist eine alternative Hardware dafür beschrieben und es sind ein paar daraus gewonnene Erkenntnisse beschrieben.
Ja, diese Bauanleitung habe ich gesehen und gelesen, da hatte ich meine Hardware schon fertig. Schaue ich mein Logfile an, kann ich die dort berichteten Ergebnisse bestätigen. Wenn ich die Verbindung zwischen VitoConnect100 und der Heizung im Proxy abschalte, dann "pingt" die Vitoconnect nach der Heizung mit 0x04 0x16 0x00 0x00. Dauert die Auszeit nicht zu lang, dann findet die VitoConnect die Heizung wieder und plappert erneut drauf los.
Ich schau mal, ob ich das vcontrold auf dem PI an meinen Proxy "anflanschen" kann. Sobald das klappt, poste ich wie es geht.
Hallo muu55,
ich habe einen ähnlichen Aufbau mit meinem Raspi3 versucht:
- Optolink-Kabel an /ttyUSB0
- USB-UART-Adapter1 an /ttyUSB1
- VitoConnect mit zweitem USB-UART-Adapter2
- die beiden USB-UARTs mit GND und gekreuzten TX und RX verbunden
Mit python ein paar zeilen Code geschrieben:
- beide serielle Schnittstellen werden mit ( 4800, 8, 2, E) geöffnet
- in zwei Threads wird jeweils die eine Schnittstelle gelesen und die Daten an die andere gesendet
Bisher kann ich sehen, dass vom Optrolink periodisch 0x05 geschickt wird, was auch an den VitoConnect rausgeht - dieser reagiert aber garnicht (sendet auch nichts von sich aus ...)
Habe ich etwas vergesen? Hast Du vielleicht eine Idee oder Dein Beispiel-Code?
P.S.: Losgelöst von diesem Versuch funktioniert die ViCare-App und ich kann auch einige Daten manuell auslesen.
Also ich vermute, die VitoConnect erwartet an ihrem USB-Port einen USB-Seriell Adapter mit CP210x Chip, der dieselbe Vendor:Chip ID wie das Optolink-Kabel hat. Also z.B. die in Uwes Bauanleitung aufgeführten "CJMCU CP2102 MICRO USB to UART TTL Module 6 Pin serial Converter". Genau so einen habe ich auch benutzt.
Hier die Addressen+Länge, die von "meiner" VitoConnect100 laufend abgefragt werden:
00 F0 02
00 F8 01
00 F8 08 GWG_SystemIdent
00 F9 01 GWG_Kennung
00 FA 01 WPR_Hardware_Index
00 FB 01 SystemIdent_SW1
00 FC 01 WPR_Protokollversion_LDAP
00 FD 01 WPR_Protokollversion_RDAP
00 FE 01 WPR_Software_Version_Byte1
00 FF 01 WPR_Software_Version_Byte2
08 10 04 TiefpassTemperaturwert_KTS 08 3A 01 TemperaturFehler_ATS 08 3B 02 TemperaturFehler_KTS 08 8E 08 Uhrzeit 08 96 06 TiefpassTemperatur_RTS_A1M1 08 9C 03 NRF_TemperaturFehler_RTS_M1
20 00 30 WPR_HK1_Normaltemperatur
20 30 08
Danke für den Hinweis. Ich habe 3 verschiedene USB-UARTs ... leider alle mit einem PL2303-Chip :( Mal sehen wann die Bestellung vom CP2102 eintrudelt (gab genau 1 Angebot aus DE auf ebay ...). Dann setze ich mich wieder dran ...
Hast du @muu55 eine Möglichkeit, die Kommunikation der VitoConnect mit dem Viessmann-Server mitzuschneiden (z.B. mitmproxy? Ggf. liesse sich das API des Viessmann-Servers dann zu weiteren Erkenntnisgewinnen über Featuresets/Adressen/EventTypes anderer Anlagen nutzen. Die XML-Dateien der VitoSoft-Demo sind zwar schon sehr umfassend, allerdings auch relativ alt und nicht fehlerfrei.
Kannst du in den Logs Kommunikation finden, die nicht ReadData/0x01/Virtual_Read oder WriteData/0x02/Virtual_Write, sondern z.B. Funktion Calls/0x07/Remote_Procedure_Call sind? (wg. Ergänzung der Dokumentation von Protokoll 300)
Falls du die XML-Dateien der VitoSoft mal angeschaut hast:
Es gibt EventTypes mit der gleichen Adresse, aber unterschiedlicher BytePosition (quasi Offset). Kannst du erkennen, ob der Zugriff dann auf Adresse+BytePosition in ByteLength Länge stattfindet oder ob die Adresse in voller BlockLength abgefragt wird? Und wie sieht das beim Schreiben von EventTypes aus, die eine BitLength > 0 haben? Hintergrund ist der, dass ich zunächst dachte, der Adressraum wäre linear und direkt adressierbar (was z.B. 0x00F8 ff. nahelegt), bis ich dann herausbekommen habe, dass das nicht so ist (konkret war das bei der Fehlerhistorie, die ich mal nicht in Vielfachen von (BlockLength/BlockFactor) ausgelesen hatte).
Ich habe längere Zeit die Daten mit dem Sniffer aufgezeichnet, die Vitoconnect mit der Heizung (also auf der seriellen Ebene) austauscht. Zum Viessmann-Server sollte er dann wohl nichts anderes schicken können, als er von der Heizung geliefert bekommt. Auszug siehe Excel-Datei hier. In dieser Datei Vitoconnect-Output.zip sind noch mehr Daten gespeichert, z.T. mit grafischer Auswertung, um 'rauszufinden, wann und wie häufig die Adressen abgefragt werden. Darin sieht man zwar die zyklischen Abfragen, aber auch, dass die Abfragen variiert werden und sich nicht 100% gleichartig wiederholen.
Was den beschriebenen Adressraum anbelangt: Ich glaube jetzt, dass die Adressen eher als Befehle zu verstehen sind, die die Heizungssteuerung mit unterschiedlich langen Datensätzen beantwortet. Damit werden nicht einfach Speicherplätze im Bereich von 0x0000 bis 0xFFFF adressiert und das dort gespeicherte Byte zurückgegeben. Beispiel: Die Abfrage der Adresse 0x2500 (Status Heizkreis A1M1) mit
| 41 | 05 | 00 | 41 | 25 | 00 | 16 | 81 |
|---|
liefert
| xx | xx | xx | xx | xx | xx | xx | 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | xx |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 41 | 1B | 01 | 41 | 25 | 00 | 16 | 02 | 02 | 53 | 25 | 04 | 00 | 47 | 01 | 01 | 00 | 00 | 01 | C8 | 00 | 00 | 00 | 00 | 47 | 01 | 00 | C8 | 00 | 3A |
Im Antwortdatensatz mit 22 Byte Nutzdaten stecken laut "ecnEventType.xml" (aus der Vitosoft-Demo) an der Byteposition 1 (wird ab 0 gezählt) mit Länge 1 der Heizungsstatus als Integer, ab Pos. 2 mit 4 Byte Länge der Aufheiztimer als Double in Sekunden, ab Pos. 6 mit 2 Byte Länge die Vorlauf-Solltemperatur als Double (hier 32,7°C, Berechnung wie hier), an Pos. 8 mit 1 Byte Länge der Heizkreisfreigabe-Status als Integer, an Pos. 10 mit 1 Byte Länge der Status der Heizkreispumpe als Integer, an Pos. 11 mit 1 Byte Länge die RSWS-Betriebsart (was immer das ist) als Integer, ab Pos. 12 mit 2 Byte Länge die Raumsolltemperatur als Double (hier 20°C), an Pos. 16 mit 1 Byte Länge der Zustand Frostgefahr.
Was mich irritiert: An der gleichen Adresse kann auch ein Datensatz mit 17 Byte Datensatzlänge abgefragt werden kann. Laut der obigen XML-Datei sind dann andere Daten unter den genannten Bytepositionen/Offsets verfügbar. Z.B. an Pos. 2 steht anstelle "HK_AufheiztimerA1M1" der Wert von "NRF_HK_VT_Solltemperatur_A1M1".
Danke für dein Log. Habe gerade erst gesehen, dass da ja ganze 19 Sheets mit Daten drin sind.
Im 4. Byte der Antwort wo der klassischen P300 Protokolldefinition nach nur 0x01, 0x02, 0x07 vorkommen dürfte, sind Bits 7,6,5 offenbar als Zähler (0..7) verwendet worden (da kann man sich Anwendungsmöglichkeiten ausdenken: Erkennung fehlender Pakete, Zuordnen von Anfragen zu Antworten, ...). Den Daten nach hast Du eine Systemkennung 0x20CB0009. Also 20CB Hardwarereindex 0, Softwarereindex 9. Bei meiner 0x20CB000B (ähnlich, nur Softwarerevision 11) kann ich diese Zählersache nicht beobachten.
Hast du ein Log, wo die Anfragen der Vitoconnect auch auftauchen?
Ein wenig stutzig macht mich die Logzeile
06 | 41 | 06 | 03 | 21 | 00 | F0 | 01 | 01 | 1C
Was für eine Anfrage produziert diesen Fehler? Die Adresse 0x00F0 (ecnsysDeviceIdentF0) und die Länge 1 müsste doch valide sein.
PS: Ich kann auf die Schnelle nix sehen, aber hast du irgendwo geloggt, wie die Fehlerhistorie und die Fehlerhistorie des Feuerungsautomaten gelöscht werden?
Danke für dein Log. Habe gerade erst gesehen, dass da ja ganze 19 Sheets mit Daten drin sind.
Hallo Sönke, die Logs in den ersten Blättern obiger Datei sind während der Zeit entstanden, als ich mir den USB-Sniffer ausdachte. Am Anfang war die Hardware so, dass nur die Antwortdaten der Heizungsregelung an die Vitoconnect aufgezeichnet wurden. Die Erläuterungen und Kommentare auf den einzelnen Blättern sind wahrscheinlich auch nicht sehr aufschlussreich. Es war halt nicht zur Veröffentlichung gedacht. Ab Tabellenblatt T8 sind auch Sendedaten enthalten. Jetzt (so auch hier) ist standardmäßig der Datenverkehr in beiden Richtungen gespeichert.
Im 4. Byte der Antwort wo der klassischen P300 Protokolldefinition nach nur 0x01, 0x02, 0x07 vorkommen dürfte, sind Bits 7,6,5 offenbar als Zähler (0..7) verwendet worden (da kann man sich Anwendungsmöglichkeiten ausdenken: Erkennung fehlender Pakete, Zuordnen von Anfragen zu Antworten, ...). Den Daten nach hast Du eine Systemkennung 0x20CB0009. Also 20CB Hardwarereindex 0, Softwarereindex 9. Bei meiner 0x20CB000B (ähnlich, nur Softwarerevision 11) kann ich diese Zählersache nicht beobachten. Hast du ein Log, wo die Anfragen der Vitoconnect auch auftauchen?
Meine Vermutungen zu diesen drei ominösen Bits (und was mir sonst noch so aufgefallen ist) hatte ich hier geschildert. Da die drei Bits schon in den Anfragen an die Heizung hin und wieder als gesetzt auftauchen, kann es eigentlich nicht mit dem Softwarestand der Regelung zusammenhängen. Die scheint in ihren Antworten dieses Byte einfach aus der Anfrage zu wiederholen. Logs dazu siehe ebenfalls hier. Eine Systematik bezüglich der Werte dieser drei Bits habe ich bislang nicht erkannt.
Ein wenig stutzig macht mich die Logzeile
06 | 41 | 06 | 03 | 21 | 00 | F0 | 01 | 01 | 1CWas für eine Anfrage produziert diesen Fehler? Die Adresse 0x00F0 (ecnsysDeviceIdentF0) und die Länge 1 müsste doch valide sein.
Die Adresse 0x00F0 erscheint in der "ecnDataPointType.xml" (aus der Vitosoft-Demo) nicht, jedenfalls nicht unter Device-ID "VScotHO1_4" - die hier zutreffen sollte. In der "ecnEventType.xml" (auch aus der Vitosoft-Demo) steht sie mit der Bezeichnung "KBUS_V300_T03_VirtKanal_07" und der Länge von zwei Byte. Ich vermute, Du hast die Zeile aus dem Blatt T1 der "Vitoconnect-Output.xlsm". Dort hatte ich einfach mal den Beginn des Datenverkehrs zwischen Vitoconnect und Heizung aufgezeichnet, allerdings wie gesagt, nur die Antwortdaten. Warum Vitoconnect die Adresse benutzt, bevor der Typ der Steuerung abgefragt wird, erschließt sich mir nicht. Jedenfalls ist die Adresse 0x00F0 bei mir ungültig. Ich hatte mal die Heizung mit Hilfe des Programms "Vies-sion" mit allen Adressen 0...0xFFFF traktiert, dabei gibt es bei 0x00F0 auch einen Fehler. Wenn es Dich interessiert, kann ich nochmal ein Log vom Startvorgang der Vitoconnect erzeugen, diesmal mit den Daten aus beiden Richtungen.
PS: Ich kann auf die Schnelle nix sehen, aber hast du irgendwo geloggt, wie die Fehlerhistorie und die Fehlerhistorie des Feuerungsautomaten gelöscht werden?
Bislang habe ich nur ganz wenige Schreibvorgänge manuell ausgelöst und mitgeloggt. Die Fehlerhistorie (an 0x7507) habe ich nicht angefasst. Da dieser Datenpunkt als read/write ausgewiesen ist, kann man den Inhalt evtl. einfach auf Null setzen??
Gruß Uwe aka Golter
Mein Programm schreibt die Kommunikation zwischen Heizung und VitoConnect100 nach stdout. Hier das Log der letzten Tage: vito100.log.gz Entpackt sind das 112 MB, die Datei enthält 987817 Frage/Antwort Pärchen.
Die Zeilen mit 0: kommen von der VitoConnect100, die Zeilen mit 1: von der Heizung. Am Anfang sieht man wie sich die Geräte finden und danach beginnt das endlose Frage/Antwort-Spiel.
0: 04 1: 06 05 0: 16 00 00 1: 06 0: 41 05 00 81 00 F0 02 78 1: 06 41 07 01 81 00 F0 02 0B 00 86 0: 41 05 00 A1 00 F8 08 A6 1: 06 41 0D 01 A1 00 F8 08 20 CB 28 CB 00 00 01 0A 98 0: 41 05 00 C1 49 04 01 14 1: 06 41 06 01 C1 49 04 01 06 1C 0: 41 05 00 E1 39 04 01 24 1: 06 41 06 01 E1 39 04 01 06 2C 0: 41 05 00 01 29 04 01 34 1: 06 41 06 01 01 29 04 01 00 36 ...
Um die Kommunikation von der VitoConnect nach Hause (Viessmann Server) zu analysieren, müsste ich erst noch den Network Setup um die Box herum etwas umbauen.
- Optolink-Kabel an /ttyUSB0
- USB-UART-Adapter1 an /ttyUSB1
- VitoConnect mit zweitem USB-UART-Adapter2
- die beiden USB-UARTs mit GND und gekreuzten TX und RX verbunden
Mit python ein paar zeilen Code geschrieben:
- beide serielle Schnittstellen werden mit ( 4800, 8, 2, E) geöffnet
- in zwei Threads wird jeweils die eine Schnittstelle gelesen und die Daten an die andere gesendet
Könntest du den Python-Code sharen? Ich habe einen ähnlichen Aufbau vor, es geht erstmal nur darum die Daten mitzulesen. In meinem Fall ein Pellet-Kessel (Vitoligno 300-C), bei dem es nützlich wäre einige Werte zu erfassen (Anzahl Zündvorgänge, Brenndauer, Pelletverbrauch,...). Leider bietet die App nichts davon an, ich vermute aber das das Vitoconnect die Werte ausliest. Ziel wäre es, dieses auf dem Raspi abzuzweigen und separat wegzuschreiben (z.B. Grafana).
Hallo hendrikland,
hier mein Beispiel. Aufruf ist dann z.B.
python3 "programm.py" > "logfile"
Und es ist ein UART mit dem Chip CP2102 notwendig (PL2303 geht definitiv nicht) .
#!/usr/bin/python
#!/usr/bin/env python
import serial
import time
import threading
__ready = b'\x05'
serv = serial.Serial("/dev/ttyUSB1",
baudrate=4800,
parity=serial.PARITY_EVEN,
stopbits=serial.STOPBITS_TWO,
bytesize=serial.EIGHTBITS,
timeout=0.3)
sero = serial.Serial("/dev/ttyUSB0",
baudrate=4800,
parity=serial.PARITY_EVEN,
stopbits=serial.STOPBITS_TWO,
bytesize=serial.EIGHTBITS,
timeout=0.3)
def serial_read(s,t, info):
while True:
msg = s.read(24)
if msg:
start_time = time.strftime("%d.%m.%Y %H:%M:%S")
print(info, end="")
print(start_time, end="")
print(" ", end="")
for c in msg:
print("%02x " % c, end="")
print()
t.write(msg)
#serial_read(sero, serv)
thread1 = threading.Thread(target=serial_read, args=(serv, sero, 'S ',),)
thread2 = threading.Thread(target=serial_read, args=(sero, serv,'R ',),)
thread2.start()
thread1.start()
@hendrikland Hi. Ich habe auch eine Vitoligno 300-C und suche verzweifelt nach Adressen, vor allem den FehlerStatus. Ich bekomme korrekte Antworten bei der Fehlerhistorie der letzten 10 Fehler, aber der Status selbst funktioniert noch nicht. Hattest du schon Erfolg und würdest du die Adressen mit mir teilen? Grüsse Richard
Please tell me the request address V100 boiler pump in operation or not / It is not in the list of addresses of Viessmann-adresses
Könntest du den Python-Code sharen? Ich habe einen ähnlichen Aufbau vor, es geht erstmal nur darum die Daten mitzulesen. In meinem Fall ein Pellet-Kessel (Vitoligno 300-C), bei dem es nützlich wäre einige Werte zu erfassen (Anzahl Zündvorgänge, Brenndauer, Pelletverbrauch,...). Leider bietet die App nichts davon an, ich vermute aber das das Vitoconnect die Werte ausliest. Ziel wäre es, dieses auf dem Raspi abzuzweigen und separat wegzuschreiben (z.B. Grafana).
@hendrikland Bist du mit dem Vitoligno 300-C weiter gekommen? Ich würde meinen auch gerne anbinden und die Werte von dir interessieren mich auch. Danke und Gruß
Wir standen vor dem gleichen Problem und wollten die VitoConnect 100 noch weiter laufen lassen. Da mir ein Raspberry für die Arbeit zu schade war und es mittlerweile für <10 € einen ESP32 DevBoard (mit CP2102 USB / UART Chip) gibt, wurde es dann eben eine minimale ESPHome Lösung.
Netterweise kann man den ESP direkt in den USB Port der VitoConnect 100 stecken und fleißig als Proxy den Traffic verfolgen oder eben weitere Requests einfließen lassen. Kleiner Bonus: Es läuft demnächst auch auf dem ESP ein kleiner Modbus Slave der unserer VitoCal 200-S die frei "verfügbare" PV-Strom Messwerte übergibt.
Für Viessmann ist diese Variante ohne größeren Aufwand und bei ausschließlich mitlesendem Gebrauch quasi nicht detektierbar.
Wichtig! Es reicht kein ESP8266 und kein Software UART, da die Kommunikation doch schon sehr (A) zeitkritisch erfolgen muss und (B) doch einiges von der VitoConnect 100 abgerufen wird.
@idstein wärst du bitte so nett und teilst kurz dein ESP Sources/Aufbau und eine kurze Beschreibung was du mit deinem DEV Board gemacht hast? Braucht keine große Beschreibung, vorallem interessiert mich wie du den USB Traffic forwardest / interceptest
ich hab mir jetzt eine Bridge gebaut, womit man vcontrold und vitoconnect parallel betreiben kann und die fehlenden Werte kriegt: https://github.com/h0nIg/vcontrol-vitoconnect-bridge/
Hi @idstein das sieht ja sehr spannend aus, kannst du deine ESPhome config teilen?
Hy @idstein
Echt cooles Projekt :) würd auch gerne mehr darüber erfahren :)
mfg Mike
@idstein wärst du bitte so nett und teilst kurz dein ESP Sources/Aufbau und eine kurze Beschreibung was du mit deinem DEV Board gemacht hast? Braucht keine große Beschreibung, vorallem interessiert mich wie du den USB Traffic forwardest / interceptest
Aktueller Stand baut das ganze auf ESPHome bei mir lokal auf fürs Management, Updates, ein bisschen Security usw. Die Funktionalität die Werte konkret auszulesen habe ich noch nicht finalisiert, ich hoffe aber demnächst hier weiter zu kommen.
Funktion
- VitoConnect Passthrough (ohne Sniffing)
- ALE Energy Meter Simulator (Photovoltaik)
Roadmap
- Parse data points already accessed via VitoConnect
- Allow asking for specific data points independent of VitoConnect
Hardware
- ESP32 Dev Kit C V4 [Pinout]((https://github.com/openv/openv/files/9732491/ESP32_DevKit_C_V4_Pinout.pdf)
- Kabel Micro-USB
- IR-Emitter SFH4556 OSRAM 860nm 5mm 20° (https://www.ebay.de/itm/333428475405)
- IR-Receiver No-Name 5mm 940nm? Diode (https://www.amazon.de/dp/B08WCT6ZJ4)
Software
- ESPHome
- Fork VitoWifi (https://github.com/bertmelis/VitoWifi)
substitutions:
# Unique device ID
device_id: "heating01"
device_name: "Heizung Optolink"
esphome:
name: ${device_id}
includes:
- viessmann-vitoconnect/optolink.h
- viessmann-vitoconnect/optolink.cpp
external_components:
- source: github://epiclabs-io/esphome-modbus-server@master
refresh: 60s
components:
- modbus_server
esp32:
board: az-delivery-devkit-v4
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
password: !secret wifi_ap_password
# Enable Home Assistant API
api:
password: !secret api_password
encryption:
key: !secret api_encryption
# Enable over-the-air updates
ota:
password: !secret ota_password
# Enable Web server
web_server:
version: 2
local: true
port: 8080
auth:
username: !secret web_user
password: !secret web_password
logger:
baud_rate: 0 #disable logging over uart
uart:
- id: vitoconnectOpto2
tx_pin: GPIO1
rx_pin: GPIO3
baud_rate: 4800
data_bits: 8
parity: EVEN
stop_bits: 2
# debug:
# direction: RX
# after:
# delimiter: [0x41]
- id: vitocal200S
tx_pin: GPIO17
rx_pin: GPIO16
baud_rate: 4800
data_bits: 8
parity: EVEN
stop_bits: 2
# debug:
# after:
# delimiter: [0x06, 0x41]
- id: ale3energymeter
tx_pin: GPIO32
rx_pin: GPIO33
baud_rate: 19200
data_bits: 8
parity: EVEN
stop_bits: 1
# debug:
# dummy_receiver: true
# after:
# bytes: 8
sensor:
# TODO replace with local Optolink reading; current value is based on reading EEBUS via GridX Box
- platform: homeassistant
id: heatpump_power_consumption
entity_id: sensor.heatpump_power_consumption
device_class: power
unit_of_measurement: W
accuracy_decimals: 0
- platform: homeassistant
id: meter_l1_power_supply
entity_id: sensor.meter_l1_power_supply
device_class: power
unit_of_measurement: W
accuracy_decimals: 0
- platform: homeassistant
id: meter_l2_power_supply
entity_id: sensor.meter_l2_power_supply
device_class: power
unit_of_measurement: W
accuracy_decimals: 0
- platform: homeassistant
id: meter_l3_power_supply
entity_id: sensor.meter_l3_power_supply
device_class: power
unit_of_measurement: W
accuracy_decimals: 0
button:
# - platform: template
# name: "Vitocal Send EOT"
# on_press:
# - uart.write:
# id: vitocal200S
# data: [0x04]
# - platform: template
# name: "Vitocal Send Sync"
# on_press:
# - uart.write:
# id: vitocal200S
# data: [0x16, 0x00, 0x00]
- platform: template
name: "Vitocal Request AT"
on_press:
- uart.write:
id: vitocal200S
data: [0x41, 0x05, 0x00, 0x01, 0xF8, 0x02, 0x00]
custom_component:
lambda: |-
auto my_custom = new UartOptoLinkSensor(id(vitoconnectOpto2), id(vitocal200S));
return {my_custom};
modbus_server:
- id: modbuserver
uart_id: ale3energymeter
address: 60 # slave address
holding_registers:
- start_address: 0 # REG_FIRMWARE
default: 10
- start_address: 1 # REG_MODBUS_REG
default: 52
- start_address: 2 # REG_MODBUS_FLAGS
- start_address: 3 # REG_BAUDRATE_HIGH
- start_address: 4 # REG_BAUDRATE_LOW
default: 0x4B00
- start_address: 5 # REG_TYP_ASN_FN_1
on_read: return atoi("AL");
- start_address: 6 # REG_TYP_ASN_FN_2
on_read: return atoi("E3");
- start_address: 7 # REG_TYP_ASN_FN_3
on_read: return atoi("D5");
- start_address: 8 # REG_TYP_ASN_FN_4
on_read: return atoi("FD");
- start_address: 9 # REG_TYP_ASN_FN_5
on_read: return atoi("10");
- start_address: 10 # REG_TYP_ASN_FN_6
on_read: return atoi("C2");
- start_address: 11 # REG_TYP_ASN_FN_7
on_read: return atoi("A0");
- start_address: 12 # REG_TYP_ASN_FN_8
on_read: return atoi("00");
- start_address: 13 # REG_HW_VERSION
default: 11
- start_address: 14 # REG_SN_HIGH
default: 0x1234
- start_address: 15 # REG_SN_LOW
default: 0x5678
- start_address: 21 # REG_STATUS
on_read: |
// No problem=0, Communication problem=1
return api_apiserver->is_connected() ? 0 : 1;
- start_address: 24 # REG_ERROR_REG
default: 0 # None=0, L1=1, L2=2, L1L2=3, L3=4, L1L3=5, L2L3=6, L1L2L3=7
- start_address: 26 # REG_TARIFF
default: 0 # TARIF_T1=0, TARIF_T2=4
- start_address: 27 # REG_TARIF1_ENERGY_TOTAL_HIGH
- start_address: 28 # REG_TARIF1_ENERGY_TOTAL_LOW
- start_address: 29 # REG_TARIF1_ENERGY_PARTIAL_HIGH
- start_address: 30 # REG_TARIF1_ENERGY_PARTIAL_LOW
- start_address: 31 # REG_TARIF2_ENERGY_TOTAL_HIGH
- start_address: 32 # REG_TARIF2_ENERGY_TOTAL_LOW
- start_address: 33 # REG_TARIF2_ENERGY_PARTIAL_HIGH
- start_address: 34 # REG_TARIF2_ENERGY_PARTIAL_LOW
- start_address: 35 # REG_PHASE_1_VOLTAGE
- start_address: 36 # REG_PHASE_1_CURRENT
- start_address: 37 # REG_PHASE_1_POWER 1545 = 15,45 kVA
on_read: |
if (!api_apiserver->is_connected() || !id(meter_l1_power_supply)->has_state() || !id(heatpump_power_consumption)->has_state())
return 0;
return (id(meter_l1_power_supply)->state - id(heatpump_power_consumption)->state / 3) / 10;
- start_address: 38 # REG_PHASE_1_REACTIVE_POWER
- start_address: 39 # REG_PHASE_1_COS_PHI
- start_address: 40 # REG_PHASE_2_VOLTAGE
- start_address: 41 # REG_PHASE_2_CURRENT
- start_address: 42 # REG_PHASE_2_POWER 1545 = 15,45 kVA
on_read: |
if (!api_apiserver->is_connected() || !id(meter_l2_power_supply)->has_state() || !id(heatpump_power_consumption)->has_state())
return 0;
return (id(meter_l2_power_supply)->state - id(heatpump_power_consumption)->state / 3) / 10;
- start_address: 43 # REG_PHASE_2_REACTIVE_POWER
- start_address: 44 # REG_PHASE_2_COS_PHI
- start_address: 45 # REG_PHASE_3_VOLTAGE
- start_address: 46 # REG_PHASE_3_CURRENT
- start_address: 47 # REG_PHASE_3_POWER 1545 = 15,45 kVA
on_read: |
if (!api_apiserver->is_connected() || !id(meter_l3_power_supply)->has_state() || !id(heatpump_power_consumption)->has_state())
return 0;
return (id(meter_l3_power_supply)->state - id(heatpump_power_consumption)->state / 3) / 10;
- start_address: 48 # REG_PHASE_3_REACTIVE_POWER
- start_address: 49 # REG_PHASE_3_COS_PHI
- start_address: 50 # REG_TOTAL_POWER
- start_address: 51 # REG_TOTAL_REACTIVE_POWER
Hy @idstein
Echt ein MEGA-COOLES Projekt :) Werde das gespannt weiterverfolgen und hoffentlich hab ich bald mal Zeit das "Nachzubauen". Erstmals werde ich das ohne dem "Modbus-Energymeter-Simulator" machen... Soll aber mit der PV dann auch noch folgen.
Danke, dass du das Projekt mit uns teilst 😄
Mfg Mike
Hi @idstein, cooles Projekt ich verwende momentan die Viessmann API um über das Vitoconnect100 die Daten in mein Loxone Smarthome zu bekommen. Allerdings ist die API sehr eingeschränkt und teilweise jetzt auch kostenpflichtig. Wegen der Garantieverlängerung würde ich aber gerne das Vitoconnect weiter in betrieb lassen. Daher wäre es echt cool wenn man mit deiner einfachen Lösung das Vitoconnect weiterverwenden kann und zusätzlich Daten lokal abfragen und auch setzen kann. Bin mit ESP Home bisher noch nicht ganz firm. Kannst du kurz den aktuellen Stand nochmal etwas detaillierter beschreiben? Ich habe verstanden, dass die Daten zwischen dem IR Modul und dem Vitoconnect in beide Richtungen durchgereicht werden. Zusätzlich schleifst du PV Daten hier ein. Können auch Daten aus dem Traffic ausgelesen werden ? Vorlauftemperatur oder so? Wie läuft die Installation auf dem ESP32. ESPHome flashen und dann zusätzlich VitoWifi?
Vielen Dank!
Moin ihr! hab ich das richtig verstanden - ihr habt eine Wärmepumpe mit Optolink? Wenn dem so ist, könnt ihr mir mal die 4 Bytes ab Adr. F8 und ein Byte an Adr. F0 sagen? danke & beste Grüsse! Phil
Morgen, Kann ich leider nicht, da bei mir noch alles original ist und ich nichts auslese.
mfg mike
aber da is eine Vitotronic drin, oder? da könnte dan im Menü unter 'Service' ganz hinten ein Punkt 'Software Information' oder so sein. Das Passwort dafür ist 'vimaster'
HW/SW Index sind das 3. und 4. Byte von F8, ich glaube die Zahl vor dem Punkt ist F0. Ich gehe davon aus, dass bei einer Vitotronic die ersten beiden F8 Bytes 20 CB sind...