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

[garagenlager]

Moin zusammen, hab am WE mal weitergebaut an meiner Home Assistant Einbindung läuft soweit ganz gut. Der automatische Start über systemctl war problematisch, müsste da noch die Zeile

ExecStartPre=/bin/sleep 30

in die Service Konfigzeile reinpacken, damit das System auf die Netzwerkverbindung 30 Sekunden wartet und dann erst den Service startet. Mir ist noch nicht ganz klar, in welcher Datei ich die relevanten Parameter der Vitodens 300-W finde. Hab mir mal die open3edatapoints ausgedruckt. Irgendwie fehlen mir da aber relevante Werte, wie z. B. VL Temperatur, ....

[HerrP]

>> Werte, wie z. B. VL Temperatur, ....

268 : O3EComplexType(9, "FlowTemperatureSensor", [

  O3EInt16(2, "Actual", signed=True),

  O3EInt16(2, "Minimum", signed=True),

  O3EInt16(2, "Maximum", signed=True),

  O3EInt16(2, "Average", signed=True),

  O3EByteVal(1, "Unknown")]),

Die Open3Edatapoints ist ja die Ansammlung aller Datenpunkte, die uns bisher 'über den Weg gelaufen' sind. Relevant für die 300-W wäre eher die Liste, die du per

  printdatapoints.py -dev vdens

bekommst.

Die aber wirklich auf deine Anlage zutreffenden Datenpunkte erhälst du mit depictSystem und dann

  printdatapoints.py -dev _680

und das Gleiche mit allen _6yz, die bei dem depict erzeugt wurden.

Welche davon dann wirklich relevant sind - da steht hier die Bitte um eine umfassende Dokumentation an Viessmann im Raum... Wobei die vielleicht auch nicht ganz zu Unrecht sagen werden "Viele Datenpunkte sollen euch eigentlich garnicht interessieren" - aber um das abgrenzen zu können, braucht es zumindest eine Dokumentation der Datenpunkte, die die Betreiber* interessieren.

Grüsse!

Phil

[HerrP]

open3e ist umgezogen!

open3e steht jetzt unter dem Dach der Organisation open3e. Das hat den Hintergrund, dass es ja schon länger nicht mehr nur einen Autor hat, sondern viele, unter anderem ja auch welche von euch. Ich habe davon keine Ahnung, aber der gute abnoname sagt, es wäre so eine gute und faire Sache. Hintergründe können nachgelesen werden u.a. unter About Organizations. Keine Angst: Es bleibt natürlich alles Open Source und nicht-kommerziell, und so wird es auch immer bleiben.

Der neue Link zum Projekt ist https://github.com/open3e/open3e

Alle, die mitmachen per push/pull mögen bitte ihren Arbeits-Clone neu clonen von dem neuen Repo, damit ein push dann auch auf das richtige Ziel läuft. Falls ihr zwischendurch was gemacht habt, was noch nicht synchronisiert ist, vorher ein Backup machen, damit ihr eure Änderungen / geänderte Files dann wieder in den neuen Clone schieben könnt.

In diesem Zug möchten wir dann auch das Wiki rüberholen. @TSG  können wir uns dazu bitte kurzschliessen!? Ich muss mal nachlesen und ggf. nachfragen, wie wir das am besten gemanaged bekommen. Eventuell wäre es einfacher gewesen, es vor dem Umzug rüberzuholen, aber nun ist es so, wie es ist...

und jetzt erst mal wieder

viel Spass an dem Projekt und beim Mitmachen!

beste Grüsse!

Phil

[Thomas_MG]

Hallo.

