Einfache Angabe von Reading-Values in notify Commands

viegener · 09 Februar 2016, 23:26:22

@betateilchen: ich erkläre es gerne: Es geht nicht darum die Funktion zu finden, sondern zu wissen, welche Funktion in API und Semantik stabil bleibt. Ich gehe davon aus, dass in fhem.pl offizell nutzbare Funktionen sind, die auch im API einigermassen stabil bleiben, da sie in anderen Modulen verwendet werden und auch interne Hilfsfunktionen, die einfach zur Modularisierung verwendet werden und sich auch mal ohen Ankündigung ändern. Da Rudi die Funktionen grundsätzlich relativ sprechend benennt, ist manchmal nicht klar, was offiziell ist und was "intern" ist.

@Rudi: Anpassen will ich ReplaceSetMagic gar nicht, ich bin nur ein fauler Programmierer und bin über deshalb auf die Funktion gestolpert. Die macht eigentlich viel mehr als ich momentan brauche aber Stand heute keine Erweiterung und Ja eigentlich implementiere ich Teile von PHP nach

Und klar, mir ging es auch nicht darum Dich aufzufordern, sondern nach Interesse bei anderen zu fragen. Deine Hilfe wäre im wesentlichen da wichtig zu klären ob etwas zum "offiziellen" Modul API gehört.

viegener · 10 Februar 2016, 00:32:15

OK, Ich habe mal angefangen: http://www.fhemwiki.de/wiki/DevelopmentModuleAPI

Kommentare, Erweiterungen, Feedback wie immer willkommen,
Johannes

betateilchen · 10 Februar 2016, 08:10:01

Zitat von: viegener am 10 Februar 2016, 00:32:15
OK, Ich habe mal angefangen:

Deine Bemühungen in allen Ehren, aber ich halte das Vorhaben nach wie vor für sinnlos.

Einer der größten Vorteile von fhem ist es doch gerade, dass eben nichts so in Stein gemeißelt ist, wie es für ein echtes API erforderlich wäre.
Wenn ich eine bestimmte Funktionalität brauche und die Vermutung habe, dass es dazu etwas in der fhem.pl geben könnte, werde ich immer in die fhem.pl schauen, denn dort ist der aktuelle Stand. Was im Wiki steht, kann einen Tag später veraltet sein und es gibt eine große Anzahl von Wiki Beiträgen, die definitiv veraltet sind und von niemandem mehr gepflegt werden. Und "Unsinn", der irgendwann mal ins Wiki geschrieben wurde, zieht sich oft noch über Monate (Jahre) als gefährliches Halbwissen durchs Forum - immer mit der Rechtfertigung "aber es steht doch so im Wiki". Das ist einer der Hauptgründe, warum ich beispielsweise für meine Module keine Wiki-Beiträge schreibe und auch nie begeistert bin, wenn es jemand anderes tut.

rudolfkoenig · 15 Februar 2016, 18:17:24

Die Frage reduziert sich fuer mich auf: "was ist besser: potentiell veraltete Doku oder gar kein Doku".

betateilchen hat zwar grundsaetzlich Recht, allerdings gibt es auch FHEM Modul-Entwickler, die nicht in der Lage sind, alle Aspekte von (gewachsenen) Perl Code zu verstehen oder nicht gewillt sind, die dafuer noetige Zeit zu investieren. Fuer diese Leute ist potentiell veraltetete Doku besser, fuer die anderen (wie betateilchen oder mich) kein Doku.

Mein Vorschlag: ins Wiki-Artikel gehoert vorne ein Hinweis, dass im Zweifel der perl-Code zu konsultieren ist, und wer Probleme feststellt, der moege sie melden. Und generell ist die Bemuehung, die Sachen zu dokumentieren, lobenswert.

viegener · 15 Februar 2016, 21:37:07

@ph1959de: Da warst Du schneller als ich, so stelle ich mir wiki for

@Rudi: Macht Sinn das Hinzuzufügen und die Intention ist für mich auch nicht das Konsultieren von Code zu ersetzen sondern das Lesen zu vereinfachen

Vielleicht noch wichtiger: Einen Hinweis zu geben, was verwendet werden kann (weniger Codeduplizierung, mehr Einheitlichkeit und schnellerer Einstieg für Entwickler). Mir hätte es geholfen, obwohl ich gefühlt seit Äonen Code anderer Leute lese und auch in Programmiersprachen die heute mit Recht nicht mehr so gebräuchlich sind

Also schonmal Dank an alle die beitragen...

Loredo · 02 April 2017, 18:03:56

Wäre es denkbar ReplaceSetMagic() dahingehend zu erweitern, dass auch INTERNALs und Attribute damit abgefragt werden können?

Anbei ein Patch als Vorschlag.

Gruß
Julian

rudolfkoenig · 03 April 2017, 10:39:22

1. Doku fehlt

2. da es mehr als 10 Zeilen betrifft: ich baue die Aenderung erst ein, falls sonst noch jemand Interesse bekundet.

viegener · 03 April 2017, 11:04:58

Ich würde auch Interesse bekunden, da ich ReplaceSetMagic intensiv sowohl für TelegramBot verwende als auch im Servermodul für das Tablet UI (FTUISRV). Man kann sich zwar heute behelfen durch den Wechsel auf die perl-Ebene, das erzeugt aber häufig Klammerorgien und schwer lesbare Konstrukte.

Ich fände es gut, wenn es zumindest auch etwas Einheitlichkeit bringen würde, damit die Syntax mit IF identisch wäre?

rudolfkoenig · 03 April 2017, 11:07:05

