Neues Modul: CanOverEthernet

[skan7526]

Danke dir Martin.

Hab dir mal Bilder meiner Config angehängt.
Ich habe eine UVR61-3 welche per DL mit dem CMI verbunden ist, und vom FHEM aus, frage ich die Daten per COE ab.

Daher auch DL Eingang definiert ( siehe Bild 1).
Damit die Daten überhaupt an FHEM geschickt werden habe ich diese beim Ausgang im CMI wie auf deinen Bildern entsprechend konfiguriert (Bild 2).

Leider fand ich keine andere Möglichkeit sonst Daten an FHEM zu schicken, geschweige denn überhaupt Daten im CMI sichtbar zu bekommen, da ich leider immer über die DL gehen muss.

Und genau da liegt anscheinend das Problem, wenn ich dich richtig verstanden habe, aufgrund einer fehlerhaften Konvertierung. Heißt ich werde mit dem Stand so leben müssen.

Viele Grüße und nochmal besten Dank
Holger

[delMar]

Ok, ich verstehe.

Ich werde mal die Anleitung deiner UVR studieren.
Vielleicht finde ich da eine Lösung.
Und ganz oft fällt mir auch was ein, wenn ich mal drüber schlafe :-D

Ich meld mich wieder.

Zusatz: deine UVR kann selber also garkein CoE, das kommt erst am CMI dazu.
Gut, das macht es aber einfacher.
Ich kann mir vorstellen, dass man generell den Gerätetyp per Attribut setzt.
Weil bei der UVR61-3 besteht das Problem ja dann bei ALLEN Werten.
Das generell dann aufgrund des Gerätetyps anders zu rechnen wäre nicht so schlimm.
Blöd fände ich, wenn man für jeden einzelnen Wert eine Korrektur konfigurieren müsste...
Ganz oft stellt sich dann beim Programmieren raus, dass es viel eleganter geht.
Ja, wie gesagt, ich melde mich.

LG

[delMar]

Ich hab die Lösung noch nicht implementiert, habe aber eine Idee, wie ich es machen werde und wollte hier kurz Bescheid geben:

ich werde wahrscheinlich ein zusätzliches Attribut dazugeben: readingsConfigAnalogDL
Da drin wird man dann die Werte definieren, die das CMI direkt über den DL-Bus kriegt.
Und so sollte ich richtig erkennen können, dass hier eine andere Formel angewendet werden muss.

Ich hoffe, morgen Abend die Zeit dafür zu finden

schöne Grüße
Martin

[skan7526]

Hi Martin,

das wäre echt super. Danke für alles.
Wenn es nicht geht, lebe ich mit dem was ich habe.

Bin schon gespannt.

Beste Grüsse
Holger

[hausbau_toel]

Hallo,

ich bin gerade dabei mir das Modul anzuschauen und auszuprobieren.
Hintergrund: Über das Modul "TA_CMI_JSON" kann, so wie ich es verstanden habe, gleichzeitig über das cmi nur eine UVR abgefragt werden und weiterhin gibt es die Begrenzung der API-Abfragen auf 60 sec. Ich möchte aber noch zusätzlich zu den Werten meiner UVR16x2 die Werte von meiner UVR1611 u. FRISTAR (Frischwasserstation) über cmi in fhem einlesen.

Jetzt habe ich das Modul ausprobiert und bekomme wie im cmi eingestellt alle 60 sec. die Werte lt. Logfile:

Code Auswählen Erweitern


