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

[HerrP]

sehr seltsam! startet Open3Eclient denn?

[ghNeandr]

"python3 Open3Eclient.py --can can0"   meckert zumindest nix an

[ghNeandr]

Die GND Verdrahtung scheint ja wirklich was zu bewirken. Allerdings, was mein "verschwundener" Beitrag auch beschreibt: 
GND ist jetzt von der VX3 zum CAN2USB Adapter durchgezogen. Allerdings nicht am E380 angeschlossen in Ermangelung eines geeigneten Pin/Anschlusses. Das dicke gegr-Erdungskabel wollte ich nicht einbeziehen.
Was das allerdings mit dem Raspbian Buffer zu tun haben soll??

[ghNeandr]

Futterzeit 😩

[TSG]

Gerne hier sammeln / eintragen:

https://github.com/TheSmartGerman/open3e/wiki/090-Homeassistant

ich in gerade auch noch fleißig am Sensoren anlegen. Wenn ich damit durch bin, werde ich diese auch zur Verfügung stellen.

AutoDiscovery müsste ja aus dem Code von open3e kommen. Das wäre hammer. einfach nur das Topic auf "homeassistant" zu stellen reicht leider nicht.

[SanMiggel]

Auto Discovery für Home assistant wäre tatsächlich eine prima Sache. Ich habe schon ein krudes Python Script geschrieben, dass das zumindest für Sensoren tut. Wenn Interesse besteht, und die Cide owner einverstanden sind, würde ich mir mal Gedanken machen wie man das im Projekt unterbringen könnte. 

Eine Möglichkeit wäre ein spezielles mqtt command das eine Discovery message triggert.

Grüße

SanMiggel 

PS: Klasse Projekt. Der cloudzwang hat mich schon seit Anfang an genervt.

[TSG]

Das wäre ja genial! Klar das wäre mit @HerrP  zu klären. ggf. erst mal auf einem eigenen branch. ioBroker, Homeassistant, ... Da müsste man schauen, wie man das unter einen Hut bekommt. Vielleicht müsste man das Thema auch hier besprechen: https://github.com/abnoname/open3e/discussions

[HerrP]

ups war die neue Seite voll an mir vorbei gegangen... @ghNeandr  der E380 hat ja offensichtlich seinen Potentialbezug. Hauptsache dein CAN Adapter hat jetzt auch einen 🙂 Aber mit dem Buffer vom Raspi kann das ja wirklich nix zu tun haben. Irgendwie is heute echt der Wurm drin. Bei Sebliner stürzt depict ab wegen der Darstellung irgendwelcher Multibyte-Zeichen, dabei macht das ja einiges, aber eigentlich nix Ausgefallenes und erst recht nix Unbekanntes mit unvollständigen oder unzulässigen Zeichen darstellen, bei dir braucht udsoncan plötzlich irgendwelchen dubiosen Buffer.... ich hab keine Ahnung was los ist.

[HerrP]

@SanMiggel  so ein MQTT Command kann man doch eigentlich 'von überall her' absetzen, oder?

[SanMiggel]

@HerrP Prinzipiell hast du natürlich Recht. Aber es würde Sinn machen, wenn man die Metadaten zur Verfügung hat. Also data point mapping z.b. Ggf. Könnte man auch Einheiten noch zu den Data Points hinzufügen.

Ich denk nochmal drüber nach...

[HerrP]

ich kenn mich doch mit dem ganzen HA Zeugs nich aus. 'Unser' @Juergen-B  alias MyHomeMyData oder auch @JörgWende sind da viel bessere Ansprechpartner (wir ham da bestimmt noch andre). Die verstehen dann auch, wodrüber ihr redet 🙂

[ghNeandr]

Am Ende des Tages noch zwei Details meiner Installation bei der Open3E_depictSystem.py mit dem Fehler
Exception: [Errno 105] No buffer space available  aussteigt:
1.  Die VX3 zeigt Fehler F.1034-1  und das seit dem Open3E_depictSystem Versuch alle 5 bis 10 min

2. CAN Bus Statistik zeigt Aktivitäten, aber nicht mehr den Fehler, der auftrat als GND nicht durch verbunden war:

Zwei Abfragen mit ip -details -statistics link show can0

um ca 18:00

RX: bytes packets errors dropped missed mcast
1001728 125216 0 0 0 0
TX: bytes packets errors dropped carrier collsns
24 3 0 0 0 0

und 24:00

RX: bytes packets errors dropped missed mcast
416725400 52090675 0 0 0 0
TX: bytes packets errors dropped carrier collsns
24 3 0 0 0 0

[Juergen-B]

@HerrPHallo Phil, ich würde ja bei HA gerne helfen, brauche da aber selbst immer mal wieder Unterstützung. Ich hab's nicht so mit den YAML-Dateien. Nutze HA fast nur für ESPHome.

Bei ioBroker kenne ich mich ganz gut aus. Bin im Moment dran, einen Adapter zu schreiben, der die Funktionalität von open3e und E3onCAN zusammenführen soll. Also UDS und Lauschen kombiniert, je nach Bedarf. Einiges tut schon. Wenn es läuft, hat man die Daten von allen gewünschten Geräte aus allen Quellen in einem Objektbaum, direkt als Raw, Tree und JSON. Man kann sich dann also aussuchen, was gerade am besten passt.

