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 einfachen Daten wie z.B. Warmwasser-Solltemperatur und so auch schon erprobt.

- In nicht all zu ferner Zukunft wird es eine einfache Windows Oberfläche zum Setzen der bisher den 'Fachpartnern' mit entsprechendem kostenpflichtigen Account vorbehaltenen Einstellungen wie zum Beispiel den "Energiespareinstellungen" bei den Gasgeräten geben.

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

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

[Juergen-B]

Ich glaube eher, dass die oberen 8 Bit unbenutzt sind. Die allermeisten Werte werden als 16 Bit Werte übertragen, warum sollte es hier anders sein?

Für eine Charge Obergrenze fällt mir kein sinnvoller Grund ein. Eine Backup-Funktion arbeitet um so besser (bzw. länger), je mehr Energie im Speicher ist. Warum sollte ich das nach oben limitieren?

[mbauer666]

Hallo, sorry wenn das hier durcheinander wird.

Ich versuche zu verstehen, was diese beiden Werte in Bezug auf die Sekundärpumpenleistung bedeuten.

Hintergrund ist das mein Volumenstrom beim Erwärmen des Heizwasserpufferspeicher immer um die 2000l/h bei der WW-Bereitung aber nur ca. 1500l/h beträgt. Mit dem hohen Volumenstrom komme ich nur auf eine Spreizung von 1,8°K, ich würde den Volumenstrom gerne testweise reduzieren, mit der Idee das die Anlage dann effizienter läuft. 

Ich habe mal versucht die Parameter in Dezimale Werte zu übersetzen. 

1100 CentralHeatingPumpMinimumMaximumLimit 14645f

1100 CentralHeatingPumpMinimumMaximumLimit = 20/100/95
1101 DomesticHotWaterPumpMinimumMaximumLimit 14643c

1101 DomesticHotWaterPumpMinimumMaximumLimit = 20/100/60

Passt ja auch zu den Parametern im Handbuch.

Denkt ihr das könnte passen? 

Es geht um die WP 250A.

[Martin_K_34260]

Das kann man in der ViGuide APP nachschauen. 

Mann kann diese auch ohne Anmeldung benutzen. Dann siehst du die gleichen Werte wie die Handwerker. Habe letzes Mal hinter einem Handwerker gestanden und mir das angeschaut.

[Martin_K_34260]

Die Abfragen vom VX3 sind schon sehr weit vorangeschritten. Ich bin jetzt am CAN Bus auch angeschlossen. Die BackupBOX hat der Installateur immer noch nicht aktivieren können. Anlage schaltet um, das Licht geht kurz an und wieder aus. Mal sehen, wann sich die Firma AquaTherm aus Kassel bei mir melden, seit 4 Wochen habe ich noch nichts gehört.

Beim Ausführen der Befehle bekomme ich immer wieder einen TimeOut. Woran könnte das liegen?

python3 Open3Eclient.py -c can0 -dev vx3 -r 1664 -v
2023-10-23 17:23:01 [ERROR] UdsClient: [TimeoutError] : timed out
Traceback (most recent call last):
File "/home/martin/open3e/Open3Eclient.py", line 111, in <module>
response = client.read_data_by_identifier([did])
File "/usr/local/lib/python3.10/dist-packages/udsoncan/client.py", line 167, in decorated
return func(self, *args, **kwargs)
File "/usr/local/lib/python3.10/dist-packages/udsoncan/client.py", line 442, in read_data_by_identifier
response = self.send_request(req)
File "/usr/local/lib/python3.10/dist-packages/udsoncan/client.py", line 2133, in send_request
self.conn.send(payload)
File "/usr/local/lib/python3.10/dist-packages/udsoncan/connections.py", line 65, in send
self.specific_send(payload)
File "/usr/local/lib/python3.10/dist-packages/udsoncan/connections.py", line 321, in specific_send
self.tpsock.send(payload)
File "/home/martin/.local/lib/python3.10/site-packages/isotp/tpsock/__init__.py", line 89, in send
return self._socket.send(*args, **kwargs)
TimeoutError: timed out

[mbauer666]

---

@Martin_K_34260  schrieb:

Beim Ausführen der Befehle bekomme ich immer wieder einen TimeOut. Woran könnte das liegen?

TimeoutError: timed out

---

https://github.com/abnoname/open3e/issues/10

[mbauer666]

---

@mbauer666  schrieb:

1100 CentralHeatingPumpMinimumMaximumLimit 14645f

1100 CentralHeatingPumpMinimumMaximumLimit = 20/100/95
1101 DomesticHotWaterPumpMinimumMaximumLimit 14643c

1101 DomesticHotWaterPumpMinimumMaximumLimit = 20/100/60

