CAN Bus, Home Automation E3 Generation lokal und kostenlos

[HerrP]

hier noch mal mein Beitrag aus 'Internet der Dinge', dem Offenen Brief an Max Viessmann, als neuer Thread - Diskussionen, Fragen etc. bitte hier 🙂

Moin Freunde!

Da Viessmann zwar ein wunderschöne Schnittstelle (UDS, ISO-TP oder DoIP) eingebaut hat, das aber nur eingeschränkt und für eine 4-stellige Summe (per WAGO Gateway) zur Verfügung stellt, haben wir uns bekanntlich dran gemacht, das selber offen zu legen. 🙂

Stand der Dinge ist:

- Wir haben eine MQTT fähige Lösung zum Anschluss an den externen CAN Bus ("Stecker 91"), die es erlaubt, E3 Geräte (Wärmepumpen, Gasgeräte, (PV Speicher gerade in der Testphase, BSZ brauchen wir noch Kandidaten)) in Home Automation Systeme einzubinden. ioBroker, mosquitto, Home Assistant, Node-RED und so weiter also alles einfach machbar und bei uns schon im dauerhaften Einsatz.

- Das Ganze läuft lokal, also ohne irgendeine Hersteller oder sonstwelche Cloud, ohne Internet! Bei der CAN Bus Kopplung kann die gleichzeitige Verbindung mit dem Viessmann Server zwecks Wahrung der Gewährleistungs- und Garantieansprüche aufrechterhalten bleiben.

Eine Anbindung über den WLAN Access Point ist auch möglich, damit aber keine parallele Viesmann-Server-Verbindung mehr.

- Aktuell ist nur das Auslesen von Daten weitergehend erprobt. Bei den wichtigen Daten haben wir auch schon die Formate zur Interpretation geklärt, wir arbeiten an einer vollständigen Klärung.

Das Schreiben ist bei vielen Daten auch schon erprobt.

und last not least: das Ganze ist natürlich kostenfrei und open source! im Sinne eins besseren Miteinanders 😉

Der laufend aktualisiert werdende Stand der Linux Lösung ist auf

https://github.com/open3e/open3e

verfügbar. Einen guten 'Leitfaden' für den Einstieg hat @Hotzen-Plotz hier zur Verfügung gestellt:

https://github.com/open3e/open3e/discussions/5

Eine Sammlung von nützlichen Informationen hat @TSG initiert:

https://github.com/TheSmartGerman/open3e/wiki

(werden wir bald auch unter das open3e Projekt migrieren) 

beste Grüße!

Phil

zur Beachtung: Der Zugriff auf das Zielgerät mittels dieser durch Viessmann nicht vorgesehenen Lösung zieht möglicherweise den Verlust von Gewährleistungs-/Garantieansprüchen nach sich und kann unter Umständen zu GEFAHREN FÜR LEIBLICHE UNVERSEHRTHEIT ODER SACHWERTE führen! Die Autoren schliessen jegliche Haftung aus.

Beispiele aktueller Home Assistant Integrationen von Wärmepumpen:

Vitocal 250 Kältekreisübersicht: View und Installationsanleitung gibt's hier: https://github.com/MyHomeMyData/iob.vis.vitocal250.git

Visualisierung der Vitocal Energiematrizen zur monatlichen Energiebilanz für ioBroker:

Wer es ausprobieren möchte: Hier gibt es eine Anleitung.

Jürgen hat auch noch weitere schöne Sachen abgeleitet.

Einen Adapter für ioBroker:

https://github.com/MyHomeMyData/ioBroker.e3oncan

und noch ein paar andre Sachen, die aber in dem Adapter integriert sind. Schaut einfach mal sein Repo an...

https://github.com/MyHomeMyData

ps. wer uns unterstützen will und kann ist herzlich willkommen!