Wenn es mal einen Alpha-Stand erreicht hat, poste ich den Link zum Repository. Dann können Mutige mal damit rum probieren.

Nutze grade recht intensiv Deine virtuelle E3, damit ich meine UDS Gehversuche nicht am realem Systen ausprobieren muss. Ein echt super cooles Tool!

Leider habe ich für Javascript keine UDSonCAN-Bibliothek gefunden. Also ist Selbermachen angesagt. ReadByDid tut schon.

[ghNeandr]

@Juergen-BHört sich so an, dass ich deine Arbeit gerne nutzen würde. Meine Absicht ist meine Vitocharge VX3/Vitocal 250-A in meiner Nodered HA zu integrieren. Bisher sehe ich nur die WP mit der ViAPI, für PV steht da aber eher nix zur Verfügung.
Sobald ich dann doch noch den Open3e Ansatz zum zuverlässigen Einsatz bringe wäre dein Projekt die gelungene Ergänzung! Ich bleib gespannt, bleib dran an deinem Projekt und viel Erfolg!

[Sebliner]

Im udsoncan.log war bei mir gar nichts eingetragen. Ich werde am Montag nochmal den 265er did wie beschrieben über 0x684 auslesen. War nur heute schon auf dem Weg zur Arbeit und morgen den ganzen Tag unterwegs 😔

edit: nun doch zumindest mal noch schnell den did von 0x684 ausgelesen und das kam raus:

So war es korrekt angefragt?

Bei der 2. identischen Anfrage kurz darauf kam dann besagte TimeoutException:

candump lief noch parallel, allerdings auch noch open3e mit Abfragen alle 5 sekunden, deswegen ist der log jetzt mega unübersichtlich. Sorry, wollte es nur schnell noch vorm schlafen machen und dann doch länger geschaut 😩

Beim drüberschauen über den candump log scheint es mir so zu sein: direkt nach anfragen des dids kam nichts über 684, nur einmal kurz nach der ersten TimeoutException kamen die gepostet 3 Einträge. Danach kamen keine 684er mehr. Ich werde Montag nochmal richtig schauen und ordentlich loggen, aber ich bekomme so schon Ärger von meiner Frau und muss erst mal ins Bett 😬

Einen online-meeting fähigen Rechner habe ich  - lohnt es sich sich einmal zu verabreden damit ich direkt alles testen kann was euch eventuell hilft bei der Fehlersuche? Gibts hier eigentlich PNs? 😅

[HerrP]

@Sebliner  jap, hier gibt's PNs. schauen wir mal. Dass in dem uds log nix drin stand wundert mich nicht, weil der Fehler eben was mit Zeichendarstellung zu tun hat, womit aber weder udsoncan noch depictSystem irgendwas am Hut haben, erst recht keine ausgefallenen Zeichen. Es werden ja einfach nur Bytes ausgelesen und die noch nichtmal dargestellt. Und der Fehler kam ja aus den Tiefen von udsoncan, genauso wie der seltsame unstillbare Bufferhunger bei ghN. Heute scheint ein seltsamer Tag zu sein...

Wir müssen erstmal klar bekommen, was wir eigentlich erreichen wollen und wie wir da hin kommen wollen. Das ist zuindest mir aktuell nicht mehr ganz klar.

[HerrP]

@ghNeandr  zumindest stehen die Fehlerzähler von deinem USB Adapter jetzt schon mal auf 0 und nicht bei ein paar Hunderttausend oder Millionen wie gestern. So gehört sich das. Auf dieser Grundlage kann man aufbauen.

Hast du ne Ahnung was die Fehlernummer bedeutet? depict liest ja blos, das sollte zu keinem Fehler führen, erst recht zu keinem, der auch noch später periodisch wieder kommt. So ein CAN Protokoll ist sehr sicher, es ist also auch nahezu ausgeschlossen, dass wegen der Floaterei irgendein Frame 'missinterpretiert' worden wär.

Hast du schon mal einen 'Hauptschalter-Reset' der ganzen Anlage gemacht? Es kann sein, dass wegen den Busstörungen auch noch bei andren Teilnehmern die Fehlerzähler hochgelaufen sind.

Bevor wir mit depictSystem anfangen, sollten wir erstmal sicher sein, dass das System jetzt stabil läuft. Wenn da weiter Timeouts drin sind, nutzt depict nix, weil es dann warscheinlich ein falsches Bild zeichnet, was nicht zu gebrauchen ist.

Lieber erstmal mit Open3Eclient mittels -dev vx3 (datapointsVx3) ein paar bekannte weit verbreitete Datenpunkt zyklisch auslesen und schauen was passiert. Du sagtest ja auch, dass das ohne 'Bufferhunger' startet (wobei das intern die gleichen Funktionen von udsoncan benutzt...). Allerdings glaube ich, dass man mit dem Retry Mechanismus Timeouts garnicht mehr unbedingt bemerken würde... da müssen wir noch mal schauen.