Ich war die Woche unterwegs und konnte nichts testen. Ich habe nur die VCal laufen lassen (ohne Probleme. Hatte gestern Abend wieder versucht die PA2 wieder zu starten mit einem neuen Ergebnis. Ist zwar auch wieder in den Timeout gelaufen aber diesmal kam eine zusätzliche Meldung, die mir sagte dass meine Datenpunkt Umwandlung mist ist.

2023-12-15 18:32:02 [ERROR] UdsClient: [UnexpectedResponseException] : ReadDataByIdentifier service execution returned a valid response but unexpected. Details : Server returned values for 1 data identifier that were not requested. Dids are : {1367}
Traceback (most recent call last):
File "Open3Eclient.py", line 363, in <module>
readbydid(addr=ecudid[0], did=ecudid[1], raw=args.raw, msglvl=mlvl)
File "Open3Eclient.py", line 216, in readbydid
value,idstr = dicEcus[addr].readByDid(did, raw)
File "/home/rechi2/open3e/Open3Eclass.py", line 114, in readByDid
response = self.uds_client.read_data_by_identifier([did])
File "/home/rechi2/.local/lib/python3.7/site-packages/udsoncan/client.py", line 174, in decorated
return func(self, *args, **kwargs)
File "/home/rechi2/.local/lib/python3.7/site-packages/udsoncan/client.py", line 476, in read_data_by_identifier
response, "Server returned values for %d data identifier that were not requested. Dids are : %s" % (len(extra_did), extra_did))
udsoncan.exceptions.UnexpectedResponseException: ReadDataByIdentifier service execution returned a valid response but unexpected. Details : Server returned values for 1 data identifier that were not requested. Dids are : {1367}

In Open3Edatapoints.py war zu dem Zeitpunkt der Codec auf

1367 : O3EInt16(2, "FuelCellThermalPower"),

Ich habs dann versucht mit 

1367 : O3EInt16(2, "FuelCellThermalPower", signed=True),

geht aber trotzdem in den timeout. Ich glaube ich habe Fehler in den Datapoints codecs. 

Ich brauche die DIDs 567,1191,1214,1313,1348,1349,1367,1435,1436,1573,1596,1795,1798

Kann mir jemand helfen mit den Codecs? Ich verstehe die leider nicht und weiss auch nicht wo ich das rausfinden kann.

Danke vorab!

LG

Thomas

[HerrP]

Moin Thomas!

les das 1667 Objekt mal 'raw' aus:

cansand can1 680#0322055700000000

(can1 richtig? Antwort kommt auf 690, bitte posten)

Aus den Daten, die du mir geschickt hattest, geht hervor, dass 2 Bytes korrekt sind. Der O3EInt16 kann den Wert auf jeden Fall interpretieren, ob der Wert dann Sinn macht, steht auf nem andren Blatt, würde aber nicht zu einem Fehler führen.

Wenn trotzdem die Meldung oben kommt, scheint was in der Datenübertragung durcheinander gekommen zu sein. Der Datenpunkt davor (1663) ist geringfügig länger, braucht aber segemented Transfer. Wenn der zu lang für die Übertragung gebraucht hat, kommt udsoncan durcheinander und es kommt zu der Meldung.

Grüsse!

[Thomas_MG]

mit 

cansend can1 680#0322055700000000 

passiert gar nichts. Befehl läßt sich absetzen aber es kommt nichts in der Konsole an/zurück. Mach ich was falsch?

Der Datenpunkt ist aber nicht 1667 sondern 1367 der den Fehler verursacht hat.

[ghNeandr]

Nach meinen Schwierigkeiten den CAN2USB Adapter an meiner VX3/E380CD Anlage zum Laufen zu bekommen, nun der Versuch mit einem neuen Adapter: leider gleiche Fehler: python3 Open3E_depictSystem.py läuft genau bis zum selben Punkt wie vorher mit dem ersten Adapter:

read DID enums ...
2951 DIDs listed.
scan COB-IDs 0x680 to 0x6ff ...
1688 || 1664 || 1791

Fehlerausgabe bis hin zu:
Traceback (most recent call last):
File "/home/pi/open3e/Open3E_depictSystem.py", line 283, in <module>
lstEcus = scan_cobs(startcob, lastcob)
File "/home/pi/open3e/Open3E_depictSystem.py", line 95, in scan_cobs
raise Exception(e)
Exception: [Errno 105] No buffer space available

Note: Open3E_depictSystem.py geändert für laufende Ausgabe:

for tx in range(startcob, lastcob + 1):
print(tx, " || ", startcob, " || ", lastcob, end="\r")

Fragen:
-- Was kann das ursächliche Problem sein?
-- Wie kann ich feststellen, ob der Anschluss des CAN2USB am E380CB richtig ist, so unterstützt ist?
-- Welche Testmöglichkeiten stehen zur Verfügung, um das CAN-BUS Verhalten an der Viessmann Anlage zu verifizieren?

[Dreman]

@Thomas_MG  Du hast aber schon 2 Terminalfenster aktiv: einmal zum Senden mit cansend can1 und ein 2. zum Empfangen mit candump can1,600:700?

[Thomas_MG]

Lieben Dank für den Tip. Sorry für die Ahnungslosigkeit. Jetzt hat es natürlich geklappt. Hier der Dump nach dem Absenden des Befehls

cansend can1 680#0322055700000000

rechi2@raspi-heizung:~/open3e $ candump can1,600:700

  can1  680   [8]  03 22 05 57 00 00 00 00

  can1  690   [8]  05 62 05 57 A7 04 55 55

  can1  680   [8]  03 22 04 BE 00 00 00 00

  can1  690   [8]  05 62 04 BE 0D 03 55 55

  can1  680   [8]  03 22 05 57 00 00 00 00

  can1  690   [8]  05 62 05 57 B2 04 55 55

  can1  680   [8]  03 22 05 9C 00 00 00 00

  can1  690   [8]  10 0C 62 05 9C C9 01 CF

  can1  680   [8]  30 00 00 00 00 00 00 00

  can1  690   [8]  21 00 48 02 B7 01 00 55

^Crechi2@raspi-heizung:~/open3e $ 

[ghNeandr]

Zusatz zu meinem Post von 13:55   >> "Nach meinen Schwierigkeiten den CAN2USB Adapter ..."

Jetzt meldet die VX3 über die ViCare in kurzer Folge "Externer CAN Bus Fehler .. " und dann "Fehler behoben (ohne einen Eingriff an der Anlage oder der ViCare).

Ein erneutes Starten von Open3E_depictSystem führt direkt zum Abbruch ... so war es auch dem den ersten Adapter. Und da geht dann nur noch Neu-Start des RPI .... alles sehr mysteriös

Gerne höre ich aus Eurer Erfahrung und hoffe auf Hilfe
Danke.

[HerrP]

@Thomas_MG  sorry, ich war schon immer leicht legasthenisch veranlagt. Aber zumindest scheint die Kommunikation mit der PT2 ja zu funktionieren...

1367 (0x0557) liefert 1191 (dez) 0x4A7

1214 : 781

1367 : 1202

1436 : liefert 9 Bytes, wahrscheinlich a la

  O3EInt16(2, "Actual", signed=True),

  O3EInt16(2, "Minimum", signed=True),

  O3EInt16(2, "Maximum", signed=True),

  O3EInt16(2, "Average", signed=True),

  RawCodec(1, "Unknown") <-  wahrscheinlich Sensor Status

Wie liest du die Werte 'normalerweise' aus? Per MQTT Anforderung oder per -r ...? Im zweiten Fall lad bitte den aktuellen develop branch runter, da hab ich grad ne Pause zwischen den reads eingebaut, die war uns irgendwie flöten gegangen 😥

[HerrP]

@ghNeandr  wir sollten jetzt wirklich mal systematisch vorgehen. Da depict reproduzierbar immer 24 ECUs offenbar 'unfallfrei' scannt und beim 25. Aufmachen des Clients den Buffer-Fehler wirft, ist davon auszugehen, dass es da Resourcen von 24 Buffers gibt, die aus irgendeinem Grund auf deinem System (Raspi 2 (b?) mit Bulleseye) nicht nach dem Schliessen des Clients wieder frei gegeben werden, auch nicht, wenn man danach 1 Sekunde wartet (hattest du doch probiert, richtig?). Das ist nicht schön, aber auch nicht existenziell. Also lassen wir das erstmal.