Ich würde gerne den Parameter 1100 auf denselben Wert wie den Parameter 1101 setzen.

Übergebe ich einfach den Hex Wert, oder muß der ausgelesene Wert von 1101 noch irgendwie angepasst werden?

python3 Open3Eclient.py  -c can0  -dev vcal  -raw  -w 1100=14643c

[HerrP]

@Juergen-B 

> Die allermeisten Werte werden als 16 Bit Werte übertragen, warum sollte es hier anders sein?

Prozentwerte der Akku-Ladung gern mal als 1-Byte Wert, vergl. z.B.

1664: O3EInt8(1, "ElectricalEnergyStorageStateOfCharge"),

> Für eine Charge Obergrenze fällt mir kein sinnvoller Grund ein.

Akku schonen. Eine LiIon Zelle lebt am längsten, wenn man sie zwischen 30 und 80% SOC betreibt. Toyota macht das bsw. bei Hybrid-Modellen (mind. einem) so, um die Batterielebensdauer zu erreichen.

Grüsse!

[Juergen-B]

Zugegeben, Akku schonen macht grundsätzlich Sinn. Aber das passt doch nicht zur Funktion BackupBox.

Hast Du eine Idee, wie wir das rausbekommen könnten?

[HerrP]

ehrlich gesagt wusste ich bis eben nicht mal was eine Backup Box ist 🙈 Aber du hast recht, eine SOC Obergrenze macht in dem Zusammenhang wohl keinen Sinn. Vielleicht ist das hintere Byte ja irgend eine Konfiguration? Hast du schon mal geguckt, ob die Viguide Demo irgend was dazu hergibt? Sonst evtl mal in der apk gucken...

[Schlotzer]

Hallo,

ich wollte mich für die Mühe bedanken, die ihr euch mit diesem Projekt macht.

Ich habe einen VX3 Standalone und lese diesen dank eures Skript soweit erfolgreich aus.

Das Skript läuft auf einem Raspberry Pi 4 mit Ubuntu 64Bit und diesem CAN-Bus Adapter: https://www.amazon.de/dp/B07Q812QK8?psc=1&ref=ppx_yo2ov_dt_b_product_details

Das einzige Problem besteht bei mir aufgrund des Kernels, wie in diesem Issue beschrieben: https://github.com/abnoname/open3e/issues/10

Der Gedanke, dass Viessmann für eine API und wie hier schon beschrieben MEINE DATEN!! Geld verlangt, ist grausam. Und selbst wenn die API kostenlos wäre, müsste ich eine aktive Internetverbindung haben um die Daten auszulesen, was dem Gedanken bzw. dem Grund für die BackupBox aus meiner Sicht etwas widerspricht.

Da ich bisher mit Python nichts anfangen kann, freue ich mich umso mehr, dass dieses Projekt existiert.

Ich möchte das Projekt gerne unterstützen.

Falls also Hilfe benötigt wird, dürft ihr euch gerne melden.

[HerrP]

Moin @Schlotzer !

> Falls also Hilfe benötigt wird, dürft ihr euch gerne melden.

Wobei wir ja immer Hilfe benötigen ist die Klärung, Zuweisung und ggf. Erstellung der Codecs für die Datenpunkte, bei denen aktuell noch RawCodec vor steht 🙂

Da das Projekt ja open Source ist kann da jeder seine Beiträge per git clone-commit-push-pull request einbringen. Zugegebenermassen stell auch ich mich damit noch etwas ungeschickt an, und wenn dir der Weg zu umständlich ist, kannst du uns deine Beträge auch hier oder per PM zukommen lassen.

Wenn was auszuprobieren ist, um zu schauen, ob es bei mehreren (und damit dann hoffentlich bei allen) Anlagen gleich funktioniert, werden wir uns gerne melden. Wenn du 'Expertenwissen' hast oder ein 'echter System/Entwickler' bist und genug Zeit für ein neues Hobby und Lust hast, mehr unbezahlte Arbeit im Sinne der Allgemeinheit (der E3 Benutzer) zu leisten, bist du auch im 'inner circle' des Teams herzlich willkommen 🖖

danke & Grüsse!

Phil

[Schlotzer]

Hallo Phil,

ich bin gelernter Fachinformatiker Systemintegration und hatte in der Ausbildung nicht unbedingt viel mit Coding zu tun.

Ich kann gerne helfen, müsste nur wissen, wie ihr die RawCodecs zuordnet.

Grüße

Nick

[Heizungspilot]

Ich habe einen Vorschlag zur Visualisierung relevanter Verdichter-Parameter, welche für die Lebensdauer von Kältemittelverdichtern hochrelevant sind.

