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

[Thomas_MG]

Ja das war ich. Ich schau mir das an und schick dir die Dateien. Ich habe in der Datei Open3E_depictSystem die last_did auf 1371 angepasst, weil komischer weise er vorher weiter bis auf 3700 zählen wollte und nach 1371 für jeden did nach 3 Sekunden ein Timeout bekam. Hat mir zu lange gedauert.

Zusätzlich habe ich in den CANbus auf 1 gesetzt in der Datei bevor ich es auf PT2 laufen lies.

Das mit den beiden Aufrufen hab ich dann spitzbekommen. Habs allerdings wie oben aufgerufen (sprich den PT2 ohne Parameter -v). Es ging soweit, kann die Daten in HA einlesen und verarbeiten. Nur bin ich nicht in der Lage die z.B. ElectricalPowerOutput von Hex in Decimal umzurechnen in Homeassistant und auch nicht die Arrays. Weiss nicht ob dies hierzu das richtige Forum ist. Ich lasse es nochmal auf der VCAL laufen und starte dann mit -cnfg. Lieben Dank für eure tolle Unterstützung!

[ghNeandr]

@HerrP  @Juergen-B

Um weiter zu verstehen, wie die CAN-Bus-Verkabelung etc. sein sollte, stößt man unweigerlich auf Firmen-Webseiten mit vielen Produkten, aber auch guten Tipps, wie es richtig gemacht werden sollte.

Eine "firmenfreie ?" Seite ist hier: https://wiki.ta.co.at/CAN-Bus
In "Beispiele für verschiedene Netzwerkvarianten - Kleines Netzwerk" ist die GND-Schaltung schematisch dargestellt.

Demnach wird die Abschirmung als durchgehende Leitung über alle Teilnehmer hinweg mit "GND" verbunden. Interessant ist die indirekte Erdung als Option und mit Gasentladungsableitung.

Der in der Diskussion gezeigte Steckeradapter hat eine galvanische Verbindung vom 9-poligen Steckergehäuse zum GND-Schraubanschluß ... zumindest bei mir!

[Martin_K_34260]

Im Projekt lesen wir die Daten direkt vom VX3 heraus. Die GridBox zeigt nur die Daten seit ihrer Aktivierung an.

Du kannst sie z. B. auch einen Monat lang ausschalten und schon zeigt diese eine Differenz zum VX3 Display oder den von uns ausgelesenen Daten an.

Wir hatten die GridBox 2 Tage im Einsatz, dann war diese defekt und der VX3 ist jetzt auf das interne Engergiemanagement umgestellt.

[Martin_K_34260]

Bei mir ist es auch auf 20% eingestellt und die 2214 liefert 1400.

Werde mal den Wert die Tage auf 10% einstellen und schauen was passiert.

[Martin_K_34260]

Das Problem wurde mittlerweile durch meine Nachforschungen gelöst und der Elektriker hat nur noch die Reihenfolge geändert und man siehe da, es funktioniert.

Der Energiezähler war in der falschen Reihenfolge eingebaut:

Falsch: Hausanschluss  -> Stromzähler  -> Backupbox  -> Energiezähler -> Haus

Richtig: Hausanschluss -> Stromzähler -> Energiezähler -> Backupbox ->Haus

[HerrP]

@ghNeandr  der Ansatz Shield mit Signal-Ground zu verbinden folgt dem Konzept, das gesamte Potential einer Schaltung bei einwirkenden Störungen mit der Störung 'mitgehen zu lassen'. Wenn du also ein Signal von 3 Volt gegen Masse hast, und es wirkt eine Störung ein, die sowohl die Masse als auch das Signal um 1 Volt anhebt, hast du immer noch 3 Volt Signalpegel, obwohl das Signal (meinetwegen gegen Erde gemessen) gerade 4 Volt hat (weil die Signal-Masse eben auch um 1 Volt bsw. gegenüber Erde angehoben wurde).

Dieses Konzept ist durchaus sinnvoll, allerdings eher bei räumlich begrenzten Dimensionen. So ein CAN Bus ist aber eher etwas 'längliches'.

Bei der Seite, die du anführst, wird die Versorgungspannung an einer Stelle erzeugt und auch im Bus mitgeführt. Es wird davon ausgegangen, dass auch die Versorgungsspannung im Störungsfall genauso angehoben wird, wie die Signale und der Schirm.

Bei deiner Applikation hast du aber jeden CAN Transceiver mit einer eigenen Spannungsversorgung versorgt. Dazu hatte ich ja oben schon kurz was gesagt.

