FHEM Forum

Hallo,

Steuerungen des Herstellers 'Technische Alternative' können über UDP-Pakete Daten austauschen, wenn man ein CMI sein eigen nennt:
https://www.ta.co.at/fernwartung/cmi/
Dort sind viele Informationen zu Protokollen, etc verfügbar.

Das Protokoll ist so offen, dass auch FHEM Empfänger (und in Zukunft wohl auch Sender) sein kann.

Ich habe mit einer Arbeit an einem Modul begonnen, welches solche UDP-Pakete empfängt und als Readings ablegen kann.
Zu finden gibts das hier:
https://github.com/delmar43/FHEM
Es handelt sich um 70_CanOverEthernet.pm und 71_COE_Node.pm
Das Modul ist noch nicht fertig. Bisher funktionieren nur Analoge Werte (Digitale werden nicht ausgelesen) und auch Fehler können noch vorkommen (zB Nachkommastellen, etc)

Dieses Modul ist eng verwant mit dem Modul TA_CMI_JSON, welches allerdings maximal 1x pro Minute Daten abfragen kann.
Und dann auch nur jene, die von der CMI exportiert werden.

Dieses Modul bekommt Daten über Netzwerk-Push, hat also mehr oder weniger Daten in Echtzeit zur Verfügung.
Außerdem können nicht nur Ein- oder Ausgänge, sondern auch Fixwerte, etc damit empfangen werden.

Was ist Can Over Ethernet?

CanOverEthernet erlaubt es, an einer bestimmten IP-Adresse virtuelle CAN-Knoten anzusprechen.
Jeder dieser virtuellen CAN-Knoten hat (wie auch echte CAN-Knoten) mehrere "Speicherplätze" (im CMI-UI als 'Netzwerkausgang' bezeichnet)

Die Vorarbeiten gestalten sich leider etwas aufwändig.

Damit Metriken von einer Steuerung über CanOverEthernet exportiert werden, sind die folgenden Schritte nötig:

• An der Steuerung (zB dem UVR16x2) muss man unter Umständen mit der Berechtigung "Experte" angemeldet sein.
• Auf der Steuerung unter CAN -> CAN-Analogausgänge die zu exportierenden Metriken konfigurieren. (siehe Anleitung der Steuerung)
• Am CMI unter Einstellungen -> Eingänge -> CAN-BUS -> Analog die vorher exportierten Metriken eintragen. Das CMI hat diese Metriken nun zur Verfügung.
• Am CMI muss man nun unter Einstellungen -> Ausgänge -> CoE -> Analog rechts im Dropdown Eingang dein Eintrag CAN-Bus auswählen und darunter eine Metrik auswählen, die man im vorigen Schritt importiert hat.
• Das CMI schickt dann die gewählte Metrik an die angegebene IP (die von FHEM), unter dem festgelegten Knoten und Netzwerkausgang.

Unter einer IP können mehrere virtuelle CAN-Knoten existieren.

Und hier kommt FHEM nun ins Spiel.

• Als IP-Adresse muss die von FHEM eingegeben werden.
• FHEM hört auf alle Knoten, die unter dieser IP Daten erhalten.
• Für jeden Knoten wird ein FHEM COE_Node device angelegt. (autocreate muss aktiviert sein)
• In diesen wird im Attribut readingsConfig angegeben, welche Metrik unter welchem Reading gespeichert werden soll.

So wird in FHEM das CanOverEthernet device angelegt

define coe CanOverEthernet


Und das reicht schon. Hiermit horcht FHEM am Port 5441 auf UDP-Nachrichten.
Dieser Wert ist fix festgelegt und kann auch nicht verändert werden.
Somit macht es auch keinen Sinn (bzw ist nicht nötig), mehrere CanOverEthernet devices anzulegen (außer evtl, man hätte mehrere Ethernet interfaces)

Wie schon erwähnt, wird für jeden Knoten ein device angelegt. Dieses muss wie folgt konfiguriert werden.

attr coe_node_5 readingsConfig 1=Fuehler 5=UWP_WW 9=Solar_Stellung 13=Solar_Durchfluss


In dem hier gezeigten Beispiel wird also für Knoten 5 ein COE_Node device von FHEM angelegt.
Was im CMI unter Knoten 5 und Netzwerkausgang 1, 5, 9 und 13 konfiguriert wurde, wird im FHEM-Device entsprechend als Reading abgelegt.
Achtung: Readings dürfen wie immer keine Leerzeichen enthalten.

CanOverEthernet als Protokoll hat so seine Eigenheiten. Ich empfehle, das "Zusatz Manual CoE" von der Herstellerseite https://www.ta.co.at/fernwartung/cmi/ zu studieren.

Ich weiß, diese Anleitung ist sehr textlastig. Eine Wiki-Seite mit Screenshots ist schon in Planung.
Je nach Interesse werde ich das schneller oder langsamer angehen :-)

Freue mich wie immer über Feedback.
Sobald das Modul stabil ist, wird es natürlich ins SVN wandern.

schöne Grüße
Martin

Hallo delmar,

dies ist mein erstes Posting hier, aber ich habe schon sehr viel gelesen und ein sehr umfangreiches FHEM mittlerweile. Die Wohnung läuft komplett über Fhem mit Homematic, MAX, Enocean, MQTT, aber die gesamte Heizung läuft über 2xUVR1611 und auch ein CAN-IO45 von der neuen x2 Serie. Mit den UVRs kenn ich mich sehr gut aus, da ich mindestens schon 20 Kundenanlagen zum Teil ziemlich komplex programmiert habe und betreue. CanOverEthernet habe ich auch schon einmal eingerichtet und freue mich, dass es mit deinen beiden Modulen nun endlich möglich ist die UVR einfach in FHEM einzubinden. Das JSON-Modul habe ich bereits eingerichtet und es lief auf Anhieb, das CanOverEthernet probier ich jetzt mal am WE. Allerdings wäre die Senderichtung von FHEM in Richtung CMI/UVR für mich wesentlich sinnvoller, da man dann z.B. auch eine Fußbodenheizung Pumpenlogik, oder den Start des BHKW bei entsprechender Anforderung von Waschmaschine oder E-Herd gut realisieren könnte.

Wie gesagt, ich freu mich sehr über deine Arbeit und hoffe bald etwas neues zum aktuellen Stand zu hören, es wird dann auf alle Fälle schnell getestet (ich kann auch gern mal die anderen Module ranhängen, wie CAN-BC, oder CAN-IO usw. hab eigentlich alles da)

Danke

Silvio

Hi Silvio,

danke für das positive Feedback!

Zitat von: silvkat am 25 Januar 2019, 16:50:01
Allerdings wäre die Senderichtung von FHEM in Richtung CMI/UVR für mich wesentlich sinnvoller, da man dann z.B. auch eine Fußbodenheizung Pumpenlogik, oder den Start des BHKW bei entsprechender Anforderung von Waschmaschine oder E-Herd gut realisieren könnte.

Ja, das hab ich am Radar. Ich möchte selber auch die Rücklauf-Soll-Temperatur von der Wärmepumpe an die UVR schicken.

Zumindest für zB Freigaben (als Fixwerte realisiert) nutze ich derzeit einen Workaround:
Ich hab mir aus den Browser-Tools den request vom CMI WebUI rauskopiert und ein HTTPMOD eingerichtet. So kann ich zumindest die Fixwerte für Freigaben ändern.
Aber wie gesagt: ist nur ein Workaround. (wichtig: den Referrer im Header setzen, sonst akzeptiert das CMI wohl keine solchen requests.)

defmod httpUvr16x2_FBH HTTPMOD none 0
attr httpUvr16x2_FBH userattr requestHeader.1 requestHeader1 requestHeader2 set01Name set01NoArg:0,1 set01URL set02Name set02NoArg:0,1 set02URL setHeader1 setHeader2
attr httpUvr16x2_FBH alias UVR 16x2 FBH
attr httpUvr16x2_FBH httpVersion 1.1
attr httpUvr16x2_FBH room Heizung
attr httpUvr16x2_FBH set01Name Freigabe_Ein
attr httpUvr16x2_FBH set01NoArg 1
attr httpUvr16x2_FBH set01URL http://usr:pwd@192.168.4.xxx/INCLUDE/change.cgi?changeadrx2=01000144141100&changetox2=1
attr httpUvr16x2_FBH set02Name Freigabe_Aus
attr httpUvr16x2_FBH set02NoArg 1
attr httpUvr16x2_FBH set02URL http://usr:pwd@192.168.4.xxx/INCLUDE/change.cgi?changeadrx2=01000144141101&changetox2=0
attr httpUvr16x2_FBH setHeader1 Referer: http://192.168.4.xxx/menupagex.cgi?nodex2=01005800
attr httpUvr16x2_FBH webCmd Freigabe_Ein:Freigabe_Aus


Zitat von: silvkat am 25 Januar 2019, 16:50:01
das CanOverEthernet probier ich jetzt mal am WE

Danke dass du dir die Zeit nimmst.
Das Modul ist noch in einem sehr frühen Zustand. zB stimmen Temperaturen nur, solang sie im positiven Bereich sind.
(nur damit du weißt, mit welchen Unzulänglichkeiten du noch rechnen musst).

Ich wollte aber grundsätzlich mal rausfinden, ob die Art der Einrichtung Sinn macht, und ob es generell Interesse am Modul gibt.

Die nächsten beiden Wochen bin ich beruflich unterwegs, da wird die Zeit zum programmieren knap sein.
Über Rückmeldungen und Anregungen hier im Forum bin ich aber trotzdem auch in der Zwischenzeit dankbar.
Nichts motiviert mehr, als zu wissen, dass man das Zeug nicht nur für sich selber coded :-)

schöne Grüße
Martin

Hallo delmar

ich schreibe parallel ain Modul für die DoorBird Türeinheit.
Diese sendet UDP datagramme ab, die ich auswerten muss.

Dabei bin ich auf deine https://github.com/delMar43/FHEM/blob/master/70_CanOverEthernet.pm (https://github.com/delMar43/FHEM/blob/master/70_CanOverEthernet.pm) gestossen.

Ich habe die Anteile für die UDP Auslesung meiner Meinung nach herauskopiert und übertragen.

Nun habe ich 2 Probleme:

a) Nach Neu-Definition des Device stürzt mir das gesammte fhem mit dem Log-Eintrag "Can't call method "fileno" on an undefined value at ./FHEM/73_DoorBird.pm line 176." ab.
b) Nach einem Neustart scheint alles hochzufahren aber ich erhalte keine UDP-Einträge im Log-File.

Paralleldiskussion hier: https://forum.fhem.de/index.php/topic,96399.msg895433.html#msg895433
Hast Du bereits schon Erfahrung mit dem UDP datagrammen sammeln können?

Danke

Gruss
    Sailor

Hi Sailor

Sorry, ich seh auf den ersten Blick auch nicht, was dein problem ist.
Funktionieren die anderen UDP module denn bei dir?

Schöne Grüße
Martin

Hallo Delmar,

vielen Dank für das neue Modul basierend auf CanOverEthernet. Den Ansatz finde ich sehr interessant, da man – wie Du ja bereits geschrieben hast – nicht an dem 1 minütigen Aktualisierungstakt hängt, Daten nur gesendet werden wenn sie verändert wurden und es möglich ist – trotz einer älteren UVR1611 – an fast alle Daten heran zukommen. Ich hatte jetzt 8 Jahre lang ein BL-Net am laufen, möchte aber auf das komfortablere C.M.I wechseln.

Dein Modul ist eingehängt und liefert fleißig alle gewünschten analogen Daten und das – so möglich und sinnvoll - im festgelegten 10s Takt. Das etwas aufwendige Konfigurieren lohnt sich in meinen Augen, da das Online-Schema des C.M.I für die Visualisierung parallel betrieben werden kann, da es den 1-Minutentakt für sich ganz allein beanspruchen kann.

Nun zur vorsichtigen Frage, wann hast Du wieder "Lust" und Zeit das Parsen der digitalen Werte einzubauen? Oder hast Du neben der Doku auf der TA Seite eine zusätzliche Quelle, wie das Format aussieht, das ich es gegebenenfalls einbauen könnte.

Das Senden auf diesem Wege wäre natürlich langfristig auch eine feine Sache, für mich aber eher Prio2.

Schöne Grüße Stephan

RaspberryPi 3B, FHEM v5.9

Hallo Stephan,

freut mich, dass es soweit funktioniert.