pps. und wir freuen uns über jedes 'like' (👍) - damit zeigt ihr deutlich, dass ihr eine offene und lokale Kommunikation mit den 'One Base' Geräten eigentlich von Viessmann erwartet

[RomanSch]

Ich habe oben auf @wamo beitrag geantwortet bzgl. Der Netzwerk Konfiguration. Deine Idee mit WiFi und RJ45 auf dem Raspi nutzen geht in die selbe Richtung aber du musst auch dort mit zwei Routen arbeiten (die Befehle unter Linux hab ich gerade nicht auswendig parat, im Gegensatz zu den Windows commands). Daher muss die FRITZ!Box/Router Garnichts spezielles können oder speziell konfiguriert werden

[HerrP]

Moin @RomanSch !

Wenn ich @wamo  richtig verstehe und seinen Screen Shot richtig interpretiere geht es ja bereits. Kann es sein, das wenn die WLAN 'Karte' im 0er und die LAN 'Karte' im 178er Subnetz läuft es garkeiner 'extra' Route bedarf? Eigentlich gibt es ja nur eindeutige Wege...

Grüsse!

Phil

[wamo]

richtig, mit meinem Windows Rechner funktioniert das Problemlos.

Habe nur den Netzwerkdienst Ras und Routing freigeschaltet!
glaube aber das das nicht unbedingt gebraucht wird, wenn der MQTT Broker richtig Configuriert ist.

der lauscht Netzwerkübergreifend auf Port 1883 !
wollte das jetzt aber auf meinem Server mit Ubuntu einrichten, da habe ich allerdings noch Probleme!
in erster Linie Wlan einrichten und mit den AP von Viessman verbinden bekomme ich über die Konsole nicht hin!
muss den Server heute mal aus dem Versteck holen, Monitor und Tastatur anschliessen und dann mal sehen ob das dann da auch funktioniert?

weiß jemand ob auf dem Can Bus die gleichen Datenpunkte wie auf dem AP sind?

oder sind da eventuell mehr?

überlege ob ich mir nicht doch noch einen Adapter bestelle und mal mit dem Can Bus versuche.

binn jetzt neugierig geworden, und da gibt es mein eigenens 'Www' Walter wills wissen !

[Hotzen-Plotz]

@HerrPIch habe mir jetzt mal einen Adapter bestellt und einen passenden originalen "Stecker 91" besorgt. Ohne dremeln sehe ich da sonst auch keine Chance.

Die Software habe ich auf den Raspi kopiert und sie wartet jetzt auf die fehlender Hardware. Ich bin gespannt, ob da wirklich direkt ein Sub-D Stecker mit dabei ist.

Es wäre super, wenn Du bei den anderen iobroker Usern nachfragen könntest

a) welchen iobroker Adapter für MQTT die nutzen (es gibt mehr als eine Option), also wie genau das Ding heisst. Ich mutmasse es ist der hier: https://github.com/ioBroker/ioBroker.mqtt

b) welche Einstellungen man darin machen muss, um die Daten vom Open3e aufzusaugen. Es scheint einen ganzen Haufen von Clienbt settings zu geben (siehe Link oben), die für wenig bewanderte Leute absolut nichtssagend sind.

[HerrP]

Moin @Hotzen-Plotz !

Ich hoffe mal, dass 'die anderen ioBroker User' hier mitlesen und sich mal zu Wort melden. Leider (für das hier jetzt) ist unser 'Könner' Jürgen (leider erinnere ich sein Account hier nicht) gerade über den grossen Teich in Urlaub...

Ich hab aber noch mosquito (Adapter?) irgendwie in Erinnerung, aber das ist glaubich nicht entscheidend.

ps. wie gesagt - wenn das mit dem d-Sub Stecker wirklich ein Problem sein sollte, löte ich grad an einen drei Kabel dran und schick ihn dir.

[HerrP]