Man kann das jetzt unendlich weiter auswalzen, es bringt nix. Es gibt bei einem Ground-Konzept nicht eins, das richtig ist und alles andere falsch, richtig und wichtig hingegen ist, dass man ein Ground Konzept ausarbeitet und diesem strikt folgt und nicht mehrere 'Strategien' durcheinander mischt.

Da du das, was Viessmann gemacht oder hinzugekauft hat (E380 - schlecht designed) nicht beeinflussen kannst, hast du nur die Möglichkeit, mit deinem CAN-USB Adapter 'das Richtige' zu machen. Da der (abgebildete) Bus-seitig isoliert, also potentialfrei, ist (sowohl der Transceiver als auch dessen Spannungsversorgung!), solltest du das Potential an das auf dem Bus herrschende anbinden. Zumindest auf der Vitocal gibt es einen CAN_Gnd, und diesen solltest du mit dem CAN_Gnd deines Adapters verbinden. Ich denke, bei der PT2 wird es nicht anders sein.

Wenn du dir die Transceiverschaltung anguckst, werden dir die beiden 25k Widerstände an CAN_Hi/CAN_Lo auffallen. Der Transceiver 'zentriert' sich (im rezessiven Zustand) also sozusagen selber um 0,5V über GND. Das funktioniert so lange, wie nicht von der anderen (dem Bus 'abgewandten') Seite etwas mit weniger Impedanz das Potential verschieben will.

Da es nicht in deiner Hand liegt, das gesamt System gleichförmig floaten zu lassen, solltest du Störungen, die der Schirm einfängt, nicht auf das Gnd-Potential des (Signal-)Busses leiten.

Wie gesagt - das ist eine Wissenschaft für sich und es gibt dabei nicht eine allgemeingültig richtige Lösung, ausser dass das Konzept stimmen und durchgängig beachtet werden muss. Häufig wird der Schirm mit einem RC Netzwerk irgendwohin gekoppelt, ob an PE oder Gnd ist dabei die Frage des Konzepts.

Was schreibt Viessmann zur Schirmanbindung?

>> Der in der Diskussion gezeigte Steckeradapter hat eine galvanische Verbindung vom 9-poligen Steckergehäuse zum GND-Schraubanschluß

Richtig! Der GND Schraubanschluss hätte aber mit 'Shield' oder 'Cover' bezeichnet werden sollen und hat eben keine Verbindung zum CAN-Bus GND, welcher auf Pin 3 geführt wird!

Viel wichtiger als der blöde Schirm ist das Verdrillen der CAN_Hi und CAN_Lo Signalleitungen. Und dabei drauf achten, dass sich Gnd nicht um mehr als die oben gelb markieren Spannungen von diesem verdrillten Leistungspaar entfernt. Das erreichst du am besten, indem du nichts von aussen auf Gnd einkoppelst.

[HerrP]

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

@Bu-Na  du kannst mit Open3E auf alle (UDS-sprechenden) Geräte zugreifen, die von dem Bus, an dem Open3E 'hängt', direkt erreichbar sind. Es gibt aber mehrere CAN Busse in so einem Viessmann System - den externen Bus (Klemme 91), den internen Bus, ggf. den Batterie-Bus, evtl. einen 'Master-Bus' (Own Bus?), ...

Wir haben es bsw noch nicht geschafft, vom Externen Bus an die Batterie Management Systeme zu kommen. Evlt bekommen wir das noch mittels irgendwelcher Gateways hin, aber so weit sind wir noch nicht.

Es gibt also definitiv 'Steuergeräte', an die man aktuell mit Open3E an Klemme 91 nicht dran kommt.

[HerrP]

@Thomas_MG 

>> weil komischer weise er vorher weiter bis auf 3700 zählen wollte und nach 1371 für jeden did nach 3 Sekunden ein Timeout bekam. Hat mir zu lange gedauert.

Ich habe das p2_timeout von 1 auf 3 Sekunden erhöht, weil 1 Sekunde zumin auf dem virtuellen Bus bei ganz langen Datenpunkten nicht gereicht hatte und es dann zu 'Verschiebungen' bei erkannten DIDs gekommen ist. Das fiel dann auf, indem das Scan-all mit Fehler abgebrochen war.

Ich werde es wieder auf 2 Sekunden reduzieren (oder auf 1,5? - es ist halt nicht immer sicher und auch nicht vorhersagbar, weil keiner weiss, was sonst noch mit welcher Prio auf dem Bus los ist. Es ist eben ein Kompromiss zwischen 'Komfort' (Schnelligkeit) und Sicherheit...).

Der Scan läuft gewöhnlich bis 3500, und in dem Bereich liegen auch die bekannten DIDs. Es kann sein, dass zwischendurch lange keine für das Gerät sind und vlt auch am Ende nicht, aber sicher kann man nur sein, wenn man es versucht hat.