Es geht dabei um das Verhältnis der Ölsumpf- bzw. Verdichtertemperatur und der Sauggastemperatur am Verdichtereintritt. 

Zur Vermeidung kritischer Ölverdünnung muss ein Mindestabstand von ca. 15K eingehalten werden, d.h. die Öltemperatur muss stets min. ca. 15K höher liegen als die Sauggastemperatur.

Beide Temperaturen müssten auf dem CAN vorhanden sein, so dass eine solche Darstellung prinzipiell möglich sein sollte. Evtl. könnte man auch Daten der Ölsumpfheizung noch mit einbeziehen, sofern verfügbar.

Der technische Hintergrund dazu ist in der Anlage von Copeland S. 14 und 

Bedingungen für einen langlebigen Verdichterbetrieb S. 40 nachzulesen.

Was haltet Ihr davon ?

Gruß

Michael

[HerrP]

ohne mich jetzt mit Details beschäftigt zu haben (ich hab keine Wärmepumpe...) würd ich sagen, dass das gut möglich ne sinnvolle Sache sein kann (alles was Lebensdauer verlängert und damit zu weniger Belastung für unsere Umwelt und Resourcen beiträgt halte ich für sinnvoll).

jetzt frage ich mich, was dich davon abhält, deinen Vorschlag umzusetzen, bzw. was 'von unserer Seite' dazu notwendig sein könnte. Ein Beispiel von vielen Möglichkeiten, wie man Werte auf einfache Art in eine Visualisierung reinbringt, findet sich auf Seite 1 oder zwei dieses Beitrags. Fehlen dir die Nummern der entsprechenden Datenpunkte? Oder sind die nicht von der Main Control Unit abrufbar (das zu erweitern ist ja unser nächster 'Meilenstein'...)? Oder bin ich jetzt auf dem falschen Dampfer?

Aber alleine eine Visualisierung nutzt ja nix, wenn man nicht was dagegen tut oder das sogar automatisch getan wird, wenn es in einen 'ungesunden Bereich' abgleitet? Sorry, mir fehlt wie gesagt vollkommen der Hintergrund - hilf mir doch bitte mal auf die Sprünge!

Grüsse!

Phil

[HerrP]

Moin Nick @Schlotzer !

die Codecs werden den Datenpunkten ja in den entsprechenden Open3EdatapointsXyz.py zugeordnet. Dazu werden sie da einfach reingeschrieben. Oft stecken ja mehrere Informationen in einem Datenpunkt, das wird mittels des 'ComplexType' Codecs gelöst, wo man den Datenpunkt mit 'zerlegen' kann. Sollte ein notwendiger Codec nicht existieren, kann dieser geschrieben und der Open3Ecodecs.py zugefügt werden. RawCodec heisst ja nur, dass die Daten/bytes so wiedergegeben werden, wie sie über den Bus geliefert werden - das ist in den allermeisten Fällen nicht sonderlich 'informativ'.

Die etwas größere Herausforderung besteht darin, die 'Bedeutung' der einzelnen Datenbytes zu ergründen. Da hilft oft nur der Vergleich mit irgendwoher bekannten/ersichtlichen Werten, z.B. mit irgendwelchen Displaydaten, mit Informationen aus Vicare (oder auch Viguide wenn möglich), aus der API oder auch aus Dokumentationen wie dem Handbuch oder bsw. der Doku zum Wago Gateway oder vlt auch der API.

Grüsse!

Phil

[Schlotzer]

Hey Phil @HerrP ,

ok verstehe.

Ich schau mal was sich machen lässt.

Brauche vermutlich etwas Zeit mich einzufinden aber das bekomme ich schon hin.

Eine Frage noch zum aktuellen Stand:

Ich bin gerade immernoch beim auslesen der Daten und suche den Code für den Netzbezug und die Einspeisung. Ist der schon vorhanden, oder fehlt der noch?

Ich habe die ganzen Codes durchgeschaut und leider nichts passendes gefunden.

Grüße

Nick.

[petkow]

Den Netzbezug lese ich aus

1603: O3EComplexType(4, "PointOfCommonCouplingPower", [O3EInt32(2, "P1", signed=True, scale=1.0), O3EInt32(2, "P2", signed=True, scale=1.0)]),

wobei P1 die Wirkleistung ist. Der Wert ist identisch mit der in der GridBox App.

Da zurzeit meine Batterie leer ist und auch nichts vom Dach kommt, ist der Wert von P1 gleich dem Verbrauchswert meines Zählers.

P2 scheint die Scheinleistung zu sein, bin mir da aber nicht sicher.

[Schlotzer]

Danke @petkow, das funktioniert bei mir auch.

