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

[JörgWende]

Hallo @GW3 das sehe ich zum ersten mal - klingt als ob nicht das komplette Projekt heruntergeladen ist.

O3EComplex und die anderen Typen sind in der Datei OpenE3Codecs.py definiert. 

Kannst Du das Projekt evtl nochmals mit git pull (oder dem Download als zip) laden und die Konfiguration lt readme durchführen ?

Ansonsten: issue im github aufmachen. 

[Stefan_Ge]

Herzlichen Dank an alle hier - endlich kann ich meine Vitodens 300W aus dem Jahre 2019 bald lokal steuern und bin nicht mehr auf die grottige Viessmann Cloud API, pyvicare etc. angewiesen - grandios.

Benötige aber noch eure Hilfe! Bis jetzt konnte ich erfolgreich benötigte Werte über die Linux Shell auslesen und auch schreiben, sowie über MQTT auszulesen (mein Ziel ist zwei Heizkreise aus/anschalten, Solltemperaturen ändern, Wasserboiler-Temp ändern und Boiler an/ausschalten, sowie noch einige Daten zusätzlich zu lesen und in Home Assistant abzubilden).

Was ich nicht schaffe ist Werte über MQTT zu schreiben, bricht immer mit Fehler ab.

Ich starte Open3Eclient mit diesen Parametern:

root@open3e:/opt/open3e# python3 Open3Eclient.py -c can0 -dev vdens -r 271,274,334,396,424,426,531,1415,1416 -m 192.168.178.xx:1883:open3e -t 10 -muser user:password -l open3e/cmnd
Enter listener mode, waiting for commands on mqtt...

Werte werden nun wunderbar alle 10 Sekunden über MQTT gepublished.

Sobald ich nun aber aus Home Assistant ein MQTT Packet absetze z. B. zum setzen der Wasserboiler-Temperatur auf 58 Grad unter Topic open3e/cmnd mit z.B. Payload