[Thomas_MG]

@HerrP .

Hast recht. ich habe einen Fehler gemacht. Durch irgendeinen Grund hat er mir das timeout pro did nach 1371 gezeigt. Ich habs nochmal laufen lassen bis 3500 und jetzt ging es und hat auch mehr Punkte gebracht! Ich musste aber auch die datapoint Dateien umbenennen und die Dateinamen in der devises.json anpassen. Jetzt läuft es soweit.

Ich hab noch ein paar Fleissaufgaben und danach mache ich mich an ein kleines Wiki.

Ich hänge immer noch wie einen Matrixwert auslese. Z.B. bei der 250er:

vitocal/565_EnergyConsumptionDomesticHotWater 000000002c0000002c000000960500008106000000000000

wie verarbeite ich den Wert?

LG

LG

[Awot252]

In welchem Gehäuse habt ihr den CANBus USB Adapter?

[TSG]

Leider noch keines, aber ich habe dieses gefunden: https://www.printables.com/de/model/535609-innomaker-usb2can-module-case

Werde ich vermutlich erst  auf's wochende dazu kommen mal einen Drucktest zu machen.

[TSG]

@HerrPIch gebe mein bestest. Bin mit GitHub nur meher in der Theorie vertaut. Ich würde versuchen einen Pull Request zu stellen. Geht dann auch das wiki? Ich denke es macht Sinn, dein Projekt als Master zu betrachten. Und nicht auf einen Fork zu verlinken.

Jetzt habe ich auch noch einen Branch für homeassistant aufgemacht, wird das ganze vermutlich nicht einfacher machen. Aber veruchen könnten wir es mal... Sonst gerne per PN

[JörgWende]

Hi @Thomas_MG  … schau mal in den develop branch … da haben wir schon an den Matrixwerten gearbeitet.

548 : O3EComplexType(24, "EnergyConsumptionCentralHeating", [O3EInt32(4, "Today", scale=10), O3EInt32(4, "Week", scale=10), O3EInt32(4, "CurrentMonth", scale=10), O3EInt32(4, "PastMonth", scale=10), O3EInt32(4, "CurrentYear", scale=10), O3EInt32(4, "PastYear", scale=10)]),
565 : O3EComplexType(24, "EnergyConsumptionDomesticHotWater", [O3EInt32(4, "Today", scale=10), O3EInt32(4, "Week", scale=10), O3EInt32(4, "CurrentMonth", scale=10), O3EInt32(4, "PastMonth", scale=10), O3EInt32(4, "CurrentYear", scale=10), O3EInt32(4, "PastYear", scale=10)]),

Feedback ist willkommen.

J.

[ghNeandr]

@Awot252 
In welchem Gehäuse habt ihr den CANBus USB Adapter?

Mein alter Trick, ein kleines Plastikkästchen in dem ich Eisenkleinteile gekauft hatte. Rechts und links je ein Loch, fürs Usb Kabel und die verdrillten Drähte vom 9-poligen Stecker/Schraubverbindung zum E380. Fertig.

Das Kästchen ist mit Deckel und transparent, so sehe ich die schönen roten LED's.
Kästchen mit Deckel und transparent, der Adapter blickt schön rot. 😄

[ghNeandr]

So jetzt Start ins Vergnügen. Adapter installiert, verdrahtet. Open3E SW installiert, no problem.

Der Ablauf von

$ python3 Open3E_depictSystem.py

ist sehr zeitaufwendig, sollte in den Hinweisen gesagt werden.

Vielleicht ist es sinnvoll das py-Listing nicht auf die Console zu schreiben, sonst in eine Datei umzuleiten.

$ python3 Open3E_depictSystem.py > scan.txt

Der Abschluß des Scans gibt als letzte Zeile aus:
run Open3Eclient with -mqtt and -a to get EVERYTHING on your MQTT app.

Da bin ich jetzt etwas überfragt!?
Ein MQTT Broker läuft auf meinem RPI zusammen mit Nodered. Für Monitoring des MQTT nutzte ich das sehr aussagekräftige MQTT-Explorer.
Kann jemand dabei helfen wie typischerweise der Befehl für Open3Eclient with -mqtt and -a aussehen sollte.
Quatscht der Open3e dann permanent über MQTT?

[ghNeandr]