Zitat von: nagelauge am 11 Februar 2019, 19:55:07
wann hast Du wieder "Lust" und Zeit das Parsen der digitalen Werte einzubauen?

An der Lust scheiterts nicht :-)
Ich hab leider keine Doku gefunden, die das Format der digitalen Daten erläutert.
Das analoge Format war einerseits schon wo anders implementiert, und andererseits beinahe schon selbsterklärend, wenn man den Einstieg gefunden hatte.
Beim digitalen Format waren 1, 2 Ungereimtheiten und mir hat noch die Zeit gefehlt, mich tiefer reinzugraben.

Wenn du mit Infos aushelfen kannst, oder sogar einen Patch liefern könntest, würde mir das die Sache unheimlich erleichtern.

Danke!

schöne Grüße
Martin

Hallo Martin

Zitat von: delmar am 12 Februar 2019, 07:19:10
Ich hab leider keine Doku gefunden, die das Format der digitalen Daten erläutert.
Wenn du mit Infos aushelfen kannst, oder sogar einen Patch liefern könntest, würde mir das die Sache unheimlich erleichtern.

Unter https://www.ta.co.at/fernwartung/cmi/#software bieten die doch die LINUX Pakete für deren Auswerte-Software an.

Als ersten Schritt hätte ich dort mal geschaut, ob es irgendwo lesbare Bibliotheken gibt, die Aufschluss über deren Auswertung geben.
Aber ich gebe zu: Das wäre eine üble Fleißarbeit...

Gruß
    Sailor

Grundsätzliche Frage:
wie hättet ihr euch das Senden von Daten vorgestellt?
Mir würde einfallen, am CanOverEthernet-Device (also *nicht* auf den Node devices) mittels SET Ziel-IP, Ziel-Knoten, Ziel-Kanal und Wert anzugeben.

also zB

set CanOverEthernet sendData x.x.x.x 2 1=33.0 2=5 3=0

Was haltet ihr davon?
Alternativen sind herzlich willkommen.

schöne Grüße
Martin

Hallo,

ich habe funktionierende PERL-skripte für COE mit digital-analog-senden-empfangen.
Mit Fhem habe ich gerade angefangen. Die Skripte sind für andere Projekte getestet, als Denkanstoß aber vielleicht hilfreich. Hat jemand interesse?

Thomas   

Hallo Thomas

Ja, sehr gern

Schöne grüße
Martin

Hallo Martin,

https://github.com/thhoe/coe-mi

Programmieren kann ich eigendlich nicht. Das ist alles copy and past nach g*****.
coe-mi.pl läuft bei mir schon länger.  Es war geplant mit nagios verschiedene Werte zu überwachen. Ist aber nie fertig geworden.
udp.pl war mein 1. Test Daten zu senden. Meine Regelung kann jetzt Wettervorschau.
coe1.pl und coe2.pl läuft seid ein paar Tagen. Die Werte werden nicht verarbeidet.
coed.pl habe ich nur kurz zum Test geschrieben. Im CMI>Status>COE werden die Daten richtig angezeigt.

Dein Problem mit negativen Themperaturen hatte ich auch.
Der Trick ist : das CMI spricht Big Endian.
Danach war alles recht einfach.

Thomas

Danke Thomas. Kann es kaum erwarten, die Zeit dafür zu finden ;)

Schöne Grüße
Martin

Hallo zusammen,

auf GitHub hab ich jetzt ein Update veröffentlicht, welches hoffentlich das Problem mit negativen Werten löst.
Danke Thomas, dein Hinweis mit big/little endian hat den Nagel auf den Kopf getroffen.
Mein Problem war, dass ich einen unsigned short verwendet habe. Es muss aber ein signed short sein.

Vielleicht schaff ich's auch noch, die Digitalen Werte abzudecken, dann wär das Modul eigentlich reif fürs SVN.

Test-Feedback herzlich willkommen

schöne Grüße
Martin

Hallo zusammen,

hat das schon jemand von Euch an der UVR1611 umgesetzt?
Ich wollte das heute mal ausprobieren.
Tu mich aber an folgendem Punkt in der Anleitung schwer:

Zitat von: delmar am 19 Januar 2019, 21:29:47
...

• Auf der Steuerung unter CAN -> CAN-Analogausgänge die zu exportierenden Metriken konfigurieren. (siehe Anleitung der Steuerung)

...

schöne Grüße
Martin

Ich finde diese Menüpunkte dort nicht und will mein eigentlich gut funktionierendes "Heizung- und Loggingsystem" nicht abschiessen.

Im Voraus vielen Dank für Eure Tipps

Zitat von: Bualicher am 22 September 2019, 12:21:49
Hallo zusammen,

hat das schon jemand von Euch an der UVR1611 umgesetzt?

Die Steuerung ist egal, wichtig ist das CMI kommuniziert mit ihr.

Zitat
Tu mich aber an folgendem Punkt in der Anleitung schwer:

Ich finde diese Menüpunkte dort nicht und will mein eigentlich gut funktionierendes "Heizung- und Loggingsystem" nicht abschiessen.

Im Voraus vielen Dank für Eure Tipps

Auf den CMI : Einstellungen-> Ausgänge -> COE
Wenn du Daten nutzen willst die das CMI nicht kennt musst du auf der UVR diese als Netzwerkausgang programmieren.

TA hat das als Kommunikation zur Erweiterung des CAN-Netzes über Internet vorgesehen. Fhem Simuliert eine Steuerung im CAN -Netz. Ich persönlich nutze ein Script um die Wetterprognose an meine UVR1611 zusenden, und Daten mit VZ zu loggen. Das funktioniert nur weil ich die Heizung so programmiert habe. Das Datenlogging von TA musste ich deaktivieren, war es aktiv hat die UVR sporadisch ein Reset gemacht (ohne COE) . Mit dem Bootlader hatte es noch problemlos funktioniert. Nur als Beispiel zum zerschießen eines funktionieren System.

Hilft das? Sonst beschreibe bitte welche Daten du testen möchtest.

Thomas

Hallo zusammen,

ich lese hier mal mit, da ich einen älteren D_LOGG Logger habe, den ich gerne mit FHEM auslesen möchte.

Gruß Peter

Hallo Peter,

COE funktioniert nur mit einem CMI.
Für den D_Logg gab es die dlogg-linux von Volker Römer. [https://github.com/fb/dlogg-linux]

Thomas

Hallo Thomas,

danke für die Info, das werde ich mir mal anschauen.

Gruß Peter

Zitat von: Bualicher am 22 September 2019, 12:21:49
Ich finde diese Menüpunkte dort nicht und will mein eigentlich gut funktionierendes "Heizung- und Loggingsystem" nicht abschiessen.

Hallo,
ich werde das im Wiki entsprechend mit Screenshots dokumentieren - hoffentlich bald.
Jede Reise beginnt mit dem ersten Schritt: https://wiki.fhem.de/wiki/CanOverEthernet

schöne Grüße
Martin

Die Wiki-Seite ist jetzt soweit mal vollständig.
Feedback zur Qualität der Beschreibung ist herzlich Willkommen.

Für alle die das Modul verwenden: bitte die Statistik Funktion aktivieren. Wenn dadurch ausreichendes Interesse belegt ist, stelle ichs gern als offizielles Modul ins SVN. (zwei Installationen sind meine eigenen  ::))

Hallo delmar,

Danke für deine Arbeit. 2 Hinweise habe ich.
- Deine 1.Überschrift ist "Konfigurieren des CMI". Besser passen würde "Konfigurieren der UVR16x2". 
- Konfigurieren des CMI gehört meiner Meinung nach vor den Punkt "Was haben wir bis hier erreicht?".

Meine UVR1611 habe ich zusätzlich über den DL-Bus mit den CMI verbunden. Damit habe ich ohne weitere Programmierung zugriff auf alle Ein- und Ausgänge (ohne Netzwerk) der Steuerung im CMI. Das kann nützlich sein wenn mehr wie 16 Werte überwacht werden sollen.

Noch ein Tipp. In deinen Screenshots sehe ich das deine 16x2 Knoten 1 ist. Alle Geräte im CAN-Bus Synchronisieren ihre Zeit mit diesen Knoten. Besser geeignet ist das CMI als Knoten 1. Hier kann die Zeit mit NTP eingestellt werden. Den NTP-Server kann man zwar auswählen, aber der Standart funktioniert bei mir als einziger Problemlos.


Thomas

Zitat von: thhoe am 23 September 2019, 08:51:46
- Deine 1.Überschrift ist "Konfigurieren des CMI". Besser passen würde "Konfigurieren der UVR16x2". 
- Konfigurieren des CMI gehört meiner Meinung nach vor den Punkt "Was haben wir bis hier erreicht?".

Danke, ist umgesetzt.

Zitat von: thhoe am 23 September 2019, 08:51:46
Meine UVR1611 habe ich zusätzlich über den DL-Bus mit den CMI verbunden. Damit habe ich ohne weitere Programmierung zugriff auf alle Ein- und Ausgänge (ohne Netzwerk) der Steuerung im CMI. Das kann nützlich sein wenn mehr wie 16 Werte überwacht werden sollen.

Das ist ja sehr bequem. Du bist eingeladen, die Wiki-Seite mit diesen Infos zu ergänzen :-)

Zitat von: thhoe am 23 September 2019, 08:51:46
Noch ein Tipp. In deinen Screenshots sehe ich das deine 16x2 Knoten 1 ist. Alle Geräte im CAN-Bus Synchronisieren ihre Zeit mit diesen Knoten. Besser geeignet ist das CMI als Knoten 1. Hier kann die Zeit mit NTP eingestellt werden. Den NTP-Server kann man zwar auswählen, aber der Standart funktioniert bei mir als einziger Problemlos.

Cool, das wusste ich nicht, danke. Mein Installateur hat das so eingestellt, aber ich werde mir das bei Gelegenheit mal ansehen...

Zitat von: thhoe am 23 September 2019, 08:51:46
Danke für deine Arbeit.

Danke fürs Feedback, so macht das gleich noch mehr Spaß

Super, vielen Dank an alle.

Habe das jetzt mal innerhalb von der UVR und dem CMI umgesetzt. Eingangsdaten von der UVR kommen auf jeden Fall mal am CMI an. In FHEM reicht mir hoffentlich heute Abend die Zeit für die Umsetzung.

@delmar: super Wiki-Eintrag. Bei der UVR1611 sieht die Menüführung etwas anders aus. Hier gibt es den Menüpunkt "CAN" nicht. Hier über Netzwerk gehen und die Aus-/Eingangsvariablen Digital (kommt hoffentlich bald) oder Analog setzen (s. Bilder).

@thhoe

Zitat von: thhoe am 22 September 2019, 13:39:49
...
Das Datenlogging von TA musste ich deaktivieren, war es aktiv hat die UVR sporadisch ein Reset gemacht (ohne COE) . Mit dem Bootlader hatte es noch problemlos funktioniert. Nur ...

Ich frage parallel die Daten über den UVR1611 Data Logger Pro (https://github.com/berwinter/uvr1611/blob/master/README.md) ab und visualisiere das. Läuft jetzt seit einigen Jahren recht zuverlässig. Bis jetzt habe ich hier noch keine negativen Auswirkungen von CoE bemerkt.

Zitat von: Bualicher am 23 September 2019, 09:09:13
Bei der UVR1611 sieht die Menüführung etwas anders aus. Hier gibt es den Menüpunkt "CAN" nicht. Hier über Netzwerk gehen und die Aus-/Eingangsvariablen Digital (kommt hoffentlich bald) oder Analog setzen (s. Bilder).

Danke für die Screenshots. Wenns für dich ok ist, gebe ich die demnächst mal auf die Wiki-Page dazu.

Zitat von: delmar am 23 September 2019, 09:17:34
Danke für die Screenshots. Wenns für dich ok ist, gebe ich die demnächst mal auf die Wiki-Page dazu.

Gerne. Aus diesem Grund habe ich die Screenshots gemacht.

So, habe es in FHEM eingerichtet. Alle Werte stehen jetzt in den Readings (s. Bild).

Im Wiki ist noch ein Fehler:

ZitatDas macht man über das Attribut readingsConfig. Beispiel:
attr cmi_node_2 readingsConfig 1=T.Kollektor 2=T.Solar_VL 3=T.Aussen
Das Format ist immer Index=Readingname. Mehrere Readings werden durch Leerzeichen getrennt. Wenn etwas schiefgeht, prüfen, ob nicht eventuell ein Leerzeichen im Namen des Readings vorkommt.

Muss heißen:
attr COE_Node_2 readingsConfig 1=T.Kollektor 2=T.Solar_VL 3=T.Aussen

Oder einfach so, wie das automatisch erstellte Device heißt.

Zitat von: Bualicher am 24 September 2019, 07:33:59
Im Wiki ist noch ein Fehler:

Danke, ist korrigiert :-)

