Test Adapter canbus v1.1.x Latest

[crycode]

Aktuelle Test Version	1.2.x
Veröffentlichungsdatum	22.06.2021
Github Link	https://github.com/crycode-de/ioBroker.canbus

Der CAN-Bus (Controller Area Network) ist ein serielles Bussystem. Er kam ursprünglich vorrangig von Fahrzeugen zum Einsatz und ist inzwischen auch im Bereich der Heimautomatisierung recht verbreitet.

Dieser Adapter soll eine direkte Anbindung eines CAN-Interfaces (z.B. can0) an ioBroker ermöglichen.
Hierbei geht es um reine CAN-Nachrichten von bis zu 8 Byte Datenlänge. Aufgesetzte Protokolle wie z.B. CANOpen sind nicht vorgesehen.

Unterstützt wird jede Hardware, die sich auf einem Linux-basierten Betriebssystem als CAN-Interface meldet. Aufgrund der zugrundeliegenden socketcan Library werden Windows-Systeme leider nicht unterstützt.

Die Admin-Seite ist mit React auf Basis von adapter-react gebaut. Da dies noch recht neu ist, wären hier sicherlich auch ausgiebige Tests nicht verkehrt.

Dieser Adapter verwendet Sentry Libraries um automatisch Fehler an die Entwickler (mich) zu senden. Für mehr Details und Informationen zum Deaktivieren des Error-Reportings siehe Sentry-Plugin Dokumentation.

Features

• Empfangen und Senden von CAN-Nachrichten in Standard- und Extended-Frames
• Jede Nachricht kann einzeln zum Senden und/oder Empfangen konfiguriert werden
• Möglichkeit automatisch empfangene, aber noch nicht konfigurierte, CAN-Nachrichten hinzuzufügen
• Konfiguration von Parsern für die einzelnen CAN-Nachrichten zum Lesen/Schreiben von Daten von/in den Rohdaten-Buffer der Nachrichten
  • Zahlentypen
  • Boolsche Werte inkl. Bitmasken
  • Strings in verschieden Encodings
  • Eigene Scripte zum Lesen vom / Schreiben in den Buffer der Rohdaten
• Erweiterte Import/Export Funktionen
  • Import von Nachrichtenkonfigurationen zur Erweiterung der bestehenden Konfiguration
  • Import vor vordefinierten "bekannten" Konfigurationen von GitHub direkt im Admininterface
  • Export und Import der Nachrichtenkonfigurationen als json oder csv Dateien
• Optionale Verwendung der Datenlänge (DLC)
• Optionale Unterstützung des RTR-Flags
• Optionale Raw-States, welche die Rohdaten der empfangenen bzw. gesendeten/zu sendenden CAN-Nachrichten-Objekte beinhalten

Anforderungen

• Linux Betriebssystem
• CAN-Hardware, die vom Kernel unterstützt wird und ein Interface wie beispielsweise can0 bereitstellt
• Kenntnisse über die CAN-Nachrichten auf dem Bus (nicht zwingend erforderlich, aber hilfreich)

Parser

Über die Parser können Daten aus den Rohdaten einer CAN-Nachricht extrahiert bzw. in diese hineingeschrieben werden.

Es gibt vordefinierte Parser für die nachfolgend aufgeführten Datentypen und zusätzlich die Möglichkeit eigene Scripte zum Lesen/Schreiben zu erstellen.

Zahlentypen im Big-Endian und Little-Endian Format

• Signed und Unsigned 8, 16 und 32 Bit Integer
• 32 Bit Float
• 64 Bit Double

Boolsche Werte

• 1 Byte inkl. Unterstützung von Bitmasken

Strings

• 1 bis 8 Byte Länge
• Encodings: ascii, base64, hex, latin1, utf8, utf16le

Eigene Skripte
Beim Parsertyp Custom können eigene Skripte zum Lesen/Schreiben der Werte genutzt werden.
Diese Skripte laufen in einer Sandbox (ähnlich den Skripten vom JavaScript Adapter).

Folgende Features können in den Skripten genutzt werden:

• Die meisten Node.js Standardfunktionen
• async/await
• Log-Funktionen des Adapters: log.warn('something'), log.info('something'), log.debug('something')
• getStateAsync('id') und getObjectAsync('id'), wobei id die vollständige ID des States/Objektes ist

Fehler in den Skripten werden vom Adapter abgefangen und ins Log geschrieben.

In beiden Skripen sind die Variablen value und buffer vordefiniert. buffer enthält dabei jeweils die aktuellen Rohdaten der CAN-Nachricht als Node.js Buffer. value sollte beim Lesen auf den gelesenen Wert gesetzt werden. Beim Schreiben enthält value den zu schreibenden Wert.