Ist nur sehr schwer zu interpretieren, ob das wirklich die Werte sind, da bei mir gerade das Meiste aus dem Speicher gezogen wird und daher die Werte sehr klein sind.

Aber ich denke mal, dass das passt.

Für alle die sich fragen, wie das geht:

In der Open3EdatapointsVx3.py die Zeile bei der der Code 1603 steht damit austauschen:

1603: O3EComplexType(4, "PointOfCommonCouplingPower", [O3EInt32(2, "P1", signed=True, scale=1.0), O3EInt32(2, "P2", signed=True, scale=1.0)]),

[mbauer666]

---

@Heizungspilot  schrieb:

Es geht dabei um das Verhältnis der Ölsumpf- bzw. Verdichtertemperatur und der Sauggastemperatur am Verdichtereintritt. 

Zur Vermeidung kritischer Ölverdünnung muss ein Mindestabstand von ca. 15K eingehalten werden, d.h. die Öltemperatur muss stets min. ca. 15K höher liegen als die Sauggastemperatur.

---

@Heizungspilot 

das sind vermutlich diese beiden Datenpunkte, die du meinst, oder?

1772 CompressorOilTemperatureSensor 37.6

321 CompressorInletTemperatureSensor 11.0

[Heizungspilot]

Ich habe viele Jahre Verdichter entwickelt, habe aber bei IT keinerlei Skills.

Die Idee zur Visualisierung ergab sich beim Betrachten eurer Kältekreisübersicht.

Darin könnte man im Verdichterbetrieb z.B. die (gemessene) Öltemperatur (oder den Verdichter) rot markieren, wenn diese nicht mindestens 15K die gemessene Sauggastemperatur überschreitet.

Man könnte beispielsweise ein Laufzeit-Kollektiv des Verdichters erstellen, wie lange dieser in unterschiedlichen Temperaturbereichen bzw. Temperaturdifferenzen lief.

Daraus könnte man z.B. ableiten, wie lange Pausenzeiten max. sein dürfen ohne dass es zu ungesunden Betriebszuständen kommt oder man könnte sehen ob die Ölsumpfheizung funktioniert usw.

Letztlich könnte man damit Verdichterschäden vorbeugen bzw. übermäßigen Verdichterverschleiß vermeiden.

U.v.m.

Gruß

Michael

[HerrP]

danke, Michael, jetzt versteh ich das etwas besser. die ganze Darstellung und Einfärbung und Verarbeitung passiert wohl am besten in der Hausautomatisierung. Dementsprechend kein akuter diesbezüglicher Handlungsbedarf bei open3e (soweit ich das verstehe).

[HerrP]

> 1603: O3EComplexType(4, "PointOfCommonCouplingPower", [O3EInt32(2, "P1", signed=True, scale=1.0), O3EInt32(2, "P2", signed=True, scale=1.0)]),

Achtung, das ist formal nicht korrekt. Ein Int32 Wert hat 4 Bytes. Heissen muss es folglich

1603: O3EComplexType(4, "PointOfCommonCouplingPower", [O3EInt16(2, "P1", signed=True, scale=1.0), O3EInt16(2, "P2", signed=True, scale=1.0)]),

oder es ist 1 Int32 Wert...

aber es scheint ja aktuell trotzdem zu funktionieren (was mich wundert - von wann ist die Open3Ecodecs.py?). Trotzdem wäre es gut, wenn ihr das formal korrekt macht, damit es auch später noch funktioniert.

[Schlotzer]

Hallo @HerrP,

ich habe das ganze Projekt am Montag von Github geladen.

Also ist meine Open3Ecodecs.py auf dem Stand von Montag (23.10.).

[Heizungspilot]

Ja, die Bezeichnungen hören sich plausibel an !

In meiner Kältekreisübersicht von Viessmann sehe ich, dass die Kaltstarts anscheinend ohne die elektrische Ölsumpfheizung aus dem kritischen Temperatur-Bereich herauskommend gefahren werden. Das sollte man mal genauer beleuchten. Unklar ist, ob, wann und wie Viessmann die Ölsumpfheizung dazuschaltet ?

Evtl. findet einer von euch noch ein Ansteuersignal für diese Ölsumpfheizung ?

Gruß

Michael

[mbauer666]

Hi @Heizungspilot,

noch etwas durcheinander, ich habe heute morgen mal anzufangen die Datenpunkte die nach Kompressor/Kältekreis klingen, abzugreifen und zu Plotten. Das zweite Bild zeigt nur die Kurven 

1772 CompressorOilTemperatureSensor 

321 CompressorInletTemperatureSensor

Der dargestellte Zeitraum zeigt einen Kompressor Start, um den Heizungs-Puffer zu laden.