CAN Bus

[crycode-de]

Hallo zusammen,

ich habe kürzlich mit den Arbeiten an einem allgemeinen CAN Bus Adapter begonnen.

Dieser Issue soll dazu dienen euch zu zeigen, dass der Adapter bereits in Arbeit ist und zudem vielleicht noch zu ein paar neuen Ideen führen. :-)

Durch den sehr allgemein gehaltenen Aufbau des Adapters soll es möglich werden, mit nahezu allen Geräten über den CAN Bus zu kommunizieren, sofern die entsprechenden CAN-IDs und die Zusammensetzung der Daten bekannt sind.

Geplanter Aufbau

Hardware

Als Hardware wird auf dem jeweiligen System ein CAN Interface benötigt. In meinem Anwendungsfall ist dies ein MCP2515 CAN Controller, der an einem Raspberry Pi hängt.

Software

Softwareseitig erfolgt die Einbindung des CAN Bus über das Node.js Modul socketcan.

Es wird ein Linux-System benötigt.

Adapterconfig

In der Adapterconfig können das CAN Interface (z.B. can0) und einzelne CAN Nachrichten definiert werden.

Eine CAN Nachricht ist dabei über Ihre CAN-ID in Hexschreibweise gekennzeichnet, wobei Standard- und Extended-Frames unterstützt werden.

Zu jeder CAN Nachricht können dann Parser hinzugefügt werden, welche aus den Datenbytes der Nachricht Zahlen, Booleans oder Strings extrahieren bzw. hineinschreiben können.

Hier ein Screenshot des bisherigen Aufbaus der Konfiguration der CAN Nachrichten (hübsch gemacht wir später):

Objektstruktur

canbus.0.
 +--042
    +--parser1
    +--parser2
    +--json
    +--rtr
    +--send

Beim Empfangen einer konfigurierten Nachrichten-ID werden über die Parser automatisch die Werte ausgelesen und sind dann beispielsweise über canbus.0.042.parser1 verfügbar. Zudem werden die Rohdaten als JSON-Array in canbus.0.042.json gespeichert.

Ist eine Nachrichten-ID zum Senden konfiguriert, dann können die zu sendenden Daten über die Werte der Parser oder direkt in json geschrieben werden. Wenn die Option Autosend aktiviert ist, löst dies sofort ein Senden der CAN Nachricht aus. Andernfalls kann über den State canbus.0.042.send manuell das Senden der Nachricht getriggert werden.

Zusätzlich gibt es eine Option "gesehene" CAN Nachrichten automatisch in der Objektstruktur hinzuzufügen. Diese können anschließend in der Konfiguration in die konfigurierten Nachrichten übernommen werden.

Aktueller Stand

Repo: https://github.com/crycode-de/ioBroker.canbus

• Admin Seite ✔️
  • Übersetzungen mit Weblate ✔️
• Anlegen der Objektstruktur ✔️
• Empfangen von CAN Nachrichten ✔️
  • Generelle Parser-Logik beim Empfangen ✔️
• Senden von CAN Nachrichten ✔️
  • Generelle Parser-Logik beim Senden ✔️
• Parser
  • Zahlen ✔️
  • Wahrheitswerte inkl. Beachtung der Bitmasken ✔️
  • Strings ✔️
  • Benutzerdefiniert mit kurzen Benutzer-Scripts ✔️
• Möglichkeit zur Nutzung in Scripts ✔️
• raw-States ✔️

---

Ideen und Vorschläge sind gerne willkommen. 😃

[TheBam1990]

Grundsätzlich ist das eine gute idee allerdings Wäre es sehr cool wenn CANOpen auch möglich wäre und was eigentlich wichtiger ist das man die anbindung universell gestalten könnte. Z.b. auch über eine netzwerkschnittselle wie mit diesem gerät https://www.amazon.de/Qiterr-2-Wege-CAN-Bus-zu-LAN-TCP-IP-Datenadapter-CANET-2-Ethernet-zu-CAN-Schnittstellenwandler/dp/B07X6JJ35C

oder USB natürlich auch also CAN to USB wandler

[crycode-de]