Screenshots

Schlusswort

Die Übersetzungen sollten in Deutsch und Englisch vollständig und korrekt sein.
Übersetzungen für andere Sprachen sind teils automatisch übersetzt und teils noch gar nicht vorhanden. Wer mag kann gerne über Weblate die Übersetzungen vervollständigen/korrigieren.

Viel Spaß beim Testen!
Ich freue mich auf Feedback.

Grüße
Peter

[zmaier]

@crycode :
Erstmal vielen DANK für diesen Adapter, das ist genau was ich gesucht habe!!!!
Bist auch der Peter im mikrocontroller.net Forum zum Thema Junkers Gastherme?

Eine Frage hab ich zum Parser.
Am Bus wird eine 2 Byte Nachricht versendet die in HEX die Aussentemperatur in 100tel Grad ausgibt.
z.B : 024B -> 5.78°C oder FF76 -> -1.18°C

Wie könnt ich die Umwandlung direkt mit dem Parser machen?

[crycode]

@zmaier

Bist auch der Peter im mikrocontroller.net Forum zum Thema Junkers Gastherme?

Nein, bin ich nicht.

Am Bus wird eine 2 Byte Nachricht versendet die in HEX die Aussentemperatur in 100tel Grad ausgibt.
z.B : 024B -> 5.78°C oder FF76 -> -1.18°C
Wie könnt ich die Umwandlung direkt mit dem Parser machen?

Das sollte mit einem Custom Parser recht einfach machbar sein. Die Werte sehen mir nach einem Int16 im Big Endian Format aus. Das Skript zum Lesen wäre dann wie folgt:

value = buffer.readInt16BE() / 100;

Wobei ich bei deinen angegebenen Beispielen leichte Abweichungen habe. 024B ist 5,87 und FF76 ist -1,38.

Ich gehe mal davon aus, dass du die Werte nur lesen und nicht schreiben möchtest? Dann kannst du als Skript zum Schreiben einfach einen Kommentar einfügen, damit der Adapter beim Starten keine Warnung wegen eines leeren Skripts ins Log schreibt:

// kein schreiben

[zmaier]

@crycode
Danke!
Das hilft mir sehr weiter.

Schöne Grüße
Martin

[zmaier]

@crycode

Was mir gerade aufgefallen ist :
ich habe z.B. eine Nachricht mit ID 201, bei dieser ID habe ich eine Custom Parser eingestellt.

Die Nachricht kommt regelmässig, nach dem Neustart des Adapters wird auch der richtige (zum Parser passende) Datenpunkt erzeugt. Nur dieser Datenpunkt verschwindet irgendwann wieder?
Starte ich den Adapter neu ist er wieder da ?

Hast du eine Idee warum? Kann ich ein deguber mitlaufen lassen um dem Problem auf die Spur zu kommen?

[zmaier]

@zmaier :

Was mir auch aufgefallen ist, die Datenpunkte kommen auch nach einer Zeit wieder - aber dann sind alle Einstellung zu diesem Datenpunkt weg (z.B. speichern in InfluxDB).

[crycode]

@zmaier Das ist seltsam
Sind das Nachrichten- oder die Parser-Datenpunkte, die verschwinden?
Der Adapter löscht eigentlich nur beim Start die Objekte, wenn sie nicht konfiguriert sind. Nicht konfigurierte Nachrichten werden zudem nur gelöscht, wenn der entsprechende Haken auf der "Allgemein" Seite gesetzt ist.

Kannst du für den Adapter mal das Log auf debug stellen?
Wenn der Adapter ein Objekt löscht sollte dort zusammen mit ein paar anderen Meldungen delete unconfigured parser <id> oder delete unconfigured message <id> geloggt werden.

[zmaier]

@crycode :
Die Parser-Datenpunkte veschwinden und kommen aber nach einiger Zeit wieder.
Aufgefallen ist mir das, weil ich gestern Abend einige IDs mit einem Custom Parser konfiguriert habe und diese neuen Datenpunkte dann in der Datenbank speichern wollte.
Gestern Abend sind einige Punkte verschwunden und nach Neustart des Adapters wieder erzeugt worden.
Heute früh war bei einigen Datenpunkten die Einstellung zur InfluxDB nicht mehr vorhanden.
Wie wenn die Punkte verschwinden, dann wieder kommen und das Häcken bei "InfluxDB aktivieren" nicht gesetzt wird.