Bei der Durchsicht des Open3E_depictSystem.py scans sehe ich nur Datenelemente die wohl mit der PV Anlage und dem Batteriespeicher zu tun haben.
Die Wärmepumpen Installation wird auf diesem Weg wohl nicht angesprochen/ abgefragt. D.h. der CAN Bus gilt nicht für die WP. Geht da noch was, oder muss ich zusätzliche HW / SW haben um ein komplettes Abbild der Installation WP/PV zu bekommen?

[TSG]

Ich arbeite daran eine umfangreichere Doku zu erstellen: https://github.com/TheSmartGerman/open3e/wiki/030-Installation-und-Inbetriebnahme-von-open3E

[Thomas_MG]

Super Sache. Kann ich mich da dran hängen? Ich kann das Thema mit 2 CanBus Adapter hinzufügen.

[GW3]

Hallo, tolles Projekt. Ich versuche eine Schnittstelle zwischen meiner A250 und Homeassistant zu realisieren.

Ich hab dabei ein Verständnisproblem zu dem Scan.

Wenn ich

python3 Open3E_depictSystem.py

aufrufe werden am Bildschirm Datenpunkte gefunden, z.B.  für das Device 680

found 268:9:FlowTemperatureSensor

in dem FileOpen3Edatapoints_680.py steht

268 : None,

Wäre super wenn das jemand erklären könnte warum hier None steht.

Vielen Dank schon mal

[Thomas_MG]

@JörgWende Hammer. Läuft!

Ganz lieben Dank!

[Juergen-B]

Für den hier bereits empfohlenen Adapter habe ich eine Halterung zum Selberdrucken erstellt. Ist nach oben offen, also kein geschlossenes Gehäuse.

Wird mit 3 Schrauben auf einer Unterlage fixiert (vorher Muttern einlegen), dann der Adapter mit zwei M2.5 Schrauben angebracht.

Die STL-Datei gibt es hier.

[HerrP]

@GW3 

>> found 268:9:FlowTemperatureSensor

>> in dem File Open3Edatapoints_680.py steht

>> 268 : None,

Wenn in einer Open3Edatapoints_6yz.py bei einem Datenpunkt : None steht heisst das, dass es bei dem Codec (die Interpretation der Daten) keine Änderung gegenüber der (generellen) Open3Edatapoints.py gibt, also es so aussieht wie in Open3Edatapoints.py verzeichnet. Auf dein Beispiel bezogen steht da 

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")]),

 und so ist es dann auch bei deinem gescannten Device.

Dass der Datenpunkt trotzdem in der Open3Edatapoints_680.py aufgeführt ist, hat den Zweck, anzuzeigen, dass der Datenpunkt bei ECU 0x680 existiert (in der Open3Edatapoints.py stehen ja auch noch ganz viele Datenpunkte, die auf der 0x680 nicht existieren). Das ist wichtig für ein --scanall.

Jörg hat die treffende Bezeichnung 'Overlay' für die datapoints_6yz kreiert:

Die 6yz Tabelle wird über die generelle datapoints drüber gelegt,

• da wo in der 6yz nix steht, ist auch nix.
• da wo in der 6yz None steht, schimmert der Eintrag aus der generellen datapoints durch,
• da wo in der 6yz etwas Explizites steht, gilt das Expizite.

Wenn etwas Explizites da steht, kann das zwei Gründe haben:.

1. Es gibt schlicht noch keinen Eintrag in der generellen Open3Edatapoints.py
2. Die Länge der ausgelesenen Daten unterscheidet sich von der in der Open3Edatapoints.py und folglich kann der Codec dort nicht 'unfallfrei' angewendet werden. Dann schreiben wir den RawCodec hin, weil wir gewöhnlich nichts Tiefergehendes wissen.

Bei 1. wäre es sinnvoll, den Eintrag in die generelle offizielle Open3Edatapoints.py zu übernehmen, damit eine einmal gefundene Decodierung dann automatisch für alle anderen Geräte angewendet wird.

Bei 2. lohnt es nachzusehen, ob es sich in der generellen Tabelle um einen 'einfachen' Codec handelt. Ist es bsw. dort ein O3EUtf8, so liegt die Vermutung nahe, dass es auch ein Utf8 String ist, lediglich mit einer anderen Länge. Dann kann man das in seiner lokalen datapoints_6yz auch so reinschreiben und hat dann die Klartext/de/codierung mit passender Länge. Wenn es etwas complex/er/es ist, muss man gucken...

Für 1. wäre es schön, wenn auf Dauer mal alle Leute entweder ihre _6yx.py's bei uns 'einschicken' oder selber die entsprechenden Datenpunkte in der Open3Edatapoints.py im abnoname/open3e develop branch ergänzen (per Fork -> einpflegen -> zum Mergen pushen).

[HerrP]

@Thomas_MG 

