Neues Modul: CanOverEthernet

[Stephanz]

Hallo Martin,
du hast Recht.
Ich habe auch noch eine UVR610 im Bus, da kommt es richtig an.
Danke!

[JuergenNiessen]

Die Knotennummer muss die vom UVR sein, die auch im Notify angegeben ist. Also 2. Ausgangsnummer ist 7.
Für diesen Anwendungsfall muss am CMI überhaupt nichts konfiguriert werden und außer mittels der IP im Notify auch nicht berücksichtigt werden.

Jetzt habe ich es auch geschafft. Ich hatte als Knoten in der UVR die 6 eingegeben, da ich folgendes definiert hatte:

Code Auswählen Erweitern

defmod COE_Node_cmi_6 COE_Node 6
Aber das Eine hat mit dem Anderen ja gar nichts zu tun.

Und ja, eigentlich braucht jeder ein ein EZ-3, das Ding ist echt cool

[delMar]

Jetzt habe ich es auch geschafft. Ich hatte als Knoten in der UVR die 6 eingegeben, da ich folgendes definiert hatte:

Code Auswählen Erweitern

defmod COE_Node_cmi_6 COE_Node 6
Aber das Eine hat mit dem Anderen ja gar nichts zu tun.

Freut mich, wenns nun funktioniert.

Hast du noch Fragen zwecks besserem Verständnis? Dann ruhig raus damit

[JuergenNiessen]

Freut mich, wenns nun funktioniert.

Hast du noch Fragen zwecks besserem Verständnis? Dann ruhig raus damit

Wenn ich nun den "eigenen Ausgang" auf den "eigenen Eingang lege" sollte ich doch drauf achten, dass der Ausgang nicht schon anderweitig belegt ist, oder?

[delMar]

Wenn ich nun den "eigenen Ausgang" auf den "eigenen Eingang lege" sollte ich doch drauf achten, dass der Ausgang nicht schon anderweitig belegt ist, oder?

Ich bin nicht sicher, ob ich die Frage richtig verstehe. Aber ja, wenn man bereits verwendete Ein- oder Ausgänge mehrfach verwendet, dann wird ständig der Wert überschrieben werden.
Du kannst gern auch ein konkretes Beispiel nennen.

[JuergenNiessen]

Ich bin nicht sicher, ob ich die Frage richtig verstehe. Aber ja, wenn man bereits verwendete Ein- oder Ausgänge mehrfach verwendet, dann wird ständig der Wert überschrieben werden.
Du kannst gern auch ein konkretes Beispiel nennen.

Ich bin jetzt wieder ein Stück weiter:

Nach dem Neustart der C.M.I sieht das bei mir aus, wie in Bild 1.

Nachdem ich folgendes ausgeführt habe

Code Auswählen Erweitern

set cmi sendDataAnalog 172.19.10.70 25 5=100;;1 6=100;;1 7=100;;1 8=100;;1

sieht das dann so aus, wie in Bild 2.

Es wurde ein virtueller Knoten 25 angelegt. Von diesem Knoten kann ich dann auch die Werte auf den Ausgängen 5 bis 8 abgreifen.

Fündig geworden bin ich u.a hier:

https://help.ta.co.at/DE/CMIHELP/coe____can_over_ethernet_.htm#

Da wird beschrieben, wie zwei C.M.I.s untereinander kommunizieren. Dort steht auch unter 6.:

Im CAN-Netzwerk des Empfangs-C.M.I. darf diese virtuelle Knotennummer nicht bereits vergeben sein, auch nicht für das Empfangs-C.M.I. Es dürfen mehrere virtuelle Knotennummern für ein C.M.I. vergeben werden.

Weiter hat mir auch dies geholfen:

https://github.com/thhoe/coe-mi/blob/master/coe/COE_Doku.pdf

und das dort beschriebene "udp test tool 3.0"

[Stephanz]

Das mit dem virtuellen Knoten muss ich unbedingt noch ausprobieren.

Wenn ich nun den "eigenen Ausgang" auf den "eigenen Eingang lege" sollte ich doch drauf achten, dass der Ausgang nicht schon anderweitig belegt ist, oder?