2022.02.11 20:11:57 4: COE_Node (COE_Node_cmi_3) - Config found: 1=T_Kollektor_UVR1611
2022.02.11 20:11:57 5: COE_Node (COE_Node_cmi_3) - 1=T_Kollektor_UVR1611
2022.02.11 20:11:57 4: COE_Node (COE_Node_cmi_3) - [3][1][0][1][type=1][value=-2.6]  configured: T_Kollektor_UVR1611
2022.02.11 20:11:57 0: COE_Node (COE_Node_cmi_3) - [3][1][1][2][type=0][value=0]  2 not configured. Skipping.
2022.02.11 20:11:57 0: COE_Node (COE_Node_cmi_3) - [3][1][2][3][type=0][value=0]  3 not configured. Skipping.
2022.02.11 20:11:57 0: COE_Node (COE_Node_cmi_3) - [3][1][3][4][type=0][value=0]  4 not configured. Skipping.
2022.02.11 20:12:50 4: COE_Node (COE_Node_cmi_3) - Config found: 1=T_Kollektor_UVR1611
2022.02.11 20:12:50 5: COE_Node (COE_Node_cmi_3) - 1=T_Kollektor_UVR1611
2022.02.11 20:12:50 4: COE_Node (COE_Node_cmi_3) - [3][1][0][1][type=1][value=-2.8]  configured: T_Kollektor_UVR1611
2022.02.11 20:12:50 0: COE_Node (COE_Node_cmi_3) - [3][1][1][2][type=0][value=0]  2 not configured. Skipping.
2022.02.11 20:12:50 0: COE_Node (COE_Node_cmi_3) - [3][1][2][3][type=0][value=0]  3 not configured. Skipping.
2022.02.11 20:12:50 0: COE_Node (COE_Node_cmi_3) - [3][1][3][4][type=0][value=0]  4 not configured. Skipping.
2022.02.11 20:13:50 4: COE_Node (COE_Node_cmi_3) - Config found: 1=T_Kollektor_UVR1611
2022.02.11 20:13:50 5: COE_Node (COE_Node_cmi_3) - 1=T_Kollektor_UVR1611
2022.02.11 20:13:50 4: COE_Node (COE_Node_cmi_3) - [3][1][0][1][type=1][value=-2.8]  configured: T_Kollektor_UVR1611
2022.02.11 20:13:50 0: COE_Node (COE_Node_cmi_3) - [3][1][1][2][type=0][value=0]  2 not configured. Skipping.
2022.02.11 20:13:50 0: COE_Node (COE_Node_cmi_3) - [3][1][2][3][type=0][value=0]  3 not configured. Skipping.
2022.02.11 20:13:50 0: COE_Node (COE_Node_cmi_3) - [3][1][3][4][type=0][value=0]  4 not configured. Skipping.
2022.02.11 20:14:50 4: COE_Node (COE_Node_cmi_3) - Config found: 1=T_Kollektor_UVR1611
2022.02.11 20:14:50 5: COE_Node (COE_Node_cmi_3) - 1=T_Kollektor_UVR1611
2022.02.11 20:14:50 4: COE_Node (COE_Node_cmi_3) - [3][1][0][1][type=1][value=-2.8]  configured: T_Kollektor_UVR1611
2022.02.11 20:14:50 0: COE_Node (COE_Node_cmi_3) - [3][1][1][2][type=0][value=0]  2 not configured. Skipping.
2022.02.11 20:14:50 0: COE_Node (COE_Node_cmi_3) - [3][1][2][3][type=0][value=0]  3 not configured. Skipping.
2022.02.11 20:14:50 0: COE_Node (COE_Node_cmi_3) - [3][1][3][4][type=0][value=0]  4 not configured. Skipping.
2022.02.11 20:15:50 4: COE_Node (COE_Node_cmi_3) - Config found: 1=T_Kollektor_UVR1611
2022.02.11 20:15:50 5: COE_Node (COE_Node_cmi_3) - 1=T_Kollektor_UVR1611
2022.02.11 20:15:50 4: COE_Node (COE_Node_cmi_3) - [3][1][0][1][type=1][value=-2.8]  configured: T_Kollektor_UVR1611
2022.02.11 20:15:50 0: COE_Node (COE_Node_cmi_3) - [3][1][1][2][type=0][value=0]  2 not configured. Skipping.
2022.02.11 20:15:50 0: COE_Node (COE_Node_cmi_3) - [3][1][2][3][type=0][value=0]  3 not configured. Skipping.
2022.02.11 20:15:50 0: COE_Node (COE_Node_cmi_3) - [3][1][3][4][type=0][value=0]  4 not configured. Skipping.
2022.02.11 20:16:50 4: COE_Node (COE_Node_cmi_3) - Config found: 1=T_Kollektor_UVR1611
2022.02.11 20:16:50 5: COE_Node (COE_Node_cmi_3) - 1=T_Kollektor_UVR1611
2022.02.11 20:16:50 4: COE_Node (COE_Node_cmi_3) - [3][1][0][1][type=1][value=-2.8]  configured: T_Kollektor_UVR1611
2022.02.11 20:16:50 0: COE_Node (COE_Node_cmi_3) - [3][1][1][2][type=0][value=0]  2 not configured. Skipping.
2022.02.11 20:16:50 0: COE_Node (COE_Node_cmi_3) - [3][1][2][3][type=0][value=0]  3 not configured. Skipping.
2022.02.11 20:16:50 0: COE_Node (COE_Node_cmi_3) - [3][1][3][4][type=0][value=0]  4 not configured. Skipping.
2022.02.11 20:17:50 4: COE_Node (COE_Node_cmi_3) - Config found: 1=T_Kollektor_UVR1611
2022.02.11 20:17:50 5: COE_Node (COE_Node_cmi_3) - 1=T_Kollektor_UVR1611
2022.02.11 20:17:50 4: COE_Node (COE_Node_cmi_3) - [3][1][0][1][type=1][value=-2.8]  configured: T_Kollektor_UVR1611
2022.02.11 20:17:50 0: COE_Node (COE_Node_cmi_3) - [3][1][1][2][type=0][value=0]  2 not configured. Skipping.
2022.02.11 20:17:50 0: COE_Node (COE_Node_cmi_3) - [3][1][2][3][type=0][value=0]  3 not configured. Skipping.
2022.02.11 20:17:50 0: COE_Node (COE_Node_cmi_3) - [3][1][3][4][type=0][value=0]  4 not configured. Skipping.
2022.02.11 20:18:50 4: COE_Node (COE_Node_cmi_3) - Config found: 1=T_Kollektor_UVR1611
2022.02.11 20:18:50 5: COE_Node (COE_Node_cmi_3) - 1=T_Kollektor_UVR1611
2022.02.11 20:18:50 4: COE_Node (COE_Node_cmi_3) - [3][1][0][1][type=1][value=-2.7]  configured: T_Kollektor_UVR1611
2022.02.11 20:18:50 0: COE_Node (COE_Node_cmi_3) - [3][1][1][2][type=0][value=0]  2 not configured. Skipping.
2022.02.11 20:18:50 0: COE_Node (COE_Node_cmi_3) - [3][1][2][3][type=0][value=0]  3 not configured. Skipping.
2022.02.11 20:18:50 0: COE_Node (COE_Node_cmi_3) - [3][1][3][4][type=0][value=0]  4 not configured. Skipping.
2022.02.11 20:19:50 4: COE_Node (COE_Node_cmi_3) - Config found: 1=T_Kollektor_UVR1611
2022.02.11 20:19:50 5: COE_Node (COE_Node_cmi_3) - 1=T_Kollektor_UVR1611
2022.02.11 20:19:50 4: COE_Node (COE_Node_cmi_3) - [3][1][0][1][type=1][value=-2.7]  configured: T_Kollektor_UVR1611
2022.02.11 20:19:50 0: COE_Node (COE_Node_cmi_3) - [3][1][1][2][type=0][value=0]  2 not configured. Skipping.
2022.02.11 20:19:50 0: COE_Node (COE_Node_cmi_3) - [3][1][2][3][type=0][value=0]  3 not configured. Skipping.
2022.02.11 20:19:50 0: COE_Node (COE_Node_cmi_3) - [3][1][3][4][type=0][value=0]  4 not configured. Skipping.