Die Meldungen der VX3 deuten auf Probleme mit der CAN Bus Verkabelung hin, möglich wäre auch ein Baudrate Konflikt. Der Fehler F.1034, den wir auch schon gesehen haben, sowie die Stände der Fehlerzähler des CAN2USB unterstreichen diese Annahme, aber danach haben wir ja die Geschichte mit CAN_GND und den Buswiderständen korrigiert.

Also:

Als erstes bitte jetzt die Fehlerzähler des Adapters auslesen per

ip -details -statistics link show can0

und das Ergebnis hier posten. Da sollte auch die Baurate vom Adapter drin stehen (250000 wäre korrekt)

Als zweites bitte noch mal genau die Busverkabelung prüfen: 

- Sind CAN_Hi überall an den Klemmen für CAN_Hi und CAN_Lo überall an den Klemmen CAN_Lo angeschlossen?

- Ist CAN_GND von der VX3 mit CAN_GND (Pin 3) des Adapters verbunden?

- Sind genau 2 Widerstände am Bus zwischen CAN_Hi und CAN_Lo angeschlossen (Widerstand/Brücke/Jumper)?

Wenn das alles passt, erstmal nur auf dem CAN Bus lauschen. Mindestens der E380 brabbelt ja ständig vor sich hin. Dazu

candump can0 -tA

in ein Terminalfenster eintippern. Wenn da kommt 'candump not found' oder so, die can-utils installieren:

sudo apt-get install can-utils

und nochmal candump. Bitte den Output dann hier posten, dann machen wir ggf. weiter, indem wir ein paar Werte per cansend auslesen. Das funktioniert dann so:

candump can0,600:700

in einem Terminalfenster eingeben.

In einem zweiten Terminalfenster

cansend can0 680#032201F900000000

schicken und im candump Fenster schauen

dann ein

cansend can0 680#032201FA00000000

schicken und im candump Fenster schauen

Die Antworten sind Datum und Uhrzeit als hex Werte (jeweils die letzten 3 Bytes vor dem 55h).

Wenn das geht, lesen wir die gleichen Werte per open3e. dazu in das Verzeichnis wechseln, in dem open3e sich befindet. Dann

python3 Open3Eclient.py -c can0 -r 505,506 -v

eingeben und die Antworten sowie den Output vom candump hier posten.

Dann schauen wir weiter.

Grüsse!

[Thomas_MG]

@HerrP Danke!

Ich habe es heute morgen mit nur 4 DIDs gestartet (1214, 1348, 1367, 1436). Komischerweise funktioniert das bis jetzt. 

Ich lese die Daten per -r request aus. Ich lade Sie runter und versuchs. Melde mich dazu.

LG

Thomas

[HerrP]

wie gesagt, ohne die (bislang vergessene) Pause im read loop kann usdoncan schon durcheinander kommen. Das kann auch 'stochastisch' passieren, je nach dem, was sonst grad so auf dem Bus los ist. Die 20ms Pause sind auch nicht unbedingt viel, aber bei MQTT machen wir nur 10ms...

[Awot252]

Gibt es einen Parameter bei der Warmwasserbereitung, die den Verdichter für X Minuten ausschaltet?

[Awot252]

@mbauer666 

Den Raspi hab ich installiert, den CANBUS Adapter hab ich mit dem Stecker von Viessmann verkabelt. Nur wo ich den bei der 252 anschließen soll, ist mir ein Rätsel.

[mbauer666]

---

@Awot252  schrieb:

@mbauer666 

Den Raspi hab ich installiert, den CANBUS Adapter hab ich mit dem Stecker von Viessmann verkabelt. Nur wo ich den bei der 252 anschließen soll, ist mir ein Rätsel.

---

Sieht es bei dir nicht so aus wie in der Anleitung die ich dir hier  schonmal geschickt habe?

[Awot252]

Ich dachte ich muss den gelben Stecker 91 in die entsprechende Buchse irgendwo einstecken.

[mbauer666]

---

