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

[bb77]

und rohdaten über ip lesen geht jetzt auch, sehr sehr schön. 🙂

[Barny58]

Hallo Phil,

ich habe eine VX3 standalone.

Nun gibt es auf Github 3 Versionen

   1- abnoname/open3e/blob/master

   2- MyHomeMyData/E3onCan/blob/main

   3- maxxberg/open3e/blob/dev

zu1- Ist die Hauptversion. Hier sind jedoch auf Open3EdatapointsVx3.py keine Werte enthalten

zu2- Die Daten von Viessmann energy meter E380 CA können in dieser Version ausgelesen werden

zu3- In der Datei Open3EdatapointsVx3.py sind viele Werte schon ausgearbeitet

Folgende Fragen habe ich.

- Werden die 3 Systeme zusammengeführt.

- Welche Version ist für den VX3 die "Beste"

- Kann ich alle 3 Versionen parallel auf dem RPI in unterschiedlichen Verzeichnissen laufen lassen

Beste Grüße

Barny58

[HerrP]

@bb77  danke für die Tests! und für die positive Rückmeldung! 🙂

Die Daten ohne die Simulationsdaten (virtdata_6yz.txt - per Default leider disabled) nutzen mir für meine virtuelle E3 leider nicht viel. Du könntest mal gucken, was für von 'None' abweichende Codecs in den datapoints_6xz.py stehen, ggf. können wir damit die general datapoints erweitern.

Was du mit dem Kram jetzt anfangen kannst, siehst du, wenn du mal ein -a bei MQTT Anbindung ausführst (allerdings besser nur, wenn du problemlos wieder Löschen kannst, das wird ne Menge...). Naja, so gaanz viel Nutzen hat man davon nicht, ausser, dass man sieht, was noch so erreichbar ist, und vielleicht fällt einem dabei ja irgendwas ein 😉

Was auf jeden Fall damit gegeben ist, ist dass die datapoints zu dem System passen (inkl. Modell und Softwarestand) und keine nicht vorhandenen oder nicht gelisteten DIDs da sind und dass die Datenlängen passen (also das -a auch fehlerfrei durchläuft).

[HerrP]

Moin @Barny58 !

die Open3EdatapointsVx3.py ist nur ein 'Overlay' über die generelle Tabelle. Wenn da überall 'None' steht, heisst das, dass es so ist, wie in der Open3Edatapoints.py verzeichnet (None = nix anders). Die Datei ist trotzdem notwendig, weil damit beschrieben wird, welches Sub-Set von Datenpunkten für die VX3 gilt.

du kannst python3 printdatapoints.py -dev vx3 ausführen, das legt das Overlay Open3EdatapointsVx3 über die Open3Edatapoints und du bekommst die Datenpunktliste für die VX3 mit den entsprechenden Codecs.

zu 1. warte bitte noch grad, bis der develop zum master gemerged wurde, dann geht wieder alles (passiert in den nächsten 24 Stunden, bis dahin einfach den develop nehmen, der ist soweit 'perfekt' glaubich) ich habe es gerade gemerged, ich hoffe es hat alles richtig geklappt 😉

Der grundlegende Unterschied zwischen open3e und E3onCAN ist, dass open3e Werte explizit anfordert/ausliest und E3onCAN Daten 'aufschnappt', die vom System sowieso übertragen werden. Manche (viele?) Werte werden aber nur bei Änderung übertragen, d.h. du bekommst sie nicht zyklisch oder im 'schlimmsten' Fall nie. Es werden auch nicht alle Werte übertragen, und Einstellungen kannst du damit auch nicht ändern.

open3e arbeitet hierbei ausschliesslich mit UDS (Unified Diagnostic Services), was vom E380 so nicht wirklich unterstützt wird (der ist ein Zukaufprodukt und spricht mehr CANopen). E3onCAN schnappt aber auch die CANopen PDOs auf. Ich glaube, es gibt bei open3e Datenpunkte, mit denen die E380 Werte von einem anderen Steuergerät (was wiederum die Daten aufgeschnappt hat) ausgelesen werden können.