Update auf GitHub enthält nun auch das lesen von digitalen Werten.

Eine kleine Änderung ergibt sich dadurch: die analogen Werte dürfen erst ab Kanal 17 beginnen, weil 1-16 laut Spez den digitalen Werten vorbehalten ist.
Wenn man für analoge Werte einen kleineren Kanal angibt, dann überschreiben sich digital und analog permanent, weil ja der Wert eines Kanals nur in ein Reading geschrieben werden kann.
Wer keine digitalen Werte schreibt, kann die analogen derzeit noch theoretisch auch auf 1-16 speichern - dafür werde ich aber demnächst einen check einbauen und dann wirds nicht mehr funktionieren.

Wenn keine Probleme gemeldet werden, werde ich das mal als erste Version ins SVN stellen (inklusive check) und mich dann um das Senden von Daten and CoE Devices kümmern.
Die Wiki-Seite aktualisiere ich auch noch bei Gelegenheit

Danke
schöne Grüße
Martin

Vielen Dank für Deine tolle Arbeit. Hab jetzt zwar die neue Version noch nicht getestet, aber mit den digitalen Werten ist auf jeden Fall mal alles einsehbar  :)
Senden über CAN gibt einem dann natürlich noch ganze andere Möglichkeiten.

Eine Frage habe ich aber noch zu aktuellen Version:

Zitat von: delmar am 24 September 2019, 12:57:19
...
Eine kleine Änderung ergibt sich dadurch: die analogen Werte dürfen erst ab Kanal 17 beginnen, weil 1-16 laut Spez den digitalen Werten vorbehalten ist.
...

Laut CMI könnte ich 64 digitale und 64 analoge Werte über CoE senden. Zumindest könnte ich die in den Einstellungen definieren.
Gibt es in Deinem Modul eine Begrenzung hierfür?
Würde es funktionieren wenn ich die analogen Werte bei 65 beginnen lassen würde? Wer weiß wieviele UVRs noch in die Heizungsanlage kommen  ;)

Zitat von: Bualicher am 24 September 2019, 13:55:50
Laut CMI könnte ich 64 digitale und 64 analoge Werte über CoE senden. Zumindest könnte ich die in den Einstellungen definieren.
Gibt es in Deinem Modul eine Begrenzung hierfür?

Die Begrenzung ist nicht im Modul, sondern ich denke im Protokoll.
Du kannst an einen CAN-Knoten 16 digitale und 16 analoge Werte senden.

Richtig, du kannst in Summe 128 Werte senden, allerdings nicht alle an einen Knoten.

Die Formulierung ist eigentlich irreführend.

Ein Gerät kann aber sehr wohl aus mehreren CAN-Knoten bestehen.

Was nun passiert, wenn du den digitalen Kanal 17 beschickst, oder den analogen Kanal 33, weiß ich auch nicht.
Ich denke, digital 17 würde einen analogen Wert überschreiben. Analoge Werte auf Kanal 15 würden vielleicht ignoriert werden.

Und generell würde ich denken, dass auch Werte, die an einen Kanal größer als 32 geschickt werden, einfach ignoriert werden.
Entweder werden sie garnicht verschickt, oder aber vom Empfänger nicht ausgewertet.

Das FHEM-Modul kann hier auf jedenfall großzügiger mit Kanäle umgehen.
Unterm Strich sollte aber das Verhalten zwischen allen Geräten gleich sein, weshalb ich mich gern an die Spezifikation halte.

Ich hoffe, das beantwortet deine Frage?

schöne Grüße
Martin

Ich habe jetzt noch mit der Arbeit am Versenden von Daten per CoE begonnen.
Irgendwie habe ich angenommen, dass ich auch in der Eingangs-Konfiguration des CMI CoE auswählen kann.
Allerdings ist das nicht der Fall.

Im PDF der Doku für Can Over Ethernet https://www.ta.co.at/download/datei/826810/ (https://www.ta.co.at/download/datei/826810/) steht:

ZitatSobald der erste Wert vom Sende-C.M.I. übertragen wurde ist der virtuelle Knoten (nur direkt am Regler) im Menü Netzwerk/Netzwerkknoten als aktiver Knoten sichtbar. Dieser aktive Knoten sollte aber nicht angewählt werden. In der Browseransicht des C.M.I. ist dieser Knoten nicht zu sehen.

Als Screenshot ist dort leider nur die UVR1611 abgebildet.

Könnte jemand, der schon erfolgreich Daten per CoE an das CMI schickt, mir das nochmal erläutern?
Also konkret: muss ich nun am Empfänger-CMI etwas konfigurieren? Wie kriege ich die Daten vom CMI an die UVR?

Vielen Dank im Voraus

schöne Grüße
Martin

Modul ist im FHEM SVN eingecheckt, da das Empfangen von Werten stabil funktioniert. Für eine version 1.0 mMn völlig ok :-)

Sollte ab morgen beim FHEM-Update mitgeliefert werden.

schöne Grüße
Martin

DelMar, cool stuff was du da machst.

Awsome.

Die Fehlende kommunikationseinheit zwischen FHEM und UVR hat mich bisher davon abgehalten, meine HIMAX zu beerdigen, die regelt nämlich dank meiner über 15 Jahre entwickelten Tuiks inzwischen ganz ordentlich, aber wie immer, es ginge besser, selbständiger und mit Ersatzteilen wirds langsam auch schwierig und meine Zeitschaltur rasselt inzwischen wieder.

Da es inzwischen offensichtlich Vortschritte bei der Kommunikation gibt, hab ich heute ne UVR16x2 bestellt, zum Basteln und Spielen.

Blöde Zwischenfrage, hab ich vermutlich irgendwo überlesen, drum verstehe ich nicht, warum du für die Werte übers CMI gehst anstelle den can bus direkt anzuzapfen?

https://github.com/staircaseblog/uvr16x2logging
https://forum.fhem.de/index.php?topic=69853.0

Ich lehn mich mal weit aus dem Fenster und behaupte, über CAN BUS kann man von jeder belibige dranhängenden UVR (oder auch andere CAN Teilnehmer) die Werte lesen und schreiben, quasi nach lust und laune, sofern man sich im CAN BUS Protokoll an die von TA gesetzten Regeln hält. Das CMI kanns ja auch, warum sollte das Raspi CAN Modul das nicht können? (so könnte man z.B. dem Touch neben der Wohnungstüre weitere infos zustellen wie z.B. ne Anrufliste oder Klingel-Historie, Zisternen-Stand etc.)

Wozu also der Umweg übers CMI?

Zumindest bei ner 16x2 ist die visualisierung eh aufm display bzw aufm can touch.

Die TA UVR 16x2 mit Touch hat doch nur 2 gravierende Mankos: logging und wetter-daten einbindung.

Logging ist über die oben verlinkten can bus module möglich. check.

Einziger Haken einer 16x2 ist damit noch die fehlende Einbindung der Wettervorhersage, die man mit einer lokalen Funkwetterstaion + wunderground + FHEM und einem CAN BUS Modul durch korrekturfaktoren der Innen-Raum-Zielwerte/Rücklaufzielwerte gemäß Wetterprognose schlicht nach Contron Vorbild realisieren könnte.

Somit würde ein Ausfall des FHEM oder eine Kommunikationsunterbrechung nur zur Rücksetzung der "Korrekturfaktoren" führen und die Steuerung in den "nicht prognose geführten" betrieb versetzen und damit störungsfrei und nicht ganz so effizent weiter laufen.

Gruß Manne

Hi Manne,

danke für dein Feedback.

Zitat von: mannebk am 25 September 2019, 03:17:31
Blöde Zwischenfrage, hab ich vermutlich irgendwo überlesen, drum verstehe ich nicht, warum du für die Werte übers CMI gehst anstelle den can bus direkt anzuzapfen?

Ich bastle seit ca 12 an meinem Smart-Home. Anfangs war der Plan, alles selber zu machen. Ich hab Rollladenaktoren gelötet, mit 1-Wire angebunden, etc.
Fazit nach 12 Jahren: selber gebastelte Hardware bzw selber gefrickelte Anbindung an Systeme hat nur Ärger gemacht. Ich könnte einen Vortrag darüber halten (oha, hab ich ja: https://youtu.be/3P-V0qx0gXM?t=278)

Zitat von: mannebk am 25 September 2019, 03:17:31
Ich lehn mich mal weit aus dem Fenster und behaupte, über CAN BUS kann man von jeder belibige dranhängenden UVR (oder auch andere CAN Teilnehmer) die Werte lesen und schreiben, quasi nach lust und laune, sofern man sich im CAN BUS Protokoll an die von TA gesetzten Regeln hält. Das CMI kanns ja auch, warum sollte das Raspi CAN Modul das nicht können? (so könnte man z.B. dem Touch neben der Wohnungstüre weitere infos zustellen wie z.B. ne Anrufliste oder Klingel-Historie, Zisternen-Stand etc.)

Jein. Raspi kann das sicher. Allerdings würde es eine von jenen handgemachten Hardwareanbindungen sein, die mir in den letzten Jahren nur Probleme gemacht haben.
Und ich schließe garnicht aus, dass ich der Grund für die Probleme bin. Aber so isses nun mal.
Und CAN ist nicht gleich CAN. FHEM würde man für deine Beispiele in jedem Fall benötigen. Die Klingel kann sicher nicht mit der Heizung kommunizieren, etc. Selbst wenn auf beiden CAN draufstehen würde.

Zitat von: mannebk am 25 September 2019, 03:17:31
Wozu also der Umweg übers CMI?

Weil CMI über Ethernet geht und somit (für mich) so einfach anzubinden ist, wie sonst nichts.
Gegenüberstellung: das CMI bietet um 150 Euro eine problemlose Anbindung, inklusive der Möglichkeit, Firmware-Updates für die UVR zu machen. Diese müsstest du beim Raspi-CAN erstmal noch programmieren. Die UVR kann natürlich auch über SD-Card Firmware updates kriegen.

Ein Raspi-CAN kostet vielleicht 30 Euro, benötigt aber soviel Setup, dass selbst geschenkt noch zu teuer wäre. Im Falle eines Komplett-Ausfalles des Systems (zB weil ein Blitzschlag sämtliche Hardware tötet) muss hier viel mehr gemacht werden, als nur ein LAN-Kabel anzustecken.
Ich bastle gern am Smarthome herum. Allerdings finde ich es viel lustiger, neue Protokolle einzubinden (siehe meine FHEM-Module). Kaputte Hardware reparieren, damit meine Heizung überhaupt funktioniert (konstruiertes Beispiel) ist die Art von Bastlerei, die mich nicht interessiert. Und kaputt gehen die Dinge immer am Wochenende oder wenn man mal 2 Tage nicht zu Hause ist, etc.

Darüberhinaus funktioniert das CMI mit vielen Steuerungen, nicht nur mit meiner UVR16x2; nur, um ein weiteres Beispiel zu nennen.

Zitat von: mannebk am 25 September 2019, 03:17:31
wunderground

Die haben ihre freie API im März dieses Jahren eingestellt. wunderground kannst du für eigene Anbindungen somit leider knicken.

Zitat von: mannebk am 25 September 2019, 03:17:31
Somit würde ein Ausfall des FHEM oder eine Kommunikationsunterbrechung nur zur Rücksetzung der "Korrekturfaktoren" führen und die Steuerung in den "nicht prognose geführten" betrieb versetzen und damit störungsfrei und nicht ganz so effizent weiter laufen.

Den nicht-prognose-geführten Betrieb im Falle eines Ausfalls habe ich auch mit dem CMI.

Beispiele aus der Praxis:
Ich hatte über 1-wire viele Aktoren an FHEM integriert. 2 Jahre lief alles problemlos, bis plötzlich einzelne Aktoren nicht mehr gefunden wurden (Rollläden, zum Beispiel).
Ich habe das Problem nie gefunden. Erst hab ich aktive Hubs eingebaut (obwohl an der Topologie nix verändert wurde), aber nach mehreren Monaten war wieder das selbe Problem. Keine Ahnung, warum. Ich habe die Rollladen-Aktoren schließlich durch Homematic Aktoren ersetzt, die seit nunmehr ca 4 Jahren ohne auch nur eine einzige Unterbrechung problemlos laufen.

RS-485: ich hatte Stromzähler angebunden. Wieder das selbe wie bei 1-wire. Monatelang funktioniert alles, dann plötzlich kommt keine Verbindung mehr zu Stande. Leitungslänge: 1 Meter.
Das nervt einfach nur.
Als Kabel habe ich übrigens immer Cat 5e (PIMF) verwendet. An der falschen Stelle gespart habe ich also sicher nicht; wenn man von der "richtigen" Hardwareanbindung absieht.

Homematic-wired (auch RS-485): aus irgendeinem Grund kam Überspannung auf einen Aktor. Der Aktor ging flöten (somit konnte ich kein Licht mehr schalten), riss den RS-485 Adapter mit sich, welcher über USB auch den Raspi inkl. SD-Card tötete.
Den Grund für die Überspannung habe ich bis heute nicht gefunden. Der Ersatz Aktor von Homematic-wired läuft jetzt autonom, ohne die Bus-Anbindung an den Raspi. Sollte wieder was sein, erspare ich mir wenigstens das Neu-Aufsetzen von FHEM.

Unterm Strich:
Meine "alles selber bauen" Mentalität hat mein Smart-Home an den Rand des Scheiterns gebracht.
Ich bin für mich zu dem Schluss gekommen, dass das Verbinden von bestehenden Lösungen einfach die nachhaltigere Lösung ist.

Witzig: wenn ein gekauftes Teil nach 6 Monaten Probleme macht, schimpft man. Wenn etwas selbst gebasteltes nach 6 Monaten Probleme macht, freut man sich zuerst mal, dass es so lange problemlos gelaufen ist. Aber - ich wiederhole mich - wenn es zum zweiten Mal innerhalb von 6 Monaten kaputt geht, nervt es nur noch.

Ich hoffe, das beantwortet deine Frage ansatzweise :-)

