UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[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

[Marcel Klug]

Hallo, ich habe mich mal fix angemeldet.
Ich bin 36 Jahre alt und komme aus der IT.
Ja ist blöd aber ich bräuchte mal eure hilfe. Ich habe eine UVR610K hier möchte ich über canbus messwerte bekommen und meine Pumpen verriegeln/entriegeln. Firmware ist die neuste drauf.
Das kommt über den canbus

{"id":"0x00000720","data":[5]}
{"id":"0x00000720","data":[5,145,1,1,244,236,77,53]}
{"id":"0x000001E0","data":[1,6,43,43,43,43,43,43]}
{"id":"0x000001A0","data":[0,0,0,0,0,0,0,0]}

Anbei habe ich mal noch meine Projektdatei mit angehangen
Doppelpumpe.tdw

Vielleicht kann mir mal jemand helfen. Das verstehe ich leider nicht richtig.

Mit Freundlichen Grüßen
PS: Vergessen. Sonst hängt nichts weiter auf dem canbus, außer mein ESP32 der als can <-> mqtt Brücke dient.

[philipphamid]

@jakob-stefan Hi Jakob, ich bastle auch schon eine Weile mit meiner UVR67 herum und scheitere daran die richtigen IDs bzw. Zuordnungen zu finden … kannst du vielleicht deinen Code zu Verfügung stellen?

[Jakob Stefan]

@philipphamid gerne, so gut ich kann:
also ich habe am Raspberry ein can0 interface aktiviert und dort alles eingestellt, damit die Kommunikation mit der UVR67 funktioniert. Danach mit der Anleitung über den ioBroker und der CAN Variablenliste auf der Steuerung verifiziert, welcher Datenpunkt mir was beschreibt. Anschließend habe ich in nodered auf meinem Raspberry die Daten vom CAN Bus abgehorcht und gleich die nicht benötigten Felder entfernt. Jetzt müssen diese aber noch auf meinen HomeAssistant, das mache ich via MQTT und dort werden die empfangenen Datenpakete wieder in nodered in Empfang genommen, gefiltert und den richtigen Datenpunkten zugeordnet, sodass diese dann auch angezeigt werden können. Parallel dazu habe ich das Heartbeat Signal noch als Watchdog in Verwendung

Ich habe mal die beiden nodered Flows exportiert und ein paar Screenshots mit dabei, hoffe das hilft, ansonsten gerne nochmal fragen.

UVR67.zip

LG Jakob

[noio]

Hallo , ich schliesse mich hier an......

Ich hab die CAN Kommunikation mit Raspberry PI und MPC2515 can Modul ins laufen gebracht.
Es läuft bei mir ohne CMI.
Leider ebenso das Problem mit der neuesten Firmware.....Bekomme keine sinnvollen Werte von den Analog und Digital Ein/Ausgängen....

LG noio

[noio]

Mit den Digitalen Ausgöngen bin jetzt weiter gekommen.

Sie werden mit der ID 181 übernommen.
Die Ausgänge 1-8 sind mit offset 0 verfügbar
Die Ausgänge 9-16 kommen mit offset 1 herein....

LG noio

[noio]

Hallo ,

Danke Jungs......jetzt hab ichs gerafft
Wenn manns richtig macht dann funzt es auch.......

Selber heard beaten dann gehts ab......🥰

can.log

canbus-messages.json

Learning by doing.........goes on

MFG noio

[noio]

Hallo ,

Als Ergänzung zum Eröffnungspost

Will man mehr als vier Datenpunkte , an die gleiche CAN Knotennummer ,übermitteln so steigt der HEX Wert der Sendeadresse um 80 ......

z.B.: Sendet man Daten an Konten 4 :

Datenwerte 1-4 an 204
Datenwerte 5-8 an 284
Datrnwerte 9-12 an 304
Datenwerte 13-16 an 384

und geht dann mit 17-20 mit 244 weiter....

Viel Spass
MFG

noio

[noio]

@Rudi86 sagte in TA Daten über CAN-Bus lesen/schreiben:

könnt ihr auch den Datentyp auf "custom" stellen und im Skript zum lesen "value = buffer.readInt16LE

"value = buffer.readUInt16LE()" wäre richtig , sonst kommt nichts vernünftiges raus, bei höheren Werten.....wie zB.: Betriebsstunden welche in Sekunden gesendet werden......

MFG
noio