Lange Rede kurzer Sinn - du kannst open3e und E3onCAN gleichzeitig betreiben und dir von jedem das holen (bzw. auf deinen MQTT Broker holen), was du möchtest / was es bietet. E3onCAN belastet dabei nicht den Bus, weil es nur zuhört. Auf dem Bus ist aber jede Menge Platz, also ist open3e auch nicht problematisch. Ich glaube bei E3onCAN gibt es auch keinen Listener Modus, mit dem du per MQTT Message Informationen anfordern kannst (da bin ich mir aber nicht wirklich sicher, @Juergen-B hab ich was vergessen oder falsch beschrieben?)

Der Fork vom maxxberg ist einfach ein uralter Stand von open3e, da gab es das 'Overlay Prinzip' noch nicht. Soweit mir bekannt, hat er nix, was abnoname/open3e nicht hätte.

ich hoffe, ich hab eine einigermassen passende Erklärung gegeben, sonst sag bitte noch mal Bescheid!

Grüsse!

Phil

[Hotzen-Plotz]

Ich habe nochmal ein paar Fragen:

1) Für die Vitodens finde ich die Heizpläne in den DIDs 761-767. Die Soll-Raumtemperaturniveaus sind da mit "Mode" und einer Zahl bezeichnet. So ist "Komfort" = Mode 4 und "Normal" = Mode 3.

Weiters finde ich auch im DID 1643 die aktuell damit einhergehende Soll-Raumtemperatur.

Ich finde aber nirgends das grundsätzliche Mapping von Reduziert/Normal/Komfort auf RT-Sollwerte. Ideen?

2) Ich habe diesen Scan mit "Open3E_depictSystem.py" mal durchlaufen lassen. Jetzt fällt mir auf, dass ich Dussel im Moment mit meiner Kommandozeile gar nix im Sinne einer "--config devices-json" schreibe. Was genau ist der Effekt, wenn ich diesen config Teil nicht sende?

3) Kann ich den Lesenaufruf mit "-r" und all den Dutzenden DIDs auch irgendwie in einer "args" Datei unterbringen?

4) Genauso fiel mir jetzt auf, dass ich die Übersichtsabfrage mit "-a" gemacht habe ohne den "-m 127.0.0.1:1883:open3e" Teil. Nach dem Scan stand da "run Open3Eclient with -mqtt and -a to get EVERYTHING on your MQTT app." Also sollte man mit dem "-m" was tun. Was für eine Auswirkung hat das?

[JörgWende]

Moin,

zu 1 habe ich auch lange nachgedacht. Mein Verständnis der Logik:

die Steuerung schaut für den aktuellen Wochentag/Uhrzeit in den Scheduler und holt sich die für den Zeitpunkt gültigen Mode (komfort etc). Dann holt sie sich den Temperaturwert für den Mode und geht in die Heizkennlinie - daraus ergibt sich die notwendige Soll Vorlauftemperatur. Diese ist jetzt der (einer der) Parameter für die eigentliche Steuerung.

J.

[Hotzen-Plotz]

Genau. Meine Frage bezieht sich nun auf den Schritt "Dann holt sie sich den Temperaturwert für den Mode ".

Diese Zuordnung finde ich nicht in den DIDs. Habe ich das übersehen?

Die Soll-Vorlauftemperatur habe ich per Skript abgebildet und blende sie in meinen Grafiken ein. Die läßt sich ja schön über die offizielle Formel aus Niveau/Steigung/gedämpfter Aussentemperatur und aktueller Soll-Raumtemperatur berechnen.Das passt auch prima zu den real gemessenen Vorlauftemperaturen.

[JörgWende]

Den Scheduler habe ich gerade nicht im Kopf (gerade noch geschaut 761ff), aber die anderen (VC 250) wären bei mir:

426 TargetPoints

881 Heating Curve

988 Target Set Point

PS: darüber habe ich auch festgestellt, dass meine Vorlauftemperatur begrenzt wurde - 1193 TempMinMaxLimit: min 20 max 40.

[Juergen-B]

