Einfache Angabe von Reading-Values in notify Commands

[Markus Bloch]

Hallo zusammen,

in dem Post http://forum.fhem.de/index.php/topic,27218.msg304040.html#msg304040 hatte ich einen Vorschlag zur einfachen Verwendung von Reading-Values in notify Commands gemacht. Generell würde ich es ja toll finden eine solche Möglichkeit systemweit zu schaffen. Allerdings gibt es im DOIF Modul ja bereits eine ähnliche Syntax (mit doppelten Klammern). Daher wär mein Vorschlag dies nur für notify Commands zu machen, da man sich so die ganzen Perl-Kontstrukte mit ReadingsVal spart.

Im notify-Modul wär das mit einem Einzeiler erledigt.

Die Frage hier in die Runde: Macht das Sinn?

Danke und viele Grüße

Markus

[justme1968]

ich glaube so etwas wäre recht praktisch.

eventuell ist aber [device:reading] nicht ohne probleme rückwärts kompatibel ist. vielleicht ist [[device:reading]] besser.

das könnte man in EvalSpecials einbauen, dann wäre es ziemlich notify spezifisch
oder in commandSet, dann könnte man es bei jedem fhem set verfügbar und könnte auch mit FILTER= verwendet werden
oder in AnalyzeCommand dann, wäre es im prinzip überall möglich. eventuell beisst es sich dann aber mit doif.

ich wäre mindestens für variante 2. dann kann man über devspec z.b. alle devices suchen die ein reading haben das genau einem reading eines bestimmten devices entspricht (oder nicht entspricht).

das ersetzen an sich könnte so aussehen:

Code Auswählen Erweitern

$cmd =~ s/\[\[([^\]]*):([^\]]*)\]\]/${\(ReadingsVal($1,$2,"\[$1:$2\]"))}/g;

gruss
  andre

[rudolfkoenig]

[name:reading] waere eine Idee, wenn es vom DOIF nicht besetzt waere.
[[name:reading]] ist mAn deswegen nicht optimal, weil Anfaenger, die DOIF Schnipsel sehen, verwirrt, und in ausgelagerten Funktionen nicht  klappt. DOIF implementiert mit [] auch Zeitpruefungen, damit will ich nicht anfangen.

Mein Vorschlag: ReadingsVal(.*), ReadingsNum(.*), ReadingsTimestamp(.*), InternalVal(.*), OldValue(.*), AttrVal(.*), Value() wird in FHEM-Befehlen und im Shellskripten ersetzt.

$value{x}, % und @ wird nur noch bei aktivierten Attribut (compatibility < 5.6) ersetzt.

[justme1968]

das hätte theoretisch den vorteil das es sehr einfach von einem fhem zu einem perl notify umgebaut werden könnte. praktisch aber nicht weil es mit den strings und der interpolation nicht hin haut. eventuell verwirrt das einsteiger auch?

irgendwie ist es auch nicht elegant so viel schreiben zu müssen

ist die [device:reading] variante wirklich problematisch wenn sie auf set beschränkt ist und genau so funktioniert wie in doif?

die anderen funktionen zur verfügung zu haben wäre aber tatsächlich nicht schlecht.

ich weiß. das klingt alles sehr unentschieden und wenig hilfreich...


das compatibility attribut  finde ich gut. auch wenn es vermutlich mehr als einen aufschrei geben wird. vielleicht wäre in einem ersten schritt nur eine log und motd meldung besser?

[Markus Bloch]

Hallo zusammen,

ich würde es ebenfalls begrüßen ein [device:reading] zu unterstützen, als auch die genannten Vorschläge mit den Funktionsnamen von Rudi.

Soweit ich der commandref zu DOIF entnehme, ist es nicht möglich in den Kommandos ein solches Konstrukt [device:reading] zu verwenden. Diese Syntax beschränkt sich offenbar nur auf die Expressions und sind nicht für auszuführenden Kommandos anwendbar.

Viele Grüße

Markus