Auf der "Allgemein" Seite hab ich "nicht konfigurierte NAchrichten löschen" nicht gesetzt.

Ich werde das weiter beobachten.

Blöde Frage, wie setze ich das LOG auf debug ?

[crycode]

@zmaier Bei den Instanzen den Expertenmodus aktivieren, dann in der Spalte "Log-Stufe" auf "info" klicken und "debug" auswählen.

Wenn der Haken für die InfluxDB verschwindet, dann deutet das darauf hin, dass das Objekt neu erzeugt wurde, was ja auch zu deinem beschriebenen Verhalten passt.

Was mir spontan noch einfällt: Hast du vlt. die Nachrichten-ID doppelt angelegt? Aktuell prüft der Adapter nicht auf doppelt angelegte IDs, aber diese könnten zu einem unerwarteten Verhalten führen.

[crycode]

@zmaier Hast du irgendwelche aktuellen Infos dazu oder hast du das Problem inzwischen gefunden?

[zmaier]

@crycode : Sorry für die späte Rückmeldung - ich hab in den letzten Tagen den Innenputz bekommen - leider hab ich grad keine Zeit für mein Heizungsspielerein
Ich werde mich aber, wenn die Zeit hoffentlich bald mal wieder da ist, melden und mir das Thema genauer anschauen.

DANKE
Martin

[crycode]

Im Latest-Repo ist jetzt die v1.0.0-beta.6 verfügbar.

In dieser Version wurde ein Fehler bei der Erstellung der Objekte behoben und eine Prüfung auf doppelt konfigurierte Nachrichten hinzugefügt.

[cb187]

Hallo ich würde gerne meine Rotex Wärmepumpe darüber einbinden.Diese unterstützt can.Zur Zeit verwende ich ein fhem Modul HPSU und bringe dieses nach IO.Würde es aber gerne mit diesem Adapter direkt ohne fhem abfragen und auch schreiben können.Ist das mit diesem Möglich und kann mir da geholfen werden?

[crycode]

@cb187 Generell musst du dafür wissen welche Datenpakete (Nachrichten) auf dem Bus gesendet werden und in welcher Form die Daten dabei kodiert sind.

Als fiktives Beispiel:
Nachricht mit der ID 0x042 ist die aktuelle Temperatur mit 4 Datenbytes als Float Zahl.

Wenn du diese Informationen für alle benötigten Nachrichten hast, dann kannst du die Nachrichten entsprechend im Adapter anlegen und Parser konfigurieren, die dann die eigentlichen Daten lesen und schreiben können.

[cb187]

@crycode ok ich hab nen usb to can interface ist dieses auch möglich?

[crycode]

@cb187 Solange dir das ein "echtes" CAN Interface im System erzeugt (z.B. can0) sollte das funktionieren.

Das kannst du recht einfach mit der Eingabe von ip a in einem Terminal prüfen. Die Ausgabe sollte u.a. etwas ähnlich folgendem beinhalten:

3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
    link/can

[cb187]

@crycode leider zeigt er mir can0 nicht an.Ist ein USBtocan interface vom auto.Hab auch die utils installiert.In fhem wird er gefunden

[crycode]

@cb187 Diese Interfaces nutzen meistens den ELM327 Chip, der leider kein echtes CAN-Interface für den Kernel bereitstellt, sondern eigene AT-Befehle zur Kommunikation nutzt. Zudem reicht er (soweit ich weiß) die CAN-Nachrichten nicht einfach durch, sondern ist eher für Diagnoseabfragen bei Autos gedacht. Die Performance soll auch nicht so das wahre sein.

Was du brauchst wäre z.B. ein CAN Hat für den Raspberry Pi mit einem MCP2515 CAN-Controller.

Das lässt sich sogar relativ einfach selbst bauen: https://crycode.de/can-bus-am-raspberry-pi

[cb187]

@crycode ich weiss das meine Rotex WP Can benutzt, über fhem und dem elm interface funzt es.Naja da muss ich das erstmal über fhem weiternutzen.

[crycode]

@cb187 Ich nehme an, du meinst dieses FHEM Modul? Das ist extra für die Nutzung zusammen mit dem ELM327 gebaut.
Der ioBroker.canbus Adapter hingegen basiert auf SocketCAN und greift somit direkt auf Funktionen des Kernels zu.
Ich habe noch einen Linux SocketCAN driver for ELM327 auf GitHub gefunden. Vielleicht hilft dir der schon weiter?

Generell kann ich mir vorstellen, auch eine Funktion mit ELM327 in den Adapter einzubauen, jedoch fehlt mir dafür aktuell die entsprechende Hardware.