[HerrP]

Moin Jürgen @Juergen-B ! Das freut mich, dass noch jemand was von der virtualE3 hat und ich sie nicht nur für mich gebaut habe 🙂 Sie ist an manchen Stellen noch nicht 100%ig, aber das hängt eher damit zusammen, dass sie mal auf alles und mal nur auf die datapoints oder aus den virtdata oder beidem oder oder oder antworten soll... Aber mit -cnfg dev und einem sauber abgebildetem Set ist eigentlich alles rund.

Ich bin gespannt was du da wieder baust! Hoffentlich verstehe ich das! 😉

[HerrP]

@ghNeandr 

Wiederstände hast du doch einen an der VX3 und einen an dem Adapter (da den Jumper gesteckt) und keinen auf dem E380, richtig? Dann mach mal einen Hauptschalter Reset, ich denke bei der VX3 ist auch schon 'Eskalationsstatus' erreicht. Es gibt auch ein NMT Command zum communication reset, aber wer weiss ob die überhaupt noch zuhört...

[Juergen-B]

Beta-Tester sind natürlich willkommen 🙂

open3e und meinen Adapter würde ich aber nicht parallel betreiben, sonst trommeln zwei Systeme unsynchronisiert auf dem Bus rum. Man könnte nach ECU-Adressen (0x680, 0x6a1, ..) aufteilen, das würde funktionieren. Sehe aber keinen Sinn darin.

Denke, die Diskussion können wir führen, wenn Du den Adapter  mal gesehen hast.

[HerrP]

Moin @ghNeandr !

So eine VX3 schaltet man natürlich nicht mal eben aus und wieder an wie einen Fernseher...

Möglicherweise reicht Schritt 1 zum Zurücksetzen des Fehlers / der Fehlerzähler schon. Schritt 2 wäre dann sozusagen der 'Hauptschalter'. Wenn der CAN Controller dann weiter von der Batterie am Leben gehalten wird, drohen Schritte 3 und 4.

Einschalten muss man danach dann ja auch wieder - möglichst ohne erneuten Inbetriebnahmeassistenten...

Weiss jemand, wie man einen Fehler Reset an der Vitocharge macht ohne sie auszuschalten?

@TSG  ich würde nach dieser Erfahrung gern im Wiki das Bild mit 2-adrigen Anschluss des galvanisch getrennten CAN2USB an den Energiezähler dick durchstreichen! Wäre das ok für dich? Das Bild steht als erstes da, und wer nicht weiter liest, denkt dann wohlmöglich man solle es so machen. Ich kann mir auch gut vorstellen, dass viele der Timeout Probleme nicht vom ISO-TP Kernel kommen, sondern von dieser 'bodenlosen' Verdrahtung...

[TSG]

@HerrP Das Wiki ist "offen" jeder kann daran editieren. Gerne einen Hinweis zum CAN GND einfügen. Bild darf auch gerne durch ein passenderes ausgetauscht werden.

In diesem Fall noch eine Direkte Frage:

Im arg File reicht eine der beiden Angaben: dev oder config? habe ich das richtig verstanden?

--dev
vcal
--config
devices.json

[HerrP]

wenn du --config (-cnfg) benutzt wird --dev (-dev) ignoriert, es reicht also definitiv eine der beiden Angaben.

-dev kommt noch aus den Anfängen, wo wir mit 'unseren' Anlagen geprobt hatten und gesehen, dass es bei einer vcal anders aussieht als bei einer vdens.

Du kannst sogar beide Angaben weglassen, dann wird in open3e ein device (oder streng genommen erstmal eins für die default-ECU Adresse und später gegebenenfalls für jede andere angesprochene ECU Adresse ein weiteres) angelegt, was den kompletten 'Datensatz' der Open3Edatapoints.py hat. Dann darf man aber kein --scanall machen, weil dann zwangsläufig Datenpunkte ausgelesen werden wollen, die auf dem realen Gerät nicht existieren (kein Open Base Gerät hat alle Datenpunkte). Ausserdem gibt es Probleme, wenn du einen Datenpunkt 'anfasst', bei dem die Datenlänge auf dem realen Gerät anders ist als in der Open3Edatapoints hinterlegt (es gibt ein paar wenige Datenpunkte, die auf verschiedenen Geräten unterschiedliche Längen und damit unterschiedliche Codec-Definitionen haben).

[Wolfgang04]

Hallo Zusammen, 

ich klinke mich hier mal ein. Ich bin zwar auch nicht der YAML-Guru, habe aber selber einen Home Assistant seit ca. 2 Jahren laufen und in dieser Zeit ein paar Erfahrungen gesammelt. Ich würde gerne das Projekt und die Integration in HA unterstürzen und mich mit Euch austauschen. Hierzu habe ich eine eigene Diskussion für "Home Assistant" unter 

https://github.com/abnoname/open3e/discussions/54

gestartet. 

Viele Grüße

Wolfgang

[TSG]

Ich habe da mal ein Paar sensoren angelegt:  https://github.com/TheSmartGerman/open3e/blob/homeassistant/homeautomation/homeassistant/mqtt_sensor...