[Damian]

Hallo zusammen,

ich würde es ebenfalls begrüßen ein [device:reading] zu unterstützen, als auch die genannten Vorschläge mit den Funktionsnamen von Rudi.

Soweit ich der commandref zu DOIF entnehme, ist es nicht möglich in den Kommandos ein solches Konstrukt [device:reading] zu verwenden. Diese Syntax beschränkt sich offenbar nur auf die Expressions und sind nicht für auszuführenden Kommandos anwendbar.

Viele Grüße

Markus

Die Syntax [<device>:<reading>] wird hauptsächlich in den Bedingungen von DOIF benutzt. Allerdings kann man sie bei DOIF auch im ausführenden Teil benutzen (sowohl bei FHEM-Befehlen, wie auch in Kombination mit geschweiften Klammern) z. B.

...(set <device> [<device>:<reading>])

...({fhem("set <device>  [<device<:<reading>]"})

Auch so etwas ist möglich:

... (set <device> {([<device1>:<reading1>]+[<device2>:<reading2>])})


allerdings wird nicht alles in eckigen Klammern ersetzt. Es ist eine Plausibilität eingebaut, es wird geprüft, ob die Angaben in eckigen Klammern tatsächlich ein Device bzw. Reading darstellen können.

Gruß

Damian

[justme1968]

das wäre glaube ich mit der oben vorgeschlagenen ausdruck zum ersetzen kompatibel. und wenn es das device und das reading nicht gibt bleibt der [...] ausdruck auch unverändert stehen. den [^\]] teil der regex könnte man noch etwas schärfer auf die in reading erlaubten werte einschränken. aber ich glaube das gibt im ergebnis keinen unterschied.

ich habe gestern etwas mit dieser variante in commandSet gespielt und vor allem die möglichkeit das auch in :FILTER= zu verwenden ist wirklich praktisch.

gruß
  andre

[rudolfkoenig]

andre/Damian: bin etwas verloren: soll ich die Ersetzung jetzt mit [] oder mit [[]] einbauen?

[Damian]

andre/Damian: bin etwas verloren: soll ich die Ersetzung jetzt mit [] oder mit [[]] einbauen?

Ich denke beides wird für Probleme in Verbindung mit DOIF sorgen.

[[]] wird in der Bedingung von DOIF bereits für indirekte Zeitangaben genutzt. Das dürfte für Verwirrung sorgen.

[<device>:<Reading>] funktioniert bei DOIF nur mit konkreten Angaben, also ohne regexp. [<Device>:*] führt z. Zt. bei DOIF zu einer Fehlermeldung "reading does not exist: <Device>:*"

Da müsste ich also Anpassungen in DOIF vornehmen. In der Bedingung von DOIF wird [<Device>:*] prinzipiell nicht gehen, da es in Perl übersetzt wird und dort muss es ein eindeutiger Bezeichner sein (if (a* eq "") {} macht in Perl und anderen höheren Programmiersprachen wenig Sinn).

Gruß

Damian

[justme1968]

ich hatte es gar nicht so verstanden das es auch darum geht im device oder reading namen sogar eine regex zu erlauben. es geht ja darum ein bestimmtes reading aus einem bestimmten device zu verwenden. und beides sollte genau angegeben sein.

wegen dem [[..]] konflikt mit doif würde ich doch die einfachen klammern verwenden. diese verwendung wäre dann auch identisch mit DOIF (bis auf die fehlermeldung).

der vorschlag von oben das mit

Code Auswählen Erweitern

$cmd =~ s/\[([^\]]*):([^\]]*)\]/${\(ReadingsVal($1,$2,"\[$1:$2\]"))}/g; zu lösen erlaubt auch gar keine regex. wenn es das reading im device gibt wird es verwendet, wenn nicht bleibt der [device:reading] ausdruck unverändert stehen. man könnte auch direkt eine 'no such reading...' meldung einsetzen.

gruss
  andre

[Damian]

