Guten Morgen,
meine Frage bezieht sich auf folgende Aufgabenstellung.
Wenn ich ein DbRep-Device erstelle, wird es mit dem assozierten DbLog-Device verbunden (DEF) und es erscheint auch die Relation in "Probably associated with". Soweit so gut.
Welches Device mit dem DbRep anhand von Datensätzen in der DB auswerte, wird innerhalb des DbRep mit einem Attribut festegelegt, z.B. "MySTP5000".
Ich möchte nun erreichen, dass in "Probably associated with" des _ausgewerteten_ Devices (im Beispiel "MySTP5000") das DbRep mit erscheint.
Wie in der sub "getPawList" in fhem.pl zu sehen ist, könnte man explizit in dem _ausgewerteten_ Device ein Reading "associatedWith" erstellen um dieses Ziel zu erreichen.
Nun ist die eigentliche Frage, ob es denn eigentlich gewünscht ist in fremden Devices Readings zu erstellen ?
Da es diese Funktion in fhem.pl gibt, gehe ich mal davon aus.
Aber gesehen hatte ich es bisher noch nicht, glaube ich zumindest.
Danke und euch einen schönen Sonntag,
Heiko
ZitatNun ist die eigentliche Frage, ob es denn eigentlich gewünscht ist in fremden Devices Readings zu erstellen ?
Erwuenscht suggeriert was Falsches, aber manche Module wie statistics, dewpoint muessen das machen.
Wenn Du das machst, dan achte darauf, das es richtig gemacht wird, also hinzugefuegen und entfernen, und nicht einfach ueberschreiben.
Danke Rudi,
ZitatWenn Du das machst, dan achte darauf, das es richtig gemacht wird, also hinzugefuegen und entfernen, und nicht einfach ueberschreiben.
Ja, das ist mir bewusst.
Weiß nicht wie du es siehst, aber es wäre m.M. nach sinnvoll perspektivisch zwei zentrale Subs zu haben um dieses Reading konsistent modifizieren zu können, z.B. SetAssociatedWith und ModifyAssociatedWith.
Wenn mehrere Modulautoren diese Möglichkeit nutzen, kann es sonst vllt. doch mal Fehler geben. Dann weiß man nicht woher das Problem kommt und kann schlecht supporten.... nobody is perfect :)
LG,
Heiko
Wenn das in mehreren Modulen benoetigt wird, dann baue ich das ein.
Habe das Setzen des Readings versuchsweise umgesetzt. Klappt soweit gut, allerdings ist mir gleich zu Beginn mit dem sysmon-Modul untergekommen, dass z.B. dieses Modul die Readings regelmäßg löscht, zumindest verschwindet das Reading bei dem sysmon-Zyklus. Das kann bei anderen Modulen auch möglich sein. Im DbRep mache ich es technisch bedingt ebenfalls so.
D.h. ein Reading "associatedWith" zu nutzen ist vermutlich nicht optimal. Da werde ich mir etwas anderes ausdenken müssen. Nur mal als kurze Rückinfo zu diesem Thema.
Zitatallerdings ist mir gleich zu Beginn mit dem sysmon-Modul untergekommen, dass z.B. dieses Modul die Readings regelmäßg löscht
Das ist etwas kurzsichtig vom Modul, da es verhindert, dass Helfermodule ihre Arbeit verrichten.
Habe jetzt im DEF von DbRep einen Zusatz eingefügt, den ich je nach gesetzten Attribut im DbRep steuere. Damit habe ich es selbst in Hand und klappt auch einwandfrei.
Unschön ist, dass nun DEF je nach den Selektionseinstellungen des Users sehr umfangreich werden kann.
Schön wäre es, wenn die sub getPawList um die Auswertung eines {HELPER}{DEF} erweitert werden könnte.
Solltest du dafür offen sein, würde ich morgen mal einen Patch erstellen, bin zur Zeit unterwegs.
LG,
Heiko
ich bin mal direkt der Auffassung dass dies kein Reading sondern (bestenfalls) ein internal ist.
ZitatSolltest du dafür offen sein, würde ich morgen mal einen Patch erstellen, bin zur Zeit unterwegs.
Patch brauche ich nicht, aber ich verstehe auch nicht, was gewuenscht ist.
Zitatich bin mal direkt der Auffassung dass dies kein Reading sondern (bestenfalls) ein internal ist.
Was genau meinst du mit "dies"?
associatedWidth ist schon lange ein Reading, manche Module (z.Bsp MQTT2_DEVICE) kann das aus define/attr Parameter nicht ableiten, sonder nur aus der Entstehungsgeschichte (device wurde aus bridgeregexp abgeleitet).
Guten Morgen Rudi,
ZitatPatch brauche ich nicht, aber ich verstehe auch nicht, was gewuenscht ist.
Was ich meinte ist eine kleine unten mit ++ gekennzeichnete Erweiterung der sub getPawList.
sub
getPawList($)
{
my ($d) = @_;
my $h = $defs{$d};
my @dob;
foreach my $dn (sort keys %defs) {
next if(!$dn || $dn eq $d);
my $dh = $defs{$dn};
if(($dh->{DEF} && $dh->{DEF} =~ m/\b$d\b/) ||
($h->{DEF} && $h->{DEF} =~ m/\b$dn\b/)) {
push(@dob, $dn);
}
++ if(($dh->{HELPER}{PAW} && $dh->{HELPER}{PAW} =~ m/\b$d\b/) ||
++ ($h->{HELPER}{PAW} && $h->{HELPER}{PAW} =~ m/\b$dn\b/)) {
++ push(@dob, $dn);
++ }
}
my $aw = ReadingsVal($d, "associatedWith", ""); # Explicit link
push(@dob, grep { $defs{$_} } split("[ ,]",$aw)) if($aw);
return @dob;
}Dadurch hat man die Gestaltung im eigenen Modul in der Hand, braucht nichts in anderen Devices zu setzen, muss nicht das eigene DEF "missbrauchen" und es stört auch nirgends wenn die Liste sehr lang werden wird.
Habe es bei mir getestet. Funktioniert einwandfrei so wie ich es mir vorstelle und ich würde mich freuen wenn du es übernehmen würdest.
Danke und einen schönen Sonntag,
Heiko
Ich will nicht mit {HELPER} in fhem.pl anfangen, fand die Idee schon immer merkwuerdig.
Was spricht gegen das Pruefen der associatedWith Reading?
ZitatWas spricht gegen das Pruefen der associatedWith Reading?
Setzen in dem assoziierten Device ist aus den schon beschriebenen Gründen ungünstig. Man hat es nicht wirklich in der Hand.
Im eigenen Device wäre es kein Problem, wobei die Usability wegen dem u.U. zu erwartenden Umfang nicht gut ist.
Würdest du denn mitgehen, ein verstecktes ".associatedWith" mit zu rüfen ?
Die sub wäre dann z.B.:
sub
getPawList($)
{
my ($d) = @_;
my $h = $defs{$d};
my @dob;
foreach my $dn (sort keys %defs) {
next if(!$dn || $dn eq $d);
my $dh = $defs{$dn};
if(($dh->{DEF} && $dh->{DEF} =~ m/\b$d\b/) ||
($h->{DEF} && $h->{DEF} =~ m/\b$dn\b/)) {
push(@dob, $dn);
}
}
my $aw = ReadingsVal($d, "associatedWith", ""); # Explicit link
push(@dob, grep { $defs{$_} } split("[ ,]",$aw)) if($aw);
++ $aw = ReadingsVal($d, ".associatedWith", ""); # Explicit link
++ push(@dob, grep { $defs{$_} } split("[ ,]",$aw)) if($aw);
return @dob;
}
Damit wäre das Ziel ebenfalls erreicht denke ich.
ZitatSetzen in dem assoziierten Device ist aus den schon beschriebenen Gründen ungünstig. Man hat es nicht wirklich in der Hand.
Aus dem gleichen Grund ist ein {HELPER} auch nicht besser.
ZitatWürdest du denn mitgehen, ein verstecktes ".associatedWith" mit zu rüfen ?
Soweit ich sehe, ist damit dein Ziel:
ZitatIch möchte nun erreichen, dass in "Probably associated with" des _ausgewerteten_ Devices (im Beispiel "MySTP5000") das DbRep mit erscheint.
damit aber nicht erreicht, es verkuerzt hoechstens die DBRep Detailansicht.
Dieser Wert muss in der Schleife geprueft werden.
Zitatdamit aber nicht erreicht, es verkuerzt hoechstens die DBRep Detailansicht.
Dieser Wert muss in der Schleife geprueft werden.
Ah ja, stimmt natürlich :)
Ich gehe nochmal in mich und teste etwas ...
Jetzt habe ich es, denke ich. Nach einigem Testen und suchen der besten Variante ist es wohl am einfachsten die if-Bedingung in der Schleife so zu erweitern:
sub
getPawList($)
{
my ($d) = @_;
my $h = $defs{$d};
my @dob;
my $aw;
foreach my $dn (sort keys %defs) {
next if(!$dn || $dn eq $d);
my $dh = $defs{$dn};
if(($dh->{DEF} && $dh->{DEF} =~ m/\b$d\b/) ||
++ ($dh && ReadingsVal($dn, ".associatedWith", "") =~ m/\b$d\b/) ||
($h->{DEF} && $h->{DEF} =~ m/\b$dn\b/) ||
++ ($h && ReadingsVal($d, ".associatedWith", "") =~ m/\b$dn\b/)) {
push(@dob, $dn);
}
}
$aw = ReadingsVal($d, "associatedWith", ""); # Explicit link
push(@dob, grep { $defs{$_} } split("[ ,]",$aw)) if($aw);
return @dob;
}
Habe es bei mir durchgetestet und klappt wie gewünscht. Und zerstört nicht die Ansicht bei entsprechendem Umfang. :D
ZitatUnd zerstört nicht die Ansicht bei entsprechendem Umfang.
Waere es schlimm, wenn es tut?
Will mehrfache Definitionen, soweit moeglich, vermeiden.
ZitatWaere es schlimm, wenn es tut?
Naja, kann wirklich sehr umfangreich werden je nach der Selektionsbedingung des Users die nicht vorauszusehen sind.
Ein "schlimm" ist ja wie immer auch Ansichtssache des Users und abhängig von seinen persönlichen Einstellungen, Nutzungsverhalten und Ansichten.
Dann kommt dann wohl recht schnell die Frage ob man es denn nicht verstecken könnte.
Ich hatte in meinem Vorschlag extra das versteckte Reading genauso genannt wie das "öffentliche". Damit wäre m.M. die Assoziation zum Verwendungszweck gewahrt.
Ich verstehe deine Ansicht, finde es andererseits auch nicht so dramatisch das .associatedWith zusätzlich zu verwenden, da ein Blick in die Sub ja genügt um die Möglichkeiten zu erkennen.
Würde mich wirklich freuen, wenn du die Erweiterung wohlwollend übernehmen könntest. :)
Habs mit leichter Aenderung uebernommen, bitte pruefen.
Herzlichen Dank Rudi.
Mache ich heute Abend wenn ich wieder zu Hause bin.
Grüße,
Heiko
Habe es getestet und funktioniert wunderbar. Jetzt kann ich die Assoziationen implementieren.
Danke !
Grüße,
Heiko