abbrechen
Suchergebnisse werden angezeigt für 
Anzeigen  nur  | Stattdessen suchen nach 
Meintest du: 

CAN Bus, Home Automation E3 Generation lokal und kostenlos

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!

HerrP_2-1692095743490.png

 

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:

 

HerrP_3-1692095743607.jpeg

 

HerrP_3-1697543763132.png

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

1.025 ANTWORTEN 1.025

>> 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?)?

@ghNeandr 

>> 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).

 

@GW3 

>> 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_0-1701867843455.png

 

@abnoname   @HerrP 

Im open3s/Readme im Abschnitt "Depict System" heißt es:
>> Use Open3Eclient with cmd line argument -cnfg devices.json afterwards.

Meine RPI Installation verlangte:

python3 Open3Eclient.py --can can0 -cnfg devices.json

Ggf. ändern im README.md


@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...

Top-Lösungsautoren