@wamo  die Objekte/Datenpunkte sind unseres Erkenntnisstandes nach die gleichen, egal ob man per DoIP oder ISO-TP (onCAN) kommuniziert. Auf 'dem' CAN Bus gibt es aber noch 'internen Verkehr', und es gibt ja auch zwei CAN Busse (einen externen auf Stecker 91 und einen internen).

>> mit dem AP von Viessman verbinden ... mal sehen ob das dann da auch funktioniert?

bei uns hat es zuerst auf Linux Systemen funktioniert. sollte eigentlich kein Problem sein.

Wenn du grossen Forschungsdrang hast, wärest du vielleicht auch nützlich in unserer Gruppe!? 😉

[wamo]

heute den ganzen Tag mit meinem Server mit Ubuntu gekämpft, fast das ganze System dabei zerschossen!
da funktioniert nichts, weder die Wlan Verbindung zum Viessmann AP, kann zwar verbinden, aber noch nicht mal anpingen!
noch die Installation von open3e, da funktioniert pip3 einfach nicht!

wollte das updaten , neu installieren und dabei fast mein ganzes System zerstört!

Fehler bei pip3 install -r requirements.txt

error: externally-managed-environment

× This environment is externally managed

Edit:

open3e konnte ich jetzt installieren, hab im i-net dazu was gefunden.

mit

pip3 install -r requirements.txt --break-system-packages

hat es funktioniert !

[HerrP]

---

mit

pip3 install -r requirements.txt --break-system-packages

hat es funktioniert !

---

gut zu wissen! Die Raspbians sind wohl nicht "externaly managed"

[Datenreisender]

Man kann open3e auch einfach in einem Docker Container laufen lassen. So kommt open3e dann nicht mit anderen Python Anwendungen auf dem Rechner in Konflikt. Docker gibt es auch für den Raspberry, allerdings sollte man das nur auf dem Raspi 4 machen.

[Hotzen-Plotz]

Hm. Ich habe jetzt den Adapter und Kabel hardwaretechnisch dran.

Auf meinem Raspi funktionierte dann auch das "pip3 install -r requirements.txt"

Allerdings bekomme ich die Software nicht zum Laufen.

Das hier "sudo ip link set can0 up type can bitrate 250000" schien ausgeführt zu werden, es kam zumindest keine Fehlermeldung.

Aber der erste richtige Befehl geht in die Hose:

"python3 Open3Eclient.py -d xxx.xxx.xxx.xxx -dev vdens -a"

führt zu

"Traceback (most recent call last):
File "/opt/git/open3e/Open3Eclient.py", line 62, in <module>
conn = DoIPClientUDSConnector (DoIPClient(args.doip, 0x680))
File "/home/[username]/.local/lib/python3.9/site-packages/doipclient/client.py", line 191, in __init__
self._connect()
File "/home/[username]/.local/lib/python3.9/site-packages/doipclient/client.py", line 766, in _connect
self._tcp_sock.connect((self._ecu_ip_address, self._tcp_port))
ConnectionRefusedError: [Errno 111] Connection refused"

Dabei habe ich die IP Adresse xxx.xxx.xxx.xxx angepasst auf die IP-Adresse des Raspi.

Die Doku "-d DOIP, --doip DOIP use doip access, e.g. 192.168.1.1" ist ja auch dürftig bzgl. der Frage, welche IP Adresse hier gemeint ist.

Jeder Tip ist willkommen.

---

[HerrP]

Moin @Hotzen-Plotz !

Du gehst doch jetzt über CAN, richtig? Die Kommandozeile mit der IP Adresse wäre wenn du das E3 Gerät über WLAN im AP Modus ansprechen willst. Mit CAN ist das einfacher. schreib einfach mal

python3 Open3Eclient.py -c can0 -dev vdens -r 268 -v

das sollte die Vorlauftemperatur auslesen und ausgeben.

Du hast doch eine Vitodens (Gastherme), oder? Wenn du eine Vitocal (Wärmepumpe) hast, musst du das '-dev vdens' gegen '-dev vcal' tauschen (wobei das bei der Vorlauftemp glaubich egal ist).