ZitatIch fände es gut, wenn es zumindest auch etwas Einheitlichkeit bringen würde, damit die Syntax mit IF identisch wäre?

Kanns bitte jemand bestaetigen, dass id/di/ad/da kompatibel zu IF ist?

Loredo · 03 April 2017, 13:41:21

Das konnte ich aus der DOIF CommandRef leider auch nicht in Erfahrung bringen. Mir war so als wenn es da früher einmal ähnliche Optionen gab (mir ist was in Erinnerung mit "&" am Ende, um ein Internal statt ein Reading abzufragen), aber diese Information konnte ich nirgends finden.

Einen Patch für die set-Befehl Doku liefere ich dann gerne nach

justme1968 · 03 April 2017, 13:45:46

das verhalten von list sollte man auch im hinterkopf behalten.

list verendet i: r: und a: vor dem reading/attribut/internal namen. ohne angabe werden alle drei in dieser reihenfolge durchsucht, mit angabe jeweils nur das angegebene.

wenn die anderen kommandos den selektor an den namen anhängen sollte man list vielleicht auch umstellen/erweitern.

Loredo · 04 April 2017, 07:55:34

Ich habe mich etwas im DOIF Quellcode umgesehen; die einzige Übereinstimmung ist offenbar das bisherige :d für die Extraktion der 1. Dezimalzahl aus einem Reading.
Für INTERNALs wird am Beginn(!) des Readingnamen ein & erwartet, Attribute lassen sich gar nicht abfragen und für beides gibt es keine Dezimalzahl Extraktion.

Es gibt hier also keine Konsistenz/Kompatibilität zum list Befehl in DOIF.
Ich denke es macht hier Sinn, dass ReplaceSetMagic() weitestgehend zum list Befehl kompatibel ist und die Art der Quelle als Präfix führt und die zusätzliche Beschränkung auf die erste Zahl wie bisher als Suffix. Allerdings sehe ich es eher als kritisch an, wenn das aktuelle Verhalten dahingehend ersetzt wird, dass bei keiner Angabe alle 3 Quellen nacheinander durchgegangen werden. Ich würde r: zwar explizit einbauen, das weglassen von selbigem sollte aber auch aus Performancegründen ebenfalls nur nach einem Reading suchen wie bisher auch.

viegener · 04 April 2017, 14:11:53

Zitat von: Loredo am 04 April 2017, 07:55:34
Ich habe mich etwas im DOIF Quellcode umgesehen; die einzige Übereinstimmung ist offenbar das bisherige :d für die Extraktion der 1. Dezimalzahl aus einem Reading.
Für INTERNALs wird am Beginn(!) des Readingnamen ein & erwartet, Attribute lassen sich gar nicht abfragen und für beides gibt es keine Dezimalzahl Extraktion.

Es gibt hier also keine Konsistenz/Kompatibilität zum list Befehl in DOIF.

ich frage mich,ob es nicht ein guter Ansatz wäre mehr Konsistenz zu erreichen, und list, set, IF und DOIF, etc zu versuchen die gleiche Syntax zu verpassen. Zweiheitlichkeit oder gar Dreiheitlichkeit anstatt Einheitlichkeit ist für mich nicht wirklich eine Lösung im Sinne der Benutzer (und zwar erfahrene und unerfahrene Benutzer gleichermassen)

Loredo · 04 April 2017, 14:20:58

Ich habe den Patch nun angepasst.

Man kann r:, a:, i: als Präfix sowohl beim Device Namen als auch beim Readingnamen verwenden. Um mit DOIF kompatibel zu sein, kann man auch & statt i: verwenden.

Der bisherige Suffix :d wird so auch von DOIF unterstützt und verwendet.
Ich habe den Suffix noch dahingehend erweitert, dass man auch :i oder :r oder :r[0-9]+ verwenden kann, um die Zahl gleichzeitig noch in einen Integer zu wandeln oder runden zu lassen.

ReadingsNum() ist dahingehend optimiert, dass nun tatsächlich nur der erste Zahlenwert eines Strings zurückgegeben wird (so wie zumindest zuvor in der englischen Doku beschrieben; die deutsche Doku wich davon ab, war aber präziser was das alte Verhalten angeht einfach alles wegzuschmeißen, was keiner Zahl entspricht). Dies stimmt jetzt mit dem Verhalten von DOIF überein, was vorher nicht der Fall war.

AttrNum() und InternalNum() sind als neue Funktionen hinzugekommen.
Alle 3 *Num() Funktionen haben einen 4. optionalen Parameter erhalten, um darüber ebenfalls den Wert als Integer bzw. gerundeten Wert zurückgeben zu lassen.

Ich habe alles auf deutsch und englisch dokumentiert und die Patches ebenfalls angefügt.
Dabei habe ich auch fehlende Doku zu ReadingsAge() hinzugefügt, die Formatierung angeglichen und die Beispiele korrigiert.

rudolfkoenig · 04 April 2017, 16:51:16

Ich bin erschlagen vom Patch, sowohl vom vorne/mitten/hinten Platzierbarkeit der Optionen, wie von den verschiedenen Rundungsparameter (:i, :d, :r0). Dass man & _und_ i: verwenden kann, finde ich verwirrend. Ich habe die Befuerchtung, dass ich das so nicht supporten kann.

Ich habe jetzt eine kleinere Version eingecheckt, die genauso wie der devspec Filter arbeitet, also mit optionalen a:, r: oder i:, liefert aber den erstbesten zureck, falls kein Praefix spezifiziert ist. Immerhin ist damit die urspruengliche Forderung auch erfuellt.

Danke fuer die Doku fuer ReadingsTimestamp und ReadingsAge, habs uebernommen.