Oregon Sensorempfang gleichzeitig mit sduino und RFXtrx433E Empfängern

[Burny4600]

Ich greife mal wieder ein altes Thema auf, das bei mir als noch nicht gelöst aufgefallen ist.

Ursprünglich hatte ich nur den RFXtrx433E Empfänger im Einsatz. Als noch weitere Oregon Sensoren hinzukamen benötigte ich einen weiteren Empfänger. Aus Kostengründen entschloss ich mich für den sduino.

Wie schon vor länger Zeit diskutiert, gibt es ein Problem beim gleichzeitigen Empfang mittels sduino und RFXtrx433E Empfängern.
Das Problem besteht darin, dass es für ein und demselben Sensor zwei unterschiedliche Typen ermittelt werden.
Dabei kommt es zu dem Fall, dass die Oregon Sensoren einmal unter TYPE OREGON, und ein weiteres Mal unter TYPE TRX_WEATHER versucht wird anzulegen.
Das geht natürlich nicht.

Nun wollte ich mittels autocreate dies unterbinden, und habe die Sensoren unter ignoreTypes eingetragen. (PCR800|THGR810.*|THWR800.*|UVN800.*|WGR800)
list autocreate

Code Auswählen Erweitern

Internals:
   FUUID      5c45b012-f33f-f4d2-ffa9-eaf5221cea356689
   NAME       autocreate
   NOTIFYDEV  global
   NR         69
   NTFY_ORDER 50-autocreate
   STATE      disabled
   TYPE       autocreate
   received:
     SD_BELL:
       42 464096F:
         1603111824.7324 1
       42 E8C812D:
         1603111647.21621 1
Attributes:
   device_room %TYPE
   disable    1
   filelog    /media/hdd/fhem/log01/autocreate/%NAME-%Y-%m-%W.log
   ignoreTypes (PCR800|THGR810.*|THWR800.*|UVN800.*|WGR800)
   room       _System
   weblink    1
   weblink_room Plots

Trotzdem ist das autocreate nicht vollständig deaktiviert.
Es wird zwar kein Filelog und SVG angelegt, aber dennoch erscheint zb TRX_WEATHER: Unknown device WGR800, please define it.
So, was jetzt?

Zudem wird er UV-Sensor nicht nur als unterschiedlicher Typ angelegt, sondern als unterschiedliche Sensoren.
sduino       TYPE OREGON       UVN800_1
RFXtrx433E    TYPE TRX_WEATHER     UVN800

Bei den restlichen Oregon Sensoren gibt es keinen Unterschied der Sensor-Bezeichnung.
Oregon Sensoren: PCR800, THGR810_1 bis THGR810_10, THWR800_1 bis THWR800_3, UVN800, WGR800

Ich sehe hier jedenfalls noch einen Handlungsbedarf, da es leicht wieder dazukommen kann, dass jemand ebenfalls in die gleiche Falle tappt und nicht gleich erkannt wird woran diese Eigenheit liegt.

[rudolfkoenig]

Der Name ignoreTypes ist irrefuehrend, es wird der vorgeschlagene Name des Geraetes geprueft.
Weiterhin wird (analog zu FileLog,notify,etc) der Regexp mit ^ und $ ergaenzt, automatisch generierte IDs muss man mit .* beruecksichtigen.

[KölnSolar]

Hat denn der Sensor eine Kanalnr. ?
Wenn ja, müsste das TRX_WEATHER angepasst werden. Wenn nein das OREGON-Modul.

[Sidey]

Wenn ich es Recht in Erinnerung habe,
dann ist das eigentliche Problem doch, dass ein und der gleiche Sensor von zwei logischen Modulen abgebildet wird.

Beide prüfen ob es einen Sensor in ihrem Namespace gibt bevor sie autocreate anweisen es anlegen zu lassen.

Autocreate ändert dann gewisse Definitionen
Welche exakt habe ich gerade nicht mehr im Kopf. Vermutlich filelog und den Plot.

Nunja, zumindest an diesem Beispiel zeigt sich, dass es unvorteilhaft ist, den gleichen Sensor mit mehreren logischen Modulen abzubilden.

Ich könnte im Oregon Modul womöglich eine Prüfung einbauen, ob eine Definition unter dem geplanten Namen schon verfügbar ist und im Bedarfsfall zwei zufallszeichen anhängen bis der Name verfügbar ist.
Dann hättest Du halt den einen Sensor mit zwei Namen.

Wenn allerdings der Sensor vom Typ Oregon zuerst angelegt wird und erst danach der Sensor vom Typ TRX_Weather angelegt wird, hilft dir das nichts.

Daher eher auch an Rudi gerichtet, ob er nicht eine Warnmeldung für solche Fälle in autocreate einbaut, denn lösen lässt sich das Problem heute doch durch umbenennen der zuerst angelegten Definition.

Gruß Sidey

[rudolfkoenig]

Daher eher auch an Rudi gerichtet, ob er nicht eine Warnmeldung für solche Fälle in autocreate einbaut, denn lösen lässt sich das Problem heute doch durch umbenennen der zuerst angelegten Definition.

