bedingtes set

[justme1968]

mit dem angehängten patch wird das set commando um eine optionale bedingung erweitert. damit lassen sich in einem einzigen set dann z.b. nur die lampen hoch dimmen die tatsächlich auch an sind oder nur die runter dimmen die heller als 50% sind. die vorgeschlagene syntax sieht so aus:

Code Auswählen Erweitern

set [bedingung] <device> <params>...die eckigen klammern müssen tatsächlich hin geschrieben werden. bedinung selber hat die form reading:regex oder ein perl ausruck in {}. wenn das erste zeichen nach der öffnenden eckigen klammer ein ! ist wird die bedingung negiert. beispiele sehen dann so aus:

Code Auswählen Erweitern

set [!state:off] TYPE=HUEDevice dimUp
set [state:off] meienLampe on-for-timer 10
set [{(ReadingsVal($DEVICE,"pct",0)>80)}] TYPE=HUEDevice dimDown

der zeite patch erweitert structure so das falls das erste argument des set eine bedinung nach obigem format ist diese bedingung an das CommandSet weitergereicht wird und so für jedes device ausgewertet wird. beispiel:

Code Auswählen Erweitern

define s structure s TYPE=HUEDevice
set s [!state:off] dimUp
set  s [{(ReadingsVal($DEVICE,"pct",0)>90)}] dimDown

die gleiche erweiterung würde ich auch noch in die lightScene einbauen.

gruss
  andre

[rudolfkoenig]

Nette Idee und kleiner Patch, ich finde sowas gehoert aber nach devspec2array, als optionaler Filter. Ich bin nur beim Syntax unsicher:

Code Auswählen Erweitern

TYPE=HUEDevice[!state:off]
TYPE=HUEDevice:[!state:off]
TYPE=HUEDevice,FILTER=!state:off

Finde z.Zt. die dritte Variante am besten. Andere Vorschlaege?

[justme1968]

die varianten mit eindeutigem zeichen am anfang und ende haben den den vorteil das sie sich sicherer parsen/erkennen lassen, auch z.b. robust gegen leerzeichen im perl ausdruck und erlauben auch die syntax zu erweitern.

wie wäre FILTER=[<bedingung>] wobei besingung reading:regex oder ein {} ausdruck mit jeweils optionalem ! davor sein kann. 

das könnte mann dann später auf mehrere solcher ausdrücke die mit & | und klammern verknüpft sind erweitern.

diese syntax mit KEYWORD=[] könnte man vielleicht auch für die attribut im define angeben idee aus dem anderen thread verwenden

[rudolfkoenig]

Habe kein Problem mit dem vorgeschlagenen Syntax.

Mit der  define / attr Geschichte habe ich aber immer noch meine Probleme, da versuchst du ein Attribut zu setzen bevor noch das Geraet definiert ist, das kann AttrFn & Co gehoerig durcheinanderbringen.

[justme1968]

ich baue den patch mal auf devspec2array  mit der vorgeschlagenen syntax um. mal sehen ob das mit dem parsen immer noch so gut hin haut wenn es nach dem device namen/devspec kommt.

eventuell wäre es einfacher das umzudrehen. also

Code Auswählen Erweitern

set FILTER=[...] devspec ...

bevor in CommandDefine die DefFn aufgerufen wird ist das gerät zumindest rudimentär da. sollte das nicht reichen? zumindest  die fälle die ich im sinn habe wie z.b. verbose zu setzen damit schon im define passend geloggt werden kann sollte doch funktionieren.

[rudolfkoenig]

Hab devspec umgebaut/erweitert.

Die schlechte Nachricht: range (Lampe1-Lampe3) wurde entfernt. Bitte mit Regexp loesen.

Die Guten:
- Der NAME=WERT Ausdruck ist jetzt allgemeiner, und sucht NAME erst als "internal", dann als reading und zum Schluss als Attribut
- Man kann auch NAME!=WERT spezifizieren
- man kann beliebig viele :FILTER=NAME=WERT dranhaengen, um die zuvor gefundene Liste zu filtern
- der Code ist etwas verstaendlicher und kuerzer geworden.
Beispiele:
  set room=kitchen:FILTER=STATE=on off
  list room=kitchen:FILTER=STATE!=off STATE

Habs dokumentiert und eingecheckt

[justme1968]

schön das du dir idee so schnell aufgegriffen hast. ich habe aber mit der aktuellen version ein paar probleme:

- die syntax erlaubt ein paar dinge und mögliche erweiterungen leider nicht mehr die im ersten vorschlag möglich gewesen sind und ich glaube sie ist anfällig für probleme beim parsen.

- es ist nicht möglich für die filter zwischen und und oder verküpfung zu wählen

- es ist nicht möglich etwas anderes als regex zu verwenden. z.b dim > 75.

-> es geht also z.b. nicht: alle lampen die an oder heller als 75% sind.

- die möglichkeit des perl ausdrucks fehlt leider auch mit der man das hätte nachrüsten können

gruss
  andre

[rudolfkoenig]

Immer diese Haar-in-der-Suppe Sucher (die aber leider auch nette Ideen haben, die ich nicht immer sofort erkenne

- "und" ist implizit, "oder" kann man haeufig per regexp | loesen. Ich weiss, es ist nicht allgemeingueltig.
- dim>75 == FILTER=STATE=(7[6789]|8x|9x|100). Ok, elegant ist anders.
- perl Ausdruck: wieso ist folgendes

Code Auswählen Erweitern

set Lampe:FILTER={ReadingsValue("Lampe","state","") eq "off"} on
besser bzw. verstaendlicher als

Code Auswählen Erweitern

{ if(ReadingsValue("Lampe","state","") eq "off") fhem("set Lampe on") }


[justme1968]

ich gebe zu ich habe in meinem posting am anfang noch nicht alles preisgegeben. manche vielleicht noch verworrenen gedanken lassen sich auch schwer in worte fassen...

- dein beispiel für und und oder bezieht sich auf eine regex bzw. werte in einem einzigen reading. ich kann aber nicht zwei unterschiedliche redings mit oder verknüpfen. ganz zu schweigen von klammer ebenen. also z.b. alle devices die entwerde state=on haben oder pct >75. oder die readinsg dim,pct und bri.

- ja. elegant ist anders und funktioniert so auch nur bei werten bei denen die obergrenze bekannt ist

- wenn der filter auf fhem ebene angegeben wird kann ich ihn auch per strucutre oder lightScene an die beteiligten devices durch reichen (siehe letztes beispiel aus dem ersten post). das geht nicht wenn ich mich auf der perl ebene bewege. gleiches gilt z.b. auch für einem readingsProxy den ich vor ein device schalte eine priorisierung mehrerer möglicher eingangs kanäle zu einem ergebniss zusammen zu schalten.

set Lampe:Filter={meinSehrKomplexerFilter()} on

es geht also weniger um das aussehen als den wechsel zwischen fhem und perl ebene die beide varianten unterscheidet.

[rudolfkoenig]

Ich sehe immer noch nicht die richtigen Beispiele, habe aber eval dazugepackt.

Geraetename wird als $NAME (oder %NAME) an die Funktion weitergegeben, und der Rueckgabewert des Ausdrucks wird ausgewertet. Beispiel (nicht wirklich sinnvoll):

Code Auswählen Erweitern

list TYPE=FS20:FILTER={Log(1,$NAME);;1}
Passt dir das so?

[justme1968]

ist es haare in der suppe suchen wenn ich $DEVICE statt $NAME vorschlagen würde?

dann ist es mit readingsGroup und readingsProxy & co konsistent. $NAME bzw $name ist dort das parent device (also z.b. die readingsGroup selber) und $DEVICE das device um das es gerade geht.

ansonsten danke!

[rudolfkoenig]

Ja, aber ich habe es eingebaut.

Und ein "Bug" gefixed: FHEMWEB setzt "room=all" ab, und ist ueberrascht, wenn room=all zurueckkommt, weil die alte Version fuer Anfragen mit "=" ein Leerstring zurueckgeliefert hat.

[justme1968]

dann noch mal danke.

zu room=all fällt mir ein das es dabei noch das problem mit longpoll gab. ich erinnere mich aber gerade nicht mehr an den stand. mir ist aber gestern erst aufgefallen das es im raum everyting nicht gegangen ist.

[justme1968]

schau mal hier: http://forum.fhem.de/index.php/topic,19092.msg127745.html#msg127745. da wird scheinbar für den | fall zu viel zurück geliefert.

gruss
  andre

[rudolfkoenig]

Hat weniger mit "|" als mit dem "." im Namen zu tun.
devspec2array prueft nach \b<Argument>\b, damit der longpoll-Filter fuer room=X bei Mehrfachraeumen (room=X,Y,Z) greift.

Was ist deine Meinung?