@TheBam1990 CAN to USB Konverter sollten damit funktionieren, da diese (soweit ich weiß) auch ein direktes CAN-Interface im System erzeugen. Wie sieht die Einbindung ins System bei den CAN to LAN Adaptern aus? Alles was mit SocketCAN kompatibel ist wird unterstützt.

Zu CANopen: Ich denke hier wäre vlt. ein gesonderter CANopen Adapter besser. Grundlegend basiert zwar beides auf dem CAN-Bus, aber meine aktuellen Pläne beziehen sich auf den reinen CAN-Bus auf Layer 2 des OSI Modells. CANopen implementiert hingegen den Layer 7 mit diversen Standards etc. und ist deutlich komplexer.

[IngoGeorg]

Hallo @crycode-de , der Adapter ist ne geniale Sache, ich würd mich hiermit gern als Tester anbieten. Als Hardware sind das Raspi-Addon-Board PiCan2 und der PCAN-USB FD von Peak vorhanden, wobei ich den USB-Adapter mangels Notwendigkeit noch nicht am Raspi laufen hatte. Ein paar Ideen zum Parser hätte ich auch :) z.B. Parameter zum Drehen von High-/Lowbyte beim Einlesen eines WORD - siehe Endianness Gruß, Ingo

[crycode-de]

@IngoGeorg super :) ich geb Bescheid, sobald ich etwas zum Testen habe. Kann allerdings noch etwas dauern, da ich aktuell leider recht wenig Zeit dafür habe. Als Datentyp bei den Parsern ist für jeden Typ mit mehr als einem Byte jeweils Little-Endian (LE) und Big-Endian (BE) auswählbar. Bei Booleans kann zudem eine Bitmaske gesetzt werden.

[rrov1]

Hallo @crycode-de,

ich hätte auch Interesse an diesem Adapter und könnte auch etwas Zeit für die Entwicklung mit einbringen. Kann man dich da Unterstützen?

VG Rico

[crycode-de]

Die erste (noch unvollständige) Version des Adapters ist jetzt auf GitHub verfügbar: https://github.com/crycode-de/ioBroker.canbus

Enthalten sind aktuell:

• Admin-Seite auf Basis von React
• Anlegen/Aktualisieren der Objektstruktur beim Adapterstart
• Empfangen von CAN Nachrichten und Speicherung in die jeweiligen States
• Automatisches Anlegen von Nachrichten-Objekten beim Empfangen von bislang unbekannten Nachrichten inkl. live Anzeige dieser im Admin und der Option diese dann zu konfigurieren

Was aktuell noch fehlt:

• Senden von CAN Nachrichten
• Einbindung der Parser

@rrov1 Danke für das Angebot. Wenn du dich mit TypeScript auskennst, wäre vlt. eine Unterstützung bei der Implementierung der verschiedenen Parser nicht schlecht. Evlt. auch Ideen für zusätzliche Parser für "besondere" Datenarten. Zuvor würde ich nur gerne noch die generelle Parser-Logik einbauen.

[crycode-de]

Update: Inzwischen ist auch das Senden von CAN Nachrichten möglich. Ebenso sind die generelle Logik für die Parser und ein Parser für alle Zahlen-Datentypen fertig.

[crycode-de]

Update: Der Adapter ist größtenteils fertig. Lediglich die Möglichkeit zur Nutzung in Scripts und eine ausführliche Doku fehlen noch.

Wer mag kann jetzt gerne für erste Tests die aktuelle Version über GitHub installieren (https://github.com/crycode-de/ioBroker.canbus), ausprobieren und etwas Feedback geben. :-)

[IngoGeorg]

Ich setze am Wochenende mal einen raspi mit pican und ioBroker auf und werde testen und mich dann melden :-)

[IngoGeorg]

Hallo Peter,

sieht schon sehr gut aus. Die Installation lief problemlos und der Adapter ist insgesamt selbsterklärend. Ich habe mir mal eine ID angelegt und gleichzeitig mit ein paar Parsern zum Lesen und Schreiben parametriert. DLC 4 mit 01020304 als Datum ergibt Folgendes:

Soweit alles richtig, wenn man die Dezimalwerte in hex umrechnet. Diese ID ist zum Lesen und Schreiben angelegt, wenn ich die ID empfange, werden alle Daten aktualisiert. Zum Testen habe ich mit Absicht die Parser mal übergreifend angelegt. Alle 6 Parser schauen auf dieselben gesamt 32bit, so daß 1, 2 und 3-6 sich gegenseitig beeinflussen sollten. Wenn ich jetzt ein Datum ändere, z.B. 1 auf 4096dez(100h) wird richtigerweise eine Nachricht mit der ID 218 (00 00 10 00) gesendet und die JSON-Data sind auch aktualisiert, die anderen zu den 32bit gehörenden Parser-Variablen werden aber nicht aktualisiert.

Empfang ich eine Nachricht mit den gleichen Werten, sind alle Daten wie erwartet.

Ich denke, wenn die Parser so parametriert sind, dass sie sich gegenseitig beeinflussen, sollten die durch die Änderung von 1 beeinflussten Werte von 2 – 6 auch direkt aktualisiert werden, ohne dann natürlich selbst ein nochmaliges Senden der Nachricht auszulösen. Was meinst Du dazu?

Neue Nachrichten tauchen auch direkt auf und können parametriert werden. Dazu hätte ich direkt eine Bitte.

Kannst Du die Definition der Nachrichten zusätzlich per Parameter wahlweise abhängig vom DLC machen? Ich habe einen konkreten Anwendungsfall, wo ich eine ID mit 2 verschiedenen Längen sende bzw. empfange, je nachdem ob bestimmte Daten in der ID enthalten sind oder nicht. Die Unterscheidung erfolgt dann zusätzlich zur ID über den DLC. Damit könnte ich dann für eine ID mit verschiedenen DLC jeweils eigene Parser definieren.

Ein Phänomen hatte ich ein paar Mal, konnte es aber noch nicht direkt reproduzieren und bin nicht sicher ob es von Deinem Adapter verursacht wird. Allerdings sind nur die canutils und ioBroker sowie im ioBroker nur der CAN-Adapter installiert. Eventuell hatte auch der Browser ein Problem, ich teste weiter... Die Webseite der Admin-Instanz war ein paar Mal für einige Sekunden eingefroren und über die SSH hab ich via top gesehen, daß dann für einen Task des Users iobroker und das command node der %CPU – Wert sehr hoch war. Nach einigen Sekunden war der Spuk vorbei und alles reagierte wieder. Ich werde mal versuchen, ob ich das reproduzieren kann.

[crycode-de]

Wow... danke auf jeden Fall für den Test und die sehr ausführliche Rückmeldung. 👍 Aktuell ist es so, dass die Parser nur beim Empfangen einer Nachricht die Daten aus dem Buffer/JSON auslesen. Das kann ich aber gerne noch ändern, sodass sie bei jeder Änderung des json States "anspringen".

Eine optionale Unterscheidung nach dem DLC ist denke ich eine gute Idee. Das könnte auch ein Problem lösen, das mir bei meinen Datenpaketen aufgefallen ist. :-)

Das Phänomen der Admin Seite ist seltsam, aber ausschließen würde ich es jetzt erst mal trotzdem nicht, dass es mit dem Adapter zu tun haben könnte. Die Admin Seite fragt alle Objekte des Adapters ab, um eben die dynamisch hinzugefügten Nachrichten zu ermitteln. Eventuell kommt das daher... Mir ist das bisher so zumindest nicht aufgefallen, aber ich werde mal darauf achten.

[crycode-de]

Update

Der Adapter hat jetzt eine komplett neue Adminseite bekommen und die von @IngoGeorg benannten Änderungen (DLC und Parser Updates) sind umgesetzt.

Weiterhin ist ioBroker.canbus jetzt als v0.1.0-alpha.1 auf NPM verfügbar und demnächst auch im latest Repository.

[crycode-de]

Der Adapter ist nun mit v1.0.0-beta.3 im Latest Repo verfügbar.

Für Infos und Feedback bitte den zugehörigen Forum Thread nutzen:
https://forum.iobroker.net/topic/39033/test-adapter-canbus-v1-0-x-latest

@Apollon77 Ich denke damit kann hier das Label "Released" dran :-)

[Apollon77]

Thank you!