@Awot252  schrieb:

Ich dachte ich muss den gelben Stecker 91 in die entsprechende Buchse irgendwo einstecken.

---

Ich habe ja eine 250-A, da musste man die losen Kabel des Bus mit einer Schraubverbindung verbinden.  

[Awot252]

Hab die Anleitung von @Hotzen-Plotz  genommen und dabei überlesen, dass er eine Gastherme hat. Tja. 

[GW3]

Hallo @HerrP,

ich hatte bis heute meine Kommunikation mit der A250 problemlos am laufen. Ich hab meine Raspi gestoppt, einen zusätzlichen Wert in die datalist eingefügt und das Auslesen zu mqtt neu gestart.

Leider werden jetzt einige Werte (z.B. 269) nicht mehr korrekt im MQTT Explorer angezeigt.

Ich hab auch versucht, das neueste Open3Eclient.py zu holen.

Was mache ich da falsch?

Vielen Dank schon mal für deine Geduld und evtl. Hilfe.

[ghNeandr]

@GW3  >>einen zusätzlichen Wert in die datalist eingefügt 
DoubleCheck datalist ... ist es evtl. ein profaner Formatierungsfehler?

[GW3]

@ghNeandr 

,danke für die Antwort zu so früher Stunde,

Ich finde den Fehler zumindest nicht in der Liste.

Unten meine arg-Files.

Ich rufe das ganze mit

python3 Open3Eclient.py @genargs @datalist

auf

genargs:

=======

--can
can0
-cnfg
devices.json
-m
192.168.178.85:1883:open3e
-muser
mqqt-user:mos$468
-mfstr
{didNumber}_{didName}

datalist:

======

-r
268,269,271,274,284,286,318,320,321,322,324,325,355,381,389,391,396,1043,1769,1771,1772,1775,1776,2333,2334,2346,2351,2487,2488,2496,2735,3016
-t
30

[GW3]

Es sieht doch so aus, als ob der Wert 268 von der A250 ausgelesen, der Wert aber dann nicht interpretiert werden kann?

[HerrP]

ups, gewöhnlich stellt man sein mqtt Password nicht in's Netz 😉 ist aber wahrscheinlich auch kein Drama...

in der Open3Edatapoints ist "268 : O3EComplexType(9, "FlowTemperatureSensor", ..." vermerkt. Datenlänge passt also. Kannst du bitte mal checken, ob in deiner Open3Edatapoints_680 was andres steht als 268 : None, und in der Open3Edatapoints der 268 noch korrekt eingetragen ist (Zeile vorher mit Komma abgeschlossen und so)!?

Das "unknown:len=..." kommt aus dem readPure, das angewand wird, wenn der DID nicht in den zugeordneten dataIdentifiers gefunden wird (die mittels des 'Overlay Mechanismus' gebildeten).

Hier müssen die datapoints gecheckt werden (alle betroffenen).

Das "= None" hingegen kommt (soweit ich erinnere nur) bei einem Timeout. Du hast ja links neben dem 'Topic' noch den Pfeil, d.h. du kannst aufklappen und siehst die einzelnen Werte /'Sub-Topics'. Also geht das Auslesen mal gut, mal geht es nicht gut.

Kann es sein, dass beim Neustart des Raspi ein update/upgrade 'zugeschlagen' hat, und dein System jetzt auch den Kernel mit dem ISO-TP Bug hat, und es den vorher noch nicht hatte?

Hast du nach dem Neustart vielleicht auch ein neues depictSystem gemacht (was evtl. wegen Timeouts die datapoints_6** durcheinander gebracht hat)?

Hat sich irgendwas an deiner 'Bus-Physik' geändert, das bewirken könnte, dass es jetzt zu Kommunikationsproblemen mit Folge Timeout kommt?

Bitte schau mal, was in der udsoncan.log steht (und poste das)

Ich habe die Befürchtung, dass wir mit dem 'Tolerieren' des Timeouts tatsächlich jetzt Probleme verschleiern, die uns an anderer Stelle wieder einholen.....