Wenn das dann geht, und du die MQTT Geschichte anwerfen willst, musst du

python Open3Eclient.py -c can0 -dev vdens -r 268,269,271,274,318,1043 -m 192.168.0.5:1883:open3e -t 1

oder

python Open3Eclient.py -c can0 -dev vdens -r 268,269,271,274,318,1043 -m 192.168.0.5:1883:open3e -t 1 -mfstr "{didNumber}_{didName}"

aufrufen.

• hierbei steht die IP Adresse für die IP Adresse deines MQTT Brokers (anpassen im Aufruf!), nicht für die des Raspi.
• Das ':open3e' hinter der IP Adresse und Portnummer (':1883' nicht ändern) ist der MQTT Topic, unter dem das im Broker landet.
• Die Zahlen '268,269,271,274,318,1043' sind die Datenpunktnummern (DIDs), die augelesen und 'gepostet' werden. Du kannst die Nummern und die zugehörigen Objekte in OpenE3datapointsXyz.py nachschauen und natürlich anpassen (in der Kommandozeile! NICHT die datapoints.py editieren).
• Mit der Option -a kannst du auch die ganze Liste abarbeiten lassen (wenig sinnvoll).
• die Option 't 1' bescheibt die Zykluszeit, hier 1 Sekunde.
• Mit dem '-mfstr "{didNumber}_{didName}"' bewirkst du, dass du eine Klartextanzeige der Items (oder wie das heisst) im Broker bekommst.

Respekt, dass du dich trotzt deiner 'Furcht vor dem Unbekannten' da dran machst!! 🙂

Grüsse!

[HerrP]

@Datenreisender  danke für den Tip mit dem Docker Container!

Grüsse!

[Hotzen-Plotz]

Vielen Dank! 👍 Mit dem "python3 Open3Eclient.py -c can0 -dev vdens -r 268 -v" hat es jetzt wirklich geklappt!

Fanfare für den ersten Erfolg! 😁

Zu viel mehr komme ich jetzt am Wochenende vermutlich nicht mehr.

Da ich auf ein und demselben Raspi das Open3e und den iobroker mit dem MQTT-Adapter am laufen habe, mutmasse ich, dasss ich in der Befehlszeile schon die IP des Raspi eingeben muss.

Die nächste Schwelle wird sein, den MQTT-Adapter mit open3e reden zu lassen. Wie angedeutet gibts da auch was zu konfigurieren.

[HerrP]

Top!! 👍🎶  ich werde weiterhin mein Bestes tun dich zu unterstützen, aber wie schon mehrfach gesagt - bei dem Thema MQTT bin ich ziemlich raus, weil ich kein entsprechendes System habe und entsprechend keine Ahnung (/Praxis) davon. Ich werde noch mal in unserer Gruppe bitten, dass die entsprechenden Leute hier reingucken und möglichst deine Fragen beantworten 🙂

---

Da ich auf ein und demselben Raspi das Open3e und den iobroker mit dem MQTT-Adapter am laufen habe, mutmasse ich, dasss ich in der Befehlszeile schon die IP des Raspi eingeben muss.

---

da wirst du wohl recht haben. 😉  dann kannst du wohl auch 127.0.0.1 für local Host eingeben. Da spart evtl. irgendwelche 'Umwege'

[wamo]

ich arbeite zwar mit openhab aber für MQTT dürfte das wol die gleiche Befehlszeile tun.

python3 Open3Eclient.py -d 192.168.0.1 -dev vdens -t 20 -r 274,364,284,318,396,424,545 -m 192.168.178.19:1883:vitodens_333_f -muser yyyyyy -mpass yyyyyy

192.168.178.19:1883 ist die IP und Port von dem MQTT Broker, wichtig vielleicht noch, mit dem Parameter -r müssen Datenpunkte angegeben werden, nur mit Parameter -a kommt bei MQTT nichts an!