Soweit funktioniert CoE zwischen cmi und fhem.
Ein Reading bekomme ich aber nur wenn sich der entsprechende Wert ändert:

Code Auswählen Erweitern


2022-02-11_20:02:47 COE_Node_cmi_3 T_Kollektor_UVR1611: -3.1
2022-02-11_20:07:57 COE_Node_cmi_3 T_Kollektor_UVR1611: -2.6
2022-02-11_20:12:50 COE_Node_cmi_3 T_Kollektor_UVR1611: -2.8
2022-02-11_20:18:50 COE_Node_cmi_3 T_Kollektor_UVR1611: -2.7
2022-02-11_20:28:00 COE_Node_cmi_3 T_Kollektor_UVR1611: -2.5


Gibt es irgendeine Möglichkeit, dass jedes mal, wenn der Wert vom cmi kommt bzw. bereitgestellt wird (also im Beispiel alle 60 sec), ein Reading generiert bzw. aktualisiert wird auch wenn der Wert sich nicht ändert?

Ich habe auch keine event-on-change oder event-min-interval oder ähnliches gesetzt.
Hier ein List des Device:

Code Auswählen Erweitern


Internals:
   DEF        3
   FUUID      6203f438-f33f-4fd1-21ec-4417756826f72f8b
   IODev      cmi
   LASTInputDev cmi
   MSGCNT     88
   NAME       COE_Node_cmi_3
   NR         34
   STATE      defined
   TYPE       COE_Node
   cmi_MSGCNT 88
   cmi_TIME   2022-02-11 20:47:58
   READINGS:
     2022-02-11 20:42:58   T_Kollektor_UVR1611 -2.2
     2022-02-11 19:06:12   state           defined
   helper:
     CAN_NODE_ID 3