Die Beschreibung zu E3onCAN passt. Da die Anwendung nur zuhört, funktioniert es mit dem Energy Meter E380 und mit vernetzten Viessmann Geräten. Mit einer stand-alone VX3 geht es nicht.

Eiin Listener Mode ist nicht vorhanden, da nicht sinnvoll. Ein empfangenes Kommando könnte ja bei diesem Konzept (nur zuhören) nicht umgesetzt werden.

[Dreman]

@Hotzen-PlotzGanz hab ich dein Zuordnungsproblem noch nicht verstanden, aber vielleicht hilft dir das etwas weiter:

- unter 1415 findest du den aktuell laufenden Modus der Heizung:
  0101 = Nachtabsenkung, 0102 = Standard, 0103 = Komfort, 0000 = AUS
- unter 424 wiederum findest du die aktuell eingestellten RTn:
  Byte 1/2= Komfort, Byte 3/4 = Standard, Byte 5/6 = Reduziert
- und die Vorlauf_Soll brauchst du nicht zu berechnen, die findest du unter 987.

[Hotzen-Plotz]

---

@JörgWende  schrieb:

Den Scheduler habe ich gerade nicht im Kopf (gerade noch geschaut 761ff), aber die anderen (VC 250) wären bei mir:

426 TargetPoints

---

Ah, ja da hatte ich tatsächlich was übersehen. Danke! Bei mir ist es DID 424 für Heizkreis 1.

@HerrP: Der DID 424 verursacht bei mir auch ab und an Warnmeldungen weil der Bezeichner der vierten und fünften Werte da drin mit einem Fragezeichen beginnt.

[Hotzen-Plotz]

---

@Dreman  schrieb:

@Hotzen-PlotzGanz hab ich dein Zuordnungsproblem noch nicht verstanden, aber vielleicht hilft dir das etwas weiter:

- unter 1415 findest du den aktuell laufenden Modus der Heizung:
  0101 = Nachtabsenkung, 0102 = Standard, 0103 = Komfort, 0000 = AUS
- unter 424 wiederum findest du die aktuell eingestellten RTn:
  Byte 1/2= Komfort, Byte 3/4 = Standard, Byte 5/6 = Reduziert
- und die Vorlauf_Soll brauchst du nicht zu berechnen, die findest du unter 987.

---

Danke Dir für den Hinweis auf DID 987. Die Bezeichnung "MixerOneCircuitFlowTemperatureTargetSetpoint " hat mir bisher nichts gesagt. Interessant, wenn das die Planvorlauftemperatur ist.

424 hatte ich eben ja auch gefunden, vorher überlesen.

Danke auch für den Hinweis auf DID 1415 "MixerOneCircuitOperationState". Damit und der folgenden Kombi aus "Mode" und "State" konnte ich auch nix anfangen bisher.

[Barny58]

Guten Morgen Phil,

Vielen Dank für die schnelle Antwort und für die ausführlichen Informationen.

Sie haben mir sehr weitergeholfen.

Danke ebenfalls an dein Team für die hervoragende Arbeit.

Barny58

[HerrP]

ich glaube diese Modi (standard, comfor, reduced, ...) müssen wir noch in die Enums reinschreiben, damit die Klartext werden. Irgendwie bin ich dabe noch verwirrt, weil sie wohl ab und zu aus einem Byte bestehen und ab und zu noch ein zweites dabei steht, und das noch nicht final geklärt ist.

> 3) Kann ich den Lesenaufruf mit "-r" und all den Dutzenden DIDs auch irgendwie in einer "args" Datei unterbringen?

@Hotzen-Plotz  klar! du schreibst das '-r' in eine Zeile und die ganzen Parameternummern in die folgende. Dabei keine Leerzeichen oder weitere Zeilenumbrüche in die Reihe mit den Zahlen.

-r
268,271,274,284,318,331,334,360,364,365,381,386,392,396,401,424,475,526,527,531,534,544,545,548,565,691,692,693,694,695,696,697,726,727,728,729,730,731,732,761,762,763,764,765,766,767,874,880,896,919,987,1008,1024,1087,1240,1395,1415,1503,1538,1539,1555,1643,1659,1667,2257,2320,2426,2457,2855,2937,2938