bei mqtt. conf hab ich listerner 1883 0.0.0.0 drin.

Edit:

sehe gerade du rufst ja den CAN Bus ab, da muss ja am Anfang -c für den Can bus rein, aber für MQTT dürfte der Rest schon passen!

[JörgWende]

Beim IoBroker den MQTT Adapter auswählen:

Und dann in der Konfiguration das passende Topic angeben - das ist das Topic was beim e3 Client angegebenen wurde: 

Wichtig ist die Ergänzung mit „…/+“ damit werden alle Untertopics mit im Objektbaum vom Iobroker verfügbar

[Datenreisender]

Zur Analyse von Canbus Daten gibt es inzwischen eine recht umfangreiche Tool Sammlung unter Awesome-Canbus. Evtl. hilft Euch das bei der weiteren Analyse.

Einfacher wäre es natürlich, wenn sich Viessmann dazu herablassen könnte, die Dokumentation an interessierte Entwickler herauszugeben.

[Bu-Na]

Hallo CAN-Experten,

ich betreibe eine Vitocal 250-SH mit angeschlossenem WAGO-Gateway. Der Datentransfer via Modbus TCP in Richtung IOBroker funktioniert problemlos. Leider werden über das Gateway keine kältekreisrelevanten Daten (z.B. Druck, Temp. Verdichter) zur Verfügung gestellt. Darum wurde zusätzlich ein Raspberry mit "RS485 CAN HAT (B) Expansion Board" von Waveshare an den externen CAN-Bus angeschlossen und entsprechend  Waveshare-Wiki konfiguriert.

Ein CAN-Dump funktioniert problemlos:

 $ candump can0

can0 75A [1] 05
can0 000 [2] 82 51
can0 701 [1] 05
can0 190 [7] 38 2F 14 37 10 00 60
can0 1FF [8] 18 09 17 14 37 10 00 00
can0 000 [2] 82 47
can0 000 [2] 82 49
can0 000 [2] 82 4B
can0 75A [1] 05
can0 000 [2] 82 4D
can0 000 [2] 82 48
can0 701 [1] 05
can0 190 [7] 38 2F 14 37 11 00 60
can0 1FF [8] 18 09 17 14 37 11 00 00
can0 000 [2] 82 4E
can0 000 [2] 82 4C
can0 000 [2] 82 50
can0 75A [1] 05
can0 701 [1] 05
can0 190 [7] 38 2F 14 37 12 00 60
can0 1FF [8] 18 09 17 14 37 12 00 00
can0 000 [2] 82 55
can0 000 [2] 82 53
can0 75A [1] 05
can0 000 [2] 82 62
can0 000 [2] 82 61. CTRL/C

Und jetzt die Vorlauftemp:
 $ python3 Open3Eclient.py -c can0 -dev vcal -r 268 -v
2023-09-24 20:56:04 [ERROR] UdsClient: [TimeoutException] : Did not receive response in time. Global request timeout time has expired (timeout=20.000 sec)
Traceback…..

Leider läuft die Parameterabfrage per Python-Script in ein Timeout.

Habe ich hier als CAN-Laie etwas übersehen oder funktioniert diese Konfiguration grundsätzlich nicht.

Vielen Dank

[HerrP]

@Datenreisender   so ein Tool aus der Liste haben wir auch schon im Einsatz. hat auch schon genutzt. ist aber auch mit Vorsicht zu geniessen... Trotzdem gibt es noch 'Rätsel', die damit nicht zu lösen sind.

Es gibt auch AI Analyse Tools für Bus Traffic, nur leider muss man die auch erstmal mit den E3 Geräten 'bekannt' machen. und eine VX3 alleine verhält sich auf dem Bus anders, als eine VX3 im Verbund mit bsw. einer Vitocal...

[HerrP]

