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]

@Hotzen-Plotz  super Sache deine Doku!! 👍  Wie Jörg schon gesagt fände ich es auch gut, die mit in's Repo aufzunehmen.

[HerrP]

@Barny58  >> Wie ist der aktuelle Stand für den PV-Wechselrichter VX3 mit Speicher standalone.

Wir haben heute die VX3 gescant und dadraus die Datenpunktliste generiert (gut 220 Datenpunkte). Das ist erstmal ein großer Schritt weiter. Die Daten kommen aber noch als Bytes (RawCodec) und es müssen jetzt die passenden Codecs zugeordnet und ggf. ergänzt werden.

Dazu müssen die Datenpunkte ausgelesen und die Daten mit irgendwelchen auf dem Display oder in der Vicare oder sonstwoher zur Verfügung stehenden Daten oder auch mit den Handbüchern verglichen werden. Wenn eine Deckung gefunden wurde -> passenden Codec zuordnen, ggf. schreiben.

Das ist nicht ganz ohne für jemanden, dem Bytes nix sagen. Für etwas Bewandte und Interessierte ist es eine 'schöne Herausforderung im Sinne der Allgemeinheit was Gutes zu tun' (🖖)

Meinst du das wär was für dich?!

Natürlich unterstützen wir dich da auch bei.

Natürlich ist hier jede/r VX3 Betreiber/in herzlich eingeladen!

[Hotzen-Plotz]

Ich melde mich da später mal an und schaue, was geht.

Was mache ich eigentliuch mit einer DID, wie 874 "LegionellaProtectionTargetTemperatureSetpoint", wo ich nur ein Rohdatum als Hexcode-Textfeld bekomme?

Da steht "8a02". Nach meinem Verständnis ist dies 65°C (ich wüsste nicht, wie man es ändern kann, aber so stehts im Servicehandbuch S.130.)

[JörgWende]

@Hotzen-Plotzdas sind 65,0 … da müssten wir oder du das im Open3EDatapoints xxx ändern …von RawCodec auf O3EInt16

[Hotzen-Plotz]

Danke! Ich habe es lokal geändert. Sollte man wohl auch auf Github anpassen dann.

[HerrP]

@Hotzen-Plotz  machen wir, danke für den Hinweis!

Zur Erklärung: das 8a 02 ist 'little-endian', das heisst, es ist bezogen auf unsere Zahlenschreibweise verkehrtherum. die niederwertige Zahl steht links.

der 'Raw Wert' 8a 02 ist also 0x028a = 650 dezimal. Viessmann behandelt Temperaturen ganz oft in 1/10°C -> damit kommt man auf 65,0°C. Weil das ganz oft so ist, ist Default für den scale Parameter von O3EInt16 auch 10. Mann kann ihn aber auch anders angeben und damit eine andere Skalierung bewirken.

Wenn du den Wert ändern möchtest, musst du aber aktuell noch den Raw Wert vorgeben. Um es auf 60,0°C zu ändern, müsstest du also 5802 eingeben.

Das werden wir auf Dauer noch schöner machen. Das Problem ist, dass häufig mehrere Daten in einem Datenpunkt stecken (vergl. das ".1" und ".2" und so in den Handbüchern), also (wahrscheinlich) zuerst die Daten (vollständig) gelesen, dann (nur) die Bytes von Interesse geändert und die gesamten Daten dann wieder zurückgeschrieben werden müssen.

[Hotzen-Plotz]

Ich habe das jetzt wunschgemäß auch im Diskussionsbereich dort unter "Show and tell" abgelegt:

https://github.com/abnoname/open3e/discussions/5#discussion-5674376

[Datenreisender]

Da kommt nur ein 404

[Barny58]

Hallo HerrP,

ich bin leider nicht der Byte Spezialist. Kenne mich nur rudimentär aus.

Ich bestelle mir jedoch die Hardware, welche von Hotzen-Plotz in der hervorragenden Ausarbeitung vorgeschlagen wurde.

Danach stehe ich gerne zum Testen zur Verfügung.

Für diese Tests kannst du mich gerne jederzeit ansprechen.

Ich habe außerdem auch die Viessmann-Gridbox und verwende IOBroker in meinem Smart-Home.

[Hotzen-Plotz]

Wirrer Scheiss auf Github. Bei mir klappts auch nur, wenn ich eingeloggt bin. Aber selbst dann finde ich nix in der Liste der Diskussionen unter Show & Tell.