>> Ich musste aber auch die datapoint Dateien umbenennen und die Dateinamen in der devises.json anpassen. 

ja, du hast Recht, das hatte ich heute morgen kurz nach dem Aufstehen noch nicht auf dem Schirm - sorry 😉

[HerrP]

@ghNeandr 

>> Kann jemand dabei helfen wie typischerweise der Befehl für Open3Eclient with -mqtt and -a aussehen sollte.

eigentlich wie in der README beschrieben:

python3 Open3Eclient.py -c can0 -cnfg devices.json -m 192.168.0.5:1883:open3e -mfstr "{ecuAddr:03X}_{didNumber}_{didName}" -a

Wenn dein MQTT Broker auf der gleichen 'Maschine' läuft wie open3e kannst du auch 127.0.0.1 (local host) statt 192.168.0.5 benutzen (die 192.168.0.5 ist natürlich auch nur beispielhaft, genau wie das can0). Ich habe eine argsscanallmqtt gemacht, die du einfach mit

python3 Open3Eclient.py @argsscanallmqtt

aufrufen kannst statt der ganzen einzelnen cl Optionen.

Wenn du User und Passwort auf dem Broker benutzt, musst du noch

-muser ichuser:meinpwd

hinzufügen.

Ggf. musst du in dener MQTT App noch alle open3e Topics abonieren, im MQTT Explorer tauchen sie eigentlich von selber auf.

>> Quatscht der Open3e dann permanent über MQTT?

Nein. der Client macht in diesem Fall nur einen --scanall Durchlauf und beendet sich dann wieder.

Wenn du möchtest, dass er dauerhaft/zyklisch Werte postet, musst du die Optionen

-r 123,234,456 -t 10 

verwenden, gewöhnlich anstatt dem -a

>> Bei der Durchsicht des Open3E_depictSystem.py scans sehe ich nur Datenelemente die wohl mit der PV Anlage und dem Batteriespeicher zu tun haben.
Die Wärmepumpen Installation wird auf diesem Weg wohl nicht angesprochen/ abgefragt. D.h. der CAN Bus gilt nicht für die WP. Geht da noch was, oder muss ich zusätzliche HW / SW haben um ein komplettes Abbild der Installation WP/PV zu bekommen?

Das klingt als wären WP und PV nicht über CAN Bus miteinander verbunden?!? In dem Falle bräuchtest du einen zweiten CAN Adapter und zweite Instanz open3e usw. wie bei @Thomas_MG 😞 

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.

Einfach Kabel dran reicht nicht, weil im Inbetriebnahmeassistenten dann auch das Führungsgerät als solches konfiguriert wird und so. Mindestens den Inbetriebnahmeassistenten muss man also noch mal durchlaufen lassen.

>> depict ist sehr zeitaufwendig, sollte in den Hinweisen gesagt werden.

ist erledigt in develop. danke!

>> Vielleicht ist es sinnvoll das py-Listing nicht auf die Console zu schreiben, sonst in eine Datei umzuleiten.

Eigentlich ist das nicht nötig/sinnvoll, dann weiss man ja noch weniger, dass überhaupt etwas passiert und bricht evtl sogar vorzeitig ab.

Die devices/ECUs stehen mit zusätzlichen Angaben in der devices.json, die man ja anschauen kann.

Man kann sich dann mit

python3 printdatapoints.py -dev _6yz

die gefundenen Datenpunkte pro ECU sogar mit Codecs ausgeben lassen. 

Also besser die 'Lebenszeichen' on Screen lassen 😉 

[HerrP]

@TSG 

>> Ich gebe mein bestest. Bin mit GitHub nur meher in der Theorie vertaut.

ich bin auch blutiger git Anfänger 🙂 So wie ich das verstehe machst du einen Fork von abnoname/open3e in dein Account. Da kannst du dann drin arbeiten, was du ja im abnoname/open3e nicht kannst, weil du kein colaborator bist.

Arbeite bei dir dann bitte im develop branch, NICHT im master. Der develop soll develop bleiben, und irgendwann holen wir den hoch in den master. Wenn aber vorher der master mit irgendeiner Fork gemerged wurde, ist der dann in gewissen Aspekten ahead develop und es wird kompliziert......

Wenn du mit Bearbeiten erstmal fertig bist, wähle unter 'Contribute' -> 'Open Pull Request'

Dann erscheint das bei uns und wir sollten es ein-mergen können.

Zwischendurch / vor dem Pull Request vlt ein 'Sync Fork' machen...

Vielleicht klappt das mit dem Wiki auf die Art auch?!

Vielleicht kann hier noch wer Tips zu git Vorgehen geben, der/die sich besser auskennet?!