Ich wuesste nicht, wie ein generisches Modul wie autocreate rausfinden soll, dass das gleiche Geraet von einem anderen Modul schon entdeckt wurde.
Es sei denn, die beiden Module liefern das Gleiche RAW-Format, oder erlauben per FingerprintFn einen Vergleich.

An der Stelle des Benutzers wuerde ich beide FHEM Geraete anlegen (lassen), und einen der beiden mit ignore versehen.

[Sidey]

Ich wuesste nicht, wie ein generisches Modul wie autocreate rausfinden soll, dass das gleiche Geraet von einem anderen Modul schon entdeckt wurde.

Ich hatte überlegt, dass autocreate ja prüfen könnte ob die Definition die angelegt werden soll dem gleichen oder einem anderen Modul entspricht.
`UNDEFINED <Name> <Modul> <Define-Parameter>   `

Quasi verifizieren, ob eine Definition unter dem Namen <Name> existiert und ob diese den gleichen <Type> hat wie <Modul>.
Ergibt das irgendwie Sinn?

Grüße Sidey

[rudolfkoenig]

Nö
Wenn es schon definiert ist, wieso wird dann vom gleichen Modul ein UNDEFINED generiert?

[Sidey]

Wenn es schon definiert ist, wieso wird dann vom gleichen Modul ein UNDEFINED generiert?

Nicht vom gleichen, von einem anderen Modul.

Das liegt daran, was sicherlich auch etwas schlampig ist, dass die Module nur in ihrem Namespace nachsehen ob es das Gerät schon gibt.
Und dann geben sie dem autocreate halt die Anweisung leg mal an, denn es existiert ja so gesehen im Context von einem Modul noch nicht.

Autocreate verändert halt dinge, wenn eine Definition eines anderen Typs schon existiert.
Das ist meines Erachtens dadurch nicht ganz fehlersicher und war bestimmt so auch nie gewollt. Etliche Module, müssten aber vorher prüfen ob es schon eine gleichbenannte Definition gibt und dann einen anderen Namen versuchen. Machen halt wohl die wenigsten, weil das oft abgekupfert wurde. Leider auch nicht ganz fehlerfrei.
Wäre schon fast ein Minijob für eine kleine lib


Grüße Sidey

[KölnSolar]

Bei meiner obigen Aussage war ich davon ausgegangen, dass doch der devicename(und nur dieser, also unabhängig des types)geprüft wird. Wenn also der generierte devicename gleich ist, wird auch kein 2. device angelegt(weil autocreate beim Versuch es ein 2. Mal anzulegen auf die Nase fällt).
(So meine Annahme  )

[rudolfkoenig]

@KölnSolar: wenn ein FHEM-Geraet mit diesem Namen schon existiert, dann wird kein define mehr aufgerufen, sondern das angelegte Geraet mit FileLog und SVG "ergaenzt". Das wird vom createlogs Befehl verwendet.

@Sidey: ich bin bisher davon ausgegangen, dass beim UNDEFINED Event das neue Geraetname mit dem Modulnamen anfaengt, was das UNDEFINED Event erzeugt. Damit existiert kein Missverstaendnis, und ignoreTypes tut ungefaehr das, wonach es benannt wurde. Offensichtlich lag ich falsch, ich schlage aber vor, das im Modul nachzuholen.

Ich habe jetzt die ignoreTypes Pruefung in autocreate.pm um type:name erweitert, d.h. mit (TRX_WEATHER:WGR800) wird WGR800 nur dann nicht angelegt, wenn es vom Typ TRX_WEATHER ist.

@Burny4600: auch wenn autocreate das Geraet richtig identifiziert, verhindert das die Logmeldungen nicht, die kommen vorher vom jeweiligen Modul. Ich empfehle das Geraet bei beiden Empfaenger anzulegen, und einen der beiden mit ignore zu versehen.

[Burny4600]

@rudolfkoenig

@Burny4600: auch wenn autocreate das Geraet richtig identifiziert, verhindert das die Logmeldungen nicht, die kommen vorher vom jeweiligen Modul. Ich empfehle das Geraet bei beiden Empfaenger anzulegen, und einen der beiden mit ignore zu versehen.

Mein Ziel war es zwei Empfänger zu nutzen um alle Oregon Sensoren zu erfassen.
In meinem Fall sind es leider zwei unterschiedliche Empfänger die verwendet werden.
Anhand der Signalstärke kann ich es den unterschiedlichen Empfängertypen zuweisen, und den zweiten schwächeren Sensor am jeweiligen Empfänger mit ignore definieren.
Feiner wäre es natürlich, wenn auch unterschiedliche Empfänger sich an dem gleichen Modultyp bedienen würden.
Dann würde auch nicht ständig der gleiche Sensor immer wieder versucht nochmals anzulegen.
Ich verstehe, dass es nicht so einfach ist.

[rudolfkoenig]

Feiner wäre es natürlich, wenn auch unterschiedliche Empfänger sich an dem gleichen Modultyp bedienen würden.