Attributes:
   readingsConfigAnalog 1=T_Kollektor_UVR1611
   room       Z_CMI,COE_Node
   verbose    5



Danke u. Grüße

Stephan

UPDATE:
Frage hat sich erledigt - ich habe es gefunden. Mit der Änderung in 71_COE_Node.pm bekomme ich genau das verhalten wie ich es wollte:

Code Auswählen Erweitern


#      readingsBulkUpdateIfChanged( $hash, $reading, $value );
      readingsBulkUpdate( $hash, $reading, $value );


Stephan

[delMar]

Hallo Stefan,

Ich glaube, hier werden Events und Readings vermischt.

Das Reading solltest du kriegen, sobald das CMI etwas sendet.
Die Häufigkeit und ab welcher Änderung (zB ab 1 Grad unterschied zum letzten Wert, oder ab 0.1 Grad, etc) das CMI senden soll kannst du direkt dort im Web-Interface unter Einstellungen -> Ausgänge -> CoE -> Analog/Digital -> Sendebedingung einstellen.

Die Änderung, die du gemacht hast, sorgt dafür, dass mit jedem Wert, der eintrudelt, FHEM auch ein Event generiert, auf das du reagieren kannst.
Egal, ob es ein geänderter Wert ist, oder der selbe Wert wie vorher.

Mit event-on-update-reading solltest du das auch einstellen können, ohne das Modul verändern zu müssen.
Deine Änderung wird wahrscheinlich mit dem nächsten Update wieder überschrieben, weil FHEM bemerkt, dass du nicht auf der aktuellsten Version bist.
Das deine Version neueren Datums ist, zählt in diesem Fall nicht.

Code Auswählen Erweitern


attr COE_Node_cmi_3 event-on-update-reading .*


Der Grund, warum das nicht generell so gemacht wird, ist der, dass mit jedem Event auch ein Wert ins Log für die Charts geschrieben wird.
Dh wenn sich ein Wert eine Stunde lang nicht ändert, wird uU zb trotzdem jede Minute der selbe Wert geschrieben.
Und übers Jahr sammeln sich dann haufenweise Datenpunkte an, die nicht benötigt werden (Stichwort: Datensparsamkeit)

Wenn du aber keine Kurve zur Visualisierung zeichnen lässt, sollte das für dich irrelevant sein.

schöne Grüße
Martin

[hausbau_toel]

Hallo Martin,

herzlichen dank für die ausführliche Antwort.

