Neues Modul: CanOverEthernet

delMar · 27 November 2019, 15:55:56

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

chunter1 · 27 November 2019, 16:45:40

Super, danke für die Erklärung!

chunter1 · 09 Dezember 2019, 09:34:50

Hab die UVR16x2 jetzt konfiguriert und erfolgreich am Laufen.

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.

flobeewan · 13 Dezember 2019, 16:31:14

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

Code Auswählen

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

delMar · 04 März 2020, 15:16:14

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

tomcat089 · 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

delMar · 24 März 2020, 15:47:16

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

tomcat089 · 24 März 2020, 15:53:24

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

delMar · 24 März 2020, 15:57:09

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!

tomcat089 · 24 März 2020, 17:05:17

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

delMar · 24 März 2020, 18:06:32

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

tomcat089 · 25 März 2020, 09:07:20

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

tomcat089 · 25 März 2020, 09:13:16

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.

delMar · 26 März 2020, 22:05:28

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

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