ich würde eigentlich alles in die Datei schreiben, also auch die ganzen -m... Sachen. Das hat auch einen Sicherheitsaspekt, weil die ausgeführten Prompts (Kommandozeilen) auf mehrere Arten eingesehen werden können. Wenn du user und password in die Datei schreibst, sind die in der Kommandozeile nicht sichtbar.

Du kannst dir auch mehrere 'args' Dateien machen, z.B. eine, wo eben nur die grundlegenden Sachen drin sind, z.B. eine genargs:

-c
can0
-dev
vdens
-m
127.0.0.1:1883:open3e
-muser
xxx:yyy
-mfstr
{didNumber}_{didName}

und die dann z.B. zum Schreiben oder Lesen einzelner Sachen oder sowas benutzen

phython Open3eclient.py @genargs -raw -w 789=0123ABEF -v

und deine andre args (inklusive der ganzen zyklisch zu lesenden Parameter und der Zykluszeit und so) für deinen 'normalen' Betrieb/Aufruf.

Allerbesten Dank auch noch mal für deinen beta-Test und die Geduld dabei!!

[HerrP]

ach ja... und

> im Moment mit meiner Kommandozeile gar nix im Sinne einer "--config devices-json" schreibe. Was genau ist der Effekt, wenn ich diesen config Teil nicht sende?

Bei deiner Art der Benutzung wird das keinen Unterschied machen. Die Sache mit dem depictSystem hat folgenden Hintergrund:

Wir können nicht (vorher)sagen, in welcher Konfiguration und mit welchen Soft/Firmware Ständen eine Anlage vorliegt. Anstatt eine datapoints für eine Vcal X 200 mit Frimware 1.2.3.4 und eine für eine Vcal Y 250 mit Frimware 2.3.4.5 und eine für ... und eine für ...... (die wir garnicht genau kennen) zu machen, haben wir den 'Scanner' gemacht, der einfach ohne Kenntnis der vorhandenen Steuergeräte, Datenpunkte, Datenpunktlängen und Codecs das gesamte (erreichbare) System abscannt und in die Dateien schreibt, was er gefunden hat. Das passt dann definitiv zu der Anlage.

Gerade bei der Vitodens unterscheiden sich bsw. die Datenlängen von einigen Datenpunkten gegenüber der restlichen Viessmann Produktwelt, was dann (sonst) zu Problemen führt (allerdings haben wir das zur aktuellen Firmware auch in die datapointsVdens geschrieben, also kein Problem, solange sich nix ändert). Auch können wir auf diese Weise einfach bei einem Anlagen-Softwareupdate hinzugekommene oder weggefallene oder veränderte Datenpunkte 'erschlagen', ohne dafür neue datapointsVyz.py in's Netz stellen zu müssen.

Ein zusätzlicher Aspekt ist, dass du nach dem Scan nicht nur die Main Control Unit (Adresse 0x680) in deine Datenpunkten zur Verfügung hast, sondern auch bsw. die Brennersteuerung bei einer Vitodens oder den Kältekreisregler bei einer Vitocal. Was wir auf diese Weise noch nicht erreichen, sind solche Sachen wie die Batterie Management Systeme an der VX3. Die liegen auf einem Bus, der offensichtlich nicht 'direkt' mit dem externen CAN Bus 'verlinkt' ist. Wir sind noch am Tüfteln, ob man da mittels der Gateways drankommt und wenn ja wie...

Interessant wäre, ob diese 'Steuergeräte' bei einem depictSystem Scan per DoIP auftauchen, weil wir da ja die 'Tür' benutzen, die auch von den Inbetriebnahme-Tools und höchstwahrscheinlich auch vom Viessmann Serversystem benutzt wird... 

[HerrP]