Die Häufigkeit und ab welcher Änderung (zB ab 1 Grad unterschied zum letzten Wert, oder ab 0.1 Grad, etc) das CMI senden soll kannst du direkt dort im Web-Interface unter Einstellungen -> Ausgänge -> CoE -> Analog/Digital -> Sendebedingung einstellen.

Das habe ich genau so gemacht.

Die Änderung, die du gemacht hast, sorgt dafür, dass mit jedem Wert, der eintrudelt, FHEM auch ein Event generiert, auf das du reagieren kannst.
Egal, ob es ein geänderter Wert ist, oder der selbe Wert wie vorher.

Das war ja eigentlich mein Problem, dass ich Werte habe (z. Bsp. Warmasser-Solltemperatur, Gesamtenergie usw.) die sich stunden- u. teilweise tageweise nicht ändern, damit dann kein Event generiert wird und mir diese dann in Tagesplots fehlen, wo ich sie aber darstellen möchte.

Mit event-on-update-reading solltest du das auch einstellen können, ohne das Modul verändern zu müssen.

Code Auswählen Erweitern


attr COE_Node_cmi_3 event-on-update-reading .*


Das "event-on-update-reading" hatte ich nicht auf dem Schirm. Werde ich aber ausprobiern und übernehmen.

Deine Änderung wird wahrscheinlich mit dem nächsten Update wieder überschrieben, weil FHEM bemerkt, dass du nicht auf der aktuellsten Version bist.
Das deine Version neueren Datums ist, zählt in diesem Fall nicht.

Dass die Änderung beim Update überschrieben wird und ich die Änderung ggf. bei jedem Update nachziehen muss war bzw. ist mir klar.

Der Grund, warum das nicht generell so gemacht wird, ist der, dass mit jedem Event auch ein Wert ins Log für die Charts geschrieben wird.
Dh wenn sich ein Wert eine Stunde lang nicht ändert, wird uU zb trotzdem jede Minute der selbe Wert geschrieben.
Und übers Jahr sammeln sich dann haufenweise Datenpunkte an, die nicht benötigt werden (Stichwort: Datensparsamkeit)

"Datensparsamkeit" kenne und mache ich mit meinen Temperatursensoren. Die liefern kontinuierlich Readings (eben auch bei unveränderten Temperaturen) und mit  event-on-change-reading und  event-min-interval kann ich darüber gut steuern, was davon ins log-File kommt.

Nochmal vielen Dank u. Grüße

Stephan

[delMar]

"Datensparsamkeit" kenne und mache ich mit meinen Temperatursensoren. Die liefern kontinuierlich Readings (eben auch bei unveränderten Temperaturen) und mit  event-on-change-reading und  event-min-interval kann ich darüber gut steuern, was davon ins log-File kommt.

Ja, das kenne ich. Wenn man weit genug rein-zoomt in den Plot, fehlt plötzlich eine Linie.

Ach, und sorry für den Tippfehler bei deinem Namen in der Anrede 

Gib Bescheid, wenn event-on-update-reading nicht das gewünschte Ergebnis liefert

schöne Grüße
Martin

[trabantp60]

Halo Martin,

gibt es irgendwo eine Übersicht zu den manipulierbaren Fixwerten? Habe leider nichts gefunden.

Viele Grüße
Frank

Weiteres Update im Schwestermodul:
Fixwerte können nun direkt über API gesetzt werden, ohne den evtl. umständlichen Umweg über CanOverEthernet gehen zu müssen.
So müssen in Zukunft keine CAN-Kanäle mehr eingerichtet und belegt werden, nur um über FHEM bestimmte Parameter zu setzen.

https://forum.fhem.de/index.php/topic,92740.msg1141910.html#msg1141910

Da die Anzahl an CAN-Kanälen beschränkt ist, kann mit diesem Feature die CAN-Kommunikation wirklich auf die CAN-Geräte untereinander beschränkt bleiben.

schöne Grüße
Martin

[delMar]

Halo Martin,

gibt es irgendwo eine Übersicht zu den manipulierbaren Fixwerten? Habe leider nichts gefunden.

