Neues Modul: CanOverEthernet

[delMar]

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

[delMar]

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/ steht:

Sobald 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

[delMar]

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

[mannebk]

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

[delMar]

Hi Manne,

danke für dein Feedback.

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)

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.

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.

wunderground

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

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

[thhoe]

Hallo Martin,

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

[thhoe]

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

[delMar]

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

[mannebk]

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

Das Skript ist im Anhang.
Thomas

Auch dir Danke!

Gruß Manne

[delMar]

Falls das in meinem Posting anders rüberkam

Nö, isses nich

[cobra112]

Hi

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

MFG
Cobra

[delMar]

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

[delMar]

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

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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

[cobra112]

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

[delMar]

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:

Code Auswählen Erweitern


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