TA Daten über CAN-Bus lesen/schreiben

[Rudi86]

Ich wollte mal meine Erkenntnisse der letzten Tage mit euch teilen.

Die Verbindung vom C.M.I. per Modbus mit ioBroker wurde hier ja schon behandelt. Da gibt es aber durchaus Einschränkungen und ich finde es auch teilweise etwas umständlich.

Ich habe es jetzt nach längerem probieren geschafft den CAN-Bus auszulesen (also theoretisch auch kein CMI notwendig!). Was man dazu braucht ist der canbus Adapter von crycode und die entsprechende Hardware.

Problem dabei ist, dass der Adapter das genutzte CANopen-Protokoll nicht kennt, das wäre auch zu kompliziert zu programmieren glaube ich. Aber das macht nichts, das Protokoll verschlüsselt nichts.

Um jetzt einen Wert zu lesen müssen wir die Adresse vom Sender kennen und wir brauchen etwas wissen darüber wie der Bus arbeitet.

In TA wird ein Wert zum senden angelegt, z.B. am Knoten 6 Ausgang 1.
Das entspricht dann der Nachricht 206 im ioBroker. In dieser Nachricht sind die Werte 1-4 vom Knoten enthalten. Woher man das weiß erkläre ich weiter unten.
Es sind immer vier unsigned integer 16 bit little endian (uint16LE) in einer Nachricht. Ihr legt euch jetzt also im Adapter die Nachricht an und vier Parser dazu:
Einzustellen ist hier die Nachrichten-ID (206), optional die Datenlänge (8), Häkchen nur bei Empfangen, die Namen, Parser-IDs, Einheit etc. könnt ihr frei wählen.
Im Parser noch wichtig der Datentyp ist uint16 LE, das Offset ist 0, 2, 4 und 6 (1.-4. Wert vom Knoten), die Länge immer 2. Wenn der Wert eine Kommastelle hat könnt ihr auch den Datentyp auf "custom" stellen und im Skript zum lesen "value = buffer.readInt16LE(4) / 10;" (geteilt durch 10 für eine Nachkommastelle). Die Zahl in Klammern ist das Offset (hier also 3. Wert)

Im Objektbaum seht ihr dann folgendes:

Die TA-Geräte (zumindest die x2-Regler) können 32 analoge und 32 digitale Werte senden. Wir brauchen also insgesamt 8 Nachrichten um alle analogen Werte zu nutzen und müssen die entsprechenden Adressen (Hexadezimal!) dazu kennen.
Die erste Nachricht berechnet sich wie folgt:
Hex-Wert von Knoten + 512. Bzw. Direkt in Hex Knoten + 0x200. Also hier 6 + 512 = 518. Hex davon ist 0x206.
Jede weitere Nachricht ist um 0x80 verschoben (also in meinem Beispiel am Knoten 6 dann 0x286, 0x306, 0x386). Danach geht es weiter mit Knoten + 576 (0x240) = 0x246 (=> 0x246, 0x2C6, 0x346, 0x3C6).

Ihr müsst nicht alle Nachrichten und Parser im ioBroker anlegen, nur die die ihr auch braucht.

Für digitale Werte läuft das etwas anders. Wir brauchen hier nur noch eine Nachricht pro Knoten. Die Adresse ist KnotenNr + 0x180, in diesem Fall also 0x186. Die Parser sehen wie folgt aus:

Die ersten 8 Werte haben das Offset 0 und das Häkchen bei Bitmaske rutscht immer eins weiter (immer nur 1 Häkchen pro Wert). Der Wert 9 hat dann das Offset 1 und wir fangen wieder beim linken Häkchen an. Der Wert 32 hat dann also Offset 3 und das letzte Häkchen ist gesetzt.

Auch hier reicht es nur die Parser anzulegen die man braucht. Ich habe mir 1x alle Parser nur mit Nummern angelegt und kann die so mit der Copy&Paste funktion vom Adapter auf alle Knoten kopieren.