schöne Grüße
Martin

Hallo Martin,

Zitat von: delmar am 24 September 2019, 15:09:22

Könnte jemand, der schon erfolgreich Daten per CoE an das CMI schickt, mir das nochmal erläutern?
Also konkret: muss ich nun am Empfänger-CMI etwas konfigurieren? Wie kriege ich die Daten vom CMI an die UVR?

Hier ein Screenshot:

Am Ziel CMI (mein Knoten 1) brauchst du keine Einstellungen vornehmen.
Sobald er Daten empfängt wird ein COE angezeigt. Wichtig ist das jede CAN-Adresse nur einmal verwendet wird.  Ob deine Daten Sauber ankommen siehst du unter Status -> CoE
In der UVR (mein Knoten 2) definierst du einen NW-Eingang CAN, Knotennummer dein COE der sendet, Kanal der von dir gewählte.

Weitere Fragen auch per PM

Thomas

Hallo zusammen,

für die Wetterprognose nutze ich kein FHEM, aber mein CMI und CoE mit einen Linux-Server.
Das Skript ist im Anhang.

Die Auswertung erfolgt ausschließlich in der UVR1611. Die Doku habe ich noch nicht angefangen, das ganze läuft ca. 2 Monate ganz gut.


Thomas

Zitat von: thhoe am 25 September 2019, 11:52:20
Am Ziel CMI (mein Knoten 1) brauchst du keine Einstellungen vornehmen.
Sobald er Daten empfängt wird ein COE angezeigt. Wichtig ist das jede CAN-Adresse nur einmal verwendet wird.  Ob deine Daten Sauber ankommen siehst du unter Status -> CoE
In der UVR (mein Knoten 2) definierst du einen NW-Eingang CAN, Knotennummer dein COE der sendet, Kanal der von dir gewählte.

Yay, hat endlich funktioniert. Danke dafür.

Grundsätzlich ist die Funktionalität somit geklärt, ich muss "nur noch" am Parsing des commands arbeiten, und dann sollte das ebenfalls funktionieren :-)

schöne Grüße
Martin

Zitat von: delmar am 25 September 2019, 09:28:36
Ich hoffe, das beantwortet deine Frage ansatzweise :-)
schöne Grüße
Martin

Ja, in der Tat, danke für die Ausführungen!

Falls das in meinem Posting anders rüberkam, ich wollte zu keiner Zeit Kritik äußern, nur Deine Bewegründe verstehen, hab ich jetzt, danke.
Und ich kann das so gut nachvollziehen :-)

Zitat von: thhoe am 25 September 2019, 13:02:00
Das Skript ist im Anhang.
Thomas

Auch dir Danke!

Gruß Manne

Zitat von: mannebk am 25 September 2019, 15:52:28
Falls das in meinem Posting anders rüberkam

Nö, isses nich :-)

Hi

Super Modul!!!
Gibt es schone eine Möglichkeit Daten zu Senden?

MFG
Cobra

Zitat von: cobra112 am 06 Oktober 2019, 22:51:21
Gibt es schone eine Möglichkeit Daten zu Senden?

Hi

Senden von Daten ist so gut wie fertig.
Es geht nur noch darum, die usability zu verbessern.

Im Lauf dieser Woche sollte ich das Update rausbringen können.

Ich geb hier Bescheid

Schöne Grüße
Martin

Hallo,
auf GitHub ist das Update bereits verfügbar.
Ich lasse es noch etwas bei mir laufen, bevor ichs ins SVN stelle.
Auch die Doku hab ich noch nicht aktualisiert.

Hier die wichtigsten Infos:

COE_Node
Es gibt nun die Attribute readingsConfigAnalog und readingsConfigDigital. Beide akzeptieren Werte von 1-32. Analog und digital überschreiben sich gegenseitig nicht.
Beispiel

attr coe_node_2  readingsConfigDigital 1=UWP_FBH 2=UWP_Sonde 3=Freigabe_WW 4=Freigabe_FBH 5=Freigabe_Sonde


CanOverEthernet
Zum Senden der Daten sind nun die setter sendDataAnalog und sendDataDigital verfügbar.
Beispiele:

set coe sendDataDigital <Target-IP> <Target-Node> Index=Value
set coe sendDataDigital 10.0.0.1 5 1=0 2=1 3=0

set coe sendDataAnalog <Target-IP> <Target-Node> Index=Value;Type
set coe sendDataAnalog 10.0.0.1 5 1=22.5;1 1=17;0

Type ist zB 1 für Celsius. Weitere Typen sind in https://www.ta.co.at/download/datei/17511763-cmi-json-api/ gelistet

Wenns bei mir 24h gut läuft, kommts ins SVN. Feedback ist herzlich willkommen.



schöne Grüße
Martin

Hi

Wie bekomme ich es hin das ich die Daten von Homematic an die UVR schicken kann?
Thermostat Soll und ist für die Berechnung der Heizkurve.

MFG
Cobra

Zitat von: cobra112 am 09 Oktober 2019, 11:59:59
Wie bekomme ich es hin das ich die Daten von Homematic an die UVR schicken kann?
Thermostat Soll und ist für die Berechnung der Heizkurve.

Das sollte über ein Notify lösbar sein. Ich hab folgendes bei mir im Einsatz:

defmod nfySendRLSoll notify heatpump:Hzg-TempRlSoll:.* set coe sendDataAnalog 192.168.4.xxx 3 1=$EVTPART1;1

Wobei $EVTPART1 den Wert aus dem Event übernimmt und das ;1 angibt, dass es sich um eine Temperatur handelt.
In diesem Beispiel wird der Wert aus dem Event an Node 3 auf Ausgang 1 gesendet. Die IP ist vom UVR.
Dort muss als Analoger CAN-Eingang genau das eingestellt werden. (siehe screenshot)

Hoffe, das hilft. Am Abend werd ich die Doku diesbezüglich noch erweitern.
Wenn du noch weitere Fragen hast, dann immer nur her damit :-)
Je mehr Fragen, desto besser später die Doku

schöne Grüße
Martin

Hi
Wenn ich einen Wert sende funktioniert es super sende ich zwei werte an einen Konten wird mal Kanal 1 mal Kanal 2 übertragen.

Mit freundlichen Grüßen

Zitat von: cobra112 am 09 Oktober 2019, 14:09:20
Wenn ich einen Wert sende funktioniert es super sende ich zwei werte an einen Konten wird mal Kanal 1 mal Kanal 2 übertragen.

Richtig.
Bei digitalen Werten werden immer alle 16 (oder 32?) Werte auf einmal (dh in einer UDP Übertragung) übertragen.
Das heißt, wenn du nur einen dieser Werte aktualisierst, wird für die anderen wieder 0 übertragen.
Hier empfehle ich, zB alle Werte in einen dummy zu schreiben und sich im Notify auf diese zu beziehen.

Bei den analogen Werten werden immer vier Werte im Paket übertragen.
Dh, wenn du die analogen Kanäle 1 und 5 verwendest, dann werden die sich nicht gegenseitig überschreiben, weil es sich um zwei Pakete handelt.
Im ersten Paket würden die Kanäle 2-4 mit 0 überschrieben werden.
Im zweiten Paket würden die Kanäle 6-8 mit 0 überschrieben werden.
Wenn du also nur 1 und 5 nutzt, wird nix überschrieben.

Ich hoffe, ich konnte das verständlich formulieren.

Nun stellt sich die Frage, ob das Modul vorher gesendete Werte einfach speichern und immer wieder senden soll, damit nix überschrieben wird.
Die Antwort darauf habe ich noch nicht gefunden

schöne Grüße
Martin

Hi

Am besten dann alle werte in ein Dummy schreiben und dann alles auf einmal Übertragen.
Wie bekomme ich das hin?

Hab es Hinbekommen:
UVR_Temperaturen:.* set cmi sendDataAnalog 192.168.0.130 20 1={(ReadingsVal("UVR_Temperaturen","Bad_Ist","99"))};;1 2={(ReadingsVal("UVR_Temperaturen","Bad_Soll","99"))};;1 3={(ReadingsVal("UVR_Temperaturen","Dach_Ist","99"))};;1 4={(ReadingsVal("UVR_Temperaturen","Dach_Soll","99"))};;1 5={(ReadingsVal("UVR_Temperaturen","Haus_Ist","99"))};;1 6={(ReadingsVal("UVR_Temperaturen","Haus_Soll","99"))};;1

Zitat von: delmar am 09 Oktober 2019, 14:46:08
Richtig.
Bei digitalen Werten werden immer alle 16 (oder 32?) Werte auf einmal (dh in einer UDP Übertragung) übertragen.
Das heißt, wenn du nur einen dieser Werte aktualisierst, wird für die anderen wieder 0 übertragen.
Hier empfehle ich, zB alle Werte in einen dummy zu schreiben und sich im Notify auf diese zu beziehen.

Bei den analogen Werten werden immer vier Werte im Paket übertragen.
Dh, wenn du die analogen Kanäle 1 und 5 verwendest, dann werden die sich nicht gegenseitig überschreiben, weil es sich um zwei Pakete handelt.
Im ersten Paket würden die Kanäle 2-4 mit 0 überschrieben werden.
Im zweiten Paket würden die Kanäle 6-8 mit 0 überschrieben werden.
Wenn du also nur 1 und 5 nutzt, wird nix überschrieben.

Ich hoffe, ich konnte das verständlich formulieren.

Nun stellt sich die Frage, ob das Modul vorher gesendete Werte einfach speichern und immer wieder senden soll, damit nix überschrieben wird.
Die Antwort darauf habe ich noch nicht gefunden

schöne Grüße
Martin

Beim Empfangen von Daten hab ich das selbe Problem, wie kann man einstellen das er die alten werte behält?

MFG
Stefan

Zitat von: cobra112 am 09 Oktober 2019, 20:56:31
Beim Empfangen von Daten hab ich das selbe Problem, wie kann man einstellen das er die alten werte behält?

Wer sendet Daten an wen? UVR an FHEM oder umgekehrt?

Zitat von: delmar am 09 Oktober 2019, 21:07:45
Wer sendet Daten an wen? UVR an FHEM oder umgekehrt?

C.M.I. an Fhem

Ich habe gestern noch die aktuellste Version inklusive Doku-Update ins SVN gespusht.

Zitat von: cobra112 am 09 Oktober 2019, 22:50:35
C.M.I. an Fhem