>>> 4) Genauso fiel mir jetzt auf, dass ich die Übersichtsabfrage mit "-a" gemacht habe ohne den "-m 127.0.0.1:1883:open3e" Teil. Nach dem Scan stand da "run Open3Eclient with -mqtt and -a to get EVERYTHING on your MQTT app." Also sollte man mit dem "-m" was tun. Was für eine Auswirkung hat das?

das ist eigentlich egal, wenn du mit dem -a (vielleicht noch mit -v) eine Terminal Ausgabe bekommst. da steht dann auch alles drin, ist nur wenig übersichtlich... 😉 Auf der anderen Seite 'verdirbst' du dir damit nicht deine Anzeige in der MQTT App.

[HerrP]

>> Der DID 424 verursacht bei mir auch ab und an Warnmeldungen weil der Bezeichner der vierten und fünften Werte da drin mit einem Fragezeichen beginnt.

danke für den Hinweis! Wir werden das durch "Unknown" wie gewöhnlich ersetzen

(p.s. schon erledigt)

[ghNeandr]

🏇 Late arrival. Ein hochinteressantes Projekt. 👍
Haben gerade eine WP/PV Anlage in Betrieb genommen:

• Vitocal 250-A AWO-E-AC 251.A13
• Vitocell 100-W Typ CVAB / 100-E SVWA
• Vitovolt 300 / Vitocharge VX3 Typ: 8.0A10
• mit E380CA-1 Energy Meter

Die ViCare reicht mir nicht, möchte einige zusätzliche Anzeigen und Verläufe haben.

Dieses Projekt sieht sehr vielversprechend aus. Kann mir jemand ersparen die 17 Seiten durch zu scrollen / zu lesen, um den Kern für einen Schnellstart in das Projekt zu finden.

@Hotziplotzi hat einen Bericht für das Projekt veröffentlicht 🔥

Ist der USB/CAN Adapter, den Hotziplotzi empfiehlt OK? Und mehr braucht es nicht mehr .. außer Klingeldraht oder so?

Ist dies das empfehlenswerte Vorgehen oder gibt es notwendige/neuere Änderungen?

Bei mir ist ein Raspberry Pi 2 Model B Rev 1.1 (headless) mit Raspbian GNU/Linux 11 (bullseye) im Einsatz. Darauf laufen Nodered und kleinere Python3 Programme (die eigentlich schon längst auf NR umgestellt sein sollten).

Bitte um Feedback,
Danke

[HerrP]

Willkommen Neandr!

Der Adapter den du verlinkt hast ist ein anderer als der von Hotzi erwähnte, sollte aber grundsätzlich auch gehen. Deiner ist nicht galvanisch getrennt, du müsstest also mit Masseschleifen/Potentialbezügen aufpassen. Ich empfehle immer isolierte Adapter wie den bei Hotzi im Bericht. Ausser dem Adapter brauchst du ggf. noch einen Stecker, wenn du nicht eine Klemmleiste hast. Die Adern vom Klingeldraht verdrillen/verpflechten wenn die Leitung etwas länger wird. Wenn sie noch länger wird vlt ein altes LAN Kabel nehmen (verdrilltes Paar für hi/lo). Positionierung der beiden 'Abschluss'widerstände am Bus beachten.

Der Raspi ist schön wenn noch ein kleines bischen Speicher übrig ist, Bullseye könnte das sporadische Timeoutproblem mit dem ISO-TP Kernel haben, sollte sich dann aber mit dem Kernel Update a la @JörgWende beseitigen lassen (erstmal abwarten).

Bis auf die 'Zusammenlegung' von MQTT user:password hat sich nix gegenüber Hotzis Anleitung geändert meine ich. Statt -dev vcal vielleicht besser ein depictSystem machen und dann mit Option -cnfg devices.json starten (steht im args schon drin, wenn du statt der ganzen cl Agumente einfach @args benutzt), dann hast du die VX3 gleich auch mit drin. Der E380 spricht kein UDS, wird aber glaubich von der VX3 abgebildet. Sonst noch Schwesterprojekt E3onCAN mitlaufen lassen (vielleicht eh ne gute Idee, weil was du davon bekommst, brauchst du nicht extra anfordernd auslesen).