[M_K]

Hallo @HerrP, das sind tolle Neuigkeiten!

Ich würde gerne bei der Interpretation der Rohdaten unterstützen.
Meine CAN-Logger-Installation werde ich wahrscheinlich innerhalb der nächsten Woche wieder in Betrieb nehmen. Ich hoffe dann diesmal mit Lastsprüngen zu einem Ergebnis zu kommen, mit den reinen CAN-Daten war mir das nicht gelungen. Ich bin gespannt. 😁

MfG

[HerrP]

supi, gern! sag, wenn du so weit bist!

[HerrP]

@ alle

ich wollte grad

  874 : RawCodec(3, "LegionellaProtectionTargetTemperatureSetpoint"),

in O3EInt16 ändern, aber da steht der Datenpunkt hat 3 Bytes. Steht die Temperatur an den ersten zwei Bytes? Sonst muss da noch ein offset angegeben werden...

[JörgWende]

O3EInt16 liest die ersten beiden Bytes - dass sollte also ohne Offset gehen - bei mir steht im dritten Byte ein 3C, keine Ahnung was das noch liefert.

[HerrP]

hier jetzt @Hotzen-Plotzens Doku im Repo. ich hoffe es geht jetzt

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

[kk80]

Hallo,

ich betreibe auch die Kombination VX3 mit E380. Mit einem Raspi4 über usb2can kann ich bis jetzt (mit dem vcal device) immerhin schon die Datenpunkte ViessmannIdentificationNumber und BusIdentification lesen (liegen offensichtlich an der gleichen Adresse wie beim Vitocal). Ich würde mich gern am Dekodierung/Testen der anderen Datenpunkte beteiligen (little/big endian sagt mir was)

[HerrP]

Guten Morgen liebe Community!

Leider sieht es bei uns was 'Zeit' anbetrifft momentan nicht viel besser aus als scheinbar bei Viessamnn. Unser 'Chefentwickler' abnoname ist voll im Stress, deswegen ist das open3e noch nicht upgedatet. Wir bitten euch, hier ein wenig Nachsicht zu üben.

Aber der erfreulicherweise seit kurzem ebenfalls in der Gruppe befindliche superfitte Max hat ein Fork von dem Repo gemacht, in dessen Dev Tree die VX3 entsprechend dem aktuellen Stand eingebunden ist:

https://github.com/maxxberg/open3e/tree/dev Damit könnt ihr erstmal loslegen.

[EDIT: Link korrigiert - sorry für die Verwirrung]

[nochmal EDIT: sorry, auch da ist die lange Liste noch nicht drin, dazu siehe unten ein paar Beiträge weiter]

Mir ist noch nicht ganz klar, wie wir das hinterher alles inklusive eurer Beiträge wieder zusammenführen, aber die Experten haben versichert, dass das kein Problem ist.

Also Feuer frei! und notiert euch irgendwie, was ihr beitragen wollt und könnt, irgendwer, der/die nicht so unbewandert in diesen Dingen ist wie ich, wird dann früher oder später hier kundtun, wie wir das zusammenführen.

Soweit - Daumen hoch auch für euer Engagement schon mal - zusammen sind wir am stärksten! 💪 🖖

Grüsse!

Phil

ps. da der Energiezähler mit einem anderen Mechanismus kommuniziert (zyklisches Senden von PDOs statt der Möglichkeit, Werte per UDS auszulesen) ist dieser noch nicht per MQTT zu sehen, das kommt aber bald auch noch, vielleicht macht es ja auch jemand von euch. 😉

[HerrP]

hier schon mal die Inhalte der Energiezähler PDOs gemäss unserem Stand

[HerrP]

so, Update: hier ist die Open3EdatapointsVx3.py , die ihr bitte in euer Projekt aus dem Link von oben reinpackt. Ich hoffe, dann seid ihr einigermassen up to date. bitte Rückmeldung, ob es jetzt endlich passt!

[HerrP]

wie gesagt, bei den meisten 'Datenpunkten' steht RawCodec vor, das gilt es zu ändern. Bei denen mit Länge 1 ist wohl in den meisten Fällen O3EInt8 schon mal ein Fortschritt, bei denen mit Länge 2 O3EInt16. Aber es können gern auch 'Klartext Codecs' geschrieben werden 😉