Jürgen meint folgendes:
Im CanOverEthernet übertrage ich einen Wert an eine UVR, beispielsweise ist die Knoten 5, und ich will den Wert am CAN-Digitaleingang 1 auslesen. Also gebe ich im FHEM nach der CMI-IP 5 1 an.
In der UVR richte ich mir den CAN-Digitaleingang 1 ein. Als Absender gebe ich Knoten 5 Digitalausgang 1 ein.
Wenn ich jetzt aber den CAN-Digtitalausgang 1 an dieser UVR schon für etwas andres programmiert habe, gibt es sicher einen Konflikt, weil es den quasi 2mal gibt: Als Ausgang vom CanOverEthernet und als Ausgang von der UVR.
Wenn man aber einen virtuellen Knoten haben könnte, an den man per CanOverEthernet Werte schickt, und den man mit der UVR abfragt, gibt´s keine Konflikte.
Das Ganze läuft bei mir zwar, aber ich habe immer wieder Probleme, die UVR610 zwecks Datenübertragung zu erreichen. Die fehlt dann ganz einfach im CMI in der Liste der möglichen Knoten, für die eine Datenübertragung möglich ist.
Außerdem meldet das CMI seitdem ab und zu, dass das Datenlogging gestört ist. Hängt sicher auch damit zusammen.
Ich probiere das aus und melde mich.

[delMar]

Also:
Das CMI bleibt auf CAN-Knoten Ebene beim Senden von Daten komplett außen vor.
Das sendDataAnalog/Digital enthält ja die IP-Adresse vom CMI. Damit wird sichergestellt, dass ein Wert am CMI ankommt.
Das CMI broadcastet den per LAN empfangenen Wert dann im CAN-Bus.
Jedes Gerät, das an diesem Wert interessiert ist, kann ihn abgreifen.

Beispiel:
Mein CMI ist #1. meine UVR ist #16.
Meine Wärmepumpe hat zB nur RS232. Die Werte lese ich mit FHEM aus.
Für die WP hab ich mir die Node ID 3 überlegt. (Die ist nur virtuell, da es ja kein echtes CAN Gerät ist, sondern bloß ein FHEM-Device)

Will ich einen Wert der WP (die per RS232 gelesen wurde) ans UVR senden, sende ich sendDataAnalog <IP> 3 1=<wert>;;1

Das CMI schreit nun per CAN-Bus (nicht per LAN) ganz laut: ,,Ich habe Daten von Absender 3 auf Kanal 1"
In der UVR konfiguriere ich nun CAN-Analogeingang 3, Kanal 1 und kann so mit diesem Wert arbeiten.

Man sendet also Werte immer mit der Absender-Node-ID in den Bus. Jeder, der an dem Wert interessiert ist, konfiguriert ihn sich als Analog Eingang.
Ist das Verständlich?

Nochmal anders formuliert: Werte werden nicht an einen bestimmten Empfänger gesendet, sondern Werte werden mittels Absenderadresse für alle verfügbar gemacht.

LG
Martin

[Stephanz]

Genau!
Und so funktioniert das jetzt bei mir auch:
CMI ist Knoten 1.
Heizungssteuerung ist die 2.
Wärmepumpensteuerung ist die 3.
CanOverEthernet ist die 4.
Ich schicke also in FHEM meine Daten über die IP des CMI an Knoten 4, den es ja im Grunde genommen körperlich gar nicht gibt. Und in jedem der anderen Knoten kann ich mir jetzt einen CAN-Eingang einrichten, mit dem ich mir die Daten vom Knoten 4 abhole.
Einfach genial!

[delMar]

Genau genommen schickst du nicht "an" 4.
Sondern du veröffentlichst den Wert "von" 4

Schön, wenns nun klappt

[chunter1]

Bräuchte Hilfe beim DOIF zum Senden zweier Temperaturwerte an eine UVR16x2.

Mein DOIF schaut wie folgt aus:

([T_WZ:temperature] or [T_BAD:temperature])
({
fhem("set CMI sendDataAnalog 192.168.1.100 3 1=".(sprintf("%.1f",ReadingsVal('T_WZ','temperature','0'))).";;;;1 2=".(sprintf("%.1f",ReadingsVal('T_BAD','temperature','0'))).";;;;1")
})

Die Werte kommen einwandfrei bei der UVR16x2 an, allerdings erhalte ich im DOIF ein Reading "error" in dem folgendes steht:

{ fhem("set CMI sendDataAnalog 192.168.1.100 3 1=".(sprintf("%.1f",ReadingsVal('T_WZ','temperature','0'))).";;;;1 2=".(sprintf("%.1f",ReadingsVal('T_BAD','temperature','0'))).";;;;1") }: 1

Ist hier eigentlich gar nichts falsch außer dass eine "1" retourniert wird und DOIF dies als Fehler interpretiert?
Wäre für eine saubere Lösung dankbar.

[delMar]

Hallo,

Wäre für eine saubere Lösung dankbar.

Sorry, mit DOIF hab ich leider auch so meine liebe Not

In diesem Fall find ich aber tatsächlich, dass ein Notify keinen Nachteil bietet und auch sehr sauber ist.

Code Auswählen Erweitern


defmod nfySendCoeAnalog notify
    heatpump:Hzg-TempRlSoll:.*|HM_Temp_Lounge:temperature:.*|HM_Temp_Groundfloor:temperature:.*
    set coe sendDataAnalog 192.168.4.250 3
        1={(ReadingsVal("heatpump","Hzg-TempRlSoll","23.5"))};;1
        2={(ReadingsVal("HM_Temp_Lounge","temperature","22.0"))};;1
        3={(ReadingsVal("HM_Temp_Groundfloor","temperature","22.0"))};;1


Zur besseren Lesbarkeit hab ich hier Zeilenumbrüche eingefügt.
Da hier ausschließlich mit unbehandelten Events und Readings gearbeitet wird, kommt keiner der Vorteile von DOIF zum Tragen.

Da ich mit DOIF  nie glücklich geworden bin, kann ich dir leider nur eine Alternative vorschlagen.
Fragen zu DOIF selber wären im dortigen Forum besser aufgehoben.

Hoffe, dass ich dir trotzdem helfen konnte

schöne Grüße
Martin

[chunter1]

Danke für die Rückmeldung.
Hab in der Zwischenzeit die error Meldung gelöst indem ich statt der standardmäßig retournierten "1" explizit eine "0" mittles Anhängen von ";; 0" zurückgebe.

Der Code meines DOIF schaut also jetzt so aus und funktioniert:

Code Auswählen Erweitern

([T_WZ:temperature] or [T_BAD:temperature])
({
fhem("set CMI sendDataAnalog 192.168.1.100 3 1=".(sprintf("%.1f",ReadingsVal('T_WZ','temperature','0'))).";;;;1 2=".(sprintf("%.1f",ReadingsVal('T_BAD','temperature','0'))).";;;;1");; 0
})

[delMar]

Danke, dass du dein Problem hier noch aufgelöst hast.
Ich werd das DOIF auch als Beispiel auf die Wiki Seite geben.

schöne Grüße
Martin

[delMar]

Hallo zusammen,

Wer an der Abfrage der Ausgangs-Stati interessiert ist (Hand-Ein, Auto-Aus, etc), wird vielleicht im "Schwestermodul" zu diesem hier ein neues Feature ganz nützlich finden.

Wie im Wiki (https://wiki.fhem.de/wiki/TA_CMI_UVR16x2_UVR1611) beschrieben, kann FHEM nun über dieses Modul auch den Status der Ausgänge anzeigen.
Am Spannendsten daran ist wohl, dass die Abfrage nicht auf einmal pro Minute beschränkt ist (wie die offizielle API), sondern auch im Abstand weniger Sekunden funktioniert.
Für mich eine sinnvolle Ergänzung zu diesem Modul, um zB im FTUI die Ausgangsstati zu zeigen.

schöne Grüße
Martin