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
Wer es ausprobieren möchte: Hier gibt es eine Anleitung.
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
>> Ich würde aber den Fachbetrieb, der die Anlage/n bei dir installiert hat, höflich darauf hin weisen, dass er bitte die beiden Anlagen per CAN miteinander verlinkt. Das gehört sich eigentlich so.
So geschehen. Hatte heute Installationsnachbesprechung und CAN Bus soll Anfang Jan verbunden werden mit notwendiger Neuinitialsierung.
Danke für den Tipp!
>> Kann jemand dabei helfen wie typischerweise der Befehl für Open3Eclient with -mqtt and -a aussehen sollte.
>> eigentlich wie in der README beschrieben
Sorry, das Projekt ist wirklich genau dass was mir den genaueren Blick in die WP/PV eröffnet.
Ich stelle aber fest, dass mir etliches an Hintergrund fehlt, was die verschiedenen Parameter und Datenpunkte etc zu bedeuten haben, wie diese mit den Open3e Funktionen zusammenhängen.
Gibt es dazu weiterführende Details / Dokumente, ev. Zugriffe auf Viessmann Seiten?
Hallo @HerrP ,
vielen Dank für die ausführlich Antwort. Das finde ich super dass Du Dir soviel Zeit nimmst das zu erklären.
Ich könnte Dir meine Open3Edatatpoints_xxx.py schicken. Zusätzlich hab ich noch die Datapoints ausgelesen für die nicht 'None' markiert ist und das Ergebnis im File 'b.txt' abgespeichert.
Wie kann ich das zip-File schicken? Hier gibt es keine Möglichkeit ein zip-File hochzuladen?
Meine Wärmepumpe ist : IDU Vitocal 250-A AWO-E-AC
Ich hab jetzt versucht Datapoints auszulesen: Manchmal bekomme ich valide Werte, manchmal eine Fehlermeldung (ich vermute timeout). Kann ich was machen um die Fehler zu verhindern (timeout erhöhen?)?
>> etliches an Hintergrund fehlt, was die verschiedenen Parameter und Datenpunkte etc zu bedeuten haben, wie diese mit den Open3e Funktionen zusammenhängen.
die command line Optionen/Parameter von open3e könnten wir noch etwas umfangreicher dokumentieren. Wohlmöglich wäre das noch was für das Wiki von @TSG ?!
Was die Datenpunkte der Geräte anbetrifft würde ich mir auch mehr Hintergrund/Dokumentation wünschen. Das ist natürlich eindeutig ein Viessmann Task. Vielleicht wäre auch eine Link-Sammlung oder evtl. sogar eine Dokumente-Sammlung der Handbücher, die hier das Entsprechende zumindest zum Teil leisten, auch was für das Wiki. Allerdings gehe ich davon aus, dass die Handbücher auch ständigen Updates unterliegen, von daher könnte das schon 'pflegeintensiv' werden...
Open3E macht ja nichts andres als Daten auszulesen und ggf. an den MQTT Broker zu schicken (abgesehen von den noch etwas experimentellen Schreib-Funktionen).
>> Wie kann ich das zip-File schicken?
ich schick dir meine eMail per PM. Persönliche Anlagendaten besser nirgends öffentlich hochladen, weil wenn da Seriennummern drin stehen, könnte das von Viessmann als Schwarz-auf-Weiss Beleg benutzt werden, irgendwelche Gewährleistung zu verweigern.
>> Manchmal bekomme ich valide Werte, manchmal eine Fehlermeldung (ich vermute timeout)
Das hat nix mit echtem timeout zu tun, das ist ein Kernel Bug. Der ist schon beseitigt, allerdings muss sich das erst in die Distributionen 'durchmigrieren'... Es gibt ein Kernel Update, das man ggf. 'zwischendurch' schon mal ausführen kann. Das ist alles hier beschrieben: https://github.com/abnoname/open3e/issues/10#issuecomment-1807693946 Da drüber ist ein kompletter Thread zu dem Timeout Issue...
Hallo.
Ich habe jetzt 2 Canbus Adapter im laufen (einen an VCAL und einen an PT2), meine Datenpunkte werden auch ausgelesen und per MQTT an mein HA geschickt. Mit den PT2 Datenpunkten musste ich in Open3Edatapoints.py noch einige anpassen (aus der develop branch mit komplexen Datenpunkten) und siehe da, die Daten kommen im HA an. Etwas Fleisarbeit, aber funktioniert.
Ich habe noch keine automatischen service definerit um Open3Eclient.py zweimal zu starten da ich ich ständig noch mit den Daten rumspiele.
Die zweite Instanz (bei mit PT2) stoppt aber nach etwa 4-6h mit foglender Fehlermeldung:
2023-12-06 11:34:19 [ERROR] UdsClient: [TimeoutException] : Did not receive response in time. Global request timeout time has expired (timeout=20.000 sec)
Traceback (most recent call last):
File "/home/rechi2/open3e/Open3Eclient.py", line 351, in <module>
listen(args.read, args.timestep)
File "/home/rechi2/open3e/Open3Eclient.py", line 207, in listen
cmnd_loop()
File "/home/rechi2/open3e/Open3Eclient.py", line 155, in cmnd_loop
readbydid(addr, getint(did), json=(cd['mode']=='read-json'), raw=(cd['mode']=='read-raw'))
File "/home/rechi2/open3e/Open3Eclient.py", line 214, 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.9/site-packages/udsoncan/client.py", line 174, in decorated
return func(self, *args, **kwargs)
File "/home/rechi2/.local/lib/python3.9/site-packages/udsoncan/client.py", line 452, in read_data_by_identifier
response = self.send_request(req)
File "/home/rechi2/.local/lib/python3.9/site-packages/udsoncan/client.py", line 2184, in send_request
raise TimeoutException('Did not receive response in time. %s time has expired (timeout=%.3f sec)' %
udsoncan.exceptions.TimeoutException: Did not receive response in time. Global request timeout time has expired (timeout=20.000 sec)
Hat jemand ne idee was das sein könnte bzw wie kann ich den Prozess überwachen und wieder starten falls er stoppt? Die erste Instanz (VCAL) läuft durch.
LG
Hallo @HerrP super, danke.
Ich hätte noch eine Frage zur Interpretation der Daten.
Wenn ich die beiden Datapoints 268 und 269 auslese, bekomme ich ganz unterschiedliche Formate angezeigt.
In Open3Edatapoints.py sind die aber gleich beschrieben.
Dazu ist mir noch aufgefallen, dass
- 269 in File Open3Edatapoints_680.py steht
- 268 im File Open3Edatapoints_6cf.py steht
Wenn ich das richtig verstehe, schicken die beiden Devices die Daten im unterschiedlichen Format?
@GW3 schrieb:Hallo @HerrP super, danke.
Ich hätte noch eine Frage zur Interpretation der Daten.
Wenn ich die beiden Datapoints 268 und 269 auslese, bekomme ich ganz unterschiedliche Formate angezeigt.
In Open3Edatapoints.py sind die aber gleich beschrieben.
Wie sieht den die Ausgabe bei dir aus?
Hier sieht es doch sehr ähnlich aus.
0x680 268 FlowTemperatureSensor {'Actual': 28.8, 'Minimum': 26.1, 'Maximum': 57.1, 'Average': 28.3, 'Unknown': 0}
0x680 269 ReturnTemperatureSensor {'Actual': 26.6, 'Minimum': 23.9, 'Maximum': 54.9, 'Average': 26.3, 'Unknown': 0}
Bei mir steht der 269 DiD aber auch nur in der 680 Datei.
Das Kommando und das Ergebnis sieht bei mir jeweils so aus:
python3 Open3Eclient.py -c can0 -dev vdens -r 268
{'Actual': 33.9, 'Minimum': 28.0, 'Maximum': 49.2, 'Average': 32.5, 'Unknown': 0}
python3 Open3Eclient.py -c can0 -dev vdens -r 269
35010e01d901260100
bei -dev vdens wird die Open3EdatapointsVdens.py benutzt - da steht der 269 garnicht drin. Offensichtlich wird der DP dann 'pure' ausgelesen und liefert magels weiterer Infos den Raw Wert (9 Bytes).
Was mich wundert ist, dass Open3Eclient.py -c can0 -dev vdens -r 268 überhaupt funktioniert. Wenn du nicht irgendwas 'verbogen' hast, wird in dem Fall von 0x680 gelesen. Laut depict Scan gibt es aber auf 680 den Datenpunkt 268 garnicht (ich hab deine Dateien bekommen - danke!). Seltsam!
mach mal
python3 Open3Eclient.py -c can0 -cnfg devices.json -r 0x680.269,0x6cf.268
eigentlich müsste auch
python3 Open3Eclient.py -c can0 -r 0x680.269,0x6cf.268
funktionieren, das sollte aber nicht mit -a kombiniert werden... 😉
seitdem es depictSystem gibt, sollte eigentlich überhaupt nicht mehr mit -dev irgwas gearbeitet werden, sondern nur noch mit -cnfg devices.json (oder kurz -cnfg dev geht auch).
Die datapointsVdens, Vcal, VX3, ... sind nicht mehr auf Stand (oder auf einem ganz bestimmten) und passen in vielen Fällen nicht zur Anlage. @GW3 du hast doch überhaupt keine Vitodens, oder?
Hallo @HerrP , ich hab keine vitodens, sondern eine vitocal
Das korrekte Kommando wäre dann wohl:
python3 Open3Eclient.py -c can0 -cnfg dev -r 268
Stimmt das so? Danke für den Hinweis!
Leider bekomme ich (auch) einen Timeout:
$ python3 Open3Eclient.py -c can0 -cnfg devices.json -m 127.0.0.1:1883:open3e -mfstr "{ecuAddr:03X}_{didNumber}_{didName}" -a
reading 0x680, 210 datapoints, please be patient...
2023-12-06 16:55:52 [ERROR] UdsClient: [TimeoutException] : Did not receive response in time. Global request timeout time has expired (timeout=40.000 sec)
(Timeout von 20 --> 40 in Open3Eclass.py gesetzt)
Auch wenn ich den MQTT Teil weglasse ändert sich nix.
Außerdem meckert die ViCare App: "Kommunikationsstörung Externer CAN-BUS" Störung F.1034
Über cmdline
~/open3e $ sudo ip link set can0 up type can bitrate 250000
RTNETLINK answers: Device or resource busy
scheint der CAN-Bus jedoch aktiv zu sein. 🙄
wie oben (06.12.2023 13:54) schon zu GW3 gesagt, ist das kein Timeout sondern ein Kernel Bug, der mal auftritt und mal nicht. Da kannst du das Timeout auf 3 Stunden stellen, es dauert dann nur länger bis die Exception kommt 😁 Aber sie kommt.
Scroll mal hoch und folge dem Link, damit solltest du der Sache Herr werden.
Eigentlich hatten wir diese Exception aber abgefangen. Der Wert kommt dann zwar nicht, aber das Skript sollte weiter laufen.
es gibt eine Datei "udsoncan.log" oder so - könnt ihr bitte mal schauen, was da bei dem Fehler genau reingeschrieben wird!?
>> es gibt eine Datei "udsoncan.log" oder so - könnt ihr bitte mal schauen, was da bei dem Fehler genau reingeschrieben wird!?
Genau wie oben gepostet:
2023-12-06 16:55:52 [ERROR] UdsClient: [TimeoutException] : Did not receive response in time. Global request timeout time has expired (timeout=40.000 sec)
danke!
ich habe habe im develop grade das Trapping des Fehlers wieder 'aktiviert'. https://github.com/abnoname/open3e/blob/develop/Open3Eclient.py Aber wie gesagt: Es gibt dann keine Meldung, nur kein Ergebnis (glaubich)
wobei ich sehe grad... wir fangen "TimeoutError" ab, kommen tut aber "TimeoutException". wird so also nicht funktionieren...
@Juergen-B ich glaub du warst da näher dran - was wollen wir machen?!
Grundsätzlich wäre das Beste, ihr (die wo das Timeout kommt) macht das Kernel Update - dann braucht's keine 'Krücken' mehr!
ich kann das leider nicht einfach nachstellen - bei mir läuft es fehlerfrei dank altem Buster 😎
Hmmm, tja nach dem Kernel Update, reboot, ...
pi@rpixyz:~/open3e $ sudo ip link set can0 up type can bitrate 250000
pi@rpixyz:~/open3e $ python3 Open3E_depictSystem.py
read DID enums ...
2951 DIDs listed.
scan COB-IDs 0x680 to 0x6ff ...
0 responding COB-IDs found.
write devices.json ...
done.
configuration:
{}
run Open3Eclient with -mqtt and -a to get EVERYTHING on your MQTT app.
... kommt nix mehr 🙄
Und mit candump can0 ist Ruhe im Schacht.
oh 😳
was für ein System hast du am laufen? (bzw. jetzt am bocken...)
Denke, hier kommen echte Timeouts, weil halt schlich keine Daten mehr kommen. Das haben wir nicht abgefangen.
@ghNeandrSieht nach einem Hardware-Problem aus. Denke, Du solltest mal die Verkabelung anschauen, bzw. Deinen Adapter abklemmen und schauen, ob der Fehler in ViCare verschwindet.
das ist ja jetzt ganz frisch nach dem Kernel Update a la Jörg. Ich fürchte, das Update war nicht mit dem System kompatibel....
also ich schätze alles (bzw. das Update) zurück. geht das mit update, upgrade?
ich hab grad im develop auf except (TimeoutError, TimeoutException) geändert. Ist natürlich alles Pfusch...