@Bu-Na  das Timeout Problem kennen wir. Wir hattes es z.B. mit 32Bit Buster auf einem Raspi 4. Mit 64Bit Buster ging es dann. Allerdings hatte wir auch ein Raspi 4 mit 32Bit Buster, auf dem es lief. Es ist jedenfalls (soweit wir bisher gesehen haben (glaubich)) so, dass die eigentliche Kommunikation läuft - die Anfrage wird gesendet und die Antwort kommt auch, nur UDSonCAN scheint bei gewissen Systemkonfigurationen dann nicht weiter zu funktionieren und meldet Timeout.

Ich frag noch mal, ob wir inzwischen Genaueres wissen.

Mach mal einen Dump mit Filter auf COB-IDs 680 und 690 und schick die open3Eclient Anforderung. Gewöhnlich solltest du die Anfrage und Antwort auf dem Bus sehen. Wenn du UDS/ISO-TP nicht interpretieren kannst, poste den Dump bitte oder schick ihn mir (eMail gibt's per PM).

ps. 'hab grad schon den Tipp bekommen, das es mit einem Raspi 3 grundsätzlich zuverlässiger läuft als mit einem Raspi 4. welchen hast du im Einsatz? wenn 4, hast du vlt auch noch einer 3er?!

[wamo]

kann es sein das das Timout Problem auch bei der AP Abfrage kommen kann?

war am WE ja am umbauen, die Abfrage des AP und an MQTT schicken klapt mit dem Windows Rechner Einwanf frei.

das gleiche auf dem Rechner, Server mit Ubuntu hab ich aich zum laufen gebracht,

aber besonder bei der Abfrage und schicken an MQTT mit dem Parameter -t bricht das Programm immer mit Timeout ab!

im Log von udsoncan hab ich dann das gefunden :

[ERROR] UdsClient: [TimeoutError] : ECU failed to respond in time

da weiß ich im Moment nicht weiter.

[HerrP]

ah, damit wissen wir schon mal, dass UDS auch auf DoIP benutzt wird (UDSonIP - war ja eigentlich auch zu erwarten 😉 )

scheinbar hat die UDS oder die ISO-TP Bibliothek hier ein Problem auf manchen Systemen.

man könnte mal versuchen, das Timeout höher zu setzten, ich glaub, wir hatten das auch schon versucht, leider habe ich da den Faden verloren, weil in unserer alten Arbeitsumgebung (MS Teams Private Edition) alles in einem einzigen Thread lief. Aber wir bekommen die gewonnenen Errungenschaften bestimmt zurück, nur fehlen aktuell grad ein paar Leute, die da dran beteiligt waren

[Bu-Na]

Leider habe ich einen 4er mit 32Bit am Start.

Werde mal probeweise das Ding mit 64Bit aufsetzen und weiter testen...

Hier der Dump mit Filter:

$ python3 Open3Eclient.py -c can0 -dev vcal -r 268 -v

$ candump can0,680:7FFFFF,690:7FFFFF
can0 680 [4] 03 22 01 0C
can0 690 [8] 10 0C 62 01 0C 1C 01 17
can0 680 [3] 30 00 00
can0 690 [8] 21 01 4E 02 1B 01 00 55

[wamo]

@HerrP  bei mir schiebe ich das auch etwas auf die Installation von open3e, weil die nicht so ganz Reibungslos lief!
da haben mir immer wieder irgendwelche Rechte von Python Probleme gemacht.

schlauer Weise wollte ich Python mal komplett neu installieren und habe dabei meinen Rechner fast Total abgeschossen!
es läuft zwar alles wieder, aber bin mir nicht sicher ob da alles richtig ist?
komplett neu auf setzen? viel Arbeit!

[HerrP]

da war doch auch der Tip mit dem Docker Container (ist natürlich auch Arbeit und ich bin mir nicht sicher, ob die HW Anbindung dann 100%ig / 'ganz normal' ist)