ich hatte es gar nicht so verstanden das es auch darum geht im device oder reading namen sogar eine regex zu erlauben. es geht ja darum ein bestimmtes reading aus einem bestimmten device zu verwenden. und beides sollte genau angegeben sein.

wegen dem [[..]] konflikt mit doif würde ich doch die einfachen klammern verwenden. diese verwendung wäre dann auch identisch mit DOIF (bis auf die fehlermeldung).

der vorschlag von oben das mit

Code Auswählen Erweitern

$cmd =~ s/\[([^\]]*):([^\]]*)\]/${\(ReadingsVal($1,$2,"\[$1:$2\]"))}/g; zu lösen erlaubt auch gar keine regex. wenn es das reading im device gibt wird es verwendet, wenn nicht bleibt der [device:reading] ausdruck unverändert stehen. man könnte auch direkt eine 'no such reading...' meldung einsetzen.

gruss
  andre

Ich ging von Rudis Vorschlag aus:

Mein Vorschlag: ReadingsVal(.*), ReadingsNum(.*), ReadingsTimestamp(.*), InternalVal(.*), OldValue(.*), AttrVal(.*), Value() wird in FHEM-Befehlen und im Shellskripten ersetzt.

Gruß

Damian

[Markus Bloch]

Ich würde ebenfalls [device:Reading] nehmen. Da es ja analog zu DOIF ist, wäre das Verhalten für den User transparent. Wenn er so etwas in einem set-Befehl innerhalb von DOIF verwendet, ersetzt DOIF den Ausdruck, außerhalb von DOIF würde es dann AnalyzeCommand() machen.

Ich würde generell anregen, diese Funktionalität dann aus DOIF zu entfernen, da sie ja dann allgemeingültig in FHEM wäre. Dann gebe es keine Probleme

Gruß Markus

[Damian]

Ich würde ebenfalls [device:Reading] nehmen. Da es ja analog zu DOIF ist, wäre das Verhalten für den User transparent. Wenn er so etwas in einem set-Befehl innerhalb von DOIF verwendet, ersetzt DOIF den Ausdruck, außerhalb von DOIF würde es dann AnalyzeCommand() machen.

Ich würde generell anregen, diese Funktionalität dann aus DOIF zu entfernen, da sie ja dann allgemeingültig in FHEM wäre. Dann gebe es keine Probleme

Gruß Markus

Im Gegensatz zu

Code Auswählen Erweitern

$cmd =~ s/\[([^\]]*):([^\]]*)\]/${\(ReadingsVal($1,$2,"\[$1:$2\]"))}/g;

wird in DOIF nach Klammern geparst und auf fehlende Klammern hingewiesen. Auf diese Eigenschaft würde ich ungern verzichten, da bei DOIF viel mit Klammernhierarchie gearbeitet wird.

Gruß

Damian

[rudolfkoenig]

Damian: wuerde ein auf das set Befehl beschraenktes umwandeln von [geraet:readingname] DOIF stoeren?
Ich vermute nicht.

@Markus: [] generisch in AnalyseCommand zu ersetzen ist problematisch: DOIF erwartet vermutlich "String", set aber String.

Ich bin weiterhin bei meinem ReadingsVal Vorschlag (evtl. zusaetzlich): andre, was meinst du mit "praktisch aber nicht weil es mit den strings und der interpolation nicht hin haut" ? Alternativ koennte man im set alles, was mit {} geschrieben ist, als Perl auswerten, damit waere Readingsval als

Code Auswählen Erweitern

set bla cmd {ReadingsVal("bla", "reading")}
zu schreiben.

[Damian]

Damian: wuerde ein auf das set Befehl beschraenktes umwandeln von [geraet:readingname] DOIF stoeren?
Ich vermute nicht.

Na ja, es würde nie bei set ankommen bzw. set bla [<Device>.*:...] würde zu Fehlermeldung führen, weil regexp im Devicenamen bei DOIF, z. Zt. nicht erlaubt ist.


Gruß

Damian