Irgendwie werden wir auch noch publizieren, was wir zudem noch von bestimmten Datenpunkten wissen, was aber aktuell noch nicht in Codecs umgesetzt ist... aber wie ich oben schn schrieb, es geht leider nicht alles gleichzeitig 😉

[HerrP]

und nochmal zur Beachtung!! Ihr begebt euch damit auf dünnes Eis! Spätestens wenn ihr die Werte von Datenpunkten auf diesem von Viessmann nicht vorgesehenen Weg verändert, riskiert ihr möglicherweise die Gewährleistung/Garantie! Also überlegt euch, was ihr tut! und unterbrecht ggf. die Verbindung zum Viessmann Server während dessen...

ES IST NICHT AUSGESCHLOSSEN, DASS IHR MIT ÄNDERUNGEN VON WERTEN IM GERÄT GEFAHREN FÜR LEIBLICHE UNVERSEHRTHEIT ODER SACHWERTE VERURSACHT!

[Hotzen-Plotz]

Vermutlich macht es Sinn, diese Warnung direkt in den Startpost zu schreiben.

Es ist ja wirklich etwas anderes, Daten zu ändern, als sie nur zu lesen.

[Datenreisender]

@Customer_Care: Was sagt Viessmann dazu? Wenn so eine Open Source Lösung anfängt technisch besser zu sein als eine offizielle Lösung, dann sollte Viessmann so etwas unterstützen. Eine ernsthafte Unterstützung von Open Source Projekten verbessert immer die Reputation von Unternehmen.

Statt der Wago Lösung, bei der eine Analyse der Software Komponenten einige Fragen zur IT-Sicherheit aufwirft, wäre mit der in diesem Thread vorgestellten MQTT Lösung und dem Kontron PiXtend V2 L Pro als Hardware eine technisch weitaus leistungsfähigere Lösung möglich, die auch mit SMA oder Fronius PV Lösungen gut zusammenarbeitet.

Eine Dokumentation der NoGo Areas unter den Datenpunkten wäre auch hilfreich.

[HerrP]

um mal was Positives zu sagen: Viessmann hat eine gewisse Unterstützung des Projekts (bisher) zumindest nicht ausgeschlossen. Leider ist auch da das 'Problem Zeit' aktuell der begrenzende Faktor.

Mit der Wago Lösung ist übrigens ein Zugriff wieder nur auf 'ausgesuchte' Datenpunkte möglich, zu denen beispielsweise die "Energiesparfunktionen (Einstellung nur über Software-Tool)", die bei älteren Geräten noch frei zugänglich waren, mit hoher Wahrscheinlichkeit nicht gehören (ich habe noch nicht nachgeschaut).

>> Eine Dokumentation der NoGo Areas unter den Datenpunkten wäre auch hilfreich.

Das war unser ursprünglicher Ansatz, als wir nur die im Handbuch stehenden 'Datenpunkte' integriert hatten. Leider gibt es Geräte, bei denen in der Dokumentation kein einziger Datenpunkt dokumentiert ist... Ehrlich gesagt hätte ich jetzt auch keinen wirklich gefährlichen Datenpunkt aufm Schirm, aber lieber einmal zu viel gewarnt als zu wenig 😉

@Hotzen-Plotz

>> Vermutlich macht es Sinn, diese Warnung direkt in den Startpost zu schreiben.

ist erledigt. danke!

>> Es ist ja wirklich etwas anderes, Daten zu ändern, als sie nur zu lesen.

Das sehe ich genauso. Allerdings könnte man die theoretische Möglichkeit konstruieren, dass eventuell auch der Lese-Request, besonders sequentiell, zu unvorhergesehenen Ereignissen führen könnte, beispielsweise eine Überlastung von Resourcen. Wir haben hier zwar Pausen eingebaut, um das möglichst auszuschliessen, und wir haben sowas noch nie beobachtet, aber garantieren können wir eben für nix. Auch hier wäre eine Unterstützung/Information von Seiten Viessmanns sinnvoll.

Grüsse!

[HerrP]

kleines Update: wir haben ein wenig 'aufgeräumt' und das originale Repo von abnoname https://github.com/abnoname/open3e ist jetzt wieder die primäre Quelle auch für Forks für eure Beiträge (hierfür bitte den develop branch benutzen).

Grüsse!