Senden geht auch!
Wir suchen uns einen Knoten aus der im Bus nicht belegt ist, sonst würden unsere Daten eventuell überschrieben. Ich habe mich für Knoten 15 entschieden.
Beim Empfänger legen wir einen neuen Eingang an:

Also Knoten 15 / Wert 1. Die Adressen sind zum senden die gleichen (in der Doku zu CANopen ist das anders beschrieben). Also 15 in Hex ist 0xF + 0x200 = 20F. Dann legen wir mal im ioBroker eine Nachricht an:

Diesmal nicht "Empfangen", sondern "Senden" und "Automatisch senden" anklicken. Einen Parser anlegen wie gehabt. Achtung wir können keine Kommas senden. Also eventuell wieder mit Custom und diesmal dann eben mit 10 multiplizieren (zum senden im Feld rechts!). Das Script ist dann value = value * 10; buffer.writeInt16LE(value, 0);

Beim Empfänger dann entsprechend die Messgröße einstellen ("dimensionslos ,1" oder "Temperatur" sind mit einer Nachkommastelle.

Jetzt kann man das entsprechende Objekt in ioBroker schreiben und der Wert kommt beim TA-Gerät an. Eine eventuelle Warnmeldung, dass ein Knoten nicht bekannt ist verschwindet mit dem ersten Wert.

[Edit]
Schreiben digital habe ich vergessen. Das geht ganz einfach. Für unseren Knoten 15 ist das die Nachricht 18F (0x180 + 0xF). Ansonsten wie oben (Bit für Bit einen Parser anlegen) und Senden statt Empfangen.

[/Edit]

Ich hoffe mal das hilft nicht nur mir sondern auch noch anderen.

Bei Fragen zu diesem Thema könnt ihr euch gerne melden.

MfG
Rudi

[Edit 2]
OK, ich habe mal hohe Ausgänge getestet. Es scheint als wären die Werte für 17-32 nicht dort wo ich angenommen hatte sondern bei Knoten + 0x240 und folgende (richtig wäre also 0x246, 0x2C6, 0x346, 0x3C6)
[/Edit]

[drrrz]

Hi Rudi,

dein Post hier hat mir bei meinen Abenteuern mit dem CAN-Bus und TA-Geräten extrem weitergeholfen. In der Tat konnte ich so die Basis-Adresse der PDOs herausfinden über die TA-Geräte Daten auf dem CAN-Bus zur Verfügung stellen.

Ich habe nun folgendes Problem. Mit einem Firmware-Update hat TA offiziell das Datenformat am CAN-Bus geändert. Es werden nun 4 Byte statt 2 Byte genutzt, was die Auflösung erhöht. Seit diesem Update gehen die Basis-Adresse nicht mehr. Es gibt auf dem CAN-Bus keine Nachrichten mehr von, z.B., 0x200 + Node ID. Stattdessen scheint es eine neue Basisadresse 1C0 zu geben. Dort finde ich zwar Daten, die ich auf die Ausgänge gelegt habe, wieder, aber das Format der Ausgabe verstehe ich nicht. Statt einer Ausgabe von allen Werte auf einmal, scheint das x2 Gerät (ein EZ3A um genau zu sein) jetzt über die eine Basis-Adresse zyklisch und nacheinander die Werte der Ausgänge auszugeben.
Lange Rede kurzer Sinn: hast du ein x2-Gerät mit neuer Firmware und konntest beobachten, dass dein Ansatz nicht mehr funktioniert? Falls ja, hast du einen Workaround gefunden?

Danke und viele Grüße!

[Rudi86]

@drrrz Ich habe mich tatsächlich beim Lesen der Releasenotes erstmal gegen das Update entschieden, obwohl ich sogar Werte hätte die ich aktuell nicht übertragen kann weil die 4 Byte benötigen (Zählerstände).

Aktuell kann ich eh nicht vernünftig Updaten, scheinbar ist mein CMI defekt (war zuerst ganz Tot und nach abstecken vom Netzteil und neustart findet es keine Knoten mehr).

Kannst du mal einen längeren Dump posten in dem die Daten mindestens 1x wiederholt werden und einen erwarteten (oder besser mehrere) Werte dazu?

[drrrz]

@rudi86 Danke für die schnelle Antwort.

Hier ein Ausschnitt. Leider habe ich nicht mehr alle Werte im Kopf, die ich erwarte, da ich meinen Sniffer erst mal wieder abgebaut habe (Kabel vom Keller eine Etage hoch hat nicht viel Sympathien gefunden). Im Zweifelsfall kann ich natürlich noch mal ein neues Log erzeugen.

Meine beiden Nodes sind 40 (EZ3A) 56 (CMI).

0x1e8 (1C0 + 40) ist die neue Basisadresse - 88 59, gleich in der ersten Nachricht ist ein Spannungswert (Netzspannung in Volt). Es sind noch weitere Ausgänge belegt aber wie man sieht, scheint die neue Firmware die definierten CAN-Ausgänge zyklisch in das PDO zu schreiben. Die Werte sind jetzt INT32, d.h. zwei Werte werden in dem PDO übertragen. Der erste Block scheint irgendeine ID zu sein und der zweite Block enthält den eigentlichen Nutzwert. Meine Hypothese ist, dass die ID zur Zuordnung benutzt wird.

0x678 und 5f8 kann man ignorieren, dass sind SDO requests und responses, weil ich nebenbei auf der CMI via Webinterface unterwegs war.

0x738 und 728 sind die Heartbeats von Node 40 und 56.

Ich habe nebenher auch eine Anfrage bei TA direkt laufen, sollte ich da eine Antwort bekommen, poste ich sie hier.

Experimentiert habe ich auch, ob ich die alten PDOs mit einer RTR-Nachricht triggern kann - hat nicht funktioniert. Ich habe auch die CMI aus dem CAN-Netz genommen, da laut der Release-Notes das neue Format nur verwendet wird, wenn es alle Teilnehmer verstehen - das hat leider auch nicht geholfen. Ich würde vermuten, dass es irgendeinen Schalter für das alte Format gibt, den man per SDO triggern kann aber ohne konkreten Index finde ich das nicht raus.

Nochmals vielen Dank!

11:48:50.165 1 0x1e8 STD Rx 8 02 3F 0D 00 88 59 00 00
11:48:51.258 1 0x678 STD Rx 8 40 E2 57 00 00 00 00 00
11:48:51.258 1 0x5f8 STD Rx 8 41 E2 57 00 0A 00 00 00
11:48:51.258 1 0x678 STD Rx 8 60 00 00 00 00 00 00 00
11:48:51.268 1 0x5f8 STD Rx 8 00 61 DC AD 67 00 00 00
11:48:51.268 1 0x678 STD Rx 8 70 00 00 00 00 00 00 00
11:48:51.268 1 0x5f8 STD Rx 8 19 00 00 00 00 00 00 00
11:48:52.060 1 0x738 STD Rx 1 05
11:48:52.060 1 0x738 STD Rx 8 05 8A 01 01 00 00 00 00
11:48:54.569 1 0x728 STD Rx 1 05
11:48:54.571 1 0x728 STD Rx 8 05 8F 01 01 9D 9B 9D 91
11:48:54.575 1 0x1e8 STD Rx 8 01 06 2C 2C 2B 2B 2B 2B
11:48:54.621 1 0x1e8 STD Rx 8 02 02 0D 00 B0 59 00 00
11:48:56.258 1 0x678 STD Rx 8 40 E2 57 00 00 00 00 00
11:48:56.262 1 0x5f8 STD Rx 8 41 E2 57 00 0A 00 00 00
11:48:56.264 1 0x678 STD Rx 8 60 00 00 00 00 00 00 00
11:48:56.267 1 0x5f8 STD Rx 8 00 66 DC AD 67 00 00 00
11:48:56.269 1 0x678 STD Rx 8 70 00 00 00 00 00 00 00
11:48:56.272 1 0x5f8 STD Rx 8 19 00 00 00 00 00 00 00
11:48:57.586 1 0x1e8 STD Rx 8 02 01 0D 00 9C 59 00 00
11:49:01.257 1 0x678 STD Rx 8 40 E2 57 00 00 00 00 00
11:49:01.259 1 0x5f8 STD Rx 8 41 E2 57 00 0A 00 00 00
11:49:01.262 1 0x678 STD Rx 8 60 00 00 00 00 00 00 00
11:49:01.264 1 0x5f8 STD Rx 8 00 6B DC AD 67 00 00 00
11:49:01.264 1 0x678 STD Rx 8 70 00 00 00 00 00 00 00
11:49:01.264 1 0x5f8 STD Rx 8 19 00 00 00 00 00 00 00
11:49:01.659 1 0x1e8 STD Rx 8 02 3F 0D 00 D8 59 00 00
11:49:02.328 1 0x738 STD Rx 1 05

[Rudi86]

Etwas mehr Daten wären schon gut.
Was mir auffällt alle Spannungen (also alles was als Wert der letzten 4 Byte einen I32 LE ca. 23000 = 230 Volt zurück gibt) hat im 6. Byte 0D und im 5. Byte 00. Dann gibt es noch eine weitere Nachricht die hat 2C 2C. Könnte eines davon oder beides Zusammen eine Adresse sein?

Ich hatte zum Testen immer Fixwerte definiert damit man eben solche kleinen Schwankungen nicht hat und dann mehrere Ausgänge mit unterschiedlichen Werten beobachtet und dann auch mal den Wert geändert und verglichen.

[drrrz]

@rudi86 Ich baue mir mal eine „Steuerung“ mit Fixwerten 1-64 für Ausgänge 1-64 und schneide dann den Traffic mit. Wird etwas dauern, ist arg fricklig, selbst mit TAPPS2.

[drrrz]

@rudi86

Hi Rudi, anbei ein dump mit den CAN-Ausgängen 1 bis 64, die korrespondierend mit den Werten 1 bis 64 belegt sind. Wenn ich die Ausgabe vom TPDO richtig interpretiere, dann zeigt Byte 2 den Ausgang (0-63) und Byte 4 (vermutlich 4 bis 8 ) den Wert an. Das würde meine initiale Vermutung bestätigen, dass nicht mehr jeder Ausgang fix einem TPDO zugeordnet ist, sondern nur noch ein TPDO existiert, dass "bedarfsweise" (nach Wertänderung oder per eingestellter Aktualisierungsrate, z.B. 1 Minute) mit Ausgangsnummer und entsprechenden Wert befüllt und übertragen wird. Das ist natürlich ein netter Trick, um die Übertragung von 4 Byte breiten Werten und faktisch unendlich vielen Ausgängen zu ermöglichen, aber macht jedes Skript kaputt, was auf der vorhergehenden statischen Adressierung beruht.

Von TA habe ich noch keine Antwort erhalten. Ich habe immer noch Hoffnung, dass man das alte Verhalten irgendwie erzwingen kann. Ansonsten muss ich dauerhaft zurück zur 1.29.

can_dump.txt

HINWEIS: Nach Durchsicht ist mir aufgefallen, dass manche Ausgänge nicht oder nicht korrekt belegt waren, das ist kein Fehler im Log. Die Ausgänge sollten eigentlich 1:1 mit dem TA-Ausgang entsprechendem Zahlenwert belegt sein aber scheinbar habe ich da ein paar Fehler eingebaut.

[Rudi86]

OK...

Zuerst dachte ich das geht mit dem CAN-Adapter, der gibt das aber leider nicht her.

Probier bitte mal folgendes:

1. Im CAN-Adapter den Knoten anlegen
   

2. Im Javascript-Adapter die Funktion setObject erlauben
   

3. Folgendes Script erstellen (ich arbeite gerne mit Blockly, geht aber in diesem Fall leider nicht 100%)
   

Das Objekt "CAN_Test" habe ich angelegt zum testen, das musst du ersetzen mit dem json-Objekt vom Knoten.

Der Code der beiden Funktionen:

create_update

let objectName = '0_userdata.0.canbus.40.' + obj;
if(!existsState(objectName)){
    await extendObject(objectName, {type: 'state', common: {name: 'test', type: 'number', role: 'value'}}, function() {
        setState(objectName, value);
    });
} else {
    setState(objectName, value);
}

wert_berechnen

b1_hex = b1.toString(16);
b2_hex = b2.toString(16);
return parseInt(b2_hex + b1_hex, 16);

Oder als export:
CAN_Test.xml

Das Script sollte so laufen, wenn das klappt muss man die Funktion create_update noch erweitern um den CAN-Knoten damit man für einen neuen Knoten nur den Falls-Block kopieren muss...

[drrrz]

@rudi86

Vielen Dank für deine umfangreiche Antwort und Zeit, die du investiert hast.

Ich habe mittlerweile noch herausgefunden, dass Byte 3 der Typ der Daten ist, der übertragen wird.

Ich bin derzeit noch garnicht soweit, iobroker einzusetzen, da ich die Daten erst auf einer SPS sammle und dort weiterverarbeite und dann Richtung iobroker senden möchte.

Ich konnte deinen Code aber nutzen, um meine Steuerung zu programmieren und das funktioniert hervorragend. Ich kann das serialisierte Array welches von der EZ3 kommt wieder einlesen.

Derzeit versuche ich mich daran, Daten zu senden. Ein RPDO mit exakt gleichem Inhalt (außer geänderter Node ID) zu erzeugen, bzw. zu befüllen, klappt nicht. Da werde ich wohl noch mal auf dem CAN-bus zwischen CMI und EZ3 lauschen müssen. Ggfs. hat es was mit dem ersten Byte zu tun.

Der Support von TA hat mittlerweile geantwortet. Das neue Datenformat geben sie nicht heraus aber man kann wohl das Senden des alten Formats erzwingen, wenn man einen bestimmten Heartbeat sendet:

Zitat:

MSG-ID = 0x700 + Node ID (irgendeine Knotennummer die Sie in Ihrem Netzwerk nicht verwenden)
Frame/Size = 1
Daten = 5

Sobald ich Zeit habe, probiere ich das aus!

Ich melde mich, so bald ich mehr weiß.

[Rudi86]

Cool... Ich mache genau das beruflich (Eingänge auf über 200 SPSen sammeln, verarbeiten und an ein Leitstellensystem per IEC 104 senden). Was setzt du da für eine SPS ein?

[drrrz]

@rudi86

Ich habe erst vor ein paar Wochen auf Hobby-Ebene damit angefangen. Ich muss Daten von einem Wechselrichter abholen und zur Steuerung eines Heizstabs verwenden. Die CMI ist einfach zu unflexibel, da man dort nur einzelne ModBus-Register auslesen kann
Ich habe eine alte Wago SPS im Einsatz. Die 750-8204 kann CAN-Bus und Modbus RTU. Modbus TCP kann man einfach über einen der Ethernet-Porta nutzen, grandios. Bleiben halt die nicht unerheblichen Kosten für die Codesys-Runtime aber ich habe am Ende alles in einem Gerät.

Außerdem bringt mich ST zurück in die alten Pascal-Zeiten. Das Abrufen von Daten vom Modbus und weiterleiten auf den CAN-Bus ging fast ohne Code - mit dem neuen Format ist es etwa Arbeit.

An 200 SPSen würde mich allerdings nicht ran wagen - ST-Programmierung lasse ich mir derzeit von ChatGPT beibringen - ich denke, um
mehrere Steuerungen zu kontrollieren, reicht das Halbwissen nicht aus.

Zum Thema: den entscheidenden Hinweis, um Daten senden zu können, hat TA in seiner Antwort geliefert. Meine Ergebnisse:

Schreiben an die alten COB-IDs funktioniert weiterhin. Das halt den Nachteil, dass man nicht 4 Byte nutzen kann.

Das aktivieren des alten Sendeformats via eines Fake-Heartbeats habe ich nicht ausprobiert, da ich gleich einen Schritt weitergegangen bin.

Das Problem war, dass das Senden im neuen Format mit einer COB-ID, die physisch nicht existiert, nicht funktioniert. Also Absende-Node 15 - COB-ID 0x1cf - wird von den existierenden Nodes einfach ignoriert.

Lösung: ich kopiere die Heartbeat-Nachricht des EZ3 einfach mit neuer COB-ID auf den Bus und die CMI zeigt daraufhin einen weiteren EZ3 im CAN-Netz an und nimmt von diesem Fake-Node auch endlich wieder Nachrichten an.

Jetzt muss ich nur noch die Serialisierung des Arrays mit den 64 Daten-Punkten einigermaßen sinnvoll implementieren. Ich denke, ich werde einfach alle 500 ms das ganze Array auf den Bus schreiben, bevor ich jetzt anfange kompliziert auszulesen, welcher Wert, den ich übertragen will, geändert wurde.

Sollte mir dabei noch was irreguläres über den Weg laufen, würde ich es hier dokumentieren. Auf jeden Fall herzlichen Dank für die Zusammenarbeit, das war wirklich hilfreich!

[Rudi86]

Wäre FUP nicht einfacher? Das ist ja quasi fast genauso wie mit TAPPS.
Wir machen das Meiste in FUP, nur Dinge die sich mit minimalen Änderungen hundertfach wiederholen (z.B. Mapping von Ein/Ausgängen) sind in ST geschrieben.

[drrrz]

@rudi86

Ja, FUP habe ich mir angeschaut, aber das hat mich für den Anfang etwas erschrocken. Mit ST habe ich das Gefühl, mehr Kontrolle über den Code zu haben.

Aber ich habe ja noch einige Programmteile zu bauen, vielleicht schaue ich mir das noch mal an.

Habe mittlerweile auch das zyklische Senden nach Timeout oder bei Werte-Aktualisierung hinbekommen. Die Basisadresse für das eine verbleibende RPDO ist auch 0x1C0. Wenn man vom
„Fake“-Knoten 15 senden möchte also 0x1CF.

Mehr Schwierigkeiten sind mit derzeit nicht über den Weg gelaufen, bin hauptsächlich damit beschäftigt, den Code einigermaßen schön zu machen und meine ganzen Debug-Nachrichten und Haltepunkte zu entfernen

@Rudi86: nochmals herzlichen Dank, ohne deine Hilfe wäre ich nicht so weit gekommen!

[hamnx]

Hallo,
ich bin auf diesen Thread gestoßen, weil ich ähnliche Absichten habe - nämlich den TA-CAN mittels Wago Controller auszulesen, und die Werte an andere Schnittstellen weiterzugeben...
Ich stehe aber noch ganz am Anfang - ehrlich gesagt, habe ich noch nicht mal angefangen

Und ich möchte mich bei euch beiden für die Weitergabe euerer Erfahrungen bedanken - jetzt weiß ich zumindest dass es grundsätzlich Möglich ist, und ich diese Idee wahrscheinlich weiter verfolgen werde!

@drrrz Ich frag mal ganz direkt und unverschämt- wärst du eventuell bereit deinen Code hier zu teilen?

mfg
hamnx

[Jakob Stefan]

@rudi86 riesen großes DANKESCHÖN, habe schon eine schöne Weile herumgebastelt und versucht meine Heizungssteuerung (UVR67) etwas zu digitalisieren. Leider ist die Doku dazu etwas spärlich und auch von TA gabs keinen Support. Mithilfe deiner detaillierten Anleitung konnte ich nun ohne den Zusatzkosten einer CMI die Daten auf meinen Raspberry PI bekommen und in Node-RED weiterverwenden. Danke