Closed HomeAutoUser closed 3 years ago
Die Lösung steckt in getPawList
.
Diese schaute im DEF oder in einem Reading .associatedWith
nach.
Sobald man das Reading .associatedWith
mit einem Wert setzt, so taucht dieser auch in der Liste "Probably associated with" auf.
Ich habe das Problem mit https://github.com/fhem/Timer/commit/685a6f49d51e0e817e1f2760ea8dda47481672fe gefixt.
So richtig gefixt ist das aber noch nicht. Wenn ich Timer lösche, bleibt der Zusammenhang bestehen. Müsste also wieder gelöscht werden. Vermutlich werden die Readings auch nicht angelegt, wenn ich die Timerliste aus der Datei lade (nicht getestet), da ja dabei der Save-Button auch nicht betätigt wird.
Ich bin noch nicht dahinter gekommen, auf welchem Weg das bei anderen Modulen automatisch funktioniert. Wenn ich alle Module nach "associatedWith" durchsuche, finde ich gerade mal 5 mit diesem Suchbegriff. Es muss da wohl noch eine andere Variante geben.
Mist, das löschen, da wurde ich abgehalten weil das Essen klingelte.
Du hast recht. Das muss noch ergänzt werden.
Ich bin noch nicht dahinter gekommen, auf welchem Weg das bei anderen Modulen automatisch funktioniert. Wenn ich alle Module nach "associatedWith" durchsuche, finde ich gerade mal 5 mit diesem Suchbegriff. Es muss da wohl noch eine andere Variante geben.
Andere Module verwalten es teilweise selbst so wie ich das Reading selbst setze oder die Funktion welche die Verknüpfung selbst aufbaut. Dies geschieht aber nur, wenn solch ein Device im DEF ergänzt wird.
Edit: Beim so drüber nach denken, habe ich nen Codeumbau im Kopf weil man an 2 Positionen die Liste prüfen / ändern muss und an einer die Liste entfernen bzw. verringern muss wenn man einen Timer löscht. Das Gerüst habe ich im Kopf schon.
@elektron-bbs bitte mal testen. Branch: https://github.com/fhem/Timer/tree/pre-release
Ich habe vorerst keinen Fehler gefunden. Die eigene Verwaltung der Liste ist gang und Gebe wenn programmintern die zu verknüpfenden Geräte nicht im Internal DEF fündig sind.
Naja, von "gang und gäbe" kann bei 5 Modulen von ca. 600 wohl keine Rede sein :-)
Da ja die Verknüpfung bei Timern mit "DEF" sowieso noch nicht funktioniert, habe ich die sub Timer_PawList mal angepasst:
sub Timer_PawList($) {
my ($hash) = @_;
my $name = $hash->{NAME};
my $associatedWith = "";
Log3 $name, 5, "$name: Timer_PawList is running";
foreach my $d (keys %{$hash->{READINGS}}) {
if ($d =~ /^Timer_(\d+)$/) {
my @values = split("," , ReadingsVal($name, $d, ""));
if (not grep /$values[6]/, $associatedWith) {
$associatedWith = $associatedWith eq "" ? $values[6] : $associatedWith.",".$values[6];
}
}
}
Log3 $name, 5, "$name: Timer_PawList | Reading .associatedWith is: ".$associatedWith;
if ($associatedWith ne "") {
CommandSetReading(undef, "$name .associatedWith $associatedWith");
} else {
readingsDelete($hash,".associatedWith") if(ReadingsVal($name, ".associatedWith", undef));
}
}
Dadurch werden auch diese Timer, sofern deren Bezeichnung zu einem Device passt, auch mit aufgenommen.
Ansonsten könnte man es sicher auch noch vereinfachen, indem man bei save-button gezielt das eine Reading setzt und bei delete halt genau eines löscht. Das erspart jedesmal das Durchsuchen aller Readings.
Hattest du das https://github.com/fhem/Timer/commit/27dd1e7e46773d70be9e1d886367ad2401214f14 als Basis genommen?
Ich denke schon. Ich habe https://raw.githubusercontent.com/fhem/Timer/pre-release/controls_Timer.txt in der update list.
@elektron-bbs Leider berücksichtigt deine Variante nich alle Devices.
Schau mal meine Variante, dort werden auch die Devices aus dem Reading geholt wenn DEF eingestellt wurde unter dem Vorbehalt von "set" und "get" in dem Feld.
Eigenartig, jetzt funktioniert das hier auch??? Der einzige Unterschied ist ja eigentlich, das du das "sort" noch entfernt hast.
Hallo, lasse dich bitte nicht täuschen.
Diese Anpassung https://github.com/fhem/Timer/commit/27dd1e7e46773d70be9e1d886367ad2401214f14 worauf du getestet hattest ging nur eingeschränkt. Darauf hin hast du die Vereinfachung https://github.com/fhem/Timer/issues/8#issuecomment-577857923 vorgeschlagen.
Da aber dort der Fix noch nicht behoben war, wurde hier https://github.com/fhem/Timer/commit/874aa2f410d8ba0976543c009c2f164d48aac409 es korrigiert von mir. Der Sort Commit kam danach. Deswegen geht es nun mit der Version. Ich legte eine Version zum testen als Grundlage mit einem Bug, daher dieses Missverständnis.
Ach so, das erklärt es.
Mir fiel eben noch auf, das die Liste auch bei Änderungen der Attribute Timer_xx_set aktualisiert werden muss.
sub Timer_Attr() {
my ($cmd, $name, $attrName, $attrValue) = @_;
my $hash = $defs{$name};
my $typ = $hash->{TYPE};
if ($cmd eq "set" && $init_done == 1 ) {
Log3 $name, 5, "$name: Attr | set $attrName to $attrValue";
if ($attrName eq "disable") {
if ($attrValue eq "1") {
readingsSingleUpdate($hash, "internalTimer" , "stop",1);
RemoveInternalTimer($hash, "Timer_Check");
} elsif ($attrValue eq "0") {
Timer_Check($hash);
}
}
if ($attrName =~ /^Timer_\d{2}_set$/) {
my $err = perlSyntaxCheck($attrValue, ()); # check PERL Code
return $err if($err);
Timer_PawList($hash); # list, Probably associated with
}
}
if ($cmd eq "del") {
Log3 $name, 3, "$name: Attr | Attributes $attrName deleted";
if ($attrName eq "disable") {
Timer_Check($hash);
}
if ($attrName eq "userattr") {
if (defined AttrVal($FW_wname, "confirmDelete", undef) && AttrVal($FW_wname, "confirmDelete", undef) == 0) {
$cnt_attr_userattr++;
return "Please execute again if you want to force the attribute to delete!" if ($cnt_attr_userattr == 1);
$cnt_attr_userattr = 0;
}
}
if ($attrName =~ /^Timer_\d{2}_set$/) {
Log3 $name, 3, "$name: Attr | Attributes $attrName deleted";
Timer_PawList($hash); # list, Probably associated with
}
}
}
So richtig sicher bin ich mir aber bei der Funktion noch nicht. Mal wurde die Liste aktualisiert und beim nächsten Mal auch wieder nicht.
Kann man den Fall rekonstruieren wenn es nicht angepasst wird?
Es scheint, als ob "Probably associated with" immer einen Schritt hinterher hinkt:
Ich vermute, das Attribut wird erst gelöscht, nachdem die sub Timer_Attr abgearbeitet wurde.
Komisch. Normalerweise ist der Zugriff als letztes immer eingetragen.
@elektron-bbs mir kommt ggf eine Idee welche man mal versuchen sollte.
Den Aufruf der sub mal verzögern um 1 Sekunde. Nicht das wir die Sun abarbeiten und dann zurück springen und dann den normalen Programmablauf fortsetzen.
@elektron-bbs bitte noch einmal testen. Wenn du das Attribut gelöscht hast, kann es maximal mal passieren, das du ein Browserrefresh benötigst für die aktuelle Liste. Hier "hingte" es nun nicht mehr hinterher.
Das scheint jetzt beim Löschen des Attributes zu funktionieren. Damit es auch bei Änderungen anschlägt, müsste noch bei set eine Zeile ergänzt werden:
if ($attrName =~ /^Timer_\d{2}_set$/) {
my $err = perlSyntaxCheck($attrValue, ()); # check PERL Code
InternalTimer(gettimeofday()+0.1, "Timer_PawList", $hash);
return $err if($err);
}
Pefekt, so dachte ich mir das auch. Ich habe die Zeile ergänzt.
Forum https://forum.fhem.de/index.php/topic,103986.msg1015549.html#msg1015549
test with list -R
all links from Devices or Logfile must in list