Kannst du bitte Verbose vom COE_Node auf 4 stellen und den Log Output dann hier ins Forum stellen?
Je nachdem, was dort drin steht, werden dann wahrscheinlich deine readingsConfigAnalog noch interessant sein und auch, wie du die COE-Ausgänge am CMI konfiguriert hast.

Danke!
schöne Grüße
Martin

Hi

Hat sich erledigt. Nach Neustart der C.M.I. geht alles.

Ich habe einen Fehler im log, welcher mir gerade ziemliche Probleme bereitet, bzw. FHEM in bestimmten Situationen abstürzen lässt:

019.10.30 17:53:54 3: CanOverEthernet (CMI) - Define done ... module=CanOverEthernet
Can't call method "fileno" on an undefined value at ./FHEM/70_CanOverEthernet.pm line 76.

Wie bekomme ich den Fehler weg?

Zitat von: Bualicher am 30 Oktober 2019, 18:09:25
Ich habe einen Fehler im log, welcher mir gerade ziemliche Probleme bereitet, bzw. FHEM in bestimmten Situationen abstürzen lässt:

Code Auswählen Erweitern

019.10.30 17:53:54 3: CanOverEthernet (CMI) - Define done ... module=CanOverEthernet
Can't call method "fileno" on an undefined value at ./FHEM/70_CanOverEthernet.pm line 76.

Hi,
meine Vermutung ist, dass schon ein anderer Prozess den selben Port geöffnet hat.
Entweder, du hast eine vorige Instanz von FHEM selber noch als Zombie-Prozess laufen, oder ein anderes Script, dass auf 5441 horcht, oder du hast vielleicht zwei CanOverEthernet devices definiert?

Wenn du fhem stoppst und folgenden Befehl ausführst, solltest du sehen, wer sonst noch auf 5441 horcht:

sudo lsof -i tcp:5441


Hoffe, das hilft
schöne Grüße
Martin

Hallo Martin,

vielen Dank für die Arbeit, die du in dieses Modul steckst. Für alle, die FHEM im Docker-Container laufen lassen, gleich der Hinweis, dass bei der Port-Freigabe unbedingt  "5441:5441/udp"  stehen muss, also mit /udp, das war bei mir das Problem, warum es lange nicht funktioniert hat.
Ich kann jetzt Werte problemlos vom CMI empfangen, aber auch analoge Werte senden. Beim senden von digitalen Werten z.B. mittels "set coe sendDataDigital 192.168.0.67 50 1=1" stürzt FHEM sofort ab. Im LOG steht:
Can't use string ("1") as an ARRAY ref while "strict refs" in use at ./FHEM/70_CanOverEthernet.pmline 266.

Vielleicht kannst du mir hier helfen.

Danke Silvio

Zitat von: silvkat am 31 Oktober 2019, 13:57:54
Für alle, die FHEM im Docker-Container laufen lassen, gleich der Hinweis, dass bei der Port-Freigabe unbedingt  "5441:5441/udp"  stehen muss, also mit /udp, das war bei mir das Problem, warum es lange nicht funktioniert hat.

Richtig, danke für die Anmerkung. Ich kann bei Gelegenheit das Modul so erweitern, dass auch andere Ports verwendet werden können. Ist notiert.

Zitat von: silvkat am 31 Oktober 2019, 13:57:54
Ich kann jetzt Werte problemlos vom CMI empfangen, aber auch analoge Werte senden. Beim senden von digitalen Werten z.B. mittels "set coe sendDataDigital 192.168.0.67 50 1=1" stürzt FHEM sofort ab. Im LOG steht:
Can't use string ("1") as an ARRAY ref while "strict refs" in use at ./FHEM/70_CanOverEthernet.pmline 266.

Tatsächlich. Sorry, das hatte schon funktioniert, dürfte später wieder kaputt gegangen sein.
Ist auch notiert, wird natürlich asap repariert. Kann ich aber noch nicht genau sagen, ob 1 Tag oder 1 Woche...

schöne Grüße
Martin

Zitat von: delmar am 31 Oktober 2019, 14:31:37
Beim senden von digitalen Werten z.B. mittels "set coe sendDataDigital 192.168.0.67 50 1=1" stürzt FHEM sofort ab.

Fix ist gepusht, sollte morgen übers Update verfügbar sein.

schöne Grüße
Martin

Danke,

hab´s eben probiert und es geht wie im Wiki beschrieben. Super.

Erst mal Vielen Dank an delMar für das Modul! ;)
Werde in Kürze ebenfalls stolzer Besitzer einer UVR16x2 sein und würde gerne wissen, ob man von zwei unterschiedlichen FHEM Instanzen auf eine C.M.I. zugreifen kann oder ob man den Umweg via FHEM2FHEM gehen muss?

Zitat von: chunter1 am 27 November 2019, 09:26:52
Werde in Kürze ebenfalls stolzer Besitzer einer UVR16x2 sein und würde gerne wissen, ob man von zwei unterschiedlichen FHEM Instanzen auf eine C.M.I. zugreifen kann oder ob man den Umweg via FHEM2FHEM gehen muss?

Die Kommunikation mit dem CMI erfolgt nur über UDP - das ist Stateless.
Das heißt, du kannst von so vielen verschiedenen "Dingern" wie du willst, Daten an das CMI schicken.

Ähnlich ist es in die andere Richtung.
Wenn du den selben Wert vom CMI an 2 FHEM-Instanzen schicken willst, dann musst du das allerdings 2x am CMI konfigurieren. Je einmal pro Ziel-IP.
(die Konfiguration von der UVR zum CMI muss aber nur 1x sein)


schöne Grüße
Martin

Super, danke für die Erklärung!

Hab die UVR16x2 jetzt konfiguriert und erfolgreich am Laufen.  :D
Datenübertragung in beide Richtungen funktioniert einwandfrei.
Nur folgendes Verhalten ist mir nicht ganz klar...
Ein z.B. Temperaturwert wird immer nur dann übermittelt, wenn er sich geändert hat und das, obwohl die "Intervallzeit" auf der UVR16x2 sowie auf der CMI auf 2 Minuten eingestellt ist.
Lieg ich richtig, dass "Intervallzeit" nur bedeutet, dass der Wert in diesem Intervall auf Änderung geprüft wird aber nicht defaultmäßig übermittelt wird?
Wenn ja, dann versteh ich den Sinn der Blockierzeit nicht.  :o

Ich weiß nicht, ob ich mit meinem Thema hier ganz richtig bin, oder ob ich jeweils ein neues eröffnen soll:

Ich habe CMI (UVR16x2) und FHEM erfolgreich mittels CoE gekoppelt. Die meiste Zeit funktioniert das Update (analog/digital + read/write) auch ohne Probleme.
Wo ich zZ hänge ist:

1) Stateformat beim automatisch angelegten Device COE_Node_XXX. Hier bekomme ich nur ein definded als STATE. Sobald ich ein stateformat zu definieren, passiert in der Anzeige nichts, aber die Häufigkeit von Updatefehlern nimmt zu (das ist aber erstmal eine Vermutung).

2) Ich schaffe es nicht, dass Werte, die über CoE im fhem landen mittels logdb in die DB geschrieben werden. ich habe meine logdb zentral über .*:(WertA|WertB|etc).* definiert. Bei meinen restlichen Sensoren funktioniert das reibungslos.

Mein Problem mit den Ausfällen beim "CoE sendDataAnalog" via notify bin ich noch beim loggen, um das ganze etwas einschränken zu können.

Hallo!

Sorry für die extrem späte Antwort, ich habe keine Email Benachrichtigung über deine Nachricht erhalten.
Du bist hier komplett richtig mit deinen Fragen.

Zitat von: flobeewan am 13 Dezember 2019, 16:31:14
1) Stateformat beim automatisch angelegten Device COE_Node_XXX. Hier bekomme ich nur ein definded als STATE. Sobald ich ein stateformat zu definieren, passiert in der Anzeige nichts, aber die Häufigkeit von Updatefehlern nimmt zu (das ist aber erstmal eine Vermutung).

Kannst du die device definition und ein 'list' vom entsprechenden device mal hier reinstellen?
Ich verwende selber stateformat mit einem COE_Node device und es funktioniert.

Zitat von: flobeewan am 13 Dezember 2019, 16:31:14
2) Ich schaffe es nicht, dass Werte, die über CoE im fhem landen mittels logdb in die DB geschrieben werden. ich habe meine logdb zentral über

Code Auswählen Erweitern

.*:(WertA|WertB|etc).* definiert. Bei meinen restlichen Sensoren funktioniert das reibungslos.

LogDB mach ich auch, und auch das funktioniert bei mir.
Mein Define enthält allerdings folgenden Teil: dum_ta_coe:.*:.*
Unterschiede zu deinem ist, dass ich am Ende nochmal ein :.* drangehängt habe. Warum, weiß ich auch nicht mehr.

Warum du keine stabile Verbindung zustande kriegst, kann ich leider auch nicht sagen.
Es könnte aber auch ein CMI Problem sein. Anscheinend ist die ziemlich anfällig für stark Frequentierte Netzwerke - nur um ein Beispiel zu nennen.

Oder gibts mittlerweile vielleicht schon ein Update zu deinen Problemen?
Sorry nochmal, dass du so lange keine Antwort gekriegt hast.

schöne Grüße
martin

Hallo Martin,
das Modul funktioniert bei mir mit UVR1611 und CMI seit einigen Wochen sehr zuverlässig und performant. Die beiden letzten Tage habe ich aber gesehen, daß bei Minustemperaturen die Rückgabewerte unsinnig sind. Sobald der Aussenfühler der Heizung unter 0 Grad hat, sind die angezeigten Werte im CMI richtig, COE_Node jedoch zeigt dann dafür Fantasiewerte im Minusbereich an. Z.B. -3276.8 Grad für -0.1 Grad und andere ähnliche Werte. Kannst Du bitte mal nachsehen, wo hier ein Überlauf durch das Minus stattfindet und das ändern? Danke im Voraus
Achim

Zitat von: tomcat089 am 24 März 2020, 15:45:08
Hallo Martin,
das Modul funktioniert bei mir mit UVR1611 und CMI seit einigen Wochen sehr zuverlässig und performant. Die beiden letzten Tage habe ich aber gesehen, daß bei Minustemperaturen die Rückgabewerte unsinnig sind. Sobald der Aussenfühler der Heizung unter 0 Grad hat, sind die angezeigten Werte im CMI richtig, COE_Node jedoch zeigt dann dafür Fantasiewerte im Minusbereich an. Z.B. -3276.8 Grad für -0.1 Grad und andere ähnliche Werte. Kannst Du bitte mal nachsehen, wo hier ein Überlauf durch das Minus stattfindet und das ändern? Danke im Voraus
Achim

Hallo!

Auf welchem System läuft FHEM bei dir?
Das wird wohl ein big-endian little-endian problem sein, was bedeuet, dass das Problem zB auf einem Raspi auftreten kann, auf einer x86/x64 CPU aber nicht.

Danke!
schöne Grüße
Martin

Ja, bei mir läuft FHEM auf einem Raspi.

Zitat von: tomcat089 am 24 März 2020, 15:53:24
Ja, bei mir läuft FHEM auf einem Raspi.

ok, seltsam. bei mir auch...
um welchen wert handelt es sich? bzw um welche einheit?
es gibt mehrere typen für temperaturen, evtl hab ich da was übersehen...
ich werd versuchen, am abend einen blick auf den code zu werfen.
ein log-auszug auf verbose 5 (für das CanOverEthernet und das COE_Node wo das Problem auftritt) wären gut...
Danke!

ich logg das mit verbose 5 heute Nacht mit. Bei dem schönen Wetter haben wir hier sicher wieder Nachtfrost. Sonst könnte man den Fehler gar nicht sehen.
Ich schick Dir morgen die Protokolle.
Bis dann Achim

Alles klar.
Ich brauch nicht die ganzen Logs, es reichen die Zeilen, wo der Wert reinkommt, der dann als negativ angezeigt wird (nur, damit du hier nicht gigabytes an logs hochladen musst)

schöne Grüße
Martin

So, anbei ein Auszug aus dem Log von letzter Nacht. Ich habe noch einen richtigen Wert dazugenommen, also Temperatur 0.0.
Mir ist aufgefallen, daß die fhem LogDatei seit diesem Monat irgendwie als Big5 abgespeichert wird. Bin mir aber nicht bewußt, daß ich am Raspi oder Fhem irgendeine Änderung der Sprache gemacht habe. Sollte aber für das Problem hier keine Rolle spielen.
Bye Achim

