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:
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
Morgen. Ich habe immer noch abstürze und das regt mich so auf dass ich mir schnell Buster installiert habe. Dummerweise kommt beim start von Open3e immer diese Fehlermeldung. Hat jemand ne Idee:
Der Adapter fährt hoch wenn ich ihn starte.
Danke!
Ja.
danke für die Rückmeldung! dass open3e auch mit den alktuellen Systemen laufen wird hoffe ich doch sehr, aber es ist wie gesagt eine Frage der Zeit. Das Update vom April mit dem ISO-TP Issue ist etwa vor einem Monat überall (nicht nur bei open3e) angekommen und hat 'plötzlich' haufenweise zu den inzwischen hinlänglich bekannten Fehlern geführt. Ich hab keine Ahnung, wie lange es gedauert hatte, bis das Issue 'geortet' und beseitigt wurde, aber die Zeit zum Durchmigrieren wird ähnlich sein wie beim Einbauen des Problems.
Es gibt noch so Lösungsansätze wie den out-of-tree iso-tp driver und so, aber auf einem Produktivsystem würde ich dererlei Experimente nicht unbedingt empfehlen.
Da hilft dann eben nur Geduld und die Hoffnung, dass die Sache wirklich in Ordnung gebracht wurde. open3e ist da jedenfalls unschuldig, und alles was wir tun können, ist, den Fehler zu ignorieren und ggf. ein Retry einbauen.
Ich glaube, das werde ich machen, auch wenn es 'sich nicht ziemt', aber dann läuft es zumindest irgendwie. depictSystem wird damit allerdings nur schwerlich zu realisieren sein, weil das guckt halt, was da ist, und wenn es mal da ist und mal nicht, können wir auch nur schwerlich ein sicheres Abbild machen.
~~~~~~~~~~~~~~~~
Wenn der CAN Adapter zu Problemen im System führt, wenn er nur elektrisch verbunden wird (nicht gestartet), und dann mal und mal nicht, dann ist das mit an Sicherherit grenzender Wahrscheinlichkeit das Problem mit dem fehlenden CAN_GND (es sei denn der Adapter wäre durch ESD oder so zerschossen, oder vlt reicht es, ihn mit falscher Baudrate zu initialisieren).
Der E380 hat wenigstens noch PE/N, was zwar eine denkbar schlechte Bezugsmasse ist, aber wahrscheinlich hat Viessmann den GND von der VX3 auch irgendwie an PE gekoppelt, und so reicht es im Rahmen der -/+27..40V um zu funktionieren.
Der isolierte CAN Adapter hat garkeinen Massebezug, da reicht schon eine ungünstige Phasenlage an irgendeinem Filterkondensator eines Schaltnetzteils, und der Adapter driftet irgendwohin (deswegen verschwindet der Fehler dann auch wieder, wenn es der 25k Widerstand geschafft hat, das Potential langsam ranzuziehen...).
Verbinde bitte irgendwie das CAN_GND von der VX3 mit dem CAN_GND (Pin 3!) deines Adapters. Dann ist das in trockenen Tüchern.
Zur allergrößten Not leg den CAN_GND vom Adapter an PE/N, vielleicht über 1k Widerstand oder so. Was andres kann der E380 ja auch nicht machen. Wirklich, ich verstehe nicht, wie man so eine Schei... bauen kann, und auch nicht, wie Viessman sowas dann auch noch einkaufen kann. Da haben wieder nur irgendwelche Business Fraggles geguck "wer labelt uns einen Energiezähler mit CAN?" aber die Ingenieure wurden nicht einbezogen...
Grüsse!
Phil
So sieht meine Installation des VX3/E380 CAN-BUS aus:
Da kann ich wohl GND erstmal vergessen. Der Kabelmantel ist definitiv nicht mit GND verbunden. An beiden Enden gecheckt.
@Awot252 schrieb:Habs Dann auch mal geschafft, ioBroker und mqtt auf den Raspi zu bringen. Nur den gelben Stecker bei der 252 muss ich noch finden sowie herausfinden, wie das dann funktioniert. Als blutiger Anfänger, sehr schwierig für mich.
Scheinbar musst du die Innenheiheit aufmachen, dann scheint es eine komfortabele Anschlussleiste zu geben.
Steht in der Montageanleitung für die 252.
TimeoutError, TimeoutException - ich hab jetzt die Faxen dicke 😎
und es ist mir jetzt auch egal, ob 'man das macht' oder nicht, ich habe es jetzt eingebaut:
TimeoutError und TimeoutException werden jetzt direkt in der class getrapt und im Falle eines Falles werden bis zu 3 Retries gemacht.
Wenn es auch beim 4. Mal immer noch nicht geklappt hat, erfolgt eine Meldung in der Console und es kommt eben kein Wert, aber das Skript läuft unbeeindruckt weiter.
Die Fehlerbehandlung muss so kompliziert sein, weil das eine ein generischer Fehler ist und der andre aus der usdoncan Lib kommt.
Negative Response Exception und so sind damit nicht unterdrückt, die führen weiterhin zum Fehler und sollen das auch.
Ich habe das auch für den DID Scan in depictSystem eingebaut, für den COB Scan geht es leider nicht (so einfach), weil da Timeout die normale Reaktion ist, wenn eine ECU nicht reagiert weil sie nicht da ist. Man könnte natürlich bei jeder ECU fragen "bist du echt nicht da? wirklich nicht? auch gaaaanz sicher nicht??" aber dann dauert das Ganze nochmal dreimal so lang und selbst dann ist es nicht wirklich sicher... Ich werde mal bei den Car Hacking Tools gucken, ob es noch eine andre Möglichkeit gibt, die Anwesenheit einer ECU festzustellen, aber ich fürchte ein bugy System ist und bleibt eine unsichere Sache, da kann man programmieren so viel man will 😕
@Sebliner dass es bei E3onCAN nicht passiert, hängt mit dem eigentlichen Problem zusammen. Beim nur 'Mithören' gerät der ISO-TP Kern nicht in Gefahr, in diese Race Condition zu geraten, weil es da kein Race gibt, das mal so und mal so ausgeht und eben mal diesen oder jenen Timeout verursacht. Wegen der Race Condition ist es auch sinnlos, vorm Retry länger zu warten, weil das Race schon vorbei ist, wenn der Fehler kommt (eigentlich bräuchte man garnicht warten). Das ist alles schon genau erforscht, geklärt und eben gefixt. In dem Issue Thread https://github.com/pylessard/python-can-isotp/issues/92 bei dem Autor gibt es ausgiebig Info und Links dazu, da kann man das alles haargenau nachlesen. Es nutzt aber nichts, davon kommt der Fix auch nicht schneller in den Distributionen an.
Ich hoffe, jetzt ist aber soweit zumindest erstmal Ruhe 🙂
ist online im develop branch. alpha geteste von mir mit provozierten Timeouts (bei mir gibt es ja keinen bugy Kernel), bitte testet es auch und gebt Rückmeldung falls noch was hakt (oder auch wenn alles perfekt ist 😉 )
Grüsse & viel Spass damit!