bei Fragen einfach hier rein 😉

Grüsse & gutes Gelingen!

Phil

[ghNeandr]

Frage zum Anschluss des CAN/USB Adapters.

Zunächst, der Link in meinem Post war der falsche, ich meinte eigentlich dieser Adapter *\, der sieht wirklich wie Hotzis aus!

Wenn der CAN ein BusSystem ist, sollte es egal sein, wo ein weiteres Gerät angeschlossen wird. Damit wäre es nicht notwendig die "teuren" Stecker 91 / HMU Steckverbinder nutzen zu müssen.

Der CAN-Bus Zähler (E380CA) hat doch Klemmen zum Kabelanschluß.
Das sollte doch der ideale Zugriff auf den Bus sein (ohne 22€ oder mehr) ?

*\  USB zu CAN Konverter Modul for Raspberry Pi4/Pi3B+/Pi3/Pi Zero(W)/Jetson Nano/Tinker Board and Any S...

[ghNeandr]

@Hotziplotzi @MyHomeMyData
Tolle Anleitung um die Viessmann Anlage abzufragen. Habe den CAN/USB Adapter bestellt, den Kabelanschluß muss ich noch realisieren (dazu noch die Frage oben). Damit sollte die HW stehen.

Zur Abfrage der Vi-Anlage sehe ich den Befehl wie ihn @Thyler21 benutzt: Abfrage für "VX3".
Welche anderen Abfrage Parameter sollte ich nehmen ... wo finde ich eine Übersicht der Möglichkeiten?
Gibt es ggf. einen "General" Befehl, mit dem alle Geräte antworten, die auf dem CAN Bus sind? Ev. per MQTT?

Und dann ist da noch USER:PASSWORD
Welche Login Daten werden hier erwartet? Vom MQTT Broker auf dem RPI oder hat das was mit der Vi-Installation zu tun?

[petkow]

Ich habe den Adapter auch am E380CA angeschlossen, klappt, der Abschlusswiderstand entfällt dann automatisch.

Der Stecker am VX3 ist doch vorhanden, ist bei mir nur der Abschlusswiderstand drin, den einfach durch die Kabel ersetzten und im USB Adapter terminieren.

[Juergen-B]

Schau Dir mal das Readme von open3e an, da sind die Möglichkeiten und Optionen beschrieben.

Wenn der CAN Bus läuft, am besten erstmal ein 'Depict System' durchführen.

Dann die gefundenen Geräte mit -cnfg devices.json dem Open3eClient mitgeben. Für die VX3 noch -dev vx3.

Ja, USER:PASSWORD ist für den MQTT Broker. Falls nicht konfiguriert, die Option einfach weglassen.

[HerrP]

>> Für die VX3 noch -dev vx3.

die VX3 sollte beim depictSystem mit erfasst werden und dann in der devices.json stehen, wahrscheinlich mit Adresse 0x6A1 oder so. das -dev wird ignoriert, wenn ein -cnfg <Datei> angegeben ist.

Das wo die Buswiderstände sitzen ist nur bei weiter räumlicher Ausdehnung relevant. Wenn du nur ein paar Meter hast, ist das egal. Bei sehr langen Leitungen sollten die beiden Widerstände jeweils am 'räumlichen Ende' sitzen. Die ziehen ja nur eine rezessive 'Situation' zu 0V_diff, und wenn zu viel Kabel dazwischen ist, funktioniert das möglicherweise nicht zuverlässig (bei 1/4 MBd sollte das einigermassen zügig passieren).

[M_K]

Bzgl. E380 und VX3 würde mich mal interessieren ob schon jemand ein Abbild für die bezogene und eingespeiste Energie gefunden hat. Ich habe in den Datenpunkten für den VX3 leider nichts dazu gesehen.

Die eigentlichen Werte vom E380 (ID 0x258) lassen sich meines Erachtens (aktuell) nur eingeschränkt nutzen, da (zumindest bei mir) Offset und Skalierungsfaktor krumm und veränderlich sind und sich wohl auch zwischen Geräten unterscheiden.