Viele Grüße
Frank

Hallo,
das ist eine Referenz zum anderen Modul, dem TA_CMI_JSON.
Dort ist es folgendermaßen in der Hilfe erklärt:

Code Auswählen Erweitern


Set
fixwertAnalog
Set Fixwert to an analog value. Example:
set cmiNode fixwertAnalog <index> <value>
set cmiNode fixwertAnalog 3 64.0 will set Fixwert 3 to 64.0
fixwertDigital
Set Fixwert to a digital value. Also works for impulse values. Example:
set cmiNode fixwertDigital <index> <value>
set cmiNode fixwertDigital 2 1 will set Fixwert 2 to On/Yes.
fixwertImpuls
Trigger an impulse to Fixwert. Example:
set cmiNode fixwertImpuls <index> <value>
set cmiNode fixwertImpuls 3 1 will send an On-impulse to Fixwert 3.


Ich hoffe, das beantwortet deine Frage?

schöne Grüße
Martin

[trabantp60]

Ehrlich gesagt, nein.

Ich möchte gerne aus FHEM heraus den Betriebsmodus der UVR1611  (Zeit/Auto, Standby, Normal, Abgesenkt) umschalten können (Analogwert am Eingang "externer Schalter" bei der Heizungsreglerfunktion).
Das gelingt seit gestern, Dank Deines Moduls Can-Over-Ethernet, über den Weg mit dem CAN-Bus.
Allerdings habe ich noch keine Möglichkeit gefunden, den Betriebsmodus der Anlage auszulesen und darzustellen, um die Umstellung zu kontrollieren.
Dafür käme ggfs. das Web-API in Frage, wenn ich wüsste, welcher Wert wo auszulesen ist.

Oder eben vielleicht das seit langer Zeit genutzte TA_CMI_JSON-Modul...

[delMar]

Ok, ich denke, ich verstehe das jetzt richtig.

Du kannst im Prinzip nur die Ausgabewerte einer Funktion auslesen und in FHEM anzeigen.

Welche Ausgaben macht denn die Funktion "Heizkreisregelung" bei dir?
Vielleicht steht in "Betriebsart" der Wert, den du haben möchtest?

Falls ja, kannst du den dann mit diesem Modul über CAN-Analogausgang an FHEM geben.

[trabantp60]

Oh, das wäre schön.
Leider habe ich bislang keine Doku der Funktionen einer UVR1611 gefunden. Im TA-Wiki stehen nur die der x2. Dort wäre die Betriebsart als Zahlenwert verfügbar.
Im Web-Interface der UVR1611 sehe ich die Betriebsart aber angezeigt, weiß aber nicht, wie ich die Information auf den CAN-Bus bekomme.
Deshalb erschien mir (bislang) der Weg über die Web-API einfacher.

[thor3]

Hallo,
bei der UVR1611 musst du die gewünschten Infos erst in der UVR1611 als Netzwerkausgang definieren, dann im CMI als CAN Eingang eintragen und auf dem CMI als COE Ausgang (funktioniert analog und digital)

Gruß Nico

[trabantp60]

Hallo Nico,
soweit, glaube (hoffe) ich, das verstanden zu haben.
Nur steht der aktuell eigestellte Betriebsmodus in meinem Set leider nicht als zuweisbare Info/Funktionsergebnis zur Verfügung oder ich finde den Weg dahin nicht. Ich kann alle möglichen Temperaturen, Stati der Schaltausgänge, etc. als Ausgangsgröße auf den CAN-Bus geben. Aber eben nicht den Status der Betriebsart der Heizkreisfunktion.
Seltsamerweise wird er aber im Web-UI angezeigt, muss also irgendwo verfügbar sein. Nur weiß ich nicht, wie da dran komme.
TAPPS1 (ich hätte als nächstes in die Funktionsdatei geschaut, die sich aber nur mit TAPS1 editieren lässt) bekomme ich auf meinem 64-Bit Rechner nicht zum Laufen.

Viele Grüße
Frank