Das muessen die betroffenen Module selbst loesen.
Moeglich ist es, wie diverse Beispiele zeigen: FHZ1000/CUL, ZWDONGLE/ZWCUL usw.

[Sidey]

@Sidey: ich bin bisher davon ausgegangen, dass beim UNDEFINED Event das neue Geraetname mit dem Modulnamen anfaengt, was das UNDEFINED Event erzeugt. Damit existiert kein Missverstaendnis, und ignoreTypes tut ungefaehr das, wonach es benannt wurde. Offensichtlich lag ich falsch, ich schlage aber vor, das im Modul nachzuholen.

Nein. Das Verhalten ist mit vielen Modulen nachstellbar. Folgende Situation habe ich erkannt:

1. Definition mit dem Namen D1 wird durch Modul M1 nicht im Modul Namespace gefunden
2. M1 sendet einen UNDEFINED Event
3. Definition wird durch autocreate angelegt
4. Definition mit dem Namen D1 wird durch Modul M2 nicht im Modul Namespace gefunden
5. M2 sendet ein UNDEFINED Event
6. autocreate erkennt, dass es D1 bereits gibt und legt Filelog / gplot passend zu den Parametern aus M2 an.

Die Prüfung ob eine Definition im Moduleigenen Bereich angelegt wurde, erfolgt wie bei so vielen Modulen durch einen Klassiker:

Code Auswählen Erweitern


my $def = $modules{OREGON}{defptr}{"$device_name"};


Das ist nicht optimal, an vielen Stellen aber genau so gelöst. Wird da nichts gefunden, wird autocreate ausgelöst.
Für die Zukunft wäre es gut, an dieser Stelle in allen Modulen mit

Code Auswählen Erweitern

IsDevice($name, $type); zu prüfen ob da was existiert.
Haben aber viele heute nicht und wird auch sicher dauern, bis alle Entwickler von diesem Problem überhaupt erfahren.

Letztendlich würde ich gerne verstehen, wieso autocreate

Code Auswählen Erweitern

[UNDEFINED <Namensvorschlag> <Modulname> <Define-Parameter...> auf Basis des Events ein Filelog anlegt, wenn die vorhandene Definition nicht dem type aus dem Event entspricht.
Für was ist dieses Verhalten gut? Denn selbst wenn man die Module alle anpasst, weiss man doch trotzdem nie was und wie events ausgelöst werden aus sicht vom Autocreate.

[rudolfkoenig]

Nein.

Was genau Nein?

Meiner Ansicht nach ist es falsch, wenn die untershiedlichen Module M1 und M2 beide den gleichen Namen D1 vorschlagen, da autocreate dafuer keine Loesung hat. Es muss M1_D1 bzw. M2_D1 heissen.

Letztendlich würde ich gerne verstehen, wieso autocreate ... auf Basis des Events ein Filelog anlegt, wenn die vorhandene Definition nicht dem type aus dem Event entspricht.

Weil mir nicht im Traum eingefallen ist, dass unterschiedliche Module identische Geraetenamen vorschlagen (siehe oben), und der Aufruf von autocrete mit bereits existierenden Geraetenamen von createlogs verwendet wird.

[Sidey]

Hallo Rudolf,

Was genau Nein?

Das Nein bezog sich auf deine Annahme:

ich bin bisher davon ausgegangen, dass beim UNDEFINED Event das neue Geraetname mit dem Modulnamen anfaengt, was das UNDEFINED Event erzeugt

Und sollte nur ausdrücken, dass die Annahme so nicht zutrifft.

Meiner Ansicht nach ist es falsch, wenn die untershiedlichen Module M1 und M2 beide den gleichen Namen D1 vorschlagen, da autocreate dafuer keine Loesung hat. Es muss M1_D1 bzw. M2_D1 heissen.
Weil mir nicht im Traum eingefallen ist, dass unterschiedliche Module identische Geraetenamen vorschlagen (siehe oben), und der Aufruf von autocrete mit bereits existierenden Geraetenamen von createlogs verwendet wird.

Naja, besonders gut ist es vermutlich nicht, dass die Module einen Namen vorschlagen der bereits vergeben ist. Da stimme ich dir zu.
Besonders gut, ist es aus meiner Sicht aber auch nicht, dass Autocreate davon ausgeht, dass derjenige der ein Event mit einem Vorschlag schickt, den auch validiert hat.

Dass der Modulname vorangestellt werden muss ist mir bisher auch nicht bekannt, aber auch selbst das würde nicht verhindern, dass jemand Dinge in genau die Bezeichnung umbenennt die Autocreate vorgeschlagen wird.

Ich sehe ich zwei Baustellen
1) Module sollten prüfen ob der Name irgendwo in Verwendung ist.
2) Autrocreate sollte fehlertolerant arbeiten, wenn der vorgeschlagene Name bereits von einem anderen Modul in Nutzung ist.

Optional:
Festlegen, dass autocreate keinen Vorschlag sondern ein belastbare Angabe benötigt. Aber bis das mal überall angekommen und umgesetzt ist, habe wir schon mehrfach Weihnachten und Ostern gefeiert.

Grüße Sidey