Um die letzte Anwort klarer auszudrücken: Im Log bei coe kommen anscheinend Sonderzeichen vor, die dann von Npp als Big5 interpretiert werden:
"coe: dispatch 8\001�\001�\001~\001�\001\001\001\001\001"
So sieht das Ganze im Fhem-UI aus.

Danke für die Infos.

Hast du am CMI unter Einstellungen->Eingänge-CAN-Bus bei "Einheit" etwas eingestellt, oder steht das auf AUTOMATISCH?
Bzw, wird hier ganz unten der richtige Wert angezeigt?

Analog dazu, bitte unter Ausgänge->COE->Analog auch mal reinschauen, was da eingestellt ist, und ob der Wert ganz unten dem aktuellen entspricht

Danke!

schöne Grüße
Martin

Die Eingänge laufen bei mir alle über "Datenleitung->Analog" nicht "CAN-BUS->Analog". Dort habe ich dann "Einheit"-> "Temperatur" eingestellt.

Habe jetzt einen Kurschluß auf dem betreffenden AnalogEingang hergestellt, da es letzte Nacht zu warm war um ins Minus zu kommen: Bei Einheit "Temperatur" bekomme ich in CMI die gewünschte Temperatur von -999.9°C bei "Auto" ist es ein falsches -180,7°C. Im fhemCoE habe ich dann -2276.9 bzw. bei Auto -22769.

Zitat von: tomcat089 am 27 März 2020, 11:39:06
Die Eingänge laufen bei mir alle über "Datenleitung->Analog" nicht "CAN-BUS->Analog". Dort habe ich dann "Einheit"-> "Temperatur" eingestellt.

Habe jetzt einen Kurschluß auf dem betreffenden AnalogEingang hergestellt, da es letzte Nacht zu warm war um ins Minus zu kommen: Bei Einheit "Temperatur" bekomme ich in CMI die gewünschte Temperatur von -999.9°C bei "Auto" ist es ein falsches -180,7°C. Im fhemCoE habe ich dann -2276.9 bzw. bei Auto -22769.

Hi Tomcat,
die Temperaturen fallen wieder, und ich wollte mich nun endlich mal um dein Problem kümmern.
Deine Log-auszüge sind sehr hilfreich, trotzdem habe ich noch keine Lösung.
Es scheint, also bei dir eine Temperatur nur 1 byte lang wäre, anstatt 2.

Unter Eingang-Datenleitung-Analog hast du Temperatur eingestellt. Gut.
Was hast du dann unter Ausgang-CoE-Analog eingetellt? Vielleicht liegt dort das Problem...

EDIT: Ich habe bei mir auch Temperatur-Werte über die Datenleitung, die greife ich aber auf der UVR ab und sende sie von dort bereits über CoE weiter. Am CMI-UI ist DL somit garnicht mehr verwendet.

schöne Grüße
Martin

Hallo,

ein sehr schönes Modul und gute Beschreibung in der WIKI.
Habe gerade ein UVR67 und CIM Gerät mit diesem Modul erfolgreich eingebunden.

Kleiner Hinweis am Rande (hat nur indirekt mit dem Modul zu tun):

Bei mir wurde standardmäßig die CIM nicht als Knoten 1 im CPAN  angelegt.
Hatte zunächst Probleme, dass Datum/Uhrzeit nicht von der CIM an die UVR67 weitergeleitet wurde.
Für die Weiterleitung von   Datum/Uhrzeit  muss jedoch CIM als Knoten 1 definiert sein.

VG

Zitat von: LudgerR am 03 Dezember 2020, 12:30:10
Für die Weiterleitung von   Datum/Uhrzeit  muss jedoch CIM als Knoten 1 definiert sein.

Freut mich, dass es gut funktioniert.

Ja, das mit der Weiterleitung von Datum und Uhrzeit stimmt.
Ich werde das in die Doku mit aufnehmen.
Danke
LG

Hallo beisammen,
ich beschäftige mich gerade mit diesem Modul und will mein16x2 Touch damit ansprechen.
Im Wiki steht, daß man bei der Senderichtung fhem->CMI->16x2 die "Einheit" des
gesendeten Wertes angeben muß (z.b. 1= Temperatur). Beschrieben wäre es in einem
verlinkten Dokument bei TA. In diesem finde ich nur allgemeines zu CanOverEthernet.

In der Doku bei TA über die JSON-Schnittstelle habe ich folgendes gefunden https://www.ta.co.at/download/datei/17511763-cmi-json-api/ (https://www.ta.co.at/download/datei/17511763-cmi-json-api/):

6.2.4.2. Unit
Indicates, which unit has to be used for the value.
Unit-ID German English
0
1°C °C
2 W/m² W/m²
3 l/h l/h
4 Sek sec
5 Min min
6 l/Imp l/Imp
7 K K
8 % %
10 kW kW
11 kWh kWh
12 MWh MWh
13 V VTechnische Alternative GmbH mail@ta.co.at TB
Langestraße 124 technik@ta.co.at 2019-07-02
A-3872 Amaliendorf +43 (0) 2862 53635 Seite 7 von 9
14 mA mA
15 Std hr
16 Tage Days
17 Imp Imp
18 kΩ kΩ
19 l l
20 km/h km/h
21 Hz Hz
22 l/min l/min
23 bar bar
24
25 km km
26 m m
27 mm mm
28 m³ m³
35 l/d l/d
36 m/s m/s
37 m³/min m³/min
38 m³/h m³/h
39 m³/d m³/d
40 mm/min mm/min
41 mm/h mm/h
42 mm/d mm/d
43 Aus/EIN ON/OFF
44 NEIN/JA NO/YES
46 °C °C
50 € €
51 $ $
52 g/m³ g/m³
53
54 ° °
56 ° °
57 Sek sec
58
59 % %
60 Uhr h
63 A A
65 mbar mbar
66 Pa Pa
67 ppm ppm
68
69 W W

Sind das die Codes die ich suche?

Grüße Martin

Hallo

Zitat von: alpine310 am 22 Dezember 2020, 17:09:39
In diesem finde ich nur allgemeines zu CanOverEthernet.

Du hast recht, danke für den Hinweis. Entweder das Dokument wurde verändert, oder der Link war schon immer falsch.

Zitat von: alpine310 am 22 Dezember 2020, 17:09:39
Sind das die Codes die ich suche?

Ja, das sind sie.

Im Zweifel kannst du aber auch experimentieren, man kann hier nichts kaputt machen, falls man zB statt Temperatur eine andere Einheit angeben würde.

schöne Grüße
Martin

Hallo

Ich versuche im Moment Werte an meine 16x2 zu senden und habe dabei folgendes Problem:

Wenn ich in der Kommandozeile von fhem eingebe:

set cmi sendDataAnalog 192.168.2.3 1 1=20;0

dann passiert..nichts in der 16x2 und ich finde nichts im log

Wenn ich aber die Oberfläche von meinem Device "cmi" benutzte und dort
192.168.2.3 1 1=20;0
eingebe, auf "set" klicke dann ist der Wert sofort in der 16x2 vorhanden.....

und im log steht
2020.12.23 11:09:35 1: jsLog: FW_queryValue:{ReadingsVal('cmi','sendDataAnalog','')}
2020.12.23 11:09:35 1: jsLog: FW_queryValue:{AttrVal('cmi','room','')}

Nach jeder "set-Variante" habe ich in der fhem Oberfläche nur noch eine 1 als Rückmeldung stehen

Ich bin gerade etwas ratlos..

Gruß Martin

Zitat von: alpine310 am 23 Dezember 2020, 11:15:14

Wenn ich in der Kommandozeile von fhem eingebe:

Code Auswählen Erweitern

set cmi sendDataAnalog 192.168.2.3 1 1=20;0

dann passiert..nichts in der 16x2 und ich finde nichts im log

Hallo,
ich glaube, du musst in der Kommandozeile
set cmi sendDataAnalog 192.168.2.3 1 1=20;;0
eingeben, da das Semikolon ansonsten zum Trennen mehrerer Befehle dient.

Über den Device-Screen wird das automatisch richtig gemacht.

Ja so geht´s

ich habe den Syntax aus dem Wiki genommen...da steht nur  ";"
...cobra112 hatte im Forum seinen Vorschlag tatsächlich mit ";;" geschrieben..   ;)

Danke

Ich werde das im Wiki auch korrigieren, danke für den Hinweis.
Der Eintrag von Cobra112 wurde im Nachhinein bearbeitet. Ich Wette, die ";;" waren noch nicht drin, als ich das rüberkopiert habe ;-)

Danke!
schöne Grüße

Hallo delMar,

vielen Dank für Dein Modul. Ich lese damit seit einiger Zeit schon erfolgreich Werte aus meiner UVR16x2 über das CMI aus.

Nun habe ich versucht, auch Werte an die UVRx2 (Knoten 2) zu senden, komme aber leider nicht zum Ziel.

Ein manuelles

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

kommt leider nicht bei der UVR16x2 an. Auch der Versuch an ein CAN-EZ2 (Knoten 3) oder CAN-EZ3 (Knoten 4) zu senden, funktioniert leider nicht.

Im Logfile erscheint nichts, aber iwas schein zu passoeren, denn mein CAN-Bus scheint danach eine Zeit lang gestört. In der CAB-Bus Übersicht erscheint über den Icons der Geräte entweder der Schriftzug "COE" oder ein Einbahnstraßen-Icon.

Hallo Jürgen,

ich krieg auch jedes Mal einen Knoten im Hirn, wenn ich mir das neu durchdenken muss.
Ich hab selber nur ein UVR16x2 als einziges echtes COE Gerät, deshalb kann ich das Szenario nicht 1:1 wie bei dir durchspielen.

Aber lass es uns versuchen:

Zitat von: JuergenNiessen am 03 Januar 2021, 20:38:59

Code Auswählen Erweitern

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

Der Befehl scheint richtig.
Wenn das CMI hier den CoE Schriftzug zeigt, dann wurde ein unbekanntes, aber gültiges COE-Device erkannt.
Was machst du anders, wenn das rote Fehlersymbol erscheint?

Eigentlich sollte nur noch fehlen, dass du am EZ-2 und EZ-3 jeweils einen CAN-Analogeingang pro Wert definierst.
Knotennummer ist 2, die Ausgangsnummern sind 5, 6, 7 und 8.

Knoten 2 muss dann am CMI als generisches CoE Device gelistet werden, alle anderen Knoten sollten so wie bisher auch angezeigt werden.
Dass es für den CoE-Knoten am CMI keine ordentliche Visualisierung gibt (dein letzter Screenshot), ist normal.
Dahingehend ist im Modul nichts implementiert, es gibt auch keine Doku dazu.
Die Konfiguration erfolgt direkt in FHEM.

Ich hoffe, das hilft, gib Bescheid wie's läuft.

schöne Grüße
Martin

PS: interessantes Gerät, das EZ-3. Ich glaub, so eins brauch ich auch :-)

Hallo,
ich bin ein totaler Neuling in FHEM. Von daher bitte Sorry, wenn ich eine dumme Frage stelle. Ich bin tatsächlich dumm...

Ich habe es bis jetzt hinbekommen, dass ich einen Temperatur-Sollwert von der UVR1611 über CAN-Bus-Analogausgang, das CMI und CanOverEthernet an einen MAX-Heizkörperthermostat schicke.
Jetzt möchte ich umgedreht den Temperatur-Istwert vom Thermostat zurück an die UVR schicken. Dass sich der Wert nur sporadisch ändert, ist mir egal.

Das entsprechende Notify, das ich mir zusammengebastelt habe, sieht so aus:
AZ_HK_hinten:temperature:.* set cmi sendDataAnalog 192.168.188.99 2 7 $EVTPART1
Was ich damit erreichen will: Wenn sich von AZ_HK_hinten der Wert temperature ändert, möchte ich den Analogwert über mein CMI mit der IP-Adresse 192.168.188.99 an die UVR mit der Knoten-Nummer 2 an den Analaog-CAN-Eingang 7 schicken.
Erste Frage: Müsste das so funzen?
Zweite Frage: Was muss ich in der UVR am CAN-Analogeingang als Sendeknoten- und Netzwerkausgangs-Nummer eintragen? Als Knotennummer sicher die vom CMI?

Danke!

Zitat von: Stephanz am 06 Januar 2021, 19:34:14
Das entsprechende Notify, das ich mir zusammengebastelt habe, sieht so aus:

Code Auswählen Erweitern

AZ_HK_hinten:temperature:.* set cmi sendDataAnalog 192.168.188.99 2 7 $EVTPART1
Was ich damit erreichen will: Wenn sich von AZ_HK_hinten der Wert temperature ändert, möchte ich den Analogwert über mein CMI mit der IP-Adresse 192.168.188.99 an die UVR mit der Knoten-Nummer 2 an den Analaog-CAN-Eingang 7 schicken.
Erste Frage: Müsste das so funzen?

Was du vorhast, muss natürlich funktionieren. Das Notify stimmt aber noch nicht ganz:

AZ_HK_hinten:temperature:.* set cmi sendDataAnalog 192.168.188.99 2 7=$EVTPART1;;1


Zitat von: Stephanz am 06 Januar 2021, 19:34:14
Zweite Frage: Was muss ich in der UVR am CAN-Analogeingang als Sendeknoten- und Netzwerkausgangs-Nummer eintragen? Als Knotennummer sicher die vom CMI?

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.

Eventuell könnte es mit $EVTPART1 geben, falls als Nachkommastellenzeichen , statt . (oder umgekehrt) geliefert wird.
Ich hoffe, das hilft.

Schöne Grüße
Martin

Hallo delMar,
funktioniert.
Allerdings werden nur Zehntelgrad übertragen, also wenn 12,1 Grad gemessen werden, kommt in der UVR 121 an.
Ohne die ;;1 kommt gar nichts an, wahrscheinlich, weil dann das CMI mangels Maßeinheit der Meinung ist, dass es das so nicht weitergeben kann.
Aber da finde ich eine Lösung in der UVR.
Vielen Dank!

Zitat von: Stephanz am 07 Januar 2021, 13:27:01
Allerdings werden nur Zehntelgrad übertragen, also wenn 12,1 Grad gemessen werden, kommt in der UVR 121 an.
Ohne die ;;1 kommt gar nichts an, wahrscheinlich, weil dann das CMI mangels Maßeinheit der Meinung ist, dass es das so nicht weitergeben kann.

Das ;;1 gibt an, dass es sich um eine Temperatur handelt, nicht zB kW/h oder l/min oder EIN/AUS oder sonstiges.
Es kann aber sein, dass das UVR1611 diese Information nicht auswertet.

Auszug aus der Doku (Manual_UVR1611-N_A5.02.1_Relaisversion_Allgemein.pdf) von der Homepage des Herstellers, Seite 39

Zitat
Annahme: Am CAN-Knoten 2 ist der analoge Netzwerkausgang 1 mit der Außentemperatur belegt.
Die Übertragung erfolgt immer ohne Einheit und ohne Bezeichnung. Der Empfangsknoten erhält
daher als einzige Information die Zahl 234. Erst über die Verknüpfung mit einer Funktion z.B. Eingangsvariable Außentemperatur im Funktionsmodul HEIZKREIS wird der korrekte Wert angezeigt:
23,4°C.

Viele weitere Infos (zB auch, wie du dann mehrere Werte richtig an die UVR schickst, nicht nur einen), findest du übrigens hier: https://wiki.fhem.de/wiki/CanOverEthernet

schöne Grüße
Martin

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

Zitat von: delMar am 07 Januar 2021, 00:22:06
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:
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 ;-)

Zitat von: JuergenNiessen am 08 Januar 2021, 15:05:20
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 ;-)

Zitat von: delMar am 08 Januar 2021, 15:21:35
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?

Zitat von: JuergenNiessen am 08 Januar 2021, 15:23:38
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.

Zitat von: delMar am 08 Januar 2021, 15:32:44
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

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# (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.:

ZitatIm 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 (https://github.com/thhoe/coe-mi/blob/master/coe/COE_Doku.pdf)

und das dort beschriebene "udp test tool 3.0"

Das mit dem virtuellen Knoten muss ich unbedingt noch ausprobieren.

ZitatWenn 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.

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

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!

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

Schön, wenns nun klappt :)

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

Mein DOIF schaut wie folgt aus:

Zitat([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:

Zitat{ 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.

Hallo,

Zitat von: chunter1 am 31 Januar 2021, 13:18:02
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.


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

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:

([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
})

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

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 (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

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

Hallo beisammen
ich habe das Modul schon länger in Betrieb und es funktioniert auch soweit gut. Ich kann Daten aus
meiner UVR16x2 lesen und auch Werte in die UVR 16x2 schreiben.

Allerdings hatte ich immer wieder Probleme mit der CAN-Verbindung zwischen CMI und UVR.
Jetzt bin ich darauf gekommen, daß das durch das Schreiben von Werten aus fhem verursacht wird.

Nach einem Neustart des CMI ist alles in Ordnung. Die UVR ist im Menü CAN-Bus der CMI vorhanden.
In meinem Schema in der CMI sind auch alle Werte zu sehen und ich kann auch über das CMI auf
meine UVR zugreifen (siehe Screenshot´s)

Nach dem senden von Werten mit set cmi sendDataAnalog 192.168.2.3 1 1=0;0 2=0;0 3=0;0

ist die CAN-Verbindung gestört. Die Daten sind allerdings in der UVR angekommen.

Im Menü CAN-Bus der CMI ist das COE-Symbol zu sehen, im Schema der CMI gibt es keine Daten
und auf die UVR kann ich auch nicht mehr zugreifen (siehe Screenshot's).
Komischerweise funktioniert das Lesen und Schreiben der Daten über COE immer problemlos.

Sobald ich das CMI neu starte funktioniert alles wieder. Das ganze kann ich jederzeit reproduzieren.

Das ganze ist für mich etwas unschön, da ich regelmäßig über das Netzwerk auf mein "Schema"
und die UVR zugreifen will.

Wer kann mir weiterhelfen?

Grüße Martin

Hallo Martin,

die Doku und der Befehl sendData sind da leider nicht optimal.

Bei sendDataAnalog gibst du als Node "1" an.
Das liest sich als "sende analoge Daten an Node 1". Was deine UVR wäre.

Eigentlich wäre die richtige Lesart aber "veröffentliche analoge Daten von Node 1" sein.
Und hier ist das Problem. Node 1 ist deine UVR.
FHEM sagt aber, es veröffentlicht Daten von Node 1. Deshalb der Konflikt und der Streik des CMI.

Der richtige Weg ist, für alle Daten, die du aus FHEM heraus sendest, dir einen "virtuellen CAN Node" für FHEM vorzustellen.
In FHEM wäre das dann:

set cmi sendDataAnalog 192.168.2.3 2 1=0;0 2=0;0 3=0;0

(Der Parameter nach der IP ist nun 2)

Damit kann JEDER Can-Node im CAN-Netz nun festlegen, dass er von Can-Node 2 die Werte 1,2 und 3 lesen soll.

Sorry, es ist etwas verwirrend, sendDataAnalog ist leider ein sehr schlechter Name

Hoffe, das hilft.

schöne Grüße
Martin

Hallo Martin
das ist echt etwas verwirrend....aber jetzt funktioniert es.

Jetzt verstehe ich auch woher bei mir im CAN-Netzwerk immer der COE-Knoten 5
herkam (hatte in fhem "fälschlicherweise" die 5 verwendet).

Ich würde für alle die das später mal lesen zusammenfassen:

1. Ich denke mir für fhem eine eigene CAN-Knotennummer aus hier als Beispiel 5 (darf noch nicht vorhanden sein!!)
2. Die verwende ich dann für sendData in fhem (z.B. set cmi sendDataAnalog 192.168.2.3 5 1=0;0 2=0;0 3=0;0)
3. In der UVR muß ich unter CAN-Eingänge die 5 konfigurieren (siehe Screenshot)

Das könnte man im Wiki vielleicht genauer erklären.

Vielen Dank

Martin

Freut mich, dass es jetzt passt.

Ich hatte gedacht, das am Wiki auch so erklärt zu haben, aber du hast recht: ist es nicht.
Danke für den Hinweis, werde ich verbessern

schöne Grüße
Martin

Hallo Martin,

ich habe versucht die falschen Werte bei negativen Temperaturen zu korrigieren.
Falls Du das liest kannst Du die Änderung in der angehängten Version vielleicht einchecken.

Gruß Nico

Super, danke.

Ich werd das bei nächster Gelegenheit reinnehmen.
Ich muss aber erst meinen Raspi "reparieren", wo ich FHEM Entwicklung drauf mache. Da hat sich die SD-Karte verabschiedet  :(

schöne Grüße
Martin

Hallo Martin,

habe dasselbe Problem mit den negativen Temperaturen, daher wollte ich mal nachfragen, ob du schon die Möglichkeit hattest die Änderungen reinzunehmen?

Sonst ein grosses Danke für das Modul. Funktioniert bei mir bis auf die negativen Temps einwandfrei.

Alles Gute
Holger

danke fürs anstupsen.

hab jetzt mein dev-system wieder reaktiviert und das file aus dem anhang ins SVN gegeben.
Sollte ab morgen früh im Update sein.

Bitte Bescheid geben, wenns ein Problem gibt

schöne Grüße
Martin

Hi Martin,

Hab das Update vor drei Tagen eingespielt, Fhem neu gestartet. Leider bleibt es dabei, dass die negativen Temperaturen bei mir zumindest nicht richtig angezeigt werden. Kann es sein, dass bei mir was falsch konfiguriert ist?

Screenshot wie es derzeit bei mir aussieht im Bild anbei.
Ist im 2. Graph zu sehen.

Danke dir für die Hilfe.

Beste Grüsse
Holger

Kannst noch einen Log Auszug mit Verbose 5 dazugeben?
Werde versuchen, mir am Abend Zeit zu nehmen

Ja klar. Hab aber log mit verbose 5 grad erst aktiviert. Werde also am Nachmittag/ frühen Abend dann einen ersten log schicken.
Hoffe das passt so.

Grüsse
Holger

Klar

Danke

Hi Martin, 

ich hoffe du kannst mit dem Log was anfangen.
Tut mir leid, aber ich bin da nicht so bewandert darin und hatte echt Probleme überhaupt Log Daten zu generieren.

Und danke nochmals für die Unterstützung. Echt klasse von dir.

Danke
Holger

Danke für das Log-File. Alles richtig gemacht  :)

Handelt es sich hier um den Wert, der von DL kommt? Hab ich das richtig gelesen?

Weil: mir ist eingefallen, dass ich das Problem in einer früheren Antwort hier schon mal mit einem Nebensatz erwähnt hab.
Dieses Problem mit negativen Temperaturen tritt dann auf, wenn du direkt einen DL-Wert in das CMI importierst.

Du kannst auch direkt an deiner UVR oder RSM oder wasauchimmer einen COE-Analogausgang definieren, der als Eingang den DL-Bus nimmt.
Und den holst du dir dann im CMI genauso rein, wie die anderen Werte.

Ich hab da mal zwei Screenshots angehängt.
Ich kann dein Problem leider nicht "automatisch" lösen, weil beim Empfangen des Wertes die Information fehlt, ob dieser Wert aus DL-Bus oder von woanders gekommen ist.

Mit anderen Worten: der Wert vom DL-Bus muss schon auf deiner Steuerung gelesen werden, und von dort aus als CoE Wert ans CMI geschickt werden.
Holt das CMI den Wert direkt, ist die Konvertierung leider falsch.

Lass mich wissen, ob das verständlich war.

schöne Grüße
Martin

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

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

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

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

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:

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:


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:

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:

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


Stephan

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.


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

Hallo Martin,

herzlichen dank für die ausführliche Antwort.

Zitat von: delMar am 14 Februar 2022, 13:55:30
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.

Zitat von: delMar am 14 Februar 2022, 13:55:30
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.

Zitat von: delMar am 14 Februar 2022, 13:55:30
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.

Zitat von: delMar am 14 Februar 2022, 13:55:30
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.

Zitat von: delMar am 14 Februar 2022, 13:55:30
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

Zitat von: hausbau_toel am 14 Februar 2022, 21:57:04
"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  :o

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

schöne Grüße
Martin

Halo Martin,

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

Viele Grüße
Frank

Zitat von: delMar am 22 März 2021, 09:22:18
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

Zitat von: trabantp60 am 24 April 2022, 16:28:46
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:

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

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...

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.

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.

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

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

Frank, welche Firmware Version hast du auf der UVR1611 laufen?
Soweit ich mich erinnere, gibt es zwei Hardware-Revisionen, wobei die zweite stärkere Hardware hat und die aktuellsten Firmware Versionen nur für die neuere Hardware-Revision verfügbar waren.

es läuft die A3.30 auf der UVR1611 mit der Seriennummer 049197.
Nach der Beschreibung der T.A. (https://www.ta.co.at/download/firmware/#) bin ich mir nicht sicher, ob auch höhere Firmwarenummern lauffähig wären.

Ich hab eine UVR1611, die ist derzeit aber nicht verwendet.
Falls bis dahin von niemand was gekommen ist, kann ich die am Wochenende gern anschließen und durchprobieren.
Den Rest der Woche bin ich leider beruflich unterwegs, deshalb kann ich nicht früher.

Da wäre ich Dir zu tiefem Dank verpflichtet. Aber vielleicht ja nicht nur ich, weil das Thema auch andere interessiert...

Hallo Frank,

tatsächlich habe ich nun auch keine Möglichkeit gefunden, die Betriebsart zu Exportieren.

Übers Web-Interface kriegt man nur eine komplette HTML-Antwort, aber nicht alleine die Werte
menupage.cgi?page=1206580E liefert (nur ein Auszug)


<hr>&nbsp;&nbsp;&nbsp;&nbsp;HEIZKREISREG.<br>
<hr>BEZ.:&nbsp;&nbsp;&nbsp;HEIZKR.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
FUNKTIONSSTATUS:&nbsp;&nbsp;&nbsp;&nbsp;<a href="menupage.cgi?page=12065905">➤</a><br>
EINGANGSVARIABLE:&nbsp;&nbsp;&nbsp;<a href="menupage.cgi?page=12065903">➤</a><br>
AUSGANGSVARIABLE:&nbsp;&nbsp;&nbsp;<a href="menupage.cgi?page=12065904">➤</a><br>
<br>
BETRIEB:&nbsp;ZEIT/AUTO&nbsp;&nbsp;<a href="129006301C" id="a129006301C" class="changer">⇔</a><span id="129006301C" class="changer"></span><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ABGESENKT<br>
<br>
RAUMTEMPERATUR:<br>
Traum.IST:&nbsp;&nbsp;AUS<br>
Traum.ABSENK:&nbsp;16 °C&nbsp;<a href="12B006300D" id="a12B006300D" class="changer">⇔</a><span id="12B006300D" class="changer"></span><br>
Traum.NORMAL:&nbsp;20 °C&nbsp;<a href="12B006300C" id="a12B006300C" class="changer">⇔</a><span id="12B006300C" class="changer"></span><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ZEITPROG.:&nbsp;<a href="menupage.cgi?page=1206580F">➤</a><br>
Vorhaltezt.:&nbsp;&nbsp;0 Min&nbsp;<a href="12B1063046" id="a12B1063046" class="changer">⇔</a><span id="12B1063046" class="changer"></span>


Da müsste man sich was bauen, dass die entsprechenden Werte rauskopiert. Eine andere Möglichkeit sehe ich derzeit nicht, an den gewünschten Wert zu kommen

schöne Grüße
Martin

Hallo Martin,

vielen Dank für Deine Mühe.
Mein Workaround sieht nun folgendermaßen aus:


defmod UVR1611_MODE HTTPMOD http://<user>:<pwd>#@<IP-Adresse>/menupage.cgi?page=0201581E 60
attr UVR1611_MODE DbLogExclude .*
attr UVR1611_MODE enableControlSet 1
attr UVR1611_MODE reading01Name state
attr UVR1611_MODE reading01Regex BETRIEB:&nbsp;;([a-zA-Z/_0-9]+)
attr UVR1611_MODE showBody 0
attr UVR1611_MODE stateFormat Betriebsmodus: state
attr UVR1611_MODE userReadings lastState: { OldValue($name) }

setstate UVR1611_MODE Betriebsmodus: ZEIT/AUTO
setstate UVR1611_MODE 2022-05-16 11:56:28 state ZEIT/AUTO


und Umschalten funktioniert bei meiner Definition der CAN-Bus-Variablen mit:


Standby/Frostschutz {fhem(set cmi sendDataAnalog <IP-Adresse> 10 16=64;;0)},;;
Zeit/Auto           {fhem(set cmi sendDataAnalog <IP-Adresse> 10 16=65;;0)},;;
Normal              {fhem(set cmi sendDataAnalog <IP-Adresse> 10 16=66;;0)},;;
Abgesenkt           {fhem(set cmi sendDataAnalog <IP-Adresse> 10 16=67;;0)},;;
interner_Betrieb    {fhem(set cmi sendDataAnalog <IP-Adresse> 10 16=127;;0)}



Danke Dir!

Frank

Freut mich dass du eine Lösung finden konntest und sie hier auch dokumentierst.
Danke

Hallo,

ich habe nur eine FRISTAR3WP im Einsatz, bekomme über die beiden DL-Bus PINs aber kein Signal, wenn ich es per ESP8266 abfragen möchte.
Was würde ich minimal noch benötigen, um an die 13 Werte der Frischwasserstation zu kommen (am liebsten im 5-Sekunden-Takt).

Viele Grüße
hanzoh

Zitat von: hanzoh am 20 Juli 2022, 11:18:01
Hallo,

ich habe nur eine FRISTAR3WP im Einsatz, bekomme über die beiden DL-Bus PINs aber kein Signal, wenn ich es per ESP8266 abfragen möchte.
Was würde ich minimal noch benötigen, um an die 13 Werte der Frischwasserstation zu kommen (am liebsten im 5-Sekunden-Takt).

Viele Grüße
hanzoh

Hallo hannzoh,
Sorry für die späte Antwort.

Um mit diesem Modul arbeiten zu können benötigst du das CMI.

Die hat sich einen DL Anschluss, allerdings habe ich das Modul so nie getestet.
Die Werte solltest du damit kriegen, ich weiß allerdings nicht ob das alle 5 Sekunden geht.

Hallo zusammen,

kann mir jemand sagen warum, wenn ich den COE Knoten in der CMI CAN-Bus auswähle keine Werte angezeigt werden sondern nur der Knoten error?

Zitat von: zwockel am 03 Dezember 2022, 14:26:41
kann mir jemand sagen warum, wenn ich den COE Knoten in der CMI CAN-Bus auswähle keine Werte angezeigt werden sondern nur der Knoten error?

Generell werden da nicht nur Werte gezeigt sondern es sind zb auch Eingaben möglich.

Bei CoE ist das aber nicht implementiert. Ob das garnicht geht oder einfach seitens Hersteller nicht dokumentiert ist, weiß ich nicht.
Meiner Melnung nach ist die Beschreibung FEHLER nicht richtig.
Es gibt schlicht und ergreifend keine Daten die der COE Node liefert.

War das verständlich?

Hallo,

ich versuche das Modul zu nutzen um Werte aus der CMI auszulesen.
Grundsätzlich funktioniert das aber leider sind die Werte teilweise falsch bzw. falsch formatiert.
Bei der Einheit Temperatur funktioniert es wie es soll.
Bei anderen Einheiten leider nicht.
Hier die RAW Definition des Node

defmod COE_Node_cmi_22 COE_Node 22
attr COE_Node_cmi_22 readingsConfigAnalog 1=WW_Sollwert 2=Inverter_Power 3=PV_Abdeckung 4=Stromaufnahme_NHWP
attr COE_Node_cmi_22 room COE_Node

setstate COE_Node_cmi_22 defined
setstate COE_Node_cmi_22 2023-01-08 10:46:53 Inverter_Power 4.0
setstate COE_Node_cmi_22 2023-01-08 10:41:53 PV_Abdeckung 39
setstate COE_Node_cmi_22 2023-01-08 10:47:53 Stromaufnahme_NHWP 43
setstate COE_Node_cmi_22 2023-01-07 14:15:23 WW_Sollwert 43.0
setstate COE_Node_cmi_22 2023-01-07 13:10:56 state defined
 

1=WW_Sollwert
RAW=43.0 -> korrekt

2=Inverter_Power
RAW=4.0 -> falsch -> 0.45 kW (im CMI CoE Ausgang steht 0.40 kW, das muss ich nochmal anschauen. Da stimmt dann nur das Format nicht. 0.45 kW steht im Analogausgang des NHWP-CAN-BC2. Im Analogeingang der CMI steht schon 0.40 kW)

3=PV_Abdeckung
RAW=39 -> korrekt -> 39 %

4=Stromaufnahme_NHWP
RAW=43 -> falsch -> 4,3 kWh

Ich glaube in deinem anderen Modul mit TA_JSON_CMI muss man doch bei den Readings auch die Einheit mitgeben. Könnte man das hier auch so machen?
Oder hast du ein funktionierendes StateFormat das ich einfach nutzen könnte?

Danke dir schonmal für deine Mühe. Bin echt froh das ich meine Wärmepumpe Mal ordentlich einbinden kann :)

Sind ja nur paar Schönheitsreparaturen ;)

Gruß dreitakter

Werd ich mir auf jeden Fall ansehen, ist aber grad etwas stressig, sorry.

Hi, ich weiß nicht, ob mein Post an dieser Stelle richtig ist, aber da es sich um ein Problem mit dem Modul handelt, probiere ich es hier.
Seit dem FHEM update letzte Woche (9.10.) empfange ich keine Daten über COE_Node mehr. Das senden über CanOverEthernet funktioniert einwandfrei.
Ein verbose = 5 bringt mir auch keine Daten. Gibt es eine andere Möglichkeit den Port zu überwachen?
Mein CMI scheint nicht das Problem zu sein, da ich dort einerseits Daten empfange, andererseits nichts an der Confog geändert habe.
Danke

Hallo,
es kann schon vorkommen dass FHEM-Updates zB irgendwas mit dem Code zur Behandlung von JSON machen, was dann in Einzelfällen ein Problem sein kann.
Ich werd versuchen mir die nächsten Tage mal die letzten Änderungen anzusehen

schöne Grüße
Martin

Also ich kann das Problem nicht nachvollziehen.
Alle Updates von FHEM sind gemacht und COE_Node macht was es soll, bzw. bei mir aktualisieren alle Werte sobald sie sich ändern.

Danke für die Rückmeldungen!

Ich bin gerade wieder am Testen und das Senden zum CMI funktioniert bei mir.
Der UDP Port ist offen, eine Firewall habe ich nicht dazwischen und wenn ich die COE_Nodes lösche,
dann bekomme ich Fehlermeldungen im Log:
COE_Node (COE_Node_CMICoE_2) - No config found. Please set readingsConfigAnalog accordingly.
ERROR: >COE_Node_CMICoE_2< returned by the COE_Node ParseFn is invalid, notify the module maintainer
Sobald ich diese wieder einfüge, sind die Fehlermeldungen weg, aber Werte bekomme ich keine.
Habt ihr noch weitere Ideen, wo ich suchen könnte / was es noch sein könnte?
Dank&Gruß
Florian

Zitat von: flobeewan am 15 Oktober 2023, 16:46:49Danke für die Rückmeldungen!

Ich bin gerade wieder am Testen und das Senden zum CMI funktioniert bei mir.
Der UDP Port ist offen, eine Firewall habe ich nicht dazwischen und wenn ich die COE_Nodes lösche,
dann bekomme ich Fehlermeldungen im Log:

Code Auswählen Erweitern

COE_Node (COE_Node_CMICoE_2) - No config found. Please set readingsConfigAnalog accordingly.
ERROR: >COE_Node_CMICoE_2< returned by the COE_Node ParseFn is invalid, notify the module maintainer
Sobald ich diese wieder einfüge, sind die Fehlermeldungen weg, aber Werte bekomme ich keine.
Habt ihr noch weitere Ideen, wo ich suchen könnte / was es noch sein könnte?
Dank&Gruß
Florian

Kannst du mal verbose auf 5 stellen und hier das log reinstellen?

Hi, ich habe das heute wieder getestet. Der Fehler war leider immer noch da und ich wollte das logging staten.
Davor habe ich aber nochmal alle Komponenten (CMI, Switch und FHEM) neu gestartet und siehe da, der Fehler war verschwunden.
Danke für die Rückmeldungen.
Grüße
Florian

FYI, ab CMI Firmware 1.43.1 gibt es CoE V2 mit 4 byte Datengröße (v1 2 byte) und es werden bis zu 64 digitale und analoge Werte unterstützt (vorher 32, hier ist die Dokumentation allerdings noch etwas ungenau).

https://help.ta.co.at/DE/CMIHELP/settings_cmican_print.htm