Neues Modul: CanOverEthernet

Begonnen von delMar, 19 Januar 2019, 21:29:47

Vorheriges Thema - Nächstes Thema

delMar

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
Maintainer von: ZoneMinder, TA_CMI_JSON, ONKYO_AVR, DENON_AVR, CanOverEthernet, IPCAM.

Vielgenutzte Module sind die größte Motivation für Entwickler.
Bitte zumindest 'attr global sendStatistics onUpdate' setzen.
Denn: ohne 'sendStatistics' keine Zahlen.

alpine310

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
RasPi3, HM Heizkörperthermosate, HM Fensterkontakte, HM Rolladenaktoren, HM-LED Dimmer, HM-Funktaster mit Display, Keymatic, Anbindung an Heizungsregelung SolvisControl2 mit SolvisSmartHomeServer, Anbindung an TA-UVR16x2 (für Luftkollektoren und Lüftung)

delMar

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
Maintainer von: ZoneMinder, TA_CMI_JSON, ONKYO_AVR, DENON_AVR, CanOverEthernet, IPCAM.

Vielgenutzte Module sind die größte Motivation für Entwickler.
Bitte zumindest 'attr global sendStatistics onUpdate' setzen.
Denn: ohne 'sendStatistics' keine Zahlen.

alpine310

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
RasPi3, HM Heizkörperthermosate, HM Fensterkontakte, HM Rolladenaktoren, HM-LED Dimmer, HM-Funktaster mit Display, Keymatic, Anbindung an Heizungsregelung SolvisControl2 mit SolvisSmartHomeServer, Anbindung an TA-UVR16x2 (für Luftkollektoren und Lüftung)

delMar

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
Maintainer von: ZoneMinder, TA_CMI_JSON, ONKYO_AVR, DENON_AVR, CanOverEthernet, IPCAM.

Vielgenutzte Module sind die größte Motivation für Entwickler.
Bitte zumindest 'attr global sendStatistics onUpdate' setzen.
Denn: ohne 'sendStatistics' keine Zahlen.

thor3

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
FHEM auf RPI, diverse Sensoren ESP8266 mit ESPEasy am Strom-, Gas- , Wasserzähler, Signalduino, 7 FHT Heizkörperthermostate, Jarolift Jalousien mit AutoShutter, CAN-Bus Anbindung CoE, SMA Inverter, FBDECT

delMar

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
Maintainer von: ZoneMinder, TA_CMI_JSON, ONKYO_AVR, DENON_AVR, CanOverEthernet, IPCAM.

Vielgenutzte Module sind die größte Motivation für Entwickler.
Bitte zumindest 'attr global sendStatistics onUpdate' setzen.
Denn: ohne 'sendStatistics' keine Zahlen.

skan7526

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

delMar

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
Maintainer von: ZoneMinder, TA_CMI_JSON, ONKYO_AVR, DENON_AVR, CanOverEthernet, IPCAM.

Vielgenutzte Module sind die größte Motivation für Entwickler.
Bitte zumindest 'attr global sendStatistics onUpdate' setzen.
Denn: ohne 'sendStatistics' keine Zahlen.

skan7526

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

delMar

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

Maintainer von: ZoneMinder, TA_CMI_JSON, ONKYO_AVR, DENON_AVR, CanOverEthernet, IPCAM.

Vielgenutzte Module sind die größte Motivation für Entwickler.
Bitte zumindest 'attr global sendStatistics onUpdate' setzen.
Denn: ohne 'sendStatistics' keine Zahlen.

skan7526

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

delMar

Maintainer von: ZoneMinder, TA_CMI_JSON, ONKYO_AVR, DENON_AVR, CanOverEthernet, IPCAM.

Vielgenutzte Module sind die größte Motivation für Entwickler.
Bitte zumindest 'attr global sendStatistics onUpdate' setzen.
Denn: ohne 'sendStatistics' keine Zahlen.

skan7526

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

delMar

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
Maintainer von: ZoneMinder, TA_CMI_JSON, ONKYO_AVR, DENON_AVR, CanOverEthernet, IPCAM.

Vielgenutzte Module sind die größte Motivation für Entwickler.
Bitte zumindest 'attr global sendStatistics onUpdate' setzen.
Denn: ohne 'sendStatistics' keine Zahlen.