{"mode": "write-raw", "data":[[396,"4402"]}

, schmiert mir Open3E ab mit folgendem Fehler:

Traceback (most recent call last):
File "/opt/open3e/Open3Eclient.py", line 351, in <module>
listen(args.read, args.timestep)
File "/opt/open3e/Open3Eclient.py", line 207, in listen
cmnd_loop()
File "/opt/open3e/Open3Eclient.py", line 188, in cmnd_loop
didKey = getint(wd[0]) # key is submitted as numeric value
TypeError: 'int' object is not subscriptable
root@open3e:/opt/open3e#

Habe versucht die Payload unterschiedlichst zu formatieren mit write, write-raw mit raw-Werten. Schmiert immer mit dem Fehler ab.

Wieso klappt das denn nicht? Würde gerne Werte via MQTT schreiben und mir ersparen via ssh die shell commands alle abzusetzen von Home Assistant aus, zumal ich das noch nicht hinbekomme.

Danke danke vorab für eure Tipps!

Grüsse, Stefan

[Thomas_MG]

Hallo. 

Ich finde das Projekt echt klasse. Ich habe eine Vitocal250AH, eine Vitodens200 und einen PT2. Ich benutze homeassistant auf einem NUC (worauf auch der MQTT broker läuft). Ich habe mir den CANadapter hier beschrieben besorgt und ihn and die Vitocal angeschlossen und zusätzlich einen alten Raspi3 vorbereitet nach der Anleitung von @Hotzen-Plotz. Funktioniert soweit dass er die vcal erkennt. Allerdings kommt eine Fehlermeldung dass er die devices.json nicht schreiben kann.

------- Fehlermeldung ------

python3 Open3E_depictSystem.py

read DID enums ...

2951 DIDs listed.

scan COB-IDs 0x680 to 0x6ff ...

ECU found: 0x680 : HPMUMASTER

ECU found: 0x684 : HMI

ECU found: 0x68c : VCMU

ECU found: 0x6c3 : BACKENDGATEWAY

ECU found: 0x6c5 : BACKENDGATEWAY

ECU found: 0x6cf : EHCU

6 responding COB-IDs found.

write devices.json ...

Traceback (most recent call last):

  File "/opt/open3e/Open3E_depictSystem.py", line 263, in <module>

    write_devices_json(lstEcus)

  File "/opt/open3e/Open3E_depictSystem.py", line 201, in write_devices_json

    with open('devices.json', 'w') as json_file:

PermissionError: [Errno 13] Permission denied: 'devices.json'

-------------

Mit darauf folgendem Befehl 

python3 Open3Eclient.py -c can0 -dev vcal -a -v

bringt er zuerst eine Warnung:

WARNING:root:Cannot load logging configuration from /home/rechi2/.local/lib/python3.9/site-packages/udsoncan/logging.conf. PermissionError:[Errno 13] Permission denied: '/opt/open3e/udsoncan.log'

Er liest danach aber die gefühlt 1000 Datenpunkte aus.

Danach versuchte ich mit:

python3 Open3Eclient.py -c can0 -dev vcal -m 192.168.178.16:1883:open3e/vitocal -mfstr {didNumber:04d}_{didName} -muser MQTTuser -mpass MQTTpwd -t 30 -r 268,269,271

das senden der DIDs zum MQTT ins Homeassistant zu schicken. Darauf folgt aber folgende Fehlermeldung:

usage: Open3Eclient.py [-h] [-c CAN] [-d DOIP] [-dev DEV] [-tx ECUADDR] [-cnfg CONFIG] [-a] [-r READ] [-w WRITE] [-raw] [-t TIMESTEP] [-l LISTEN] [-m MQTT]

                       [-mfstr MQTTFORMATSTRING] [-muser MQTTUSER] [-j] [-v]

Open3Eclient.py: error: unrecognized arguments: MQTTpwd

(Benutzername und pwd hab ich geändertem Post).

Wenn ich das Passwort einfach weg lasse dann meldet er dass er ein Passwort braucht.

Ich komme nicht weiter. Was hab ich übersehen? Irgendwo scheint ein Rechteproblem zu bestehen. Bin relativ neu in diesen Themen und wurschtele mich durch. Bin aber dank eurer Hilfe schon ziemlich weit gekommen.

Lieben Dank vorab für eure Tipps!

Thomas 

[Thomas_MG]

Hab meine MQTT Verbindungsproblem gefunden. Das Argument -muser muss mit username:passwort übergeben werden. Arrrggh.

Aber er meldet immer noch die Berechtigungsfehler. Habt ihr hier noch ne Idee?

Muss jetzt mal schauen ob die Daten auch in HA ankommen.

[mbauer666]

Hier versucht der nach /opt/open3e/ zu loggen, da darf er eventuell nicht schreiben.

pip3 install -r requirements.txt 

und der Rest der Python installation ist ohne Fehler durchgelaufen? 

Ich würde mal als User pi im Homeverzeichnis den git clone noch mal ausführen. 

Du brauchst zum Aufrufen des Open3Eclient keine root -Rechte und soweit ich das sehe, wird von open3e nichts ausserhalb vom Arbeitsverzeichnis geschrieben.

[Stefan_Ge]

Hallo und herzlichen Dank an alle hier,

endlich kann ich meine Vitodens 300W aus dem Jahre 2019 bald lokal steuern und bin nicht mehr auf die Vicare Cloud API und pyvicare etc. angewiesen - grandios.

Bis jetzt konnte ich erfolgreich benötigte Werte über die Linux Shell auslesen und auch schreiben, sowie über MQTT auslesen.

Mein Ziel ist es zwei Heizkreise aus/anzuschalten, deren Solltemperaturen zu ändern, Wasserboiler-Temperatur zu ändern und den Boiler an/auszuschalten, sowie noch einige weitere Daten zu lesen und in Home Assistant abzubilden.

Benötige aber noch eure Hilfe! Denn was ich nicht schaffe ist Werte über MQTT zu schreiben. Es bricht immer mit Fehler ab.

Ich starte Open3Eclient mit diesen Parametern:

Die Werte werden nun wunderbar alle 10 Sekunden über MQTT gepublished.

Sobald ich nun aber aus Home Assistant ein MQTT Paket absetze, z. B. zum Setzen der Wasserboiler-Temperatur auf 58 Grad, schmiert mir das Programm ab.

Dazu publishe ich ein Paket im Home Assistant MQTT Broker mit Topic „open3e/cmnd“ und Payload:

Dann kommt folgender Fehler im Open3E:

Habe versucht die Payload unterschiedlichst zu formatieren mit write, write-raw mit raw-Werten, etc. Schmiert immer mit dem Fehler ab.

Wieso klappt das denn nicht? Würde gerne Werte via MQTT schreiben und mir ersparen via ssh die shell commands alle abzusetzen von Home Assistant aus, zumal ich das noch nicht hinbekomme.

Danke vorab für eure Tipps!

Grüsse,

Stefan

[Juergen-B]

Versuch es mal mit "write" statt "write-raw", also:

{"mode":"write","data":[[396,58]]}

Das sollte funktionieren.

[Stefan_Ge]

Super @Juergen-B ! Hatte verschiedene Varianten probiert aber beim mode write immer nur einmal die eckigen Klammern gesetzt. Sie wie du geschrieben hast geht es! 

Total happy - vielen Dank! 😁

[Stefan_Ge]

Okay write-raw geht auch, z. B. {"mode": "write-raw", "data":[[396,"3002"]]}. 

Hatte echt nur die Klammern immer falsch gesetzt...

[Stefan_Ge]

write-raw find ich gut bei komplexeren Werten

[Thomas_MG]

Lieben Dank. Hat funktioniert. Muss jetzt zuerst mal die tausende Datenpunkte durchforsten um zu sehen was ich mir an HA chicken will. lg

[JörgWende]

Vielleicht gibt das dir eine Idee … https://github.com/MyHomeMyData/iob.vis.vitocal250
Ist nicht von mir - will mich nicht mit fremden Federn schmücken - aber sehr hilfreich 😎🤓

Kannst ja gerne auch ein kleines readme über die Konfiguration in HA machen … das open3e Projekt soll auch eine Art Wiki bekommen …

[Thomas_MG]

Lieben Dank. Hab ich schon gesehen und steht auf meiner Liste. 
wenn meine ersten herzeigbaren Dashboards fertig habe werde ich das zur Verfügung stellen. 
Lg

[TSG]

Hallo,

ich bin jetzt auch "online". Ich habe mir dieses Wochenende mal die ganzen Post hier durchgelesen und meine Integration in Betrieb genommen (Gutes altes Raspberry Pi 2). Zum Thema was man an HW braucht 😉

Da sich zur letzten Inbetriebnahmebeschreibung doch ein paar Dinge geändert haben, habe ich versucht das ganze mal im GitHub im Wiki einzutragen. Mache auch das erste mal was mit dem GitHub wiki, da muss ich noch schauen wie das mit Unterseiten, etc. richtig funktioniert.

!! Achtung !! Nur wild zusammenkopiert, Struktur etc fehlt noch: https://github.com/TheSmartGerman/open3e/wiki

Als nächstes kommt die HA integration... Würde ich dann auch zur Verfügung stellen.

[Thomas_MG]

Kurze Frage noch. Meine PT2 ist nicht per CAN-BUS an der 250 angeschlossen. Ich plane deshalb einen 2. Canbus Adapter an den Raspi anzuschluschliessen und mit dem dann auf die PT2 zu gehen.

Kann ich einfach open3 beide canbus id's übergeben oder muss ich eine separate session starten? Gibt es noch was zu beachten bzgl depict_system.py? Ich möchte ja nicht dass er die Daten vom can 0 überschreibt. Was muss ich dazu beachten?

Danke und LG

[ghNeandr]

Der CAN/USB Adapter liegt bereit zum Verdrahten. Er soll in unmittelbarer Nachbarschaft zum E380CA einbaut und angeschlossen werden. Kabellänge < 1mtr.

Allerdings bin ich mir nicht sicher wie es genau zu erfolgen hat. Hier der installierte E380CB, und sollte der Anschluß wie gezeigt erfolgen?
Den gelben Abschlußwiderstand entfernen und den CAN/USB Adapter wie gezeigt verdrahten? Der Adapter hat ja einen Abschlußwiderstand vorinstalliert.

Frage: kein GND anschließen? Wenn ja, wo? Denn am E380CA sehe ich keinen Anschluß! 

[Juergen-B]

Für jeden CAN-Bus-Adapter brauchst Du eine eigene open3e-Instanz. Du musst ja jeweils die Schnittstelle übergeben, also z.B. -c can0 und -c can1.

Wenn der Raspi neu startet, kann es passieren, dass sich die Zuordnung der Schnittstellen zum physischen Adapter ändert. Also was vorher can0 war ist jetzt plötzlich can1 und umgekehrt.

Um babylonische Datenverwirrung zu verhindern, empfehle ich, die Zuordnung festzulegen. Das geht z.B. mit udev, Anleitung siehe hier. Wenn das einmal eingerichtet ist, werden die CANs beim Neustart oder beim Ab- und Anstecken eines Adapters automatisch neu verbunden und eingerichtet.

Bei der Gelegenheit kannst Du auch sprechende Name vergeben, also z.B. canvitocal und canpt2.

[Juergen-B]

Ja, das sollte genau so funktionieren. GND ist für die Schirmung gedacht, aber bei so kleiner Kabellänge ist das kein Thema.

Viel Erfolg!

[Thomas_MG]

Hallo Juergen.

Lieben Dank. Hat funktioniert. Beide Adapter (can0 -> vcal und can1 ->PT2) starten nach dem reboot.

Ich habe den ersten adapter abgesteckt und den zweiten mit der PT2 verbunden. Depict (mit Parameter -c can1) ist auch durchgelaufen. Es hat die Dateien devices.json neu geschrieben, heisst die Daten da drin von der 250 sind weg, das gleiche für die Datapoints. Die HMUMASTER Adresse ist bei beiden ja gleich.

Sorry für die dumme Frage (bin neu in der Materie). Wie starte ich eine zweite Instanz?

Einfach ein zweites mal aufrufen mit dem Parameter -c can1 oder muss ich open3e ein zweites mal installieren in einem anderen Verzeichnis? Und welchen -d Parameter muss ich übergeben? Beim 250er ist es ja -v cal, was auch funktioniert mit nur einem Adapter. 

Zur Veranschaulichung stelle ich mir das so vor:

Adapter 0 (VCAL)

python3 Open3Eclient.py -c can0 -dev vcal -m 192.168.178.16:1883:vitocal -mfstr {didNumber}_{didName} -muser usr:pwd -t 30 -r 268,269

Adapter 1 (PT2)

python3 Open3Eclient.py -c can1 -dev vpt2 -m 192.168.178.16:1883:vitovp -mfstr {didNumber}_{didName} -muser usr:pwd -t 30 -r 268,269

Hab ich einen Denkfehler hier?

LG

Thomas

[HerrP]

Moin Thomas!

>> Wie starte ich eine zweite Instanz? Einfach ein zweites mal aufrufen mit dem Parameter -c can1

Ja, du kannst es einfach ein zweites Mal starten (in einem neuen Terminalfenster oder sonstwie).

>> Depict (mit Parameter -c can1) ... Es hat die Dateien devices.json neu geschrieben,

Den Aspekt hatte ich tatsächlich nicht bedacht, es ist aber kein Problem:

• Benenne devices.json einfach um in devices1.json und starte die Open3Eclient Instanz auf -c can1 mit -cnfg devices1.json
• Dann depictSystem noch mal auf can0 laufen lassen, die resultierende devices.json in devices0.json umbenennen, und
• starte die Open3Eclient Instanz auf -c can0 mit -cnfg devices0.json

[Juergen-B]

---

Wie starte ich eine zweite Instanz?

---

Hallo Thomas,

entweder Du startest ein zweites Terminalfenster und startest dort eine 2te Instanz, oder Du hängst an die Kommandozeile ein "&" (ohne Anführungszeichen) an, dass wird der Prozess gestartet und das Terminal ist wieder verfügbar. Dann kasst Du eine 2te Instanz genaus starten. Über htop kannst Du die Instanzen bei Bedarf wieder stoppen.

Das Skript legt eine Log-Datei "udsoncan.log". Vermutlich stört das nicht. Falls doch Probleme macht, sag Bescheid.

Zu devices.json: Mein Empfehlung ist, die Datei passen umzubenennen. Also Open3E_depictSystem.py für die vcal  laufen lassen, dann

mv devices.json vcal.json

Open3E_depictSystem.py nochmal für die PT2 laufen lassen und

mv devices.json pt2.json

Kommandozeilen sollten anschließend so aussehen:

python3 Open3Eclient.py -c can0 -cnfg vcal.json -m 192.168.178.16:1883:vitocal -mfstr {didNumber}_{didName} -muser usr:pwd -t 30 -r 268,269 &

python3 Open3Eclient.py -c can1 -cnfg pt2.json -m 192.168.178.16:1883:vitovp -mfstr {didNumber}_{didName} -muser usr:pwd -t 30 -r 268,269

Gruß, Jürgen

P.S.: Falls 192.168.178.16 die IP-Adresse Deines Raspis ist: Schreibe stattdessen besser localhost (z.B. -m localhost:vitocal). Das funktioniert auch, sollte sich die Adresse mal ändern.

[HerrP]

bist du der, der uns auf github bezgl. der Datenpunkte für die PT2 angefunkt hat? Es wäre super, wenn du bei der PT2 das depictSystem mit Option -s laufen lassen könntest und mir die ganzen Dateien devices.json, Open3Edatapoints_*.py und virtdata_*.txt schicken könntest (nicht öffentlich, da stehen Seriennummer etc drin, die sollen nicht in's Netz. Ich schick dir meine eMail Adresse per PM).

Die Option -s (--simul) bewirkt, dass die eh ausgelesenen Daten in die virtdata_*.txt geschrieben werden. Damit kann ich dann meine virtualE3 Simulation füttern und habe praktisch ein Abbild deiner PT2 Anlage. Vielleicht gewinnen wir damit weitere Erkenntnisse, eine PT2 haben wir noch nicht 😉

[HerrP]

@TSG  top Sache dein Wiki!! konnte bisher nur kurz reinschauen, aber was ich gesehen habe ist super! Haben wir deine Zustimmung, das bei uns im open3e zu verlinken?!

[HerrP]

@ghNeandr, @ alle

>> Frage: kein GND anschließen? Wenn ja, wo? Denn am E380CA sehe ich keinen Anschluß! 

>> GND ist für die Schirmung gedacht, ...

Die Antwort von Jürgen ist nicht gaaaanz vollständig richtig. Beim Studium der Datenblätter von CAN Transceivern (hier TJA1015) findet sich Folgendes:

Diese Spannungsangaben sind auf GND bezogen, und wenn man mit einem isolierten CAN Adapter (oder sonsteinem 'Node') völlig ohne irgendeinen GND Bezug arbeitet, der Node also völlig frei floatend ist, kann es passieren, dass durch irgendwelche Einflüsse (häufig Ableitkondensatoren von Schaltnetzteilen oder irgendwelche Einkopplungen) der Transceiver auf ein Potential floated, bei dem die oben gelb markierten Grenzen nicht mehr eingehalten werden. Dann gerät der Receiver in's Clippen und sieht die Signale nicht mehr.

Ich habe viel in industriellen Umgebungen mit CAN gearbeitet und weiss aus Erfahrung, dass das durchaus ein Thema ist. Auch in CAN Implementation Guidelines wird immer die GND Verbindung empfohlen (3-Draht Verkabelung).

Der CAN Gnd vom E380 ist wahrscheinlich irgendwie impedant auf PE oder so bezogen, und in den meisten Fällen funktioniert es damit dann ohne ein CAN Gnd. Ein vollkommen isolierter CAN-USB Adapter sollte dann aber auch auf dieses Potential bezogen werden, damit er nicht irgendwohin floated (jenseits der -27/+40V gegenüber den Signalen). Die sauberste Lösung ist eben, sämtliche Transceiver isoliert auszuführen und CAN-Bus-seitig GND auf einem Potential zu verbinden - die 3-Draht Verkabelung eben. 🙂

Dabei zu beachten ist, das CAN GND auch Gnd von Vcc ist, bei unterschiedlichen Spannungsversorgungen der unterschiedlichen Transceiver also auch hier auf eine Isolierung oder eben Bezug auf ein einheitliches Potential zu achten ist.

Lasst euch jetzt keine grauen Haare wachsen, CAN ist gewöhnlich recht betriebssicher. Aber definitiv führen in der Praxis Potential 'Issues' sehr viel häufiger zu Kommunikationsproblemen, als irgendwelche Störungen durch Einstreuungen (Stichworte Verdrillen, Abschirmung) oder sowas (da ist CAN nämlich wirklich sehr unempfindlich).

Grüsse! 

ps. jetzt noch ein letzter Klugschiss: Eine Abschirmung sollte gewöhnlich NICHT auf CAN_Gnd geführt werden, sondern die Störungen nach PE abgeleitet werden. Wenn man Störungen auf ein Signal-Ground ableitet, bringt man ein gesamtes System zum 'tanzen'. Es gibt Ground-Konzepte, bei denen das gewollt ist, bei einem räumlich ausgedehnten Bus sollte das aber möglichst vermieden werden.

Deswegen ist dieser GND auch NICHT CAN_GND (= Pin 3)

sondern das ist der GND für die Schirmung und der liegt gewöhnlich am Gehäuse und das an PE 😉

[Bu-Na]

@HerrP 

Noch eine andere CAN-Bus Frage:

Kann man via Open3E auch direkt auf die am CAN-Bus angeschlossenen E/A-Geräte zugreifen?

Hier mal eine HIO aus einer VC250-SH:

Gruß Bu-Na