Newbie Vorschläge

[Phill]

Ja richtig war ein copy paste fehler hatte wahrscheinlich zu lange gebraucht den beitrag zu korregieren.   

[rudolfkoenig]

Ich habe jetzt

Code Auswählen Erweitern

$ret = CallFn($sdev, "AttrFn", "set", $sdev, $attrName, $attrVal);
eingecheckt. $a[0] statt $sdev waere auch gegangen, weil paar Zeilen weiter oben $a[0]=$sdev stand, ist aber irritierend.


Wegen der dokumentierten Aenderung der Attributwerte:
- bin traurig drueber, dass es dokumentiert wurde, weil AttrFn meiner Ansicht nach die Attribute nicht aendern soll. Sonst kann sich der Endanwender auf nichts mehr verlassen.
- kann jemand bitte erklaeren, wozu es sinnvoll ist?
- ist jetzt wieder moeglich (getestet)
- bis vor kurzem haette ich geschworen, dass Strings als Value an subs uebergeben werden, scheint aber nicht der Fall zu sein. Wenn jemand mich hier aufklaeren kann...

[Phill]

Ganz einfach, in Perl sind alle Funktionsübergaben immer eine Referenz.
Nur wird halt meißtens am Anfang gleich dereferenziert.

Code Auswählen Erweitern

my $deref = $_[0];

Und die Sinnhaftigkeit der Änderbarkeit, sehe ich darin, dass ja nicht nur ein Syntaxcheck sondern auch eine Syntaxkorrektur vorgenommen werden kann. Und jetzt auch die Möglichkeit besteht einen Standardwert Modulseitig zu definieren wenn nichts angegeben ist.

[Markus Bloch]

@_ ist ein Alias auf die Übergabeparameter. Das ist ein Standardfeature von Perl Subroutinen. Wenn man @_ verändert, verändert man die Variable, welche an die Subroutine übergeben wurde. In Perl 6 geht dies so direkt nicht mehr, da muss man schreibbare Parameter explizit aktivieren.

[betateilchen]

Und jetzt auch die Möglichkeit besteht einen Standardwert Modulseitig zu definieren wenn nichts angegeben ist.

Herr, schmeiß Hirn! Schmeiß meinetwegen irgendwas, aber ziele bitte gut, damit solcher Unfug irgendwann aufhört.

Sonst kann sich der Endanwender auf nichts mehr verlassen.

Seit wann kommt es denn DARAUF an?

[Phill]

Herr, schmeiß Hirn! Schmeiß meinetwegen irgendwas, aber ziele bitte gut, damit solcher Unfug irgendwann aufhört.

He, sei nett bitte. Das ist doch nur die Konsequenz daraus, dass sich am Standardwert 1 nichts mehr ändern wird. Und das ist eben nicht für jedes Modul was.

Wenn man es jetzt weiterspinnt, sollte das Attribut eigentlich nicht angelegt werden wenn die Funktion undef setzt.

[rudolfkoenig]

Ganz einfach, in Perl sind alle Funktionsübergaben immer eine Referenz.

Mag sein, aber ich kann mich daran erinnern, dass es nicht so war. Ich hatte mal explizit \$ uebergeben muessen, damit der Rechner mit meinem 300MB Strings nicht platzt.  Zugegeben, das ist schon etwas laenger her.

Das ist doch nur die Konsequenz daraus, dass sich am Standardwert 1 nichts mehr ändern wird.

Sehe ich ganz anders: das ist nur so, weil ich was Falsches angenommen habe, und der Feature dokumentiert und verwendet wird. Meiner Ansicht nach sollte man eine Fehlermeldung liefern, und nicht an dem Wert herumdoktern.

[betateilchen]

Meiner Ansicht nach sollte man eine Fehlermeldung liefern, und nicht an dem Wert herumdoktern.

Attribute gehören dem Benutzer. (diese Aussage stammt nicht von mir, sondern von Rudi!) Und der Benutzer soll sich bitte auch darum kümmern, und nicht irgendwelche undurchschaubaren Mechanismen in irgendwelchen Modulen. Das gilt für mich sowohl für automatisches Umbenennen, noch mehr aber für das "automatische" Verändern von Attributwerten oder das Zuweisen von "1" an jeder noch so sinnlosen Stelle.

Aber offenbar wird der Kreis der FHEM Entwickler, die nur noch danach streben, hier ihren Egoismus auszuleben, leider immer größer. Um die Benutzer geht es doch in den meisten Fällen überhaupt nicht mehr. Dieses Phänomen hat sich leider in den letzter Jahren immer stärker ausgeprägt. Vor drei Jahren hätte Rudi einen solchen Unfug wie jetzt hier im Thread vorgeschlagen niemals zugelassen, geschweige denn auch noch selbst umgesetzt.

Das ist der Punkt, der mich persönlich am meisten enttäuscht - inzwischen lässt sich offenbar jeder Mist in FHEM "wünschen" und die Kritikfähigkeit gegenüber solchen Änderungen ist gegen NULL gesunken. Diese persönliche Enttäuschung ist der einzige emotionale Punkt, der mich im Moment beschäftigt.

Wir - und damit meine ich ALLE Entwickler hier in FHEM - sind gerade auf dem besten Weg, FHEM zu einem für normale Anwender nicht mehr verständlichen und unbeherrschbaren Moloch zu entwickeln. Und das alles nur, um irgendwelche persönliche Ideen auf dem Rücken der Benutzer umzusetzen. Ob die Mehrzahl (!) der Benutzer davon tatsächlch irgendeinen Nutzen haben, interessiert nicht mehr sonderlich.

Gute Nacht.

[Phill]

Guten morgen,

ich kann mir nicht ankreiden lassen das ich hier irgendwelche Egoismen durchsetzen will oder mir hier irgendwas gewünscht hätte. Ich habe lediglich auf eine Unstimmigkeit hingewiesen, und war daran interessiert diese Aufzuklären. Wenn das dazu geführt hätte die Änderung zu unterbinden, hätte ich das genauso gut geheißen, denn es wäre das Resultat eines Entwicklungsprozesses und Sachlichkeit gewesen. Und daran bin ich interessiert. Nicht an rumstänkern und Unfähigkeit zu attestieren.

Ich bin auf jeden Fall bei dir wenn es darum geht Wildwuchs zu unterbinden, denn so ein großes Projekt funktioniert nicht ohne Standards und da mangelt es leider in FHEM.

Grüße

[Phill]

Ich hätte da noch eine Bitte! Und zwar ist mein Modul Talk2Fhem mittlerweile in einem echt zufriedenstellenden Stadium, und ich würde es gerne offiziell über SVN verfügbar machen. Jetzt habe ich von Rudolf König wegen der Schreibrechte die Antwort erhalten, dass sich das Modul noch ein Entwickler bezüglich Qualitätsanforderungen/Coaching anschauen soll.
Wer könnte sich dem mal annehmen?

https://forum.fhem.de/index.php?topic=80960.msg730163#msg730163

Grüße

[Markus Bloch]

Ich hab mir mal dein Modul durchgeschaut. Folgende Sachen sind mir aufgefallen:

- Das Lesen und Schreiben von Dateien (hier dein Configfile) führst du direkt via open()/close() durch. Hier bitte die Funktionen FileRead() und FileWrite() benutzen (https://wiki.fhem.de/wiki/DevelopmentModuleAPI#Daten_dauerhaft_schreiben.2Flesen).
Hintergrund: Nutzer die configDB benutzen können die Datei in ihre configDB übernehmen. Die Dateien werden dann direkt aus der configDB gelesen.

- Zeile 432 bitte ändern in:

Code Auswählen Erweitern

$hash->{helper}{phrase} = undef;
Hintergrund: Nach Möglichkeit immer mit den übergebenen Parametern direkt arbeiten, Da dies die offizielle Schnittstelle ist.

- Den Aufruf von AnalyzeCommandChain() im Rahmen von Talk2Fhem_Set bitte den Client-Hash mit übergeben:

Code Auswählen Erweitern

my $fhemres = AnalyzeCommandChain ($hash->{CL}, $fhemcmd) unless (IsDisabled($name));
Hintergrund: Nur so wird geprüft, ob der jeweilige User-Client berechtigt ist, diesen Befehl auszuführen (allowed-Definition)

- Die folgende Zeile dürfte so nicht funktionieren:

Code Auswählen Erweitern

notifyRegexpChanged($hash, join ",",@{$$hash{helper}{notifiers}});
Hintergrund: notifyRegexpChanged() wird ein notify-Ausdruck übergeben. Dies ist ein regulärer Ausdruck. Bei regulären Ausdrücken wird nicht mit einem Komma ver-ODER-t sondern mit einer Pipe. Wenn Du also eine Auflistung an Definitionsnamen hast, auf welche Du in deiner NotifyFn hören willst, müsstest du diese hier mit einer Pipe joinen.

Ansonsten würde ich dir empfehlen deinen Code nochmal sauber einzurücken, da man momentan absolut nicht erkennen kann wo welcher Block beginnt/aufhört. Das erleichtert Dir das Lesen deines eigenen Codes ungemein, wenn du ihn eine längere Zeit nicht mehr anfässt.

Viele Grüße

Markus

[Phill]

Vielen Dank für die Hinweise, habe sie berücksichtigt.

- Den Aufruf von AnalyzeCommandChain() im Rahmen von Talk2Fhem_Set bitte den Client-Hash mit übergeben:

Code Auswählen Erweitern

my $fhemres = AnalyzeCommandChain ($hash->{CL}, $fhemcmd) unless (IsDisabled($name));
Hintergrund: Nur so wird geprüft, ob der jeweilige User-Client berechtigt ist, diesen Befehl auszuführen (allowed-Definition)

Hab ich auch mal so übernommen, muss aber sagen, ich verstehe es nicht. Aus dem Development WIKI werde ich nicht wirklich schlau. Und bei ein paar Versuchen, war $hash->{CL} immer undef. Gibt es da irgendwo noch weitere Informationen zu? Ich habe nichts gefunden. Sollte hier der Verursacher des Set Befehls drin stehen? Also: FHEMWEB, telnet, usw?

Grüße
 

[Markus Bloch]

Ja genau, hier wird der Client-Hash hinterlegt, welcher den Befehl initiiert hat. Im Wiki ist das so direkt nicht beschrieben. Das kann man nur aus dem Quellcode von fhem.pl direkt entnehmen:

Code Auswählen Erweitern

sub
CommandSet($$)
{
  my ($cl, $param) = @_;
  my @a = split("[ \t][ \t]*", $param);
  return "Usage: set <name> <type-dependent-options>\n$namedef" if(int(@a)<1);

  my @rets;
  foreach my $sdev (devspec2array($a[0], $cl)) {

    $a[0] = $sdev;
    $defs{$sdev}->{CL} = $cl if($defs{$sdev});
    my $ret = DoSet(@a);
    delete $defs{$sdev}->{CL} if($defs{$sdev});
    push @rets, $ret if($ret